Zack's View

Which web technologies should I use?

Published on
Updated on

There’s many web technologies in the space right now and it may be hard to pick which one you or your team should use. In this article, I’ll go over my personal thought process and how I evaluate which technology(s) to use.

Evaluation criteria

Starting the project, I ask myself questions like:

On solo projects, I ask myself questions like:


With each question, I don’t keep a concrete answer when deciding. Although these are good questions to ask, almost every modern web technology can accomplish all of them.

What problems are we solving?

After thinking about the higher level questions, I look at the problems that all websites have. It can be broken in to three categories.

1. Frontend

Conventionally, frontend represents for code consumed by the browser. This is the HTML, CSS, and JavaScript that is processed by it and rendered. In this section, I’ll go over not only client-side code, but backend code that is used to generate the frontend as well.


To start, we can abstract the frontend in to two main categories. You can have server side rendered (SSR) which renders the HTML on the server at runtime and sends it to the client- in a fully multi-page application (MPA), it exclusively uses this. Client side rendered (CSR) which renders the HTML on the client- in a fully single-page application (SPA), it exclusively uses this.


In a fully MPA, we use the browsers native routing to go between pages which are often not pre-rendered without additional tools. In a fully SPA, we use a client side router to go between pages which can be pre-rendered using this router.


Modern frameworks usually combine a mixture of SSR and CSR, generating the main boilerplate on the server but then client hydrating it on the client. As well, most bundle a client side router to handle routing and make a smoother UX for the user.


SSR:


CSR:


Hybrid (both):


With the groudwork laid out, we can review some of the different tools to solve these problems. Each of these frameworks come with a backend that can do server side rendering and client side hydration. I’ll be going over:

In my opinion, these are the most promising frameworks that are production ready and hit a high score on all of the evaluation criteria. Each framework is constantly improving and copying off of eachother, so picking one because of a feature may be obsolete if another one implements it in the next week. I recommend picking one that you like the syntax of and has the features you need.


Some that I will not go over but are still good frameworks are:

Next.js

Next.js is a meta-framework for React.js that is built by Vercel. It has a lot of advance features when deploying with Vercel like Edge functions, serverless functions (aka Lambdas), a built in KV store, image optimization and CDN deployment for assets, and more. It’s a very mature framework that’s used in production by many companies. It recently adopted a new folder structure and completely different API for how you interact with your backend. Some are hesitant right now since this is a big change and some features seem to be missing. The main issues with Next is that it is opinionated and has a slight vendor lock-in with some of it’s advance features. Right now, it also does not seem as stable as it has been.

SvelteKit

SvelteKit is a meta-framework for Svelte. It has almost all the features of Next, the main difference is that your project will now be written in Svelte instead of React. In React, you export functions that act as reusable components. Your files can export as many components as you want. With Svelte, you export a single component (namely the whole file) which has a colocation of the

Astro

Astro is a meta-meta-framework. It can use any of the libraries like React, Svelte, Solid, Preact, etc. It also introduces it’s own Astro files (.astro) which is one of the simpliest syntaxes. It includes a frontmatter at the top like a markdown file which is server ran and then the html below like Svelte, it has the style tag scoped to the current file and each file is a component. If you want to use any of the other libraries it’s really easy to use a mixture and by default they are SSR. If you want any client hydrated or rendered components, you can use anything except the .astro files. The main issue with Astro is that it’s missing a client side router so navigation between pages do a full reload of the page rather than other modern frameworks which have a smooth navigation experience.

Remix

Remix is a meta-framework for React.js. It, again, has almost all the features of Next/SvelteKit. It was one of the first frameworks to introduce some of the most popular ideas that the other frameworks have now adopted. It has a simple data loading structure in which each route exports it’s component which will be it’s view and a loader function which will be ran on the server exclusively for that component. It has a simple form submissoin and tries to use web standards as much as possible. It has a client side router.

Solid Start

Solid start is a meta-framework for Solid.js. It also has similar features to the other frameworks. It copied Remix’s data loading struture with exporting a component and exporting a loader function. It has a client side router. It uses server actions for form submissions and makes going between your frontend and backend seemless.

So which one?

2. Backend

Backend problems

3. Database

database problems

: