Stuff Everybody KnowsJavaScript & When You Need It
The most important thing is not to use it.
Now let’s talk about JavaScript, starting with what I’m not going to tell you: how to write it.
Firstly, I assume you already know how to write it. You’re a web developer! But also and more importantly: there’s no single right way to write JavaScript, and nowadays you’re probably not going to be writing it yourself anyway, so you don’t need to care. Pick a framework, and let your agent get on with it. But before you do that, there are important things to consider which will inform what you tell your agent to build.
You don’t always need an app
If you don’t tell your agent what it should build, the chances are that it will build a rich web app in a framework like — in 2026 — Next.js. That’s because it’s well-known, it’s very flexible, and it’s extremely thoroughly documented, both through its own official documentation and through millions of tutorials across the web. It’s a solid choice, but not always the best one.
A rich web app has trade-offs. It takes longer to load. It’s more complex. If you don’t put in quite a lot of extra effort, it probably won’t render until all the JavaScript loads and executes, which is a huge problem for:
- Web crawlers, which don’t always execute JavaScript
- LLM-powered agents, which often summarize the text content of a page without JavaScript
- People on slow or mobile connections, who may get interrupted halfway through loading your heavy-ass JavaScript site
Ask yourself: what is your site for? Is it an application — a photo editor, an email client, something where people land and spend a long time interacting with it? Or is it something where displaying information as fast as possible is the goal — like a news site?
My favorite canonical example of a site that isn’t a rich web app and should never be is The New York Times. The purpose of every page on the New York Times is to display an article of news. The only thing you do on the New York Times is land on a page, read it, maybe scroll a bit, and leave. There’s almost no interactive functionality (and when there is, it’s often painfully annoying). It will always be a flat website because that’s what serves its users best.
My favorite example of a rich web app that should be a rich web app is Gmail. You load Gmail maybe once per day, if that, and then you keep it open in a tab forever. Gmail has a loading screen. Almost no popular web apps can get away with loading screens, but Gmail can because it adds a ton of functionality that you load once and then runs in the background, loading and saving and sending your emails. If you had to load a whole new web page every time you took an action on GMail, it would be excruciating.
So you should think about what kind of audience you’re building for, and whether the complexity and slowness of a rich web app is going to buy you anything.
Progressive enhancement
You should also consider progressive enhancement. Progressive enhancement is an old idea that keeps gaining relevance. It’s easily expressed as a question: what happens to your website if JavaScript is turned off?
That sounds like a stupid question: everybody runs JavaScript! Yes, but here’s the thing: 100% of your users run with JavaScript disabled until all of the JavaScript has loaded. It’s the last thing to happen. And a lot can happen in between somebody requesting your website and it actually loading.
If your page is loading on a phone and the connection gets interrupted halfway through — because they’re on a train and went in a tunnel, or they’re inside a building — suddenly no JavaScript loads, and your entire website doesn’t work. If what you’re trying to do is sell something or inform somebody, and your website doesn’t function unless every last bit of code loads and executes perfectly, you’re failing your users.
What you want to do is get the information onto the screen as fast as you possibly can, and then enhance it with interactivity later. There’s ways to do this both with and without frameworks, but it is not how most rich web-app frameworks work by default.
Server-side rendering: the best of both worlds
If you’re really committed to a rich web app, you can get the best of both worlds with server-side rendering. You deliver actual HTML immediately — it works, it’s readable, it’s fast — and then you hydrate it with JavaScript so it becomes fully interactive.
My favorite example is Google Sheets. It’s a tremendously complicated web application. But if you’ve ever paid close attention to loading a Google spreadsheet, you might have noticed something interesting: the thing it sends you and the thing you end up using are two totally different things.
What it does first is send you a plain HTML table — the first visible portion of the spreadsheet, containing all the data on the first sheet. Then, while your slow monkey brain is looking around for the first button to click, it’s frantically loading an entirely separate, complex web app in the background and swapping it in seamlessly.
Google built it this way because it was absolutely worth the effort to show you the spreadsheet as fast as possible and give your brain something to do while the real application loaded behind the scenes. It’s an excellent example of progressive enhancement, and how to build for impatient users.
We’ll talk more about users and how incredibly impatient they are later, but for now let’s dig deeper into user experience.