The Naked SPA — Part II — A Pragmatic Approach to JavaScript Frameworks

A Bare All Experiment in Single Page Application Building

This is the second part of a series about “The Naked SPA”, an experiment in dropping everything but the bare essentials in Single Page Application Development.

Read Part I.

Detail from “Four Lit Tealights”— Breakingpic

For The Naked SPA, I forced myself to go frameworkless. Just to prove a point. By no means am I trying to discourage the use of JavaScript Frameworks such as VueJS, Angular and React, but as someone who’s been around since the rise of the Web, I have my not-so-fashionable thoughts on the cyclic nature of their popularity, and, well, it’s great fun to challenge mainstream thinking.

“[Frameworks] are very powerful tools, written in plain vanilla language and in a very generic way, a fact that makes them great learning tools which can help anyone learn how to code without them.” — https://www.frameworklessmovement.org/

Frameworks have been developed for many reasons. In the World of Web Front-end, the main one seems to be…

The deepest reason why modern JavaScript frameworks exist — Alberto Gimeno

Of course, frameworks have lots of other advantages besides handling UI state in some magical way, but many of these reasons, like size of community, vast amount of documentation and best practice descriptions, also apply to vanilla JavaScript.

Let’s not be afraid to openly discuss framework disadvantages:

• They come and go (see framework lifecycles), and even if they don’t go, they might become less popular, cool and sexy. I’ve heard numerous complaints from developers about them having to work with a framework that wouldn’t have been their choice (anymore).
• I can sense some fatigue in keeping up with the latest hype (or framework du jour)
• They can be seen as major bloatware: they sometimes include huge amounts of unneeded stuff your app simply carries around, causing completely unneeded download penalties. As I said in the first article in this series, the footprint of some frameworks is gigantic.
• They sometimes have steep learning curves that mainly have to do with the exact way they have abstracted common HTML/CSS/JavaScript concepts, introducing more complexity.
• They are generalistic by nature, thus requiring large amounts of configuration and tweaking code (thus knowledge/time spent on StackOverflow) to account for your specific scenarios.
• Keeping up with (sometimes breaking) framework upgrades can become quite time-consuming and frustrating (remember AngularJS to Angular?), and it makes for not being in control over your own codebase roadmap.

The Magic

“Before you commit to a framework, make sure you could write it. Do this by actually writing something simple that does the basics that you need. Make sure the magic all goes away. And then look at the framework again. Is it worth it? Can you live without it?” — from “Make the Magic go Away” — Robert C. Martin

I love this quote as much as I hate ‘magic’. Think of it: how can you work with something professionally that you don’t deeply understand?

Time for an anecdote: I was interviewing a junior front-end developer recently who was working on an Angular app he ‘inherited’, and he had an issue with positioning some element, but he noticed that class names where not constant. His ‘solution’ was to look at the pattern by which the class names were generated and write a Regular Expression to catch them, in order to then inject CSS to ‘correct’ the layout.

I think this proves my point about the ‘Magic’.

When to use a Framework?

So when would it then still make sense to use a framework? I agree with Chris Ferdinandi of gomakethings.com that there a few situations where it actually does make sense to use an existing framework:

1. If your app needs to scale, and I mean really scale, to a point where having a Virtual DOM makes sense. Think a new Facebook or Twitter, with a ridiculous amount of continuous DOM changes.
2. If you need server-side rendering for better fault-tolerance (see Chris’ article for more info — I see this as an edge case)
3. If you have a larger team, or external developers, and don’t have time to write documentation to support them.

When I was talking to a senior full-stack developer lately, point 3 was the first he came up with when I mentioned my Naked SPA project, but as Chris counters, this is not the strongest of arguments, and there’s a lot of room for countering this criticism, as I’ve already stated above.

Developers understand the benefits of everything and the tradeoffs of nothing! — Rich Hickey

Evolution

There’s been quite an evolution in the technical status of web and web development. Whereas jQuery once ruled the (web) world in that it overcame browser differences and standardized stuff that wasn’t and made DOM manipulation 10 times easier than it was with plain JavaScript, things have changed since then:

• Browser wars no more. Browser differences, a lot less, at least.
• All major browsers are now mature and reliable application hosts.
• ES6 is widely supported
• The box model, flex positioning, CSS Grid, animations have become easy-to-use CSS3 features.
• SVG is mainstream.
• Etc.

Products vs Projects

I want to highlight one other reason to not just walk on by the point of framework selection (selecting the framework du jour) when you’re in it for the long term, building a SaaS Product with a longer life cycle.

When you’re building the next Unicorn, or at least trying to, you might (and should) want to embrace UI/UX best practices, but if you really want your product to stand out, you should not simply have your UI look like a clone of other apps, whether it be looks or behavior.

You want to be careful with buildup of the potential technical debt of having to switch frameworks later on. And trust me, there’s serious technical debt in having to refactor a mature app’s front-end, as we’ve seen in the AngularJS to Angular example.

The fact that many large scale SaaS products don’t use a JavaScript framework at least make me wonder.

For young SaaS startups, there obviously is an extra challenge: many of them outsource software development and aren’t aware of the consequences of framework selection until much later. With many of them simply putting a lot in the hands of an external party or freelancers, chances are that framework selection is done on terms that make sense for that party or individual, who might have a template ready or just be fluent in a certain framework. As a CTO, I have seen many situations where the damage was done early on, and a big pile of technical debt was left for a new team to solve.

More reading & Inspiration

• https://stackoverflow.blog/2020/02/03/is-it-time-for-a-front-end-framework/
• https://www.frameworklessmovement.org/
• https://github.com/frameworkless-movement/manifesto
• https://ayushgp.github.io/html-web-components-using-vanilla-js/
• https://dev.to/rishavs/making-a-single-page-app-in-ye-good-olde-js-es6-3eng
• https://medium.com/@bryanmanuele/how-i-implemented-my-own-spa-routing-system-in-vanilla-js-49942e3c4573
• https://medium.com/better-programming/you-dont-need-a-javascript-framework-df2a36c2dd0a
• https://gomakethings.com/when-you-actually-should-use-a-javascript-framework/