Simple Frontends

Recently a colleague of mine shared a story: he started a side-project with an intention to iterate relatively quickly (but still safely); he chose node.js with TypeScript for the backend logic. He is a backend developer by day (mostly focused on ecosystems other than node.js/JS/TS), although he used to write some frontend code in the past, too.

The time came to add a UI layer. And that’s when his frustration started.

Hardly any of the patterns he knew from the past remained unchanged. React? Well, the community is hyped about big end-to-end foundations like Next.js now, and even the official docs now recommend picking “one of the React-powered frameworks”. Build tools? Hardly any new project uses Webpack, as it used to a few years back.

My friend was bombarded with an overwhelming number of new terms, concepts, machinery, and cryptic configurations. He felt like there was no easy solution to his relatively straightforward needs; learning a dozen of extra tools just to be able to expose a simple frontend didn’t seem like a way to go! Reading through the examples online was a bit like the meme situation:

Source: https://glebbahmutov.com/blog/how-to-draw-an-owl/

Sounds frustrating already?

Can we have dead simple frontends instead?

Source: devhumor.com

I argue that despite yet another iteration of “frontend fatigue” (which is a term describing the situation in which we have more tools and combinations of these tools available than we can realistically comprehend), there are still ways in this maze that lead to simple solutions.

I’ll share some tricks that should make life (and coding) easier, at least when it comes to the bootstrapping phase, without the need to get a PhD in tooling first.

Being a frontend/TypeScript developer myself, I often feel the pressure and frustration, too. And guess what - it doesn’t feel right. Reducing the cognitive load is my goal - it’s better to work smart than hard!

The goal of this blogpost is to explore a handful of options for starting simple frontend projects - in other words, to have a working prototype without frustration. I will not compare frameworks or libraries, though. Nor will I talk about specific approaches to topics like state management, styling, testing etc.

The state of the frontend in 2024

Some tooling is still needed to enable certain goods, like TypeScript transpilation or production bundle optimization. However many of these most common needs are now addressed by close to zero-configuration solutions (or can heavily rely on native mechanisms), and shortly I’ll show how to achieve a “simple”, “simpler” and “dead simple” project starters.

Enter Vite

The new kid on the block, a one-stop-shop for managing source files & assets, transpiling TypeScript, and hot module replacement, is now Vite - meant to replace configuration-heavy tools like Webpack.

Obligatory meme:

Source: xkcd.com

If you, dear reader, now feel like I’m just replacing one standard with another, that’s kind of a valid doubt you have there. Stay with me, though, as I’ll try to justify this choice.

Vite is a batteries-included type of tool, requiring a minimal amount of configuration from the very beginning; it’s like it was designed to address the most common needs without a question asked - just focus on the business logic, and it will take care of the rest for you.

Moreover, it comes with a set of well-established starter projects for the most common UI libraries in both language flavors (JavaScript and TypeScript):

Source: vitejs.dev

Vite has recently become a de-facto standard across many different platforms, including Vue, React, Svelte, Qwik and others.

StackBlitz

“Trying Vite Online” was enabled in cooperation with StackBlitz, offering a fully-integrated, online development environment: a Visual Studio Code running in the browser, along with the live preview powered by WebContainers. Let’s take a look at TypeScript’s React example (react-ts):

(if you can’t see the embedded StackBlitz editor, just follow the link to react-ts)

Again - StackBlitz offers an environment ready to start development; the code is already there and the preview loads up automatically - try changing some code to see the immediate effect!

There’s no need to know npx create … spells to bootstrap a new project, nor to litter your local machine with another code directory should you not like the chosen starter project. But if it fits, then it’s a few clicks away from connecting your GitHub account to StackBlitz and saving the code with a “Create repository” button:

yay GitHub!

Take it on from here and continue your work on StackBlitz or clone the repository to your machine - it’s your choice!

Let’s now look at the code. As promised, Vite’s configuration is quite simple; it boils down to three pieces:

• “vite” dependency
• vite.config.ts file (including a react() plugin/directive)
• “vite” command (script)

These combined enable a fully functional, development/production-ready setup.

“But I don’t want React!”

And that’s completely understandable. Let’s try some “vanilla” project instead, meaning one that doesn’t impose a certain framework. Moreover, for the sake of simplicity, I’ll assume that JavaScript is enough:

(if you can’t see the embedded StackBlitz editor, just follow the link to vanilla-js)

The bare minimum configuration is even more straightforward than in the previous case - this time all that is needed is:

• “vite” dependency
• “vite” command (script)

Notice that vite.config.js wasn’t needed this time - there’s no specific framework or library in use, hence no need for an explicit Vite configuration. It works out of the box assuming default settings for a regular web app.

Because both approaches mentioned so far take advantage of Vite, there’s also a build script to assemble production-ready, static code & assets bundle. The output directory is straight away ready to be served by the HTTP server of choice.

Native modules for “dead simple” setup

For many years the only way to use import and export statements, specific to the JavaScript modules standard, was by wiring in some kind of code bundler, like Webpack, Parcel, Rollup (or Vite).

This was due to the fact that browsers couldn’t understand the native syntax, and instead required the JavaScript code to be plugged in by either one or multiple <script src=”...”> elements. The former relied on a huge bundle of code - all source files with their dependencies - “packed” into a single file. The latter (having multiple script elements) split the code into chunks, but was cumbersome to maintain in the long run (mostly due to the order of script load/execution that could quickly become difficult to reason about).

Little known fact, for some time though (since ~May 2018!), all the major browsers have been supporting native modules via <script type=”module”> tag! This means that the code can now be easily split into separate modules, values can be exported and imported, and there’s no need for external tooling to make it work. Take a look at the example:

(if you can’t see the embedded StackBlitz editor, just follow the link to dead simple frontend)

Notice how there’s a just a single script tag linking to the “main” JavaScript code entrypoint: <script type="module" src="components/app.js></script>

Subsequently, the code in components/app.js makes use of import statements to include other code. All of that without a single bundler - just plain, old HTML and JavaScript!

Code can be now written using virtually all the goodies of the ever evolving ECMAScript standard, and for the minimalist, simple setup, code bundlers can be easily skipped.

Obligatory meme to sum up the situation:

Source: imgflip.com + own sense of a good meme

A word about frameworks

Let’s take a step back and briefly mention frameworks again. The other way of setting up an out-of-the-box, development/production-ready project would be to use a full-blown ecosystem like Next.js from the very beginning. All necessary pieces are available straight away - the backend, the frontend, the configuration and all the “glue” logic. The template is available on StackBlitz as well.

One must keep in mind that there are tradeoffs - I feel like the learning curve for Next.js is quite steep. Some of my colleagues argue that it’s easy to start, but hard to master.

I would probably not put it into the category of “simple frontends”, and definitely not when the target audience is far from being devoted to advanced frontend development. On the other hand, it might be a very well-suited tool should one aim for the fullstack/isomorphic solution from the very beginning, eager to make a justified use of modern frontend architecture patterns like server-side rendering, server components etc.

Summary

I believe that simplicity is the key, especially in the ever-changing landscape of technology. While some tools are being replaced by others, I did some research to check which one offers the most simple approach, implicitly addressing the most common needs of new projects. Moreover, I believe that tools like StackBlitz offer an additional layer of smooth and welcoming developer experience: one can get their hands on code straight away, with a sensible environment setup, virtually in full isolation from their local machine.

On this quick journey, I also found that it’s sometimes good to go to the “roots”, as browsers have already been catching up with the standards for a while (despite the initial hiccup). Many modern features seem to no longer depend on complex polyfill-transpile-build pipelines, but are well supported natively.

Special thanks to Tomasz Krawczyk for his invaluable feedback and peer review of this blog post.