On front-end

Published on Dec. 21, 2024, 6:48 p.m.
Last changed on Jan. 9, 2025, 7:58 a.m.

While sitting in Uruguay where I had to fly to in emergency to help a very close relative who had fallen seriously ill there, I have just finished reading one of the best front-end related articles I have read in a long while. I found it via a very well known "professional" portal acquired by Microsoft a while ago and whose name seems to imply links. Whatever its origin, I would like to briefly use the excellent article as an opportunity to offer a few thoughts on the subject - and how they relate to the way I see front-end on Ad Lumens.

The article can be read here.

Some genuine and constructive questions I received

Several people have asked me why Ad Lumens wasn't built around "modern frameworks" such as React and Angular. Ew. Or Vue. Or Next. Or even HTMX. Apoplexy in 3…2…1…

Jokes aside, I have several problems with the (over)usage of such ~~technologies~~ frameworks - or, as the article dubs the phenomenon, frameworkism. These problems are not absolute criticism of frameworks - rather the outcome of my working with them a reasonable bit and their resulting incompatilibity with Ad Lumens.

Note: if you want to use frameworks, use frameworks! Sometimes their usage is probably a good idea (depending on scale, team size(s), technical debt, etc.). This post of more a series of light-hearted replies to some questions I received than heavy-handed criticism of frameworks.

Reinventing the wheel

Let us start with a pretty picture which I hope will be telling:

I like this image a lot because it humourously reflects what happens in many cases when frameworks overstep their boundaries and reinvent the wheel, often introducing complexity where there should be none. Of course this does not always happen, but see the "I have seen things" section below for why I tend to react (haha!!) that way.

A quick list of what I think are square eggs born out of frameworks' behinds:

CSS-in-JS
Forms and validation: FormsModule and ReactiveForm
Event handling: (click) or v-on

…but…but it's not all laughable; sometimes routing, state management, etc. are actually useful. Only… not for Ad Lumens.

Learn Javascript, not the framework(s)

Another important point is that I see many junior(ish) developers learning React or learning Angular. Or others. Now while learning anything is good in an absolute way, I sometimes worry about the time they have left to learn more Javascript - sometimes at a slighly lower level. Not that they don't! -- but much of their time spent producing code is spent reusing logics, patterns, etc. inherited from frameworks and not deeper thinking.

Now again, this is not necessarily bad - hell, the 3D explorer uses a framework too! But I do strive to "export" as much logic as I can out of it, when I can: see an upcoming ROAM+icosphere experiment page and perhaps more significantly, the procedural server-side logic that depends on zero framework.

Apart from Babylonjs and msgpack, Ad Lumens makes use of zero front-end framework:

Asynchronous requests are handled via native fetch
Event listeners are almost always delegated and routed internally via class names, identifiers or data attributes
Real-time stuff hit the native websocket API.
Document fragments are inserted using the native insertAdjacentHTML, probably one of the best inventions since warm water or sliced bread, to be honest

And with a huge tongue stuck in my cheek, here's a link.

Learn Javascript, not the packaging tools

Now when moving from the CLI world to a website built using django (honoes!! a framework!!), I realised some complexity would have to be managed at CSS and JS levels:

I wanted to split CSS and JS code into fragments reusable throughout the various "end result files": for example, site.css, 3d_explorer.css, etc.
I needed something simple and fast. i.e., not 30 minutes build times.

What I did not want:

to swim in npm hell
to spend more time managing the packaging that doing the actual coding

So the good old gulp (v4) was used and still is to this day. Works well, and transpiles/terses 2 css and 5 js tasks in under 3 seconds. Granted these are reasonable small, but still.

I confess I was little bit confused/frustrated by the deprecation of the @import statement in SASS but apart from that, everything has been running smoothly, which has definitely helped me focus on the code itself (whether front-end or back-end) rather than the meta around it.

I have seen things…

A few horror stories - or just surprising ones!

The Black Hole

I had the luck and privilege to have a very large US card network company as a client for 2 years. Met excellent people there.
But what I also met are some of the worst pages I had ever seen. Pages so heavy even light could not escape them:

initial, non-primed cache load times of 35 seconds on mid-of-the-range mobile devices. I kid you not
12MB of assets, 5 of which was Javascript spread over tens of files; 5% code coverage. :sadface:
120+ JSON requests

…all based on a framework built on top of Angular. FFS.

Let's cache!

Another client had the great idea to cache JS assets for their rather heavy SPA. The application was nice (truly) but it had a problem: the often-changing assets were almost never updated, while the Javascript code was changing all the time and generating lots of requests.

Turns out they had put in place the following caching rules, client-side and with a custom logic:

Since the code needs to be fresh and up to date, let's never cache it
Since the HTML/content stuff is not important, let's cache it for a very long time.

Nothing proper cache-busting and quick and dirty nginx configuration could not fix but still…

Regwhat?

A senior React native developer (quite good at it, by the way), did not know what a regular expression was.

Maestro reporting in

And last, a SPA had internal orchestration managed of course client-side. While I think (not sure, though!) there is nothing inherently bad about this, mucho logic should have been handled server-side. Any reasonably competent and motivated malicious user could easily have reverse-engineered the obfuscated code, examine the various fetch requests made, and whose response contained potentially sensitive information (such as internal usernames, latest change timestamps, etc), to try and corrupt the client's intended capabilities or worse, do serious damage server-side.