I feel like it’s possible to be way too puritanical about these things. Absolutely, JS bloat is an issue. But JS isn’t inherently bad, and removing it can make the user experience worse, not better.
Take HN, for example. The [-] button to collapse a thread is really useful. But if it had to POST back to the server and reload the entire page just to hide a thread I wouldn’t use it anywhere near as much.
Progressive enhancement : make your website work with no javascript and no CSS trick (CSS is not for behavior). Then use JS to add dynamic behavior on the client.
This is the approach I have always tried to take. Unfortunately it seems that most employers now want Angular/React/Vue experience so you wind up with devs shoving it in to projects where it's not really needed just to get that experience. Such is the state of Resume Driven Development.
"No JS" sounds better than "Almost no JS except for a line or two for minor usability enhancements."
What's the difference between a site with no JS and a site that has a few lines of inline JS to handle expanding and collapsing comments? Probably nothing, but one sounds better. It's just like how you never hear people bragging about being almost-completely-vegan-except-for-that-one-egg-sandwich-a-month.
You can't disable javascript in a browser, but leave "a few minor javascript improvements". So the difference is between allowing all the ad tech, surveillance, malware or not.
Which is fine. If all your JS is doing is adding a few QoL features like collapsing comments, then your site will still be completely usable if the client chooses to not run JS.
Those that run JS will still load probably just as fast as those without it even if it's not truly "no JS."
You can do a lot more than nothing about isolating unwanted javascript. Ublock origin, noscript, privacy badger, use one of many curated hosts files, etc..
If you disable JS on HN that button goes away, but you can still up / down vote. I like that, I wonder if the [-] could be implemented in CSS though, I feel like it can.
If you use the checked state to of a checkbox to change the display property (i.e. toggle between none and initial), that will change the content's visibility and its availability to screen readers.
As I do hacky work on the web I sometimes wonder why specific UI elements don't exist yet instead of people being forced to hack other elements to do things the web doesn't support. I can't remember a good example off the top of my head currently sadly.
For something fancier it would be possible to style a label with appropriate for="" attribute and hide the checkbox completely, then even apply some transitions: https://jsfiddle.net/6bgemn0s/1/
I have a similar aversion to JS as the author, but unfortunately it's still the best tool for the job in manipulating the DOM.
Phoenix LiveView looks really cool. Under the hood though it's injecting JS that diffs the current DOM and the new DOM and renders the changes rather than the entire tree. At the end of the day, it's still a JS enhancement.
...and end up keeping a websocket open, transferring far more than 30kb or even 100kb in state changes over the lifetime of the app, while also using up the devices battery and data limits? friendly reminder that 100kb of js can be cached on the device, while a stateful websocket obviously can not.
While we're here, Server Sent Events (SSE) over HTTP2/3 (which websockets doesn't support) is apparently more battery friendly for phones. Symfony recently got support for SSE using the mercure protocol, it would be lovely if more backend frameworks had first class support for SSE.
It definitely seems like two extremes right now. Personally I think we should strive for minimalism when working with JS. Things get bloated very quickly when non-technical departments have requests (tracking, A/B testing, ads, etc). These things often cannot be pushed back on.
My feelings are that front end devs should focus on performance by reducing what is in their control -- basically dependencies and overengineered clients
> Your frontend can't crash if you don't use JavaScript. HTML doesn't throw exceptions. Less code is always better.
Less code is not always better.
I'm aware that the example I chose here is similar to the checkbox trick the article outlines but I'm using it as an example of how JS can improve UI, not as a direct rebuttal to the article.
The checkbox trick itself sounds like an accessibility nightmare, so again, you're not necessarily serving the user's best interest by doing code parkour to avoid two lines of JavaScript.
There’s also nothing stopping you from generating broken HTML or CSS on the server that won’t be interpreted as anything useful by the browser. Or messing up your CSRF tokens so that your forms don’t work. Or having broken links.
Puritanical, and many of the options seem superficial / impractical.
The point about form validation is always made in these types of articles and every time I do form validation I find the built in options too limited. I've used them here or there, but they're hardly a snap in replacement for anything.
And validating them in the backend isn't really viable either if you remove js entirely. No way to send the input to server without a page refresh, which would break the workflow
If you think along these lines but also want some nice realtime interactivity check out the recently released Phoenix Live View which is a very clever system that allows you to push changes automatically to your client based on server rendered template diffing: https://github.com/phoenixframework/phoenix_live_view
the demos coming out that use this already look pretty awesome (chris mccord has been RT’ing them: https://twitter.com/chris_mccord). Also, would much rather debug Elixir than pretty much anything in the mess that is the Javascript ecosystem
Yes! I am so excited by this. For those that don’t know, Phoenix is a UI framework for Elixir, which is a more productive flavor of Erlang (citation needed).
If you think high reliability and a superb concurrency model is something that might be valuable in a web UI...check out this project! I am desperately seeking a good excuse to build something with this.
Sorry, no you didn't. I misread their website and thought they had some novel way of getting around javascript. Like those games that use checkboxes for state instead of js.
> Even with JavaScript disabled, end-users and crawlers alike will receive HTML as expected. After the HTTP request, the live view connects to the server and is upgraded to a stateful process.
> Has anyone tried modifying the description of a card in Asana lately? It's freaking slow! The UI lags for no good reason as you type.
I'm glad to see Asana called out on this. I swapped form Trello to Asana at the request of a client about 12 months ago. The feature set is comprehensive but performance is bafflingly woeful. I cannot begin to fathom what they're doing that causes my i7 to come to a screeching halt every time I drag a card from one column to the next.
The biggest problem IMO with JS and performance is event listeners.
If they setup event listeners on each card, talk, etc. it could easily kill performance.
Turns out this is easily solved by setting up a single event listener on the root element (body, #app, etc.) and then checking the event.target to see what changed.
I never noticed nor this nor the edit issue after using Asana for years now. It's probably not a CPU issue, I have i5, but it's baffling how different experiences can be for webapps.
WorksHub dev here. JS (actually ClojureScript compiled to JS) is essential for most of our platform to function, but we're working on server-side rendering of our public pages so that they don't need JS. We've just not rolled it out fully yet.
The mentioned "Checkbox/Label Trick" seems to be getting somewhat popular, but that's quite a hack and abuse of HTML semantics. Hacks like that (and this one in particular) lead to issues for browsers with CSS unused/disabled/altered, quite similarly to reliance on JS.
I'm also very dubious about the accessibility implications. Hidden checkboxes and labels covering the entire screen don't feel great, though it's not my area of expertise.
Disabled CSS would leave such form still usable. It wouldn't look, and behave exactly as intended, for sure, but I suppose these days no one expects unchanged user experience while disabling CSS. Meanwhile, disabled JS on JS-based forms usually kills them.
HTML/CSS as in the example would indeed be usable, though a similar version of this (with inline labels and checkboxes used for "aside" notes) gets rather messy when used in a textual browser or converted into another format. JS-based expansion doesn't have to get unusable either (it can merely hide bits of a document after loading, with those present in HTML), but perhaps could become unusable more easily.
I'm not arguing for use of JS, by the way (not sure if it was clear), but rather for proper use of HTML.
Would it be more fair to say it's an abuse of CSS? FWIW, I think it's a brilliant and simple solution, though the general sibling combinator sometimes feels like cheating in the best way possible.
> Would it be more fair to say it's an abuse of CSS?
In the sense of "improper usage", it applies to the resulting HTML with any CSS or without it at all; CSS is merely used here to make it look fine in some cases.
Hacks can be clever and amusing (I was amused by this one too), but usually get rather annoying as they get used widely and break things.
204s are more reliable. The "cascading" in "cascading style sheets" means they are designed and intended to be overridden. The user can and often does apply their own custom CSS.
I don't mind a few Javascript here and there if it's really needed.
But the JS abominations that were created in recent years it's completely beyond me, ironically those are the same people who insist in killing JQuery because it's "old & bloated" and "we don't need it anymore" but those people only use Chrome.
Ironically, the largest element of the website is the poorly optimized, almost 400kb hero image. After running it through https://tinyjpg.com/ I got it down to 75kb.
>The more code you have, the less agile you are. Code is a liability, not an asset. It's like tar. JavaScript libraries are getting bigger all the time and I don't think that many people are critically evaluating the actual need for them. People frequently measure JavaScript in KB or MB as if it is just a download cost. But it's not. You also have to wait for the CPU to parse/execute it. It all adds up.
I have mixed feelings about that first line. A lot of JavaScript is there to provide features and "flexibility" that otherwise would not be there....
It's hard to have this conversation as the usual statements about pages loading "too much" javascript are true-ish generally. But there are plenty of web apps that use framekworks that do great things with "too much" javascript. Yet the assumption seems to be there's a huge amount of "too much" and it's all bad and so it's discussed globally and good tools and ideas are kinda washed over with a sort of javascript paranoia.
Meanwhile a lot of these articles present personal pages or fairly limited functionality (often who have javascript on their page...). I find them interesting and fun to read from a technical perspective, but some of the implications seem to pine for the days where the web was simpler (I miss those days too in some ways) but where functionality would also be lost.
This is very much a case where i don't disagree with any given tidbit, but I do with the implications and application, if that makes sense.
Hacker News is an interesting place and while I'm kinda a n00b when it comes to web development it feels like it is a very "server side" world on HN and discussions about the front end are sometimes a bit skewed.
I have noscript that disables scripts by default. I can't read forbes, but I don't miss it, there's a lot of other internets that I can read. Should I even try to read forbes?
I feel like the folks running with no javascript already made their call, and that's their call.
If you're developing a web app that "does a lot" (I'm just going to say that rather than get into individual things) It's pretty hard to do without javascript. But if it's a site just serving up text and pics, yeah you don't "need" it.
It is refreshing to see a push towards better user experience by reducing JavaScript overhead. I imagine that many development groups building massive client-side SPA's have convinced themselves and others that the "developer convenience" it provides is worth the cost to the users.
Ironically, there are massive improvements to be made by rewinding back to the "DHTML" days of delivering most of the content traditionally and progressively enhancing with a little JS. Except we have much better JS in the browsers and don't even need things like JQuery any more.
Back-end frameworks like Rails and Symfony really help as well, by separating concerns (such as models, controllers, and templates) and keeping the code clean that produces the bulk of the app.
> ...encourage those who reach for a SPA for every project to give it a second thought.
Every time this subject comes up I always get a sense of "These hipster kids are bad programmers and their react apps are killing the web" from the anti-JS crowd.
To me, this feels like the developer equivalent of blaming immigrants and poor people for systemic economic issues.
Directing your ire at the "Show HN: Look at my React app" or the kid at your meetup, or even your issue tracker, is an easier target, but not the correct one.
People reach for SPAs because:
1. Unified development experience for interactivity provides very good developer ergonomics.
2. Dirt-cheap, stupid-simple, five-nines reliable hosting as static assets on S3 or equivalent.
So long as these developer-quality-of-life advantages exist, people will choose them, especially for independent projects. Yes, there are downsides with bloat on initial-load, yes there are web apps that would be better served as server-generated HTML.
The "bloat" problem is mostly coming from content-heavy sites from media companies that keep injecting tons of various scripts for ads, tracking, and other BS. These organizations have no excuse, and should definitely not be using an SPA if they are, but they will keep doing it so long as the economic incentives of these scripts persist.
Edit: PS, I fully support articles like this and welcome discussion on better ways to build web apps. Hopefully we'll figure out a way to have the best of both worlds. Some attempts have existed but are nascent or die quickly before they can mature. Its a difficult problem.
I think the web is a great target for apps. The other app platforms are either proprietary or have negligible market share. The web as a platform for distributing applications is a better alternative than desktop platforms that are either fragmented or a monopoly.
The abomination is turning web pages into javascript apps when HTML would be a better choice. The browser already has the capability to render text and images. News articles and blogs are better served as static content than as apps that run in the browser.
The Chrome-only web future we're heading towards is as proprietary as it gets, and absurdly complex and unfit at the same time for demanding desktop apps people actually would want to use (audio, video, CAD, etc.). Google have successfully infiltrated web standard bodies and competitors to the point these are financially dependent on Google, successfully convincing younger devs that the web is a non-proprietary community effort.
As improbable as it sounds, your best bet for a portable desktop app seems X-Windows (1980's tech) or Qtk. Unless you wanted a shitty privacy-invading Web app, or one where the site owner can shut down your app and data at any time.
It sounds like your comment was meant to be snarky, but it is an interesting question. When you push the CPU processing of the UX from the mobile device back down to the server, the energy consumption certainly moves. Does it decrease, though?
Because if all JS were to go away tomorrow, and all CPU processing happened server-side, what would that change in server resource requirements?
I'm not convinced that tightening up web development practices is what's going to solve climate change, but:
> When you push the CPU processing of the UX from the mobile device back down to the server, the energy consumption certainly moves. Does it decrease, though?
One could argue that developers/website owners might be more motivated to optimize their server code for performance, thereby decreasing their hosting bills, vs optimizing front-end code which they don't pay to run.
You're assumption that it'd move server side is incorrect. It would simply disappear. When you use a javascript library the browser has to process and load all the functions in the library, even the functions that aren't used. This wastes memory and processing cycles on the client computer.
> When you use a javascript library the browser has to process and load all the functions in the library.
That simply isn't true. Your device does load a library (usually minified), and parses the JS to be sure it is runnable. But it doesn't run every function just because it is loaded in memory. Even if it did, it happens on app load, once... then runs functions on-demand. And the size of the load can be mitigated with appropriate use of tree-shakable libraries. But without JS, the server regenerates an entire page, every time you do something, which takes some resources. It sends it over the wires, which takes some small amount of resources. The mobile device loads an entire page again.
I do agree there is wasted processing in both scenarios. But that waste doesn't just disappear when you do server-side work.
Their machine is already on and idle, by pushing processing onto the backend your just creating a provisioning issue where either under or over provisioning is a waste of people's time or resource.
No. If I want to use an old computer I shouldn't have to wait forever for content because someone thought the client should do the work. That's a bigger waste of my time than your server capacity issues.
If the client device is a desktop computer, sure. Typically, the client is a mobile device whose bandwidth and energy are precious commodities. In these cases, better for the server to do the heavy lifting.
Separating form from content (xhr based) allows for better caching and overall respond better to changing demands, therefore limit the need for over-capacity. I think it is a null sum game between the two options.
Lowtech magazine investigated energy efficient web experience a few years ago, and the conclusion was much simpler. If we really want to have an impact on the energy, don't use white background in your design and use the default font, dithered images, reduce dynamic content and don't have the server running 24/7.
I just want to say your about page is fantastic! Your Privacy section is short and to the point. Also love how up front you are on how the site is sustainable.
I built front ends for industry for 14 years without JavaScipt. Nuclear power plants, battle ships, manufacturing plants, electric grids, air traffic control systems.
Unless you have at least 20 developers for Frontend alone, don't even bother with SPA applications. I assure that the result will be much worse than a regular web app with server side rendering and some AJAX. The only good SPA applications I've seen were developed by huge companies like Microsoft or Google and smaller companies don't have the resources for that.
I'm deploying a simple SPA I wrote as a sole developer for a client later this week, and the clients have been thrilled with it so far. I've written less code than in other traditional webapps, the app is responsive and works well, and I know that sudden changes in server infrastructure (they're on-prem hosted and looking at moving to a Windows/IIS environment) aren't going to require a full-on rewrite.
I think that's probably the sweet spot for SPAs though honestly - small scope internal apps (served over relatively quick intranet connections) with access to minimal client infrastructure (all you need is a web browser).
Ah, it says "Originally published on dev.to." Here you go, lengthy HN discussion from just a month ago...
https://news.ycombinator.com/item?id=19367149