Building websites should be less complicated

You can build amazing web apps today. But it could also be a lot less complicated.

I've been doing JavaScripty, web-y things for almost 15 years now. Things have changed a lot since then. You can build out build amazing applications that were unthinkable in 2007 and you can iterate on them really quickly. How fast you can build out a native mobile app with Expo is just mindblowing.

That's the point that this article makes. There's never been a better time to build websites.

Of course, if you look at some of the replies on Hacker News, there are people complaining that it's harder than it was 15 years ago. But they are just wrong on a technical point: the web is backwards compatible, no one is stopping you from creating a Django server, using JQuery and CSS files. But in essense, the problem is that Django, etc. was the state-of-the-art back then and all you had to do was install Python and Django (or Ruby on Rails) and you were all set. But now, the state-of-the-art is much harder to get set up. Much much harder. Yeah, create-react-app sort of gets you started. But back then, you had to learn a bit of HTML, CSS, Javascript and Django, and you were good. Now, you have to learn a lot more: you need to understand prettier, babel, webpack, React, whatever CSS framework you're using, postcss, maybe next.js or some node.js, npm/yarn. All of these have configuration files. So even if create-react-app gets you a working app in 2 seconds, to do anything, you have to learn a bit about all these technologies. This tweet is a good illustration of the problem:

Of course, this is no one's fault. Rust and Javascript are different beasts. Javascript and web technologies have developed in an extremely iterative, backwards-compatible and decentralized fashion. These 3 characteristics make it hard for Javascript to be Rust or Javascript in 2007. node.js and npm circa 2012-2014 really pushed the idea of small, single-responsbility packages and this is the consequence. I won't repeat the benefits of smaller packages and decentralization: there are several! But again, from the perspective of a newbie, you have to admit it's hard to know which testing framework or which package manager to use. Even for me, after a couple of years of not programming while I worked as a product manager, it was hard to pick up the right tools. Pro-tip: read JavaScript Rising Stars and State of JS to get a quick sense of the landscape.

I don't want to dive into static site generators and server-side generation too much but I'll just say one thing: I think they add a lot of complexity. They trade off ease of programming for ease of deployment and performance. The latter clearly helps heavy traffic websites but not amateurs and students who want the former. Gatsby for example makes you learn graphql to render even simple websites. next.js, on the other hand, defaults to sever-side generation and half the packages built for the browser won't render on the server-side.

And then there are comments like this that suggest we are running around in circles:

This article strikes me as hopelessly naive. Filled with the same kind of 'new is better and solves everything' mentality I've seen in the JS community for years. There's no desire for maturity because nothing has ever matured. Even frameworks from huge companies go through radical internal paradigm shifts every 18 months. JS runs natively in the browser. the author implies compilation is required to deploy client-side rendered websites. Sass, Less, css grid, all claimed to 'solve' CSS for whatever the problem in the mind of the author happened to be. ... more of the same.

I don't think we are going around in circles though. Tailwind, for example, truly is a better way to write CSS than everything that came before. React is a lot better than Angular 1.0, which is a lot better than pre-JSX god-knows-what (strings in PHP?). We can build and maintain large, fast web applications only on the shoulders of these technologies.

At the same time, we should strive for simplicity and programmer ease of user, the kind offered by Rust today and by Django and Rails from yesterday.

There's some hope. Rome offers this pitch:

Rome is a linter, compiler, bundler, and more for JavaScript, TypeScript, JSON, HTML, Markdown, and CSS. Rome is designed to replace Babel, ESLint, webpack, Prettier, Jest, and others.

Iteration has been good for discovery over the years and as we coalesce around good ideas, we can mature those into all-in-one tooling. Rome might or might not be a dead project, but for the benefit of all the new programmers and the sanity of existing devs, hopefully all-in-one tooling and some consolidation happens soon.