How much framework do you need?

Kapil Kaisare — Fri, 15 Apr 2022 13:55:50 +0000

This essay starts a series that explores and tests a hypothesis I've nursed for a couple of years; that it should be possible to build a web UI without the use of a framework.

In a frontend-focused software engineering career spanning nearly 15 years, I've seen frameworks come and go. After a few years of working with jQuery, I switched to using Backbone, then invested a good three years understanding Sencha ExtJS, then dropped that as it faded from prominence to use Angular(2+) for the next four, and am now, at the time of this writing, wrangling a legacy Ember codebase, strangling it into a React-ish application.

The conceptual leap from jQuery and Backbone to Sencha ExtJS was perhaps the most significant, but since then, all frameworks have more or less offered similar ways of building web applications, save for React Hooks, which fronts a more functional paradigm. The conceptual sameness between these frameworks, coupled with the differences in their DSLs, caused a sense of framework fatigue as I found myself learning yet another way of doing the same thing. Learning something new that does not add to your actual ability to build something is - I propose - a waste of time.

Also consider: use a framework in an application long enough, and you will run into an architectural pattern that's not easily supported by the rules of the framework. Your ability to bend those rules will be determined by your understanding of the framework internals - a far cry from the general approach of treating the framework like a black box. I offer that frameworks like Angular, which boasts of its own compiler and a renderer interface, are difficult to learn. Angular in particular offers no documentation on its internals.

With that in mind, I'd like to clarify going in that I'm not advocating not using a framework. I define a framework as a collection of design patterns, and propose that a team should consider building their own framework using libraries and tooling that they understand well. This offers the advantage of growing an awareness of the application internals within the team, which brings with it the flexibility of changing a component of the framework for another that better suits the team's purpose.

To build the browser based client of a web application, you need your framework to provide:

A means of composing HTML into templatized, reusable blocks;
A router that, based off the change in the url, determines what component gets rendered; and
A way to build and use services that represent the application domain, perhaps fronting a state management solution.

Full fledged frameworks like Angular offer tightly coupled versions of all three. React, by itself, offers just the first, which in turn allows a team to swap individual components (like a router, or state manager) depending on what suits it best.

To test this hypothesis, I shall be building a toy web application (a todo app - what else?) without using a framework, using libraries that I think will serve my needs best. To compose my HTML into reusable components, I shall be using StencilJS, a web component toolchain. I've yet to see a router that I can use independent of a framework, so I shall explore in ensuing posts the construction of one. For state management, I'll probably use RxJS to build out my services. There will be no backend persistence; I will be using local storage for this experiment.

More to follow.

The Case for Web Components

Kapil Kaisare — Thu, 14 Apr 2022 18:57:36 +0000

From late 2018 to - at the time of this writing - 2022, I've found myself advocating and defending web components. This advocacy stems from framework fatigue induced by switching from jQuery to Sencha ExtJS to Angular to React to Svelte. For the most part, each framework has brought with it a DSL one needs to acquire to use effectively, but which is rendered obsolete when one begins working with a new framework.

Generally, a framework is collection of design patterns coupled with a means of enforcing them. If you've built your application right (think hexagonal architectures), you should be able to port your application from one framework to another without having to touch the majority of the codebase.

Web UI frameworks aren't like other frameworks because in addition to a collection of design patterns, they also provide a means of composing reusable widgets from atomic, native elements. This means of composition is unique to each framework, even when they have a common DSL like JSX. The uniqueness of each framework's composition mechanism means that widgets built in one framework cannot be ported to another.

Frameworks come and go, and on a platform that's evolving as quickly as the web browser, this is truer than most. The framework du jour might seem irreplaceable now, but at some point in the course of your project, you will run into limitations that have been solved by a newer framework. The limiting factor at that time becomes the cost of rebuilding your existing widgets for the new framework; try explaining to management why they need to fund, and allocate time for, the construction of UIs they already paid for. And even when they're willing, engineers can hardly be expected to be excited about the prospect of building the same UI again. Switching to a new framework this way is effectively a rewrite, and a rewrite brings with it the risk of recreating defects the team has already fixed.

So, understandably, management and engineering leadership express reticence at the prospect of a framework change. And as engineers struggle with fitting newer patterns into a framework that wasn't designed to support them, the quality of the codebase declines, leading to more defects and reduced team velocity. This in turn lowers confidence, which increases resistance to the idea of attempting a framework driven rewrite. The downward spiral continues until the cost of maintaining the codebase is judged equal to, or in excess of, that of rewriting the web application. The framework du jour is now eagerly embraced, and the cycle begins anew.

If one accepts that a framework change is inevitable (and perhaps even desirable) in a long living codebase, then a team's focus should be on minimizing the cost of a framework switch. Web Components offer a means to this end. They are a collection of four specifications (Custom Elements, Shadow DOM, ES Modules and HTML Templates) that collectively provide a means to building and deploying reusable widgets. A web component can be built once, and used across applications built with different frameworks. And because these are standards, they are less likely to be rendered obsolete, and are guaranteed to be supported across all modern web browsers.

While you can build components directly from the supporting Web APIs, you might find it productive to use a library that's been built to support this task. Lit and StencilJS are two of several libraries with acompanying tooling to help you build web components. And because they compile to the same 'target', they give you an additonal advantage: if you choose to switch web component libraries at some point in the future, you can make the switch for new components without having to rewrite the old ones, and use both in the same application.

References

The Custom Element specification
The Shadow DOM specification
The ES Module specification
The HTML Template specification
Lit
StencilJS

DEV Community: Kapil Kaisare

How much framework do you need?

The Case for Web Components

References