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.
Top comments (1)
Frameworks, Libraries, BaseClasses (like StencilJS or its 60+ alternatives), they are all tools that make production easier, faster; provided you mastered the tool. But never better.
Furthermore , you will be learning/demonstrating a Tool and not necessarily the underlying Web Component Technology.
It is like claiming "I made my own todo-mato soup", and starting with: