Hacker News Reader

Comment by Theoleff | Hacker News Reader

The interesting part here isn’t “no JavaScript”, it’s that HTML already covers more use cases than people remember (forms, dialogs, validation, navigation).

I ran into this repeatedly while writing my book "You Don’t Need JavaScript"[0]: most JS in these cases isn’t adding capability, it’s compensating for forgotten platform features.

[0] https://theosoti.com/you-dont-need-js/

View on HN

Agreed! I assume the reason for the forgetting of the features is that at least some were poorly supported when first released so developers create workarounds that then become the de facto standard.

It has been amazing to see the speed up in release and support of new CSS features over the last couple of years! Even the masonry layout has finally reached an experimental stage

Yup, at this point it feels more like habit than necessity. People learned to build things like dropdowns in JavaScript years ago, so they keep doing it that way.

A lot of devs simply don’t look any further when it comes to what HTML and CSS already provide.

That exactly describes me. I'm not a good frontend person. I got really, really good at building desktop GUIs in Swing (Java) back in the day and really imprinted on that way of doing things. When moving to web, I found the the display landscape really challenging to grok. I read a few books and got to where I could get most of what I wanted done, but it always took me way longer than it felt like it should, and certainly much longer than it took my coworkers. In that period I learned the contemporary patterns of the day and got pretty good at using component libraries with frameworks like React and was finally able to make things look and behave more like I wanted them to.

Because at that point so much of the focus was on javascript and component libs/frameworks, I didn't (and mostly still don't) really follow browser development. I looked into things like web components when they were first talked about but found their DX to be quite sub-par (it was still pretty early days) and haven't really looked again.

I'm personally much more interested in systems, infrastructure, devops, and all things backend, so for me frontend is a necessary evil to enable me to surface controls for my stuff to users. It's not that I don't want to stay up to speed and current, it's more that in my limited bandwidth I'm more focused on what I care about. That leads to exactly the pattern you described: I learned and got comfortable with a certain paradigm in a different time, and those ways are quite engrained.

Anyway, thank you for your comment. It really helped me identify a blind spot I previously had (which I intend to rectify) :-)

Thanks for sharing that! It’s a super common story. Frontend patterns moved fast (especially for the last 3 years), and not always in a way that encouraged checking what the browser itself could already do.

If you want to improve a bit and discover more what CSS and HTML can do today, I also try to post daily on my LinkedIn: https://www.linkedin.com/in/theosoti/

Very interesting book! These are the types of programming books I wish that were more abundant rather than "Learn X framework/language," those that solve/discuss interesting problems. Just bought a copy.

Indeed the "Learn X" books may even have a vested interest in not revealing rarely used features, so that you learn to reimplement them in X.

Thank you, it means a lot!

I originally started writing it because I was tired of books becoming obsolete every two years while the underlying problems stayed the same.

Reply on news.ycombinator.com