HTML, CSS, and Javascript, are the languages of the world wide web, the platform. They are used to create websites, to make them interactive, and to make them beautiful. At one point in my career, I was more plugged into this world. A world that I feel I’ve fallen behind since I myself have not exclusively worked on a UI project since the days of AngularJS. That doesn’t mean that I don’t do any front-end work anymore, it is just that these days I spent most of the time doing back-end development. I am familiar with some of the modern frameworks like Angular, React.js, Next.js and everyone’s new favorite, svelte. By falling behind I mean that I am not up to date with some of the new tools and technologies that have been created since the days of AngularJS. I want to use this post to write about some of these new techniques and tools that are available for front-end development.

I would like to start by exploring micro frontends, a term originally coined by the team over at ThoughtWorks on their 2016 technology radar. With their most recent technology radar advising the tech industry to adopt micro frontends. So, just what in the world are micro frontends and how is this pattern for building front-end applications different from island architechture? Given that both micro frontend and island architecture advocate creating independent UI components. The key difference is their approach to building the front-end, the idea behind the island architecture is that the HTML is rendered on the server, the HTML rendered would contain placeholders that denote regions (think widgets) on the HTML that can be hydrated on the client. Essentially you have an HTML page is rendered with most of the functionality readily available for use, loading independent apps on the client.

Both micro frontend and island architecture try to bring the benefits of microservices to the front-end, benefits like being technology agnostic and having code isolation. Thought you should really avoid mixing multiple frameworks on the same application, a problem that is known as micro frontend anarchy, though technically possible, it should be avoided. In a micro frontend architecture, you should only standardize on styling and how the different parts of the application are integrated. For styling the go-to techniques are CSS-in-JS, a technique popularized by Christopher Chedeau, andCSS Modules.

Do not confuse CSS Modules, the community standard with CSS Modules, the standard created by the Web Hypertext Application Technology Working Group (WHATWG) even though they both share the same name. Remember, developers are bad are naming things.

One of the main problems these techniques are attempting to solve is the fact that CSS was never bound to any scope, hence the name Cascading Style Sheets. CSS was created in a world where we expected the full HTML to be returned from the server. These techniques aim to avoid namespace collision, performance degradation that comes from using CSS at scale, and reducing the size of CSS bundles. You should know that these patterns come at a cost, you should be aware of their benefits and tradeoff before you use them.

Then there are web components, which consist of a number of APIs that allow you to build independent applications. This is done using Custom Elements, an API that allows you to define behaviors and styles for new HTML elements. The shadow DOM, which lets you scope CSS. HTML template, defines how to declare fragments of markup that go unused at page load, but can be instantiated later on at runtime, and ES Modules, defines the inclusion and reuse of JS documents in other JS documents. Web components are a great way to build independent applications, applications that are rendered on the client because up until 2020, the only way to use Shadow DOM was to construct a shadow root using JavaScript. For example.

1
2
3

const host = document.getElementById('host');
const shadowRoot = host.attachShadow({mode: 'open'});
shadowRoot.innerHTML = '<h1>Hello Shadow DOM</h1>';

If you are working on an app the does server side rendering (SSR), then you will need to use the declaritive shadow dom, otherwise, you will run into performance and rendering issues, FOUC which stands for ‘show a flash of unstyled content’ being the most common. Declarative Shadow Rom brings the shadow dom to the server. However, it does bring another set of issues as noted by Rich Harris, the creator of svelte.js. Declarative shadow dom is only supported in Chrome as of August 2021.

You should check out vanilla-extract. It allows you to write your styles in TypeScript (or JavaScript) with locally scoped class names and CSS Variables, then generate static CSS files at build time.

As noted in the tweet, CSS modules do not work with a declarative shadow dom, meaning we can’t use CSS modules on server rendering applications. The google chrome team proposed declaritive constructible stylesheets, it aims to fix this problem by relying on APIs that avoid FOUC. I’m starting to feel like a lot of these issues could have been avoided if the scope specification had become a part of CSS. Luckily for us some out, there are still fighting the good fight, hoping to simplify how we use CSS because to me all these patterns stem from the fact that we seem to have a hard time scoping CSS.

Anyways, moving away from web components to another front-end pattern that I’ve been seen pop up lately, and that is rendering HTML completely on the server. In reality, this is not a new pattern. This is how most of the web worked up until ~2011. One key player in this area is Hotwire, created by the same guys that made Ruby on Rails. Hotwire is heavily used over at Hey.com. It works great, for the most part, but I am concern with the fact that many of the people that created the project left the project after the basecamp debacle.

Blazor is another popular choice for building SPA with C# by running on the server or browser utilizing WebAssembly. I honestly don’t know how I feel about Blazor and its role in the platform. I do like the idea of being able to use LINQ on the browser, that is simply because LINQ is an awesome feature of the C# language.

Can’t forget about Progressive Web Apps, PWA leverage the power of the platform to create installable applications that do not require a store of any kind to act as a middle man between the consumers and the applications, kinda like the Play Store or Apple Store. Progressive web apps offer many amazing benefits, but I often hear that they can be complicated, which may explain why I’ve only seen one or two companies successfully used them. The top companies being Twitter and Google.

That be all for now. Till next time, cheerio.