Are frameworks necessary in 2019?

Toronto Skyline — Kemal Ahmed


For 5ish years, Google has been working on making Web Components a standard in browsers in an attempt to remove the need for frameworks. For the most part they’ve been successful at it.

To supplement the slow progress, they’ve come out with a polyfill library, Polymer and more recently, a ubiquitous JSX alternative, LitHTML. Their newer libraries are pure Javascript and aim to simply polyfill the missing web components features, while reducing verbosity of using web components without libraries.

It can be a hard concept for new developers who would prefer an HTML-based layout like in Vue, which is why the first push of web components spec was for the ability to bring custom elements into the web page through HTML imports. This eventually fell apart in favour of es6 modules.

Starter Kits

One of the most important things in setting up a framework or API is prototyping speed. As a result, many frameworks come with opinionated pre-built applications to use as a shell that get you up and running quickly with pre-built webpack configs, typescript, lints, state managers, SSR, etc.

For web components there is a small handful of starter kits. Google has built pwa-starter-kit. However, none of their kits have a webpack configuration that consolidates an issue where it is only compatible with libraries that are es6 modules. I settled on one that is based on create-react-app by react, called create-lit-app, despite that it has been deprecated by the creator. There are a couple other promising starter kits, but they don’t seem sufficient yet.

One of the things I look forward to with web components through es6 modules is the standardization of documentation of custom elements. Javascript already has a great documentation system through jsdoc that can indicate important component aspects, such as properties and events.

Most frameworks operate in a way that encourages using custom filetypes, such as .jsx.vue, or even .html. As a result, there is confusion and inconsistency of how the documentation should look and where it should go.

Component Libraries

As with many front end application frameworks, web components have a cult following in favour of the benefits of using web components. Google has even built a web components store that makes it easy to find available custom components.

However, due to frequent changes and compatibility concerns, there is much to be done in terms of consolidating the components so they can work well together.

Google has their own set of components that they’ve come up with whose aim is to be up to date with their material design specifications. However, it has yet to catch up with their latest library and keeping up to date with the specifications is unrealistic given the amount of resources they currently have.

A Finnish company, Vaadin, has come up with a set of enterprise-ready, premium components of their own. Some of them are paid components while others are free. However, the same issue remains that they have not been able to keep up with the library changes.


Web components have promised a lot and are still projected to be a major player in the future. Google has worked hard to make sure their web components libraries are up to date with the changing spec and best practices. However, these aggressive updates are also its downfall as the community struggles to keep up.

My hopes are that the best practices and libraries will stabilize in the coming months and the community will have time to catch up. Until then, we should continue to use frameworks for enterprise applications.