13 ms·

Your website should work without JavaScript (2021)

129 points by nameequalsmain 4y ago

solardev 4y ago
- paulryanrogers 4y ago
  Does Next SSR like this also submit traditional web forms and handle them server side? Or would that count as the 20% that's unsupported?
  - solardev 4y ago
    I would say forms are an adjacent technology. There is nothing inherent in React or JS that would either magically make or break forms. A form is just an bunch of input fields and a submit handler. If you write your fields as real HTML input fields (instead of, say, weird bespoke divs that happen to have key handlers, yuck), you can still add JS to them for autocomplete and validation and such. But they'll still work without JS. The other part is the submit handler. If you capture the submit button onclick to do something (like submit it using AJAX) then that won't work. But it's easy to add a HTTP POST fallback, and honestly that should be a best practice with or without Next. It's been like that since the jQuery days and before. Beyond that, I can't think of anything specifically involved in SSR that would affect forms. Have an example? Edit 1: If you're using a third-party module/framework/service to create a form, whether it will work with JS depends on its specific implementation. The MUI framework, for example, has higher-order form input abstractions (like the <Input> component here https://mui.com/base/react-input/#introduction https://mui.com/base/react-input/#introduction) that depend on React and JS, but are really just wrappers around the HTML <input> element. It will still accept text without JS, just lose some of its secondary features. On the other hand, with something like Typeform... I couldn't even get the actual form to load without JS enabled: https://www.typeform.com/templates/t/demo-feedback-form-template/ https://www.typeform.com/templates/t/demo-feedback-form-temp... Edit 2: I thought of another way to interpret your question. In addition to the frontend parts of Next, which the above addresses, Next also has API endpoints and edge functions that can act as form handlers if you want them to. That only works if you're hosting on a live Node server (like Vercel), not if you're baking to static clientside HTML for CDN distribution. (The difference between `next start` and `next build`) But that's kinda a tortured way to deal with form submissions. Usually the webforms would POST to someplace that's a preexisting business requirement (a Salesforce or Hubspot endpoint, for example, or even an email address), so you don't really have to use the Next middleware to handle submissions. You COULD do that in Next if you really wanted to, but I wouldn't myself... it would just be reinventing the wheel for no good reason.
  - onion2k 4y ago
    That depends on how the dev building the site writes them. They can work but they usually don't.
- chrismorgan 4y ago
  But it’s also frightfully easy with such stacks to end up with invisibly broken functionality, e.g. a form that you maybe even intended to work without JavaScript, but accidentally broke in some way; or a widget that is just blank in the HTML and gets filled afterwards (this is very common). As an example of that: in https://www.joshwcomeau.com/css/custom-css-reset/ https://www.joshwcomeau.com/css/custom-css-reset/, the first code block is a loading spinner. Why it’s different from the second one which has the content unhighlighted in a pre tag, I have no idea. And then later on there’s the “code playground” widget, which works (so long as you don’t try editing it), including syntax highlighting this time. Why? I can’t be bothered speculating. All I mean to convey is that the likes of Next.js aren’t a panacea: you do still need to be aware of what’s going on and sometimes adapt your code to work with Next.js. 80%, as you said. And as an example of another sort of unnecessary brokenness, there’s a “Show more” later in that page that should have been serialised as a <details> element, but it’s done as a <button>. Here the lesson is: lean on what HTML offers, where possible.
  - solardev 4y ago
    Good points. I might even go a step further and say that not only should you be AWARE of how your page behaves after the magic (what breaks without JS, what doesn't), you should deliberately pick and CHOOSE what's OK to break and what is essential content, and design around it. An example: At my last job (a museum), accessibility was a business need (and grantmaker requirement), and part of that is ensuring that our content was accessible by people using screen readers. At the same time, the website was owned by the marketing department, who had strong thoughts on design and "modern" UX. It was a constant tug-of-war between the two and the JS had to be carefully balanced. For something as simple as a list of exhibitions or blog posts, it was essential that everybody and any browser be able to see a list with titles, a short blurb, and a thumbnail. That was the "must-have". Nobody should be excluded from reading our actual content. Then, because we have posts stretching back years, we also wanted a good filtering system, so people could search for certain topics or keywords or whatever. That's the "nice to have" that we decided was OK to sacrifice for certain edge cases. It is possible to write such a system using plain HTML (by sending HTTP GETs/POSTs and having the backend do the filtering). But such a system was much much slower for the user (multiple seconds instead of single-digit milliseconds, because the backend had to process the request, generate the HTML, and send the whole HTML back... instead of client-side JS that can just filter an already-loaded array in a few milliseconds, or at most request a JSON of filtered post summaries that's much much smaller than a full HTML page). So we looked at our analytics and determined that almost nobody (< 1%) was using the filtering system at all. Mostly people were just going directly to individual blog posts (social shares or whatever) or looking at the top few most recent ones. It was such a rarely used feature to begin with that we decided that it was OK to sacrifice for the non-JS users. I'm not saying that this is the ideal approach, just that it is AN approach -- dictated more often by business needs and resource limits, not developer ideologies. Some of our peer institutions (other museums) went opposite ways... some wrote in pure HTML and a sprinkling of bespoke vanilla JS, with very fast and lean pages that didn't have much clientside interactivity. Others went to the other end of the spectrum, creating richly animated interactive stories that are more like a educational game than a webpage. As a developer I have my own preferences on such things, but in the grand scheme of things, our ideologies rarely matter. What practical frameworks like Next do is allow us to find an acceptable middle-ground between a lot of stakeholders, balancing UX, DX, DevOps, business requirements, resource costs, etc. Next is itself a frankenstein of technologies -- mirroring the modern JS and cloud service ecosystem -- that doesn't try to preach any particular ideology. It looks at the chaos out there, accepts it for what it is, and tries to harness the bits and pieces of it that makes sense to use in an average website. I think it does a pretty good job. You can, of course, make similar evaluations and tradeoffs as an individual dev. But it's a LOT of work to think through and build and maintain. It was easy to make a JS site and no-JS site side-by-side back in the day (along with frames and no frames!), but that's not really a practical approach for the complexities of modern sites and stakeholders; it would increase development time by an order of magnitude or more. Progressive enhancement is great for simple sites that are really more "documents" than "apps", but even that starts to break down once you move from "documents" to "document store", as in you have a pile of documents originated from some content management system / production pipeline / editorial review process that multiple stakeholders work on together. At an organization of any real scale, you can't have your webmaster editing raw HTML every time somebody wants to update a blog post. Web dev isn't a place for purists. The whole history of the web is "hack on top of hack". HTML is a barebones document markup language more aligned with Gopher than modern web apps, and JS itself was a me-too panicked reaction to Java (and later, ActiveX and Flash). That it grew to such popularity was an unfortunate coincidence of history, as the lowest common denominator that browser vendors could accept. V8's massive improvements to the JS runtime cemented its own fate, taking the web from "JS is useful for adding a little bit of interactivity" to "JS is now fast enough to BE the web". Now V8 is pretty the de facto operating system of the web, for better or worse. As individual developers, this isn't a system we work in, it's a system we work around because it's just what history left us. Every page we build is a hack on top of a hack, a workaround for another workaround that somebody wrote into spec or engine a decade ago for the needs of those days. I hate it as much as anyone, but until we can get a new web ecosystem (crypto-web doesn't count), we're just kinda stuck with it...
- mro_name 4y ago
  > a lot better than having your site break altogether. that's a humble baseline, isn't it?
  - solardev 4y ago
    It's better than nothing, though. Often the alternative isn't "let's not use a JS framework and just build a bare HTML site from scratch", but rather "let's just use the framework and forget about the few users who disable JS." So while Next & SSR isn't a perfect solution, it is often the only practical thing to do when the team or company doesn't want to spend resources on a no-JS solution.
fexelein 4y ago
As recent as 2016 I was building some sites without any JavaScript. These weren’t small sites either. You can achieve a lot using some basic forms. It was quite fun
- edfletcher_t137 4y ago
  "I Turned Off JavaScript for a Whole Week and It Was Glorious - Wired 2015" 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.
  - mattl 4y ago
    The problem is that JavaScript is used for tons of garbage purposes too. I wish for more control in my browser over what is running
    - edfletcher_t137 4y ago
      Faulting a technology for its malicious uses is a common fallacy, but a fallacy nonetheless. Not saying you're wrong (you're not), but it's not a valid argument against JavaScript.
      - shkkmo 4y ago
        It's not an argent against javascript but against enabling javascript by default.
      - dijit 4y ago
        If something is ubiquitous it will be used in its most extreme negative form. This is why things being generally available that have the potential to be harmful causes such a debate, because on the one hand it’s useful, on the other it’s harmful. The reason people blame the tool is because the tool enabled people to be able to maximise their harm, and people will maximise harm when given the opportunity. In this case: JavaScript enables people to externalise their processing cost into people’s own computers, which is a huge potential for harm as it’s a really asymmetric power dynamic.
dusted 4y ago
is it even a website if it does not work without javascript, https and websafe colors?
- mattl 4y ago
  I don’t think people worry about websafe colors anymore, as displays have moved beyond 256 colors
encryptluks2 4y ago
Once WASM becomes popular almost no website will work without JavaScript.
- mattl 4y ago
  Why would people use WASM for their HTML content?
  - encryptluks2 4y ago
    Because that is what new frameworks are doing.
    - chrismorgan 4y ago
      There are situations where JavaScript is being replaced with WebAssembly. There are absolutely no situations where serialised HTML is being replaced with WebAssembly.
      - encryptluks2 4y ago
        I see it all the time. Tons of sites out there are replacing standard HTML with JS and won't even work without JS.
        chrismorgan 4y ago
        I said nothing about replacing HTML with JavaScript.
        encryptluks2 4y ago
        That is what these frameworks will do.
      - cercatrova 4y ago
        Flutter web is one of them. It displays on a canvas element. In the future with WASM, I expect the same thing, a Rust web app that also displays on a canvas for example.
unreal37 4y ago
I guess it depends if your website does something valuable or substantial. 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.
- dijit 4y ago
  I’m genuinely curious: why would Netflix or YouTube not work without JS? 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
  - chrismorgan 4y ago
    No browser supports DASH any more; Edge 12–18 did, but that was lost in the Chromium shift. (Source: https://caniuse.com/mpeg-dash https://caniuse.com/mpeg-dash.) But HLS has wide support on mobile browsers, and on desktop Safari. (Source: https://caniuse.com/http-live-streaming https://caniuse.com/http-live-streaming.) So YouTube should in theory be able to support JavaScript-free playback for many of its users.
    - dijit 4y ago
      Whups! Thanks for pointing that out! Do you think that difference would materially affect whether YouTube or Netflix could exist as a website in a meaningful way without JavaScript? By meaningful: would it fulfil its core competence of finding videos and streaming them to the browser?
      - chrismorgan 4y ago
        For regular viewers, the only pieces of functionality I can immediately think of that couldn’t readily be done sans-JavaScript are search autocomplete, annotations, end cards, auto-play (to the next video), and maybe quality selection (I’m fuzzy on what HLS actually lets you do, never actually worked with it). Even things like voting and commenting are fairly straightforward to do basically, though you could do vastly better with an auto-resizing iframe (https://github.com/whatwg/html/issues/555 https://github.com/whatwg/html/issues/555) which would basically allow you to load new content into the document with a click (though it’ll clutter the history and make the back button behave surprisingly, see also https://github.com/whatwg/html/issues/6501 https://github.com/whatwg/html/issues/6501 on that).
sweetheart 4y ago
I’ve found that the best browsing for me has been a result of disabling HTML and CSS as well. No errors, 0 load time, accessible to anyone even if they don’t have a computer or internet connection. Websites built without JS is cute but if you’re serious about fast, accessible, error-free browsing then using HTML and CSS is really just bloat.
- edfletcher_t137 4y ago
  The infinitely-fast web! LMAO well played.
- kgbcia 4y ago
  i agree. we need a browser that connects to port 80, remove all <.*> tags using regexp and put all links at the bottom like a true document format.
  - abnry 4y ago
    I enjoy browsing with curl and discarding the bodies of http requests. The headers give me all I need.
- rado 4y ago
  There are such apps (pay for parking with SMS) and work just fine.
- deleted 4y ago
  [deleted]
  - deleted 4y ago
    [deleted]
- LinuxBender 4y ago
  I like the idea. Lets try it out. [1] [1] - https://ip.ohblog.org/ https://ip.ohblog.org/
- Kudotap 4y ago
superkuh 4y ago
It's pretty simple. If you're doing it for profit, use whatever is cheapest/fastest (ie, JS devs and their transient frameworks). If you're making a website for human people meant to last more than 3 years, use HTML.
- deleted 4y ago
  [deleted]
lagrange77 4y ago
I guess in real world scenarios, progressive enhancement is the way to go for many sites (like embedded web interfaces). Offer the minimum core functionality without js. Add js for better UX and additional functionality.
- edfletcher_t137 4y ago
  "Everything in moderation" Spot on
kgbcia 4y ago
i don't think vanilla html saves more bandwidth than JavaScript. if a part of your website needs update (react,vue,fetch) only that part is transmitted over the wire. It's also less jarring for the user, since most browsers would scroll the content to the top. 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.
- traverseda 4y ago
  When you're using a server side template all your queries happen on the server in one request. Most react/js apps I've seen need to do a bunch of requests to get that same data, one request for content, another for author profile, another for comments, etc. Maybe with non-rest-ish page specific endpoints. 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.
- giantrobot 4y ago
  > It's also less jarring for the user, 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
- int_19h 4y ago
  The bandwidth you save with partial updates has to be weighed against the size of React/Vue/whatever that had to be downloaded in the first place in order to enable them.
chrismorgan 4y ago
> Downloading d3.js (a popular graphing library) costs 1 cent in Canada. In Mauritania it costs 0.06% of the average daily income. 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 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.
- deleted 4y ago
  [deleted]
- hunter2_ 4y ago
  Those bits about the price in Canada feel like clickbait: technically possible, but with caveats learned only after clicking, like perhaps it's only experienced by people with non-Canadian SIMs who decide to use a terrible roaming plan instead of something better? But with the links being dead, this is just speculation -- not writing in this format (of third-party dependencies filling in what appear to be major gaps) would've been helpful to avoid such speculation in case I'm entirely off-base and that truly is the price of data somewhere.
  - capitainenemo 4y ago
    I don't know about actual canadian prices, but I do visit canada periodically, and only once was I in a position to go through the complexity of acquiring a roaming SIM. My cost is 20¢ per megabyte. 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.
recursivedoubts 4y ago
I would very much like for HTML to incorporate concepts from htmx (particularly more flexible transclusion) so that more dynamic websites and applications can be built entirely in HTML. 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.
- tannhaeuser 4y ago
  Agree, but HTML itself doesn't have and doesn't need "transclusion" when HTML is understood to be an SGML vocabulary and SGML has all these things and more, from basic sharing of headers/footers and other markup fragments [1] to parametric macro expansion and event-based templating [2]. [1]: http://sgmljs.net/docs/producing-html-tutorial/producing-html-tutorial.html http://sgmljs.net/docs/producing-html-tutorial/producing-htm... [2]: http://sgmljs.net/docs/templating.html 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)
  - chrismorgan 4y ago
    > when HTML is understood to be an SGML vocabulary and SGML has all these things and more 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).
- JakeAl 4y ago
  MS had a great solution back in the day with their Dynamic HTML. The anti-MS community opted for what we have been left with instead of adopting what MS came up with. DHTML was pretty awesome. https://archive.org/details/dynamichtmlrefer00redm https://archive.org/details/dynamichtmlrefer00redm
  - int_19h 4y ago
jakear 4y ago
This is the site in question: https://missingdice.com/dice-roller/ https://missingdice.com/dice-roller/. It’s a nice site, I like it. 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.
Lucent 4y ago
This proved tricky for me because of Core Web Vitals. I made ptable.com work without JS, but I still show "dead" interactive components (the properties area above) because expanding it when JavaScript arrives would destroy my Cumulative Layout Shift score.
- asddubs 4y ago
  give everything that is supposed to be js-only a class called js-only (or whatever) and then just do: <noscript><style>.js-only { display:none !important; }</style></noscript> this won't work on failed script loads, only on actually disabled javascript, though
  - jlokier 4y ago
    A .no-js class is sometimes handy too, instead of or in addition to .js-only. 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.
abemassry 4y ago
I read HN a lot, this topic always comes up so I said “I’m going to build a site that makes these readers happy. Take all their advice, no JS at all. Everything done in HTML. Everything they’re asking for” Turns out the hardest thing to do is to get people to use your site.
- bee_rider 4y ago
  The annoyance features like JS can only cause us to leave a site we were already interested in.
- preommr 4y ago
  > Take all their advice 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.
  - cercatrova 4y ago
    Ironic, isn't it, when HN is directly related to a startup accelerator with many successful products and companies.
- nicbou 4y ago
  Content is king, in the end. However serving it in a nice packaging never hurts.
ravenstine 4y ago
I don't care so much when a site with lots of interactivity requires JavaScript, but holy heck, do few things piss me off more than a blog site with articles that require JavaScript just to read text! Whomever writes web software to do that should be ashamed of themselves. 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.
- deworms 4y ago
  The point is that you're not supposed to receive the text by itself, the text is only there to entice you to visit the site, but you're supposed to click links, subscribe to the newsletter, get tracking scripts served to you, and buy whatever product/service they're luring you towards with those blog posts. 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.
- tail_exchange 4y ago
  Just out of curiosity - why is this such a big deal? Personally, as long as the page has a good UI, I couldn't care less if it is being prerendered or not.
  - Zak 4y ago
    The comment you replied to says > 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.
    - deworms 4y ago
dehrmann 4y ago
About a decade ago, the internet disagreed, and everything started requiring JS.
- forgetfreeman 4y ago
  s/internet/money 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.
- deleted 4y ago
  [deleted]
- simonw 4y ago
  Right, and now that we've spent a full decade exploring that route together we should be in a great position to step back and ask ourselves if it turned out to be a good decision.
TimPC 4y ago
Why you should double your workload in designing a website to support 2 in 1000 users. By said no PM ever.
- 2b3a51 4y ago
  Commercial site, personal blog, social media &c yes, of course, you are right 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-effectiveness-of-simple-html/ https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...
  - capitainenemo 4y ago
    ... also the original article said 1%, so that's really 300 000. the 0.2% was just the deliberate disabling. The rest were all the stuff documented here: https://kryogenix.org/code/browser/everyonehasjs.html https://kryogenix.org/code/browser/everyonehasjs.html
- mamcx 4y ago
  It reduces the workload. Using htmx + tailwindcss means to me I could duplicate all the functionality of a eCommerce backend in mere a week for something that I was, unfinished, doing in vue for almost a year. And after that? ZERO EXTRA WORK.
deworms 4y ago
Purists who refuse to load websites with JS are such a small percentage of visitors they can be safely ignored. It's an uphill battle that they're losing very fast. I don't think you can use more than 5% of websites without JS in any capacity. 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.
- chrismorgan 4y ago
  As a practising JavaScript-decliner for a few years: your “only 5% work” figure is wildly, extremely wrong. It depends a little on what types of sites you’re dealing with, but for contenty sites rather than appy sites, I’d put it past 95%, with a few notable major site exceptions (so that by content it may well be below 95%) and certain subcategories that are more commonly broken. 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.
- giantrobot 4y ago
  > Purists who refuse to load websites with JS are such a small percentage of visitors they can be safely ignored. 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. [0] https://24ways.org/2019/microbrowsers-are-everywhere/ https://24ways.org/2019/microbrowsers-are-everywhere/
  - deworms 4y ago
    For most commercial purposes screen readers can be safely ignored, they are not used by big spenders. Social share cards can be previewed readily and easily prepared without impacting the main content of the website.
throw_m239339 4y ago
Your mobile website certainly should require as little javascript as possible. You don't know what app the user is running in the background on what phone, so your tests on high end devices do not represent the experience of your visitors. There is no need for these drawer menus (often slow) or complex interactive filters that need 50 AJAX calls. Also the cookie consent modals have become the bain of mobile web experience, especially when they pop up 5 seconds after the user started to read your page on mobile phone. Don't use a modal dialogue, just make a page with the cookie consent and then re-direct to the requested page. What works on desktop don't automatically work on mobile just because you slapped a few media queries in your page.
cercatrova 4y ago
I used to think this. I even used uMatrix (RIP) to disable all JS. After a while though, it simply wasn't worth it. You'll have a vocal minority on HN of JS disablers, but the truth is most people don't know or care about JavaScript, much less want to disable it. So, it's really not worth catering to this 0.2% or even 1% of people as the article cites. 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).
- oblak 4y ago
  I am a js disabler who writes js for a living. "Apps" are hard without js. Not worth it and I do not expect anything complex or interactive to work. Stuff like HN and news/forums function just fine without, though. And that is great.
- tbran 4y ago
  I agree. Javascript can do cool stuff. When the author said: > 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.
- deleted 4y ago
  [deleted]
verisimilitudes 4y ago
I go further than handwritten HTML and CSS. I also have a Gopher hole. The only advantage a browser such as Emacs' eww has over an Emacs Gopher client is that eww is included by default. It also leads to good practices such as avoiding superfluous images and styling. Another advantage is the relatively small set of people using Gopher, meaning people who use it are more likely to reach out or similar things, like the older Internet.
labrador 4y ago
I'm not convinced by the reasons put forth in the article
mro_name 4y ago
> Building everything you can without js will make your site: an immediately readable text rather than a program that tries to generate one.
sylware 4y ago
The real pertinent reason to regulate and to get noscript/basic (x)html web portals (at least on "critical" online services) is that "javascript" requires a grotesquely and absurdely massive and complex web engine, including its SDK. 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".
- thex10 4y ago
  > 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.
  - sylware 4y ago
    My government regulating body in charge of preserving interoperability with small /alternative tech and stability in time, at least for critical online services, is not doing its job. 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.
- 4y ago
zaptheimpaler 4y ago
I make sure that my websites require JS to function even if not needed just to annoy the blockers. It's 1% of users demanding the world bend to fit their preferences, like a lot of annoying vocal minorities.

paulryanrogers 4y ago
Does Next SSR like this also submit traditional web forms and handle them server side? Or would that count as the 20% that's unsupported?
- solardev 4y ago
  I would say forms are an adjacent technology. There is nothing inherent in React or JS that would either magically make or break forms. A form is just an bunch of input fields and a submit handler. If you write your fields as real HTML input fields (instead of, say, weird bespoke divs that happen to have key handlers, yuck), you can still add JS to them for autocomplete and validation and such. But they'll still work without JS. The other part is the submit handler. If you capture the submit button onclick to do something (like submit it using AJAX) then that won't work. But it's easy to add a HTTP POST fallback, and honestly that should be a best practice with or without Next. It's been like that since the jQuery days and before. Beyond that, I can't think of anything specifically involved in SSR that would affect forms. Have an example? Edit 1: If you're using a third-party module/framework/service to create a form, whether it will work with JS depends on its specific implementation. The MUI framework, for example, has higher-order form input abstractions (like the <Input> component here https://mui.com/base/react-input/#introduction https://mui.com/base/react-input/#introduction) that depend on React and JS, but are really just wrappers around the HTML <input> element. It will still accept text without JS, just lose some of its secondary features. On the other hand, with something like Typeform... I couldn't even get the actual form to load without JS enabled: https://www.typeform.com/templates/t/demo-feedback-form-template/ https://www.typeform.com/templates/t/demo-feedback-form-temp... Edit 2: I thought of another way to interpret your question. In addition to the frontend parts of Next, which the above addresses, Next also has API endpoints and edge functions that can act as form handlers if you want them to. That only works if you're hosting on a live Node server (like Vercel), not if you're baking to static clientside HTML for CDN distribution. (The difference between `next start` and `next build`) But that's kinda a tortured way to deal with form submissions. Usually the webforms would POST to someplace that's a preexisting business requirement (a Salesforce or Hubspot endpoint, for example, or even an email address), so you don't really have to use the Next middleware to handle submissions. You COULD do that in Next if you really wanted to, but I wouldn't myself... it would just be reinventing the wheel for no good reason.
- onion2k 4y ago
  That depends on how the dev building the site writes them. They can work but they usually don't.
chrismorgan 4y ago
But it’s also frightfully easy with such stacks to end up with invisibly broken functionality, e.g. a form that you maybe even intended to work without JavaScript, but accidentally broke in some way; or a widget that is just blank in the HTML and gets filled afterwards (this is very common). As an example of that: in https://www.joshwcomeau.com/css/custom-css-reset/ https://www.joshwcomeau.com/css/custom-css-reset/, the first code block is a loading spinner. Why it’s different from the second one which has the content unhighlighted in a pre tag, I have no idea. And then later on there’s the “code playground” widget, which works (so long as you don’t try editing it), including syntax highlighting this time. Why? I can’t be bothered speculating. All I mean to convey is that the likes of Next.js aren’t a panacea: you do still need to be aware of what’s going on and sometimes adapt your code to work with Next.js. 80%, as you said. And as an example of another sort of unnecessary brokenness, there’s a “Show more” later in that page that should have been serialised as a <details> element, but it’s done as a <button>. Here the lesson is: lean on what HTML offers, where possible.
- solardev 4y ago
  Good points. I might even go a step further and say that not only should you be AWARE of how your page behaves after the magic (what breaks without JS, what doesn't), you should deliberately pick and CHOOSE what's OK to break and what is essential content, and design around it. An example: At my last job (a museum), accessibility was a business need (and grantmaker requirement), and part of that is ensuring that our content was accessible by people using screen readers. At the same time, the website was owned by the marketing department, who had strong thoughts on design and "modern" UX. It was a constant tug-of-war between the two and the JS had to be carefully balanced. For something as simple as a list of exhibitions or blog posts, it was essential that everybody and any browser be able to see a list with titles, a short blurb, and a thumbnail. That was the "must-have". Nobody should be excluded from reading our actual content. Then, because we have posts stretching back years, we also wanted a good filtering system, so people could search for certain topics or keywords or whatever. That's the "nice to have" that we decided was OK to sacrifice for certain edge cases. It is possible to write such a system using plain HTML (by sending HTTP GETs/POSTs and having the backend do the filtering). But such a system was much much slower for the user (multiple seconds instead of single-digit milliseconds, because the backend had to process the request, generate the HTML, and send the whole HTML back... instead of client-side JS that can just filter an already-loaded array in a few milliseconds, or at most request a JSON of filtered post summaries that's much much smaller than a full HTML page). So we looked at our analytics and determined that almost nobody (< 1%) was using the filtering system at all. Mostly people were just going directly to individual blog posts (social shares or whatever) or looking at the top few most recent ones. It was such a rarely used feature to begin with that we decided that it was OK to sacrifice for the non-JS users. I'm not saying that this is the ideal approach, just that it is AN approach -- dictated more often by business needs and resource limits, not developer ideologies. Some of our peer institutions (other museums) went opposite ways... some wrote in pure HTML and a sprinkling of bespoke vanilla JS, with very fast and lean pages that didn't have much clientside interactivity. Others went to the other end of the spectrum, creating richly animated interactive stories that are more like a educational game than a webpage. As a developer I have my own preferences on such things, but in the grand scheme of things, our ideologies rarely matter. What practical frameworks like Next do is allow us to find an acceptable middle-ground between a lot of stakeholders, balancing UX, DX, DevOps, business requirements, resource costs, etc. Next is itself a frankenstein of technologies -- mirroring the modern JS and cloud service ecosystem -- that doesn't try to preach any particular ideology. It looks at the chaos out there, accepts it for what it is, and tries to harness the bits and pieces of it that makes sense to use in an average website. I think it does a pretty good job. You can, of course, make similar evaluations and tradeoffs as an individual dev. But it's a LOT of work to think through and build and maintain. It was easy to make a JS site and no-JS site side-by-side back in the day (along with frames and no frames!), but that's not really a practical approach for the complexities of modern sites and stakeholders; it would increase development time by an order of magnitude or more. Progressive enhancement is great for simple sites that are really more "documents" than "apps", but even that starts to break down once you move from "documents" to "document store", as in you have a pile of documents originated from some content management system / production pipeline / editorial review process that multiple stakeholders work on together. At an organization of any real scale, you can't have your webmaster editing raw HTML every time somebody wants to update a blog post. Web dev isn't a place for purists. The whole history of the web is "hack on top of hack". HTML is a barebones document markup language more aligned with Gopher than modern web apps, and JS itself was a me-too panicked reaction to Java (and later, ActiveX and Flash). That it grew to such popularity was an unfortunate coincidence of history, as the lowest common denominator that browser vendors could accept. V8's massive improvements to the JS runtime cemented its own fate, taking the web from "JS is useful for adding a little bit of interactivity" to "JS is now fast enough to BE the web". Now V8 is pretty the de facto operating system of the web, for better or worse. As individual developers, this isn't a system we work in, it's a system we work around because it's just what history left us. Every page we build is a hack on top of a hack, a workaround for another workaround that somebody wrote into spec or engine a decade ago for the needs of those days. I hate it as much as anyone, but until we can get a new web ecosystem (crypto-web doesn't count), we're just kinda stuck with it...
mro_name 4y ago
> a lot better than having your site break altogether. that's a humble baseline, isn't it?
- solardev 4y ago
  It's better than nothing, though. Often the alternative isn't "let's not use a JS framework and just build a bare HTML site from scratch", but rather "let's just use the framework and forget about the few users who disable JS." So while Next & SSR isn't a perfect solution, it is often the only practical thing to do when the team or company doesn't want to spend resources on a no-JS solution.

As recent as 2016 I was building some sites without any JavaScript. These weren’t small sites either. You can achieve a lot using some basic forms. It was quite fun

edfletcher_t137 4y ago
"I Turned Off JavaScript for a Whole Week and It Was Glorious - Wired 2015" 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.
- mattl 4y ago
  The problem is that JavaScript is used for tons of garbage purposes too. I wish for more control in my browser over what is running
  - edfletcher_t137 4y ago
    Faulting a technology for its malicious uses is a common fallacy, but a fallacy nonetheless. Not saying you're wrong (you're not), but it's not a valid argument against JavaScript.
    - shkkmo 4y ago
      It's not an argent against javascript but against enabling javascript by default.
    - dijit 4y ago
      If something is ubiquitous it will be used in its most extreme negative form. This is why things being generally available that have the potential to be harmful causes such a debate, because on the one hand it’s useful, on the other it’s harmful. The reason people blame the tool is because the tool enabled people to be able to maximise their harm, and people will maximise harm when given the opportunity. In this case: JavaScript enables people to externalise their processing cost into people’s own computers, which is a huge potential for harm as it’s a really asymmetric power dynamic.

dusted 4y ago

is it even a website if it does not work without javascript, https and websafe colors?

mattl 4y ago
I don’t think people worry about websafe colors anymore, as displays have moved beyond 256 colors

encryptluks2 4y ago

Once WASM becomes popular almost no website will work without JavaScript.

mattl 4y ago
Why would people use WASM for their HTML content?
- encryptluks2 4y ago
  Because that is what new frameworks are doing.
  - chrismorgan 4y ago
    There are situations where JavaScript is being replaced with WebAssembly. There are absolutely no situations where serialised HTML is being replaced with WebAssembly.
    - encryptluks2 4y ago
      I see it all the time. Tons of sites out there are replacing standard HTML with JS and won't even work without JS.
      - chrismorgan 4y ago
        I said nothing about replacing HTML with JavaScript.
        encryptluks2 4y ago
        That is what these frameworks will do.
    - cercatrova 4y ago
      Flutter web is one of them. It displays on a canvas element. In the future with WASM, I expect the same thing, a Rust web app that also displays on a canvas for example.

unreal37 4y ago

I guess it depends if your website does something valuable or substantial. 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.

dijit 4y ago
I’m genuinely curious: why would Netflix or YouTube not work without JS? 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
- chrismorgan 4y ago
  No browser supports DASH any more; Edge 12–18 did, but that was lost in the Chromium shift. (Source: https://caniuse.com/mpeg-dash https://caniuse.com/mpeg-dash.) But HLS has wide support on mobile browsers, and on desktop Safari. (Source: https://caniuse.com/http-live-streaming https://caniuse.com/http-live-streaming.) So YouTube should in theory be able to support JavaScript-free playback for many of its users.
  - dijit 4y ago
    Whups! Thanks for pointing that out! Do you think that difference would materially affect whether YouTube or Netflix could exist as a website in a meaningful way without JavaScript? By meaningful: would it fulfil its core competence of finding videos and streaming them to the browser?
    - chrismorgan 4y ago
      For regular viewers, the only pieces of functionality I can immediately think of that couldn’t readily be done sans-JavaScript are search autocomplete, annotations, end cards, auto-play (to the next video), and maybe quality selection (I’m fuzzy on what HLS actually lets you do, never actually worked with it). Even things like voting and commenting are fairly straightforward to do basically, though you could do vastly better with an auto-resizing iframe (https://github.com/whatwg/html/issues/555 https://github.com/whatwg/html/issues/555) which would basically allow you to load new content into the document with a click (though it’ll clutter the history and make the back button behave surprisingly, see also https://github.com/whatwg/html/issues/6501 https://github.com/whatwg/html/issues/6501 on that).

sweetheart 4y ago

I’ve found that the best browsing for me has been a result of disabling HTML and CSS as well. No errors, 0 load time, accessible to anyone even if they don’t have a computer or internet connection. Websites built without JS is cute but if you’re serious about fast, accessible, error-free browsing then using HTML and CSS is really just bloat.

edfletcher_t137 4y ago
The infinitely-fast web! LMAO well played.
kgbcia 4y ago
i agree. we need a browser that connects to port 80, remove all <.*> tags using regexp and put all links at the bottom like a true document format.
- abnry 4y ago
  I enjoy browsing with curl and discarding the bodies of http requests. The headers give me all I need.
rado 4y ago
There are such apps (pay for parking with SMS) and work just fine.
deleted 4y ago
[deleted]
- deleted 4y ago
  [deleted]
LinuxBender 4y ago
I like the idea. Lets try it out. [1] [1] - https://ip.ohblog.org/ https://ip.ohblog.org/
Kudotap 4y ago

superkuh 4y ago

It's pretty simple. If you're doing it for profit, use whatever is cheapest/fastest (ie, JS devs and their transient frameworks). If you're making a website for human people meant to last more than 3 years, use HTML.

deleted 4y ago
[deleted]

lagrange77 4y ago

I guess in real world scenarios, progressive enhancement is the way to go for many sites (like embedded web interfaces). Offer the minimum core functionality without js. Add js for better UX and additional functionality.

edfletcher_t137 4y ago
"Everything in moderation" Spot on

kgbcia 4y ago

i don't think vanilla html saves more bandwidth than JavaScript. if a part of your website needs update (react,vue,fetch) only that part is transmitted over the wire. It's also less jarring for the user, since most browsers would scroll the content to the top. 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.

traverseda 4y ago
When you're using a server side template all your queries happen on the server in one request. Most react/js apps I've seen need to do a bunch of requests to get that same data, one request for content, another for author profile, another for comments, etc. Maybe with non-rest-ish page specific endpoints. 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.
giantrobot 4y ago
> It's also less jarring for the user, 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
int_19h 4y ago
The bandwidth you save with partial updates has to be weighed against the size of React/Vue/whatever that had to be downloaded in the first place in order to enable them.

chrismorgan 4y ago

> Downloading d3.js (a popular graphing library) costs 1 cent in Canada. In Mauritania it costs 0.06% of the average daily income. 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 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.

deleted 4y ago
[deleted]
hunter2_ 4y ago
Those bits about the price in Canada feel like clickbait: technically possible, but with caveats learned only after clicking, like perhaps it's only experienced by people with non-Canadian SIMs who decide to use a terrible roaming plan instead of something better? But with the links being dead, this is just speculation -- not writing in this format (of third-party dependencies filling in what appear to be major gaps) would've been helpful to avoid such speculation in case I'm entirely off-base and that truly is the price of data somewhere.
- capitainenemo 4y ago
  I don't know about actual canadian prices, but I do visit canada periodically, and only once was I in a position to go through the complexity of acquiring a roaming SIM. My cost is 20¢ per megabyte. 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.

recursivedoubts 4y ago

I would very much like for HTML to incorporate concepts from htmx (particularly more flexible transclusion) so that more dynamic websites and applications can be built entirely in HTML. 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.

tannhaeuser 4y ago
Agree, but HTML itself doesn't have and doesn't need "transclusion" when HTML is understood to be an SGML vocabulary and SGML has all these things and more, from basic sharing of headers/footers and other markup fragments [1] to parametric macro expansion and event-based templating [2]. [1]: http://sgmljs.net/docs/producing-html-tutorial/producing-html-tutorial.html http://sgmljs.net/docs/producing-html-tutorial/producing-htm... [2]: http://sgmljs.net/docs/templating.html 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)
- chrismorgan 4y ago
  > when HTML is understood to be an SGML vocabulary and SGML has all these things and more 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).
JakeAl 4y ago
MS had a great solution back in the day with their Dynamic HTML. The anti-MS community opted for what we have been left with instead of adopting what MS came up with. DHTML was pretty awesome. https://archive.org/details/dynamichtmlrefer00redm https://archive.org/details/dynamichtmlrefer00redm
- int_19h 4y ago

jakear 4y ago

This is the site in question: https://missingdice.com/dice-roller/ https://missingdice.com/dice-roller/. It’s a nice site, I like it. 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.

Lucent 4y ago

This proved tricky for me because of Core Web Vitals. I made ptable.com work without JS, but I still show "dead" interactive components (the properties area above) because expanding it when JavaScript arrives would destroy my Cumulative Layout Shift score.

asddubs 4y ago
give everything that is supposed to be js-only a class called js-only (or whatever) and then just do: <noscript><style>.js-only { display:none !important; }</style></noscript> this won't work on failed script loads, only on actually disabled javascript, though
- jlokier 4y ago
  A .no-js class is sometimes handy too, instead of or in addition to .js-only. 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.

abemassry 4y ago

I read HN a lot, this topic always comes up so I said “I’m going to build a site that makes these readers happy. Take all their advice, no JS at all. Everything done in HTML. Everything they’re asking for” Turns out the hardest thing to do is to get people to use your site.

bee_rider 4y ago
The annoyance features like JS can only cause us to leave a site we were already interested in.
preommr 4y ago
> Take all their advice 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.
- cercatrova 4y ago
  Ironic, isn't it, when HN is directly related to a startup accelerator with many successful products and companies.
nicbou 4y ago
Content is king, in the end. However serving it in a nice packaging never hurts.

ravenstine 4y ago

I don't care so much when a site with lots of interactivity requires JavaScript, but holy heck, do few things piss me off more than a blog site with articles that require JavaScript just to read text! Whomever writes web software to do that should be ashamed of themselves. 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.

deworms 4y ago
The point is that you're not supposed to receive the text by itself, the text is only there to entice you to visit the site, but you're supposed to click links, subscribe to the newsletter, get tracking scripts served to you, and buy whatever product/service they're luring you towards with those blog posts. 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.
tail_exchange 4y ago
Just out of curiosity - why is this such a big deal? Personally, as long as the page has a good UI, I couldn't care less if it is being prerendered or not.
- Zak 4y ago
  The comment you replied to says > 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.
  - deworms 4y ago

dehrmann 4y ago

About a decade ago, the internet disagreed, and everything started requiring JS.

forgetfreeman 4y ago
s/internet/money 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.
deleted 4y ago
[deleted]
simonw 4y ago
Right, and now that we've spent a full decade exploring that route together we should be in a great position to step back and ask ourselves if it turned out to be a good decision.

TimPC 4y ago

Why you should double your workload in designing a website to support 2 in 1000 users. By said no PM ever.

2b3a51 4y ago
Commercial site, personal blog, social media &c yes, of course, you are right 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-effectiveness-of-simple-html/ https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiven...
- capitainenemo 4y ago
  ... also the original article said 1%, so that's really 300 000. the 0.2% was just the deliberate disabling. The rest were all the stuff documented here: https://kryogenix.org/code/browser/everyonehasjs.html https://kryogenix.org/code/browser/everyonehasjs.html
mamcx 4y ago
It reduces the workload. Using htmx + tailwindcss means to me I could duplicate all the functionality of a eCommerce backend in mere a week for something that I was, unfinished, doing in vue for almost a year. And after that? ZERO EXTRA WORK.

deworms 4y ago

Purists who refuse to load websites with JS are such a small percentage of visitors they can be safely ignored. It's an uphill battle that they're losing very fast. I don't think you can use more than 5% of websites without JS in any capacity. 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.

chrismorgan 4y ago
As a practising JavaScript-decliner for a few years: your “only 5% work” figure is wildly, extremely wrong. It depends a little on what types of sites you’re dealing with, but for contenty sites rather than appy sites, I’d put it past 95%, with a few notable major site exceptions (so that by content it may well be below 95%) and certain subcategories that are more commonly broken. 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.
giantrobot 4y ago
> Purists who refuse to load websites with JS are such a small percentage of visitors they can be safely ignored. 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. [0] https://24ways.org/2019/microbrowsers-are-everywhere/ https://24ways.org/2019/microbrowsers-are-everywhere/
- deworms 4y ago
  For most commercial purposes screen readers can be safely ignored, they are not used by big spenders. Social share cards can be previewed readily and easily prepared without impacting the main content of the website.

throw_m239339 4y ago

Your mobile website certainly should require as little javascript as possible. You don't know what app the user is running in the background on what phone, so your tests on high end devices do not represent the experience of your visitors. There is no need for these drawer menus (often slow) or complex interactive filters that need 50 AJAX calls. Also the cookie consent modals have become the bain of mobile web experience, especially when they pop up 5 seconds after the user started to read your page on mobile phone. Don't use a modal dialogue, just make a page with the cookie consent and then re-direct to the requested page. What works on desktop don't automatically work on mobile just because you slapped a few media queries in your page.

cercatrova 4y ago

I used to think this. I even used uMatrix (RIP) to disable all JS. After a while though, it simply wasn't worth it. You'll have a vocal minority on HN of JS disablers, but the truth is most people don't know or care about JavaScript, much less want to disable it. So, it's really not worth catering to this 0.2% or even 1% of people as the article cites. 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).

oblak 4y ago
I am a js disabler who writes js for a living. "Apps" are hard without js. Not worth it and I do not expect anything complex or interactive to work. Stuff like HN and news/forums function just fine without, though. And that is great.
tbran 4y ago
I agree. Javascript can do cool stuff. When the author said: > 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.
deleted 4y ago
[deleted]

verisimilitudes 4y ago

I go further than handwritten HTML and CSS. I also have a Gopher hole. The only advantage a browser such as Emacs' eww has over an Emacs Gopher client is that eww is included by default. It also leads to good practices such as avoiding superfluous images and styling. Another advantage is the relatively small set of people using Gopher, meaning people who use it are more likely to reach out or similar things, like the older Internet.

labrador 4y ago

I'm not convinced by the reasons put forth in the article

mro_name 4y ago

> Building everything you can without js will make your site: an immediately readable text rather than a program that tries to generate one.

sylware 4y ago

The real pertinent reason to regulate and to get noscript/basic (x)html web portals (at least on "critical" online services) is that "javascript" requires a grotesquely and absurdely massive and complex web engine, including its SDK. 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".

thex10 4y ago
> 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.
- sylware 4y ago
  My government regulating body in charge of preserving interoperability with small /alternative tech and stability in time, at least for critical online services, is not doing its job. 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.
4y ago

zaptheimpaler 4y ago

I make sure that my websites require JS to function even if not needed just to annoy the blockers. It's 1% of users demanding the world bend to fit their preferences, like a lot of annoying vocal minorities.