The Right Tool For The Job - In Frontend Engineering

Lately, I've been thinking alot about choosing the right tools and frameworks for another project.

Ok, go ahead and choose.

Harder than you think!

Because...

So many technologies are so damn hot right now 🔥 Some old kids from the block like React, some new kids from 'round the corner like TailwindCSS 😉
More important: So many other frameworks I am eager to use in my next project! Like Bulma, UIkit, Next.js, Eleventy, Gridsome, LitElement, Shoelace, simply Sass - just to name a few.

So many tools to choose from - tools in a workshop — *So many tools to choose from!?*
Photo by Barn Images on Unsplash

But careful! There are things to consider:

Heavy dependencies like the ones named above can shape a project in many unexpected ways. It will dictate the developer experience (DX), may limit flexibility, impact performance and user experience (UX) - the look and feel of the product.
Depending on the use-case for your website or web app, a correct choice of framework / tool can enable the quick and frictionless development and maintenance of said product. But, vice versa, choosing a framework / tool not fitting the use-case of the project may ruin the finished product altogether! :alert:

Random dev: "I am building my blog with React!"
Everyone screaming: "Nooooooo!" or "Why the hell?!"

Actually, I felt confronted with the problem of choosing the right framework for a web project, when I thought about why I learnt React - of all frontend frameworks - so early on my journey?.

The ongoing hype around React gives clueless beginners the impression, React might be the solution to all frontend-related problems.

It is not. By far!

Choosing the right tool for the job

Let's divide the process into individual steps.

Define the use case / purpose of the project
Write some user stories - what is the minimum solution - what features are available in the full-blown website / web app
Answer some questions based on the use case
- Is your web app highly interactive?
- How frequently is the displayed content changing? Every second (stock market), every minute (social media), daily or fully static content..?
- Do you require user authentication and authorization?
- Do you prefer client-side JS over server-side?
- Do you need offline availability paired with an app-like feel with push notifications, installable directly from the browser? Might go for a PWA

I any case, you decide in favor of your users!

Does "But-I-Wanna-Try-This-Fancy-New-Framework" count?
> Yes. But only if it's a side-project - or no commercial ambitions there.

Is the content mostly static..?

For example, when building a blog or a landing page there's usually only static content - no need for parts of the website due to user interaction. In fact, there is so much you can achieve with HTML, CSS and presentational* JavaScript (*expression borrowed from @Brad_Frost).

Advantages of static websites

Browser receives HTML and CSS ready for being rendered instantly. So its blazing fast!
Can be served via a CDN - no web server needed!
almost no or very little client-side JavaScript needs to be downloaded
vast variety of UX possible - forms, popups, animations, video embed, third-party integrations (e.g. CodePens, Tweets)
Can be developed in a modular, components-based fashion (e.g. with web components, or static site generators like Eleventy)

Drawbacks of static websites

Limited user input processing
Full page-loads required, if underlying data of only a single component changes

..or frequently changing dynamic content?

If yes, there are certain advantages of heavy-client-side-JS-frameworks like React, Vue or Angular.

Incrementally updating components - no full page-loads required
Get the whole web app with one request and fetch data from multiple APIs / origins along the ways
frequently update data using streams
Receive and process heavy user input for maximum interactivity

From the aspects above you'll get a good grasp of what sort of product is ideally built with React & Vue.

This ain't no simple website, no! It's a web app. A programm that happens to run in the browser!

Recently, I started contributing to an open-source project called deckdeckgo. DeckDeckGo is a wonderful web app to create presentations to share and use them across the web. Imagine it to be like PowerPoint, but completely in the cloud and runs in the browser or on your phone. A perfect example for a web app - user input and interactivity is essential here - making a presentation, upload assets, store and share the slides.

It boils down to data & interactivity

Basically it all boils down to data and interactivity.

Does a simple website containing images, paragraphs, blog posts or other informational content need to be interactive?

Does a simple website heavily rely on user input and processing?

No.

There are tools to build static sites. Use them.

Other tools shine in building web apps.

I might not know all the tools in the web development universe...yet. Until I do, I'll try to choose the right tool for the job.

That's it for now. Stay tuned & happy coding 🚀