HTML, CSS and JS are not the output of our work, it is the matter we must know, account for and work with. Even if we produce it indirectly through frameworks, server rendering, templates or other languages.
These are some of my experiences with picking such frontend tools.
First criterion #
Out tools must enable us to generate code on a level that at least matches what we otherwise would have hardcoded. Beyond that, it’s mostly about convenience for users and developers.
JS & co. for task-driven solutions #
JavaScript in itself isn’t so much a choice as it is just a part of what we make. I prefer to start with JS for the parts that need it, then scale up to React (or similar) if those parts grow and involve a lot of DOM to manipulate or generate dynamically.
100 per cent React is only an option for applications. And then it’s important to keep the size as small as possible and the config on a sane level with ease of upgrade; no ready-mades like Create React App are necessary to use in production-ready projects.
Connecting or scoping CSS to the JS can be useful in some cases, but I find it important to at least write the two separated. CSS as CSS gives longevity and reusability. Changing the syntax to match JS or CSS frameworks has not provided me with any noticeable benefits so far. Recognisable class names are also a must to debug efficiently.
Component-wise, I don’t repackage HTML elements. A <button> rarely needs to be made into a <Button />.
For me, JS is for enhancing and building interactivity on a page. Frameworks are generally for applications. The more of the interface is the actual product, the more the scale tips toward using a framework. Placing articles and other typical website content inside JS seems completely useless, especially for the users.
SSG for data-driven content #
I find static site generators (SSG) reasonably fun and easy to work with when the content is the product. Mainly for data-driven sites, documentation or lightweight sites that aren’t updated all the time.
I use Hugo for content that is data-driven or documentation that doesn’t change too often and doesn’t need an admin interface. It consumes data sources, such as CSV and JSON, the templates can be as complex as necessary. Recursive templates for tables are especially fun to cook up.
SSGs should be fast to work with and fast for the users.
I’m not a major fan of markdown, which most SSGs use, it's unable to produce exactly the HTML I want. But its simplicity is also its strength, and it has its uses that outweighs the minor issues. Any serious SSG also allows HTML.
Hugo, and probably other SSGs, can generate pages from any headless CMS. Meaning it can be used as an editing interface. Having to generate a build on each edit, when you could just get it directly out there using a template language for the CMS, seems a bit slow though.
An SSG can be a viable option when we don’t want to run with a database or don’t need a lot from the server. We can set up pipelines to deploy or upload files manually via FTP. Simplicity with optional complexity is the strength of SSGs.
CMS for content variety #
For content-driven sites, the content is also the product – the system or stack should make that work more convenient than markdown or similar. Server-running CMSes solve this nicely, especially if multiple people are working on the site or there are multiple sites with one admin system.
I’ve stuck with Craft CMS for many years. I have a couple of setups that power five sites (and counting). It makes no assumptions about the content organisation. It can be used as a headless solution, feeding into whatever can consume at least JSON or GraphQL.
You can probably find a CMS built on any language you like. Just remember that the administration part is different from the consumer, or user, part. If the admin is in React, that’s fine, it’s an application – but if it packs your content inside JS, then I would continue looking.
In front of us, not others #
There isn’t one tool we can lean on for everything. Picking a suitable one is about looking at what’s in front of us, the task at hand and not so much copying what others are doing. There is no inherent gain from forcing every project onto the same stack either.
I’ve recently built a medium-sized application mainly with Python and Flask; a fun exercise and a nice way to learn about how frontend and backend work together. I also work with JSP frontends regularly, it does the trick. We can write our own CMS in Svelte and generate the pages with an SSG. Or use a headless CMS to supply a React-based application frontend.
Some things to remember #
- Working with JS and a good template language can feel more like programming than working with React does.
- It’s interesting to see how small the JS files can become compared to bundles with an entire framework, its grandma and the kitchen sink.
- If ten people prefer A, five people prefer B and seven people prefer C, most people don’t prefer A. Either way, popularity doesn’t equal quality or value for our project.
- We should pick a tool for the job, not for ourselves.
- Smaller frameworks, both in size and usage, are worth checking out.
- Keep up with the technology, but programming isn’t like software – new stuff is more of an addition than a replacement. It can always be tested or changed later.
- Anything goes in experiments and learning opportunities.