Building a front end with no JavaScript
javascript.works-hub.com
javascript.works-hub.com
Ah, it says "Originally published on dev.to." Here you go, lengthy HN discussion from just a month ago...
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.
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.
A platoon is the best that most of us could hope for.
Those that run JS will still load probably just as fast as those without it even if it's not truly "no JS."
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/
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.
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.
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.
The author also addresses your specific example (see "The Checkbox/Label Trick").
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.
> 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.
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.
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.
[1] https://dev.to/winduptoy/a-javascript-free-frontend-2d3e
I'm not arguing for use of JS, by the way (not sure if it was clear), but rather for proper use of HTML.
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.
Click a link, server replies 204, browser stays where it is. Remarkably handy and imho underutilized.
If you don’t mind a little basic JS you can do some pretty powerful things without any XHR.
usually when you're sending an xhr - you want something to change, some like status bar, cart items listing, anything
btw: you can achieve the same with simple css: `element:active` should have a background image that will perform an server side action when loaded
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.
It's tragically funny.
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 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.
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.
However, the approach of starting like you have, and adding JS only if explicitly required is great.
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.
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.
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.
Because if all JS were to go away tomorrow, and all CPU processing happened server-side, what would that change in server resource requirements?
> 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.
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.
We all can over approximate in our preferred direction.
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.
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.
"using as little JavaScript as possible"
Without, and as little as possible are mutually exclusive.
Pre-browser - ah, those were the days ;)
And next I find out it's not compatible with MS browsers. Sad.
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).