Sourcehut has No JavaScript as one of it’s selling points, so i was wondering why it would be better that way?
It loads immediately (just flat HTML/CSS/image/font files), it does not slow down user experience in the browser, it also signals very clearly there are not weird third-party JS scripts slurping the data for whatever godawful reason.
Additionally, one can build pretty nice, responsive, fast UIs with just HTML and CSS, and browser developers spent decades optimizing their rendering engines for that. JavaScript components on the front-end tend to be buggy, slow, and just all-around shitty UI/UX.
Thanks. I think I will remove the JavaScript from the website I am working on right now. I don’t really like JavaScript anyway.
It has its place, but if it can be avoided, I believe it should. Basically, if something can be implemented using just HTML/CSS, it’s probably better to do it that way.
Fun fact, I have a large JS-based project, because what the project aims to do is impossible without JS. But the website itself is almost completely JS-free, apart from the demos (which necessarily need to use the JS-based project itself).
Awesome. I have found a way to work my project without JavaScript, and it actually makes the back-end a lot cleaner.
🎉
I’d argue that it’s not a question of yes or no, but of how much. Personally, I prefer pages that work as expected without enabling them in NoScript too, but that doesn’t extend to phones too well imho.
That’s because you’ll at least have a pretty hard time getting mobile navigation right without JavaScript, at least if you don’t want to fall back to odd tree shaped navigation menus which are always visible or something like that. There are CSS hacks for that, but those violate the distinction between content and representation.
Violating the distinction between content and representation in the form of a few hidden radioboxes or checkboxes to be able to make a JS-less menu strikes me as a reasonable trade-off in a lot of cases.
Pretty advanced UIs things can be done using just CSS. For example, this little tidbit of mine. It’s not mobile-optimized, but that’s beside the point — the point is a complex interface done without a line of JS. Making it mobile-optimized is possible too, of course.
I see your point. On the page that I’m building, the mobile navigation menu is the only usage of Javascript and I think that’s reasonable (desktop users are way more likely to disable JS than mobile users, for whom you should optimize anyway in most cases). Of course, there are other use cases where content is really dynamic (e.g. Etherpad), which you just can’t tackle with only HTML & CSS.
In my opinion, it’s those little things that JS is good at and CSS is (currently) not. JS is a tool, neither more nor less, and like with all tools, it’s more important what you do with them than what tool you use.
That’s not to say that I’m not in line with you that 95-99% of all JS code in modern web pages is bloat in the best case and acting against the users interest (like by spying on them) in most others, and I’m in no way an apologist for it. Condemning its usage altogether throws the baby out with the bathwater though imho.
Oh, and on performance: JS is pretty optimized today as well. A lot of waiting for modern web pages is due to loading of external resources, which would hardly be any faster if done in C*. In conclusion, we’re blaming the language for what people do with it. 😉
* I’m not saying that 3rd party assets are necessary or good, it’s just an observation
Sure, I think we basically agree.
There are things that are impossible without JS, and there are things that are possible without it but JS is still the better choice for implementing them — as long as it’s not the bloated mess, pulling random libraries from a dozen third party services, that we know and “love” from a lot of websites. And as long as there is graceful degradation built-in.
Absolutely. 🙂
I whitelist-enable JS with ublock on a per-site and it’s so satisfying being able to fully use a website with JS disabled.
It really depends on how interactive the site needs to be. Managing the state of the UI on the frontend makes sense for sites where there is a lot of dynamic content. An email app is a good example. On the other hand, something like a blog or a news site likely doesn’t need a lot of interactivity. Also worth noting that htmx is an interesting compromise.
