Web developers: take a moment to turn off javascript on your websites. If it can't be used at all--especially if the user is confronted with a blank screen--without js support, fix it. It's a bad website. #xp

@jer_ As someone who cares deeply about people in bandwidth- and battery-constrained environments, as well as privacy, I am truly sympathetic to this point of view, but I encourage you to think about the fact that React and Vue and similar JavaScript frameworks have unleashed a tremendous amount of creativity by making complex sites easy to make for a generation of developers.

And a big reason for this is that we can ship sites without a dedicated backend—which we would need to render your sites for you when you disable JS. A requirement for a backends just to render templates would be a very high obstacle for many applications and developers, in complexity, time, cost, and electricity. It simply wouldn’t make sense.

For this reason I do not consider JS-required apps as broken. Happy to consider viewpoints I’ve missed (I’m not addressing privacy because you’re addressing developers in Fediverse who presumably aren’t doing Evil Things with JavaScript).

privacy and Javascript 

@22 @jer_ if you use Cloudflare, Google, etc. scripts though those companies are doing invasive things ... not sure what you mean otherwise since many sites which require JS are powered by some form of database and my own approach to building websites is traditional

re: privacy and Javascript 

@bookandswordblog you’re right, many web apps do need a persistence layer and therefore need a backend server to either host or proxy a database, but *tons* more sites are client-side only, either interacting with public read-only data feeds (a SQLite database, REST endpoints, etc.) or don’t even use any data (I have a tiny app that creates Ruby HTML tags for me 😅 for example for East Asian languages). Such sites tend to be built by JavaScript bundlers that combine open-source libraries like React with the app’s custom code and output a static JS file that can be served by an ultra-low-cost static provider—baked not fried (aaronsw.com/weblog/000404). If I wanted to make a no-JS version of my little Ruby HTML converter site, I’d need to have a high-cost, high-electricity compute node running Node.js or Python or C application to service each visitor’s request and *dynamically* generate programmatic output.

You’re also right that many devs will host their client-side-only sites on free static providers like GitHub Pages which are built on top of CDNs and cloud storage providers that are storing and mining visitor logs. There’s some room for shenanigans. There’s also a lot of room for privacy: I can guarantee visitors to my static site that nobody will see the data they enter into it because no packet ever leaves. And static sites offer the ultimate immunity to vendor lock-in: literally anything can serve dead bytes on disk.

Hopefully this explains why I really like shifting the computing (the “frying” per Aaron Swartz) to the client with JavaScript. I am really proud of how many great apps people have made this way. We’ve probably alienated the subset of users who disable JS by unkindly forgetting to add rich <noscript> content but this was a good reminder to avoid that discourtesy.


re: privacy and Javascript 

@22 @jer_ there are some assumptions in that "client-side only" phrase (I would have thought it excluded all sites backed by databases, you seem to include sites backed with a database which visitors can't edit) which I am trying to unpack


re: privacy and Javascript 

@bookandswordblog @jer_ thanks for bearing with my incomplete walls of text! Read-only databases are topologically equivalent to static files (see the fantastic phiresky.github.io/blog/2021/h).

I even consider JavaScript apps that interact with public REST APIs like Wikipedia editor statistics or weather, etc., to be in the same family of client-side apps: they’re talking to servers hosting pure data with no rendering, and it wouldn’t make sense to ask a web developer who made a React frontend to one of those data feeds to move to a server to just to render HTML.

If you don’t need to “log in” and persist your own content on someone else’s server (so when you have no need to collaborate with other people, no need to save your work for later or access it from a different decide), client-side JavaScript is a very valid choice, with noscript content explaining to no-JS folks why they should enable JS, i.e., what the app does, as a courtesy.

re: privacy and Javascript 

@22 @jer_ I had not thought about websites which query someone else's database for their backend! The developer can definitely treat them as just the client-side.

I still don't see any justification for most types of site being unable to show their basic factual content without enabling active scripts.

re: privacy and Javascript 

@22 @bookandswordblog all of this that you're describing, though, is foisting off the developer's inexperience on the user. That's a bad web app. If there are elements of basic usability that don't have to be client-side that are exclusively client-side, that's bad implementation.

I'm not talking about elements that require client-side work, but websites who just show broken images without js (or nothing at all) are bad.

re: privacy and Javascript 

@jer_ hmmm. Again many thanks for spending time reading my scattered thoughts and thinking about and writing a reply—I am supremely grateful for your thoughtfulness.

I invite you to consider it less a matter of developer inexperience as much as a rational decision. Again, starting from the premise that JavaScript single-page app (SPA) libraries have revolutionized how we write web apps, consider a developer who reached for this tool to design her prototype and, after proving its business case, is finally evaluating whether a rewrite is warranted—that is, should she now move all the rendering logic to a backend language, in order to live up to the standards of a microscopic minority of users who turn off JS? We know she’s not neglecting users in developing countries—their phones tend to include quite capable JS runtimes—nor is she neglecting disabled users. Her choice of tooling resulted in an app that’s only “broken” in a narrowly-defined perspective that reminds me of something our hero @nolan lovingly called “tech veganism” in nolanlawson.com/2019/05/31/tec

I don’t want to try and change your mind—I personally do respect the no-JS folks and as a courtesy to them I will spell out why they should turn on JS to appreciate a site I made in the <noscript> tag. I also love exporting websites with LaTeX equations and diagrams and source code snippets fully baked to HTML and SVG, no JS needed, to enjoy that sweet static files hosting. And finally a no-JS browser is of course in my toolkit for surviving the web (along with ad blockers and DNS blockers and proxies and VPNs and virtual machines).

But I personally can totally see why something that *could* have been a static site like Imgur or Twitter or Medium still decided to do rendering and interaction to JS. To me it’s a reasonable choice and I disagree with calling them “broken”.

re: privacy and Javascript 

@jer_ @bookandswordblog (all that said of course Twitter and Reddit and Medium 🤢 are all awful websites and as a JavaScript developer they hurt my craftsperson sensibilities. Of course you shouldn’t use them, there’s better alternatives. Hopefully it’s clear enough what I mean when I say they’re not “broken”.)

re: privacy and Javascript 

@22 @jer_ @nolan I brought it up before, but what does "web app" mean to you? To me it makes no sense to call most types of websites an app, in the way a browser mail client or GIS based map maker is an app. As I and Jer said, our main objection is not to "programs in a browser" requiring active scripts but simple displays of information requiring them.

If its all one page which loads and reloads, that suggests a site is more a web app than a web page.

re: privacy and Javascript 

@bookandswordblog (dropping others) right I can see how that can be confusing. Notionally I think of a web _app_ as something that needs interactive programming (mail client, GIS, game), but that’s too innocent because it might lead you to think think bus timetables 🚌 or prose essays don’t need interactivity. However that’s only true from the _consumer_ point of view. In in our capitalistic world, the _publisher_ of such content might be very interested in knowing exactly which parts of the page you look at for how long (IntersectionObserver does this developer.mozilla.org/en-US/do), what you selected or clicked or copied, and of course when to insert an ad. Thus even these “informational displays” wind up becoming web apps 🙄.

(Despite my eye roll I don’t think it’s useful to have an automatic revulsion for such “tracking”. I’ve worked with authors of complex technical training, like that MDN link above, and these content creators are extremely interested in knowing what pages/sections were useful, how long readers dwelled on each section further broken down into how frequent a visitor they were, etc.)

re: privacy and Javascript 

@22 as someone who has been running his own sites since 2013, making money from them since 2018, and created his own static site generator in 2021, I don't need those kinds of interactivity. I track traffic by page visits. The bus system makes its money selling tickets not PII, and advertising which is targeted at page load has been an unmitigated disaster for advertisers, publishers, and the public (its great for fraudsters tho) adcontrarian.blogspot.com/2021

re: privacy and Javascript 

@bookandswordblog I mean same here, I love making static sites for myself and for my projects, I host them on GitHub Pages so I don’t even see page counts from server lots, I just don’t care. But then again every app I’ve built as a professional developer (mostly tooling for internal users) has had deep instrumentation so the owners know as much as possible about their users and their interactions with the app.

How people make money I frankly dgaf about? So long as I get paid?

re: privacy and Javascript 

@22 @nolan @bookandswordblog I have a hard time referring to removing basic functionality as "craftsmanship"

The creator isn't the arbiter of the effectiveness of the design, the user is. When we, as an industry, add bloat and complexity for reasons that don't benefit the user in any meaningful way (and in many ways injure user experience) then we're building bad software.

re: privacy and Javascript 

@jer_ @22 regarding user experience, one important reason to block scripts is to remove nagging popups asking visitors to sign in, sign up to the mailing list (which they are already on!), disable their ad blocker, fill out a poll, etc.

NoScript and UBlock Origin would not be so popular if they were just used by privacy geeks.

Its not just about privacy or saving bandwidth but about seeing the actual content without all the cruft laid around it.

re: privacy and Javascript 

@bookandswordblog @jer_ your unexpectedly generous and patient explanations convinced me it’s time to properly learn server-side rendering which is why I’m neck-deep in the Next.js documentation at 2am 😆

It turns out my intuition about the difficulty of converting a traditional React or Vue single-page app (SPA) into something more static when you also have a backend handy is at least a couple of years too old. I personally didn’t take tools like Next or Gatsby seriously because they’re outside the orbit of the core language and framework teams, but with the newfound energy to figure it out thanks to your posts, I see that these are definitely worth using and the direction the industry is heading in.

This isn’t going to solve the usability problems Sean mentioned—you can obviously do consent banners and popup forms with just HTML and CSS—and Noscript extension will continue to silently disable any interactive elements, but with Next-like tooling you’re going to get a mostly-HTML bundle on page load that then bootstraps the truly interactive JavaScript.

Well done to both of you. Someone (me) was wrong on the internet and you fixed it 😁

re: privacy and Javascript 

@jer_ also, I am impressed by all the things you can do with HTML and CSS these days! I came back to creating my static site after ten years in grad school.

If you are building a website not a web app, HTML and CSS will take you far and are more stable than third-party active scripts.

Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!