Out with the JavaScript, in with the HTML
Brajeshwar
34 points
7 comments
May 11, 2026
Related Discussions
Found 5 related stories in 92.4ms across 8,303 title embeddings via pgvector HNSW
- I don't chain everything in JavaScript anymore AllThingsSmitty · 18 pts · April 20, 2026 · 59% similar
- JavaScript Is Enough arbayi · 20 pts · March 22, 2026 · 58% similar
- Saying goodbye to asm.js eqrion · 351 pts · May 20, 2026 · 55% similar
- HTML-in-Canvas Demos simonpure · 24 pts · May 19, 2026 · 54% similar
- Show HN: µJS, a 5KB alternative to Htmx and Turbo with zero dependencies amaury_bouchard · 124 pts · March 07, 2026 · 52% similar
Discussion Highlights (4 comments)
recursivedoubts
the web platform is making slow and not-so-steady progress as a hypermedia system, but things do seem to be picking up a bit we are working on a proposal to bring more general transclusion and a few other things here: https://triptychproject.org
paularmstrong
This is a weirdly unpopular opinion here when it comes to HTML & JS, but there's a time and place for everything. This is a neat small example, but hardly worth the effort of changing something that was already working fine. With the change, I now need another roundtrip network request to get new sizes of the same content on the current page that would have been able to be done in just a couple hundred bytes of JavaScript. Edit: also there is still no view-transition support on Firefox.
zamadatix
I feel like the option for simplicity lies between "web component" and "make 4 pages". Something near "the button changes the CSS variable controlling the size". You lose out on pre-downscaled images but gain that the images look sharper for high DPI users and don't have to maintain the image sets or deliver multiple copies when the size changes.
DLA
Love this approach and use it often, usually with a Go backend. Blazing fast, simple, respects the way the web is supposed to work. Really nice touch using the CSS transitions.