The gang goes headless all over their systems.

Even after almost 10 years and hundreds of articles about developer fatigue, especially front-end developer fatigue, we keep getting new libraries and frameworks. What's worse is that they seem to get more and more complex than the last. They are also marketed aggressively on the social media.

Progressive enhancement is poor man’s resumability.

Users don’t want a lesser version of the app. They want the full thing just faster.

@mhevery

For many developers front-end is only the tip of the iceberg they have to learn and keep up. Forget about being full-stack, now everyone is devops engineers (one person IT-departments).

The state of front-end libraries

Back in the day of AngularJS 1 we had to have framework specific wrappers for libraries or even plugins that would not work on other platforms at all. This is due to the old $digest loop that AngularJS had. If you used for example a jQuery plugin for some widget in your app you had to trigger the $digest loop, but look out! It was prone to fail because you couldn't call it while it was digesting already. So people like me found a hack to use the $timeout function to refresh a variable in the $scope object.

$timeout(() => {
    $scope.someVariable = someValueFromWidget;
})

Reminds me of the React useEffect hook (React doc). These kind of hacks and potholes are not good for the developers wellbeing. Did React even need these before the functional programming frenzy? How are you expected to know all of these unless you go through some bootcamp? Are these frameworks created to feed the bootcamp market? At least you'll feel empowered after.

Of course Vue has a similar thing called the nextTick function but with that and $timeout their functionality is clear, whereas the useEffect hook exists because React runs the component function for arbitrary number of times.

When in doubt, use setTimeout. - An old front-end proverb

The framework specific libraries still exists and I wish they didn't. The reason is that you really start to rely on them and the burden to update your app project to whatever is the newest and hottest framework keeps getting harder. Using framework agnostic libraries is more future proof solution in my opinion and using framework specific wrappers for them is ok. Shoutout to SortableJS, SwiperJS and Ionic that I've used in number of projects!

The meta frameworks

The focus of the new wave of front-end frameworks is not to only do better in the browser, it's doing something on the server and the rest on the browser. For this there are Server Side Rendering and Static Site Generators (NuxtJS, NextJS), partial front-end hydration (Astro) and the newest thing is resuming the app state with Qwik.

Now this site is built with NuxtJS because it uses Vue and I was already familiar with it. I set this up to be somewhat Server Side Rendered although it is not optimal but I'm happy with it. At least I know that I could improve it by tweaking some settings.

With this new wave the metric to follow has been time-to-first-paint or time-to-interactive. It really is just splitting hairs at this point. In my experience the performance bottlenecks have been somewhere else when there's a lot of data. Not every web project is a website after all.

If you follow the creators of these libraries, you know that they are really pushing you to try and depend on their new shiny thing. But remember that the most popular library mentioned on this blog is... jQuery. Goddammit! React is the second biggest with a usage of 3% on the web. Don't be caught by the hype.

Front-end frameworks on other platforms

Now that the meta frameworks start their work on the servers, you might be thinking that how are you going to convince your boss to use them at your work? After all your enterprise platform uses HTML and Javascript on the views but the back-end is PHP/Java/.NET/etc.. That is a hard sell to redo everything on the system to this new platform.

But with something like Vue you could just progressively enhance the views as you go by. No need even to add some build system or a new CI/CD solution on the side for it.

Usually in a meta framework setup you'll have the front-end as a separate full-stack app and the back-end as a separate REST/GraphQL server. You can always switch each one out as you like. This very clear and working distinction on new projects but we still have to keep the legacy systems up and develop on them.

Future is headless

Headless CMS platforms are great. They have their own UIs to edit articles and other data you might have on the website, and the website itself is made with some meta framework mentioned above. Headless is a proven idea.

Nowadays a lot of public facing systems are very outdated and archaic at least in Finland. Sometimes a student has to use three different system to manage their progess and things can get very confusing. Or some system is just so hard to use that we let inmates out of the prison too early by accident. We can't get rid of these systems because some data has to exist in a certain place and stored in a certain way, legally.

If these systems were to made headless we could create much better experiences with any new meta framework and whatever comes after them. These, usually goverment driven, projects could be then split in to several projects done by the book and by the right people.