No CSS, No JavaScript. Longevity on the Web | Hacker News Reader

No CSS, No JavaScript. Longevity on the Web

jch.github.io

44 pointsjollyjerry13 comments

Left out of the post, but the stack is rails, turbo, and stimulus. Hosted on a 2016 MacBook Pro with a dead battery in my closet

I think the HTML, CSS and even JavaScript are the most stable and future-proof components of your stack. Your Rails backend, on the other hand, will experience far more changes and API instability in the long run.

JavaScript was considered as a unstable and under-specified part of the Web in the "Dynamic HTML" era somewhere between 1997-2006, when Microsoft Internet Explorer implementation of DOM diverged from more standard Netscape/Firefox in many tricky ways. This has largely been solved by better standards, initiatives like Acid tests and (unfortunately) slowly spiraling into Blink engine monoculture.

> Your Rails backend, on the other hand, will experience far more changes and API instability in the long run

I see this as different layers of stability. On the bottom is a solid foundation of web standards that's widely adopted and resilient to breaking changes. Layered on that is the web framework and language. Before ruby, I really enjoyed perl, so I've experienced the collapse of a language and community. Matz had some good insights drawn from the history of other languages https://www.youtube.com/watch?v=4MM5b2F9zrM

Javascript is fascinating because of its evolution. Its initial popularity and wide install base guaranteed a lot of resources for it to grow. I'm excited to see whether wasm can bring more languages to the web.

Totally, agree. And new HTML elements (like <dialog>) and CSS features (like MPA cross-document view transitions) have made client-side JavaScript unnecessary for a loot more use-cases in recent years. This is something a lot of devs unfortunately haven't caught up on, especially if they were stuck in their framework's tiny world.

This inspired me to explore what the simplest possible framework/site generator could be, that still has great DX: https://mastrojs.github.io/

Thanks for sharing. However, this page needs code examples front and center. I read the whole page and still have no idea of the ergonomics of the framework.

Agreed, I don't want to have to dig through documentation to get the gist of your framework/library.

The guide is concise and well written. I like how it builds in the same sequence I blogged about: HTML, CSS, JS, and introduces each in a small way with links for further study. I like how it starts with a static site, but I think the end of the guide could include an example for server side processing. It was clever to use 3rd party example like search with fetch, but an example with a small JS backend to process a form and persist to a database / file would tie it together. It sounds like server-side is out of scope for the framework, so perhaps a few examples of small backends and how to plug in?

When I was reading the header/footer section, it reminded me of this issue to push for first-class includes in web platform https://github.com/whatwg/html/issues/2791

Pretty dope stuff. My first thought with a finance tracker would have been “Dashboard? Interactivity? That’s a SPA.” Very pleased with your results.

I still do not see a future without javascript. If you are not using any external libraries, why not use it?

Just use it when it is needed. Try don't use it when it is unnecessary.

> Why not use it?

You shouldn't try and find ways to add unnecessary javascript to your page.

Some users, like journalists and the visually impaired, disable JavaScript. If you can make a product that works for them, why not do it?

Some web clients, like TTY-based clients, ignore both JavaScript AND CSS. People using these clients rightly expect to get a worse web experience overall. But if you can make a functional web page for them, why wouldn’t you?

These both sound like relatively niche edge cases. But nobody knows how things will change in the future.

Thanks for touching on accessibility. I believe that good accessibility leads to a better design. The nice thing about starting with HTML is there are good defaults.

I wrote another post about building a search form about progressively enhancing a search form (https://jch.github.io/posts/2025-01-30-building-modern-searc...). Starting with semantic <search> and <input> elements gives sane browser and screenreader behavior.

Perhaps my title came on too strong, but I'm not advocating against javascript. It's more about understanding capabilities HTML and CSS can handle, and what is better suited for JS.

Reply on news.ycombinator.com