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?

    This post has been automatically translated.

  • In my small, self-created projects, I have so far hardly ever used JavaScript. They included two blogs, a mini forum, the website of a small snack bar, and a webring. Back then, PHP, HTML, MySQL, and CSS were the tools I used to achieve my goals.

    My main concern was simplicity, as well as the fact that many of my acquaintances and I myself were permanently online using "No Script" as a browser add-on. Perhaps I should also mention that this was more than 25 years ago.

    This post has been automatically translated.

    Ich kaufe ein "F" und möchte lösen: 🔳uck A🔳D!

  • 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.

    This post has been automatically translated.

  • …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?

    This post has been automatically translated.

  • …are these small islands also deliberately kept separate, or does everything end up in one big frontend bundle after all? That’s exactly where things can quickly get uncomfortable in my experience: “just autocomplete” turns into five libraries, a build step, and 300 KB of JavaScript for an input field.

    That’s why progressive enhancement seems like the most sensible middle ground to me. The server-side version is the working foundation; JavaScript can make it more convenient. In a shopping cart, for example, that could mean quick updates without a page reload—but a normal form submission should still work. A little less magic on the web is often surprisingly easy to maintain.

    This post has been automatically translated.

  • …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?

    This post has been automatically translated.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!