Web development without JavaScript—is it possible or long since unrealistic?

Hey, is web development without JavaScript still realistic today—or does it put you at too much of a disadvantage? Classic server-rendered pages, forms, and progressive enhancement still work, especially for blogs, documentation, shops, or administrative interfaces. However, without client-side logic, things quickly become inconvenient for complex real-time apps, interactive dashboards, and many UI components.

Still, I wonder whether JavaScript is now used too reflexively, even when HTML and CSS would be enough. Greater robustness, better loading times, and fewer data protection headaches speak in favor of that. How much interactivity does a modern website really need, and where do you draw the line? What do you think?

25 years later, the fundamental idea is surprisingly relevant. For a blog, takeaway site, or forum, you really don't need any JavaScript; server-side forms, clean HTML, and a bit of CSS get the job done reliably. I once built a small club website entirely without JS as a test and later added just a few convenience features—in the end, the basic version was even easier to maintain.

The difference compared with back then is more that users today are accustomed to live search, filters without page reloads, autocomplete, and instant feedback. But that doesn't mean you need a complete SPA right away. I would treat JS as an optional enhancement: the core functionality must work through links, forms, and the server, while everything else can become faster or more convenient. For internal tools in particular, though, I hardly see any real advantage in avoiding it completely anymore—there, interaction often matters more than maximum simplicity.

…Treat it as an enhancement, not as the foundation. The site should also work without it: links remain links, forms are processed server-side, and JavaScript at most improves search, filtering, or previews. Especially with forms, I often see the opposite: client-side validation replaces server-side validation, even though it can easily be bypassed.

For me, the key issue is less “JavaScript yes or no” and more whether the application remains meaningfully usable without JavaScript. With small islands, such as for autocomplete or a shopping cart, you can usually find a good middle ground. Do you tend to build such features yourselves with a bit of vanilla JS, or are you turning to HTMX, Alpine.js & Co. these days?

…often actually more valuable than the supposedly modern solution. I would also distinguish between functional dependency and convenience: If JS only updates the shopping cart faster, an outage is annoying but manageable. If neither navigation, login, nor checkout works without JS, the design is simply too tightly coupled to the client.

For small islands, it also helps to set a hard boundary: no global framework, no centralized state, one small module per function, and load it only where it is needed. Especially with forms, you can also get surprisingly far with HTML attributes, server-side redirects, and targeted loading. The more interesting question, then, is really: At what point is the additional convenience truly worth the additional complexity?

…then one should also be honest and say: This is a client-side application, not a traditional website with a few extras. In such cases, “without JS” is not a meaningful quality goal, but handling failures, slow devices, and disabled scripts properly is. An understandable error message is better than an empty interface.

I would now even include the no-JS fallback in the testing process: click through important pages once with JavaScript disabled, submit forms, and check the login and ordering process. Not every convenience feature needs to remain available, but core tasks do. Do you run such tests manually, or do you already have checks for them in CI?