There are just too many interesting things JS can do. I've been playing around with Three.js and it's been incredible the types of 3D art you can create. I want to make those experiences for users which is simply impossible without JS.
However, I will also say that most of the websites I do make will work without JS because I use Next.js as a server rendering framework, plus CSS can handle a lot of things these days, such as modals, link trees, etc that used to require JS and I use those where possible.
What I will not do though is re-implement logic just for JS disablers. A particular example is using an animation library like Framer Motion that works with JS. It is somewhat possible to achieve similar effects in CSS, creating your own spring function in SCSS for example, to interpolate between values, but I'm not going to do that because it's effectively double the work for 1% of the users. Even the 1% figure is misleading for production apps if you use TypeScript (to prevent JS breakage) or modern dev practices like distributed CDNs (to prevent a package from getting loaded).
> I'd prefer to write js all day — but finding html and css only solutions has made me a better developer.
> It's forced me to find creative ways of solving problems — and to learn new html and css features.
...it made me think about how you can often do cool thing by taking advantage of some browser functionality, then you look it up on caniuse.com and it's only available on 75% of browsers. Much worse than using a few lines of JS that can't be used by 1% of users.
This implies that if you only did the CSS version you'd do the same amount of work as the JS version but it would work for everyone. Why wouldn't you do that? Doing only the JS version means you spend the same engineering effort but it doesn't work for as many people. Choosing to do that when you have a choice makes absolutely no sense.
> > Doing only the JS version means you spend the same engineering effort but it doesn't work for as many people
Where did I say it would be the same engineering effort? I explicitly said it's more for the CSS version. In my example, the CSS version is inferior to what the JS library can already do. Creating a spring animation is only one of the things that Framer Motion can do in JS built in. If I did everything in (S)CSS I would basically be re-implementing Framer Motion, which, as I stated, is double the work for <1% of users. Why would I want to re-implement a package when it's already there for me to use? So yes, it "absolutely makes sense" to do everything in JS only.
So. There's that.
But otherwise I'm broadly in agreement. If you're making an online application, it pretty much requires JS. Not so much for CRUD db form apps/forums/blogs/wikis etc.
If you want decent/custom FE validation you do still need it
I worry about how much of the web I will be able to use.
Don’t JS free web pages have better accessibility?
The problem is that people are getting abused, even if they don't care about it. They are unknowingly lending their computers to unknown people who use them as their tools by running code on them. My computer is my tool and nobody else's.
If website owners think it's totally fine to run code on my computer when I visit their site without my permission or knowledge, I wonder what they would think if I ran code on their servers without their permission or knowledge. That would be fair. My computer for you and your computer for me.
You are free to revoke your permission for any site to run javascript, but website owners are not obligated to go out of their way to provide their services to you if you choose to do so.
JavaScript became popular because HTML stopped moving forward as a hypermedia, focusing instead on client-side features that, while certainly nice, didn't increase the expressive power of the format in terms of hypermedia.
By sticking to a rather small selection of semantic and layout primitives with some form fields sprinkled on top, we’re forcing all the responsibility onto the individual developer. Which leads to poor performance, poor accessibility, incalculable man-hours wasted building the same things over and over.
Why isn’t there a <gallery> element that I can slot child items into and style with CSS? Or a <lightbox> element to view those items in a larger size? Or tabbed control groups? These things have existed since long before people could build rich apps on the web, and having them built into the user agent would give so much power back to the user in terms of customisation and accessibility.
It’s like HTML still lives in a world where the web is solely for documents.
[1]: http://sgmljs.net/docs/producing-html-tutorial/producing-htm...
[2]: http://sgmljs.net/docs/templating.html
(Putting transclusion into quotes here because that term is from Ted Nelson and is possibly ill-defined in a HTML/SGML context)
HTML hasn’t been SGML for a long time, and it’s never going to go back. Understanding it to be an SGML vocabulary would be a serious error. In the context of HTML, what SGML supports is even more irrelevant than it was twenty years ago (and it was pretty thoroughly irrelevant even then).
Sites people use to access vital services: you should be designing Web sites that will work on old broken devices on slow connections. 2‰ of 30 million is 60 000, a stadium full.
https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...
the 0.2% was just the deliberate disabling. The rest were all the stuff documented here:
And after that?
ZERO EXTRA WORK.
If it's really that hard for you to prerender a page on the server, then just send the text by itself. Can you do that? I don't need you to prerender your header, your footer, your menus, or any of that junk. Give me the text body. Place it in an element your JavaScript code can replace when it boots, if I choose to let it run at all, which I won't if I can avoid it.
> if I choose to let it run at all, which I won't if I can avoid it.
It's not rare for people with a security/privacy background to only allow whitelisted sites to run JS.
Nowadays every marketing person will strongly insist on producing tons of semantically meaningless "blog posts" just to generate some new "content" on the site so that google ranks it higher. The blog very rarely exists for you to just read it, most of the time it's a marketing tool supposed to steer you towards something else, and it's not in their interest to allow you to just read the text without the accompanying cruft.
I block JavaScript on my own site just to make sure.
The only web engines today are blink/geeko, financed by google(vanguard/blackrock), and webkit financed by apple(vanguard/blackrock). They are all written using c++ which has also a grotesquely and absurdely massive and complex syntax, and better not have a look at the compilers... aka double the pain.
In other words: "javascript" = don't have "big tech" controlled software? no web for you!
hard truth: bazillions of online services can work perfectly without a "javacript"-able web engine (javascript alone is some work but several orders of magnitude less), namely basic (x)html forms can do wonders... and actually they were!! But web dev tantrums and planned obsolescence got involved.
The only way out of it is very strong regulation, and I am personally seeing lawyers to seek noscript/basic (x)html interoperability on "critical online services".
What is your personal incentive to do this beyond the ideological viewpoint of not being beholden to big tech?
For the record I’m in agreement with your stance, I’m just curious about this.
Was even planing to bootstrap my own small/alternative "tech" from some small/alternative noscript/basic (x)html components. Namely without the 489374392843 devs financed by google or apple...
Not to mention, it is a quasi-monopoly: blink is a fork of webkit, and geeko is kept alive by google (probably as a protection against anti-trust regulation). It is even worse from an "owner" point of view: from a "vanguard/blackrock" point of view, this is monopoly. That would concern the general anti-trust regulating body.
There are certainly way more to that, I am discussing with lawyers what to present to the judge.
It would have been much more interesting to have ladybird written in plain and simple C (with the right compile-time and runtime function tables and NOT compiling with only gcc or clang). Maybe it is not too late to fix that.
That said the real core of the pb, is the "javascript-ed" web itself, bazillions (if not all) of critical online services should work with noscript/basic (x)html browsers.
QuickJS shows that the issue is actually the "javascript-ed" webengine and the c++ language, not solo "javascript".
Offer the minimum core functionality without js. Add js for better UX and additional functionality.
Spot on
The whole point of websites is lost if they can't track visitors, see what they're paying attention to, and how to manipulate their behavior. Everyone's doing it, and if you don't, you're at a disadvantage. There are very few websites whose purpose is not to influence you to spend money on something. Most of the articles and posts you read are AI generated, or written by "content writers" never intended to be read by actual people, they're there for the google bot to keep some activity going.
Except they are not[0]. Besides micro browsers there's screen readers that can't even use sites that customize a bunch of div elements with no accessibility tags.
And I’d say the battle has actually gained some ground in the last eight years, as server-side rendering of JavaScript content stacks has made headway.
But if I made that site with JS, and some user wrote in telling me they disabled JS and it didn’t work, I’m much more likely to tell them to either enable JS or pound sand than I am to reimplement the logic on a platform where any requests beyond 125k/mo or 100hrs compute start billing me.
It's useful for most of the reasons listed in the parent article.
You can also do quite a lot in CSS these days for interactivity - and with better performance than JS. Expand/collapse sections (with animation), menus including transition delay for more mouse forgiveness, slide out panels.. Also pretty easy to then tweak it for alternate mobile layout.
It's not 2015 or 2016 anymore, not even close. We're the better part of a decade moved on. This is not a valid argument any longer. JavaScript is a critical part of the modern web experience. You may not like it, but that doesn't change the fact.
Nothing has changed.
Source: personal experience, as one who blocks JavaScript by default because it makes the web better more than it breaks things. Also very occasional observation of people browsing the web with very similarly-configured browsers apart from the disabling of JavaScript, and of people browsing the web without even uBlock Origin or similar (and that’s really painful to watch).
This site is horrible to take advice from. I would sooner ask why other people are doing things in a given way before trusting the HN hivemind to give advice on how to build a successful product.
an immediately readable text rather than a program that tries to generate one.
<noscript><style>.js-only { display:none !important; }</style></noscript>
this won't work on failed script loads, only on actually disabled javascript, though
I don't like using <noscript> to detect absence of JS, because browsers that are blocking JS (e.g. whitelists), or even blocking some JS and allowing others to load (e.g. inline vs same-domain vs cross-domain vs tracking-blockers), haven't actually disabled JS, and won't necessarily render <noscript> even if the JS won't load.
But there are similar ways to achieve the same thing which don't suffer from this problem. Unfortunately to cover all cases they are complicated, using combinations of inline <style>, <script>, document.write, similar lines in externally loaded scripts which only run if those are loaded, and DOMContentLoaded to do the right thing if a synchronous <script> did not load after all.
Once it's done it works, but it's not trivial to work through all the cases.
Also, without JavaScript, some webapps would require storing user state in a server database rather than in memory of the browser.
Fix html and we won't need JavaScript.
I'd need a more specific example, but for user state I imagine it can be stored in json-web-tokens, or in the url, depending on if you mean like the current query or some kind of actual session data.
Jarring for the user? Are your users cavemen with severe PTSD? Loading a web page is not a "jarring" experience for anyone. Was the first load of your page "jarring"? Was loading a new page "jarring"?
This idea that users are hyper delicate flowers is ludicrous. Having a page stuck with a bunch of gray gradient placeholder elements while JavaScript loads and does whatever is far more jarring than a page that just loads.
Edit: autocorrect can get bent
If it's just your hobby site... great, develop it without JS.
But if it's a site people pay to access (or requires ads) and they expect some functionality - like Youtube or Netflix say - I don't think this is possible.
As far as I understand it, YouTube and Netflix are a nicer UX with JS but there’s no particular feature that would kill it completely.
Like, for example, I thought that you can play HLS* manifests from plain HTML5 video tags.
EDIT: I was thinking of HLS and not DASH
But HLS has wide support on mobile browsers, and on desktop Safari. (Source: https://caniuse.com/http-live-streaming.) So YouTube should in theory be able to support JavaScript-free playback for many of its users.
The whatdoesmysitecost.com links are now broken and that site as a whole seems to be fairly broken, but it was discussed here last year: https://news.ycombinator.com/item?id=27759583. They claim that the method they used to decide prices is a best-case scenario, but in reality it’s generally not far off a worst-case scenario, regularly off from the likely realistic case by at least a factor of ten. Though there certainly are scenarios where the cost will be even higher than the figure presented.
—⁂—
> Very old browsers like IE < 3, Netscape 1, Mosaic, and others don't support javascript. Almost nobody uses these browsers anymore — but you can bet somebody is.
Your site should not work in those named browsers, because you should be serving by HTTPS only (no, your general-purpose public-internet site is not an exception). And using comparatively recent cipher suites so even things like IE 8 should not work. But the likes of Lynx, sure.
—⁂—
For my part, I default to turning JavaScript off via uMatrix because it makes the web better and faster and lighter far more often than it breaks things. But I also have that extension disabled in Private Browsing windows, so if I want to run something with JavaScript I can open it that way nice and easily.
And there is still quite a lot of content out there that works without JS. For example, https://lib.rs/ is lightweight and fast pure rust alternative to crates.io that works great in my tmux session, which is pretty awesome if I'm doing rust stuff in a terminal. (it was originally written as a replacement for the official site which rejected it due to the maintaners being more familiar with their JS implementation)
The last time I was there for a week I made sure to exclusively use Firefox+NoScript and setup a number of large regions in google map caching - in past I also used Firefox data saver image option, but regrettably they removed that from the config (hm, I wonder if it's still available in about:config as a hidden option - shame they also blocked about:config unless you use a non-mozilla build)
(my suspicion is it was probably one of the many cool features lost in the rewrite)
There are still data limited cell plans in the US though. Quite a few sold by T-Mobile partner resellers as economy plans.
There is nothing inherent to the internet or the promises thereof that require the kinds of interactivity that have driven the tidal wave of front end scripting that has flooded the space. The overwhelming majority of it comes down to designers being cute for no obvious reason and business entities that aggressively abuse their client's browsers and bandwidth solely because cross-browser compatibility is notionally cheaper than maintaining software across several operating systems. The rest is monkey see monkey do.
[1] - https://ip.ohblog.org/
