Whenever you adopt a framework, you must take in account that you are locking your project into an already defined road-map, that probably has been defined by a third party company/development team.
Frameworks can “die”. The community could move to another technology or a new tool. But things can get worse: a security issue gets found on a framework that is no more maintained.
Adopting a framework, you are also adopting a risk: your project is going to be legacy sooner or later. This is disruptive, especially in an enterprise scenario.

Frameworkless Movement

“The Frameworkless Movement is a group of developers interested in developing applications without frameworks. We don't hate frameworks, nor we will ever create campaigns against frameworks, but we perceive the misuse of frameworks as a lack of knowledge regarding technical debt and the availability of alternatives given by the vanilla language or by dedicated libraries.” - http://frameworklessmovement.org
This movement does not think that frameworks are evil.
Let’s start from a simple principle: if you are able to code without a framework, you are also able to decide whenever to use or not to use them. This decision is based on the knowledge of strengths and weaknesses of the framework itself.
Have you ever asked how a particular framework acts behind the scenes? For example, how IoC (Inversion of Control), in the popular Spring framework, works?
Have you ever tried to build your home-made i18n service?
Do I really need to adopt Angular framework, just because I need client-side routing in my Single Page Application?
If I adopt VueJS, just because it is a growing trend, are my colleagues ready to leverage it?
When this kind of questions come to mind, you are starting to think of frameworks in a critical way.

Web Components - a brief introduction

The goal of this section is not to give you a full overview about Web Components. There are a lot of resources in the web that you can rely on. We just need some basic concepts to understand the next proof of concept.

What is a Web Component?

“Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.” - https://www.webcomponents.org
Building blocks of Web Components are:

• Custom Elements: custom defined types of DOM elements (you can create a new HTML tag).
• Shadow DOM: encapsulation of style and markup in a Web Component (you have an isolated DOM structure).
• ES Modules: reusable JS modules (you don’t have to use third party libraries such as SystemJS or requireJS).
• HTML Template: fragment of markup that could be dynamically loaded (you can exploit a lazy loading strategy).

How can I use a Web Component?

There are several ready-to-use components, provided for example by the Polymer library (https://www.polymer-project.org/).
The good news is that you don’t need to adopt an entire framework, to use a particular component.
For example, if I want to use a slider that follows Material Design (https://material.io/design/components/sliders.html), I just need to:

1. Install it: npm install @material/mwc-slider

2. Include in my page:
   
   import '@material/mwc-slider';
   

   <mwc-slider value="25" min="10" max="50"></mwc-slider>
   

3. Et voilà:
   

Can I customize a ready-to-use Web Component?

If such Web Component is well designed, the answer is definitely yes.
For instance, if you don’t like the style, or you need to listen to the change event of the slider defined above, you just need to look at its APIs (https://github.com/material-components/material-components-web-components/tree/master/packages/slider).

Ok, but the Web Component in my mind does not exist.

No issue with that: you can just build your custom Web Component. Look at next section!

Parking Widget - A Frameworkless, custom and reusable HTML element

In scenarios where I need a Web Component that is highly customizable, and near to my business requirements, you can also define a coarse grain component.
In that proof of concept (https://github.com/vpellegrino/parking-widget) I show how to realize an interesting UI widget, without using any framework (VanillaJS).
The requirement was to realize a widget to show a collection of parking slots and let the user buy one. Such widget should be easily embedded in any Web application.

Technical Details

The Parking widget is a simple, light and framework-less web-component (HTML CustomElement).
It can be added to the DOM:

<parking-widget id="my-parking-widget"></parking-widget>

Initialization is simple, via two properties:

1. model is the JSON definition (e.g. src/assets/model.json), used to fill and render all widget dynamic areas.
2. onSelectionCallback is the function provided to the widget that will be called each time a parking slot selection takes place. That function is expecting one argument: the object related to the selected parking slot.

Communication mechanism

Can be represented as below:

Conclusion

In a well designed architecture, business logic should be separated by the specific project configuration or framework usage.
How many times you, as developer, are making estimations based on a particular framework? It does not make sense!
Functional requirements like budget, usability, domain-specific constraints should guide architectural choice and hence estimations.
And remember: you don't need a framework to build a good web application.