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.
“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.
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.
Building blocks of Web Components are:
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:
npm install @material/mwc-slider
<script type="module"> </script> <mwc-slider value="25" min="10" max="50"></mwc-slider>
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).
No issue with that: you can just build your custom Web Component. Look at next section!
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.
The Parking widget is a simple, light and framework-less web-component (HTML
It can be added to the DOM:
Initialization is simple, via two properties:
modelis the JSON definition (e.g.
src/assets/model.json), used to fill and render all widget dynamic areas.
onSelectionCallbackis 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.
Can be represented as below:
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.
Did you like this article? Consider becoming a Patron!