Building a front end with no JavaScript

https://javascript.works-hub.com/learn/a-javascript-free-frontend-61275

by dbnotabb • 7 years ago

171 104 7 years ago

Bravo. Does anybody know of an energy-efficieny criterion or so to drive the 201x's webapp abominations out of existence going forward?

codingdave2• 7 years ago

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?

lefty2• 7 years ago

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.

Quarrelsome• 7 years ago

surely the more the client can do, the better.

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.

cjmoran• 7 years ago

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.

loudmax2• 7 years ago

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.

tannhaeuser2• 7 years ago

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.

batmansmk• 7 years ago

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.

h43z• 7 years ago

Nice. I always try to follow the rule don't do it in code when it can be done in markup (and/or css).

pmarreck3• 7 years ago

The reason why this is preferential is probably due to the fact that markup and CSS are declarative while JS is procedural

0n34n7• 7 years ago

Nice! It's all about use case - for example, creating an invoice on a mobile device with spotty connectivity will not work.

However, the approach of starting like you have, and adding JS only if explicitly required is great.

nissarup• 7 years ago

But you do need JavaScript to read the article about building a front end with no JavaScript...

aflag• 7 years ago

And it's actually quite heavy to load.

defanor4• 7 years ago

It says it's a repost from dev.to[1], which doesn't require JS to function.

[1] https://dev.to/winduptoy/a-javascript-free-frontend-2d3e

nathell• 7 years ago

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.

adregan• 7 years ago

Previous discussion here (article was originally posted on dev.to): https://news.ycombinator.com/item?id=19367149

andy_ppp2• 7 years ago

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

pmarreck3• 7 years ago

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

FiddlyPack• 7 years ago

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.

arnvald• 7 years ago

Small correction: Phoenix is a web framework, not a UI framework.

plopz2• 7 years ago

How does that do websockets without javascript?

andy_ppp2• 7 years ago

Did I say it didn’t use Javascript? It does address some of the concerns of the article though.

donatj• 7 years ago

HTTP 204 is amazingly under utilized in avoiding JavaScript. It allows messages to a server without a page refresh or XHR.

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.

dzek69• 7 years ago

so you click stuff and nothing changes - how that is useful? :)

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

mrob• 7 years ago

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.

lytedev3• 7 years ago

Analytics immediately comes to mind! I'm going to have to look into this as I'm wanting to get away from GA!

Benjamin_Dobell• 7 years ago

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.

kowdermeister• 7 years ago

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.

everdev2• 7 years ago

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.

baddox3• 7 years ago

React does this, both for performance and to normalize event behavior across browsers.

cypressious• 7 years ago

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.

pmarreck3• 7 years ago

Nice to see someone who cares about their job! :)

ramon2• 7 years ago

Has anyone heard of https://purecss.io/ ??? Example: https://purecss.io/layouts/side-menu/

wut42• 7 years ago

This example uses some JavaScript

ramon2• 7 years ago

Did you see the JS?

DonnyV• 7 years ago

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.

defanor4• 7 years ago

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.

lytedev3• 7 years ago

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.

defanor4• 7 years ago

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.

untog3• 7 years ago

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.

freshm087• 7 years ago

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.

defanor4• 7 years ago

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.

duxup4• 7 years ago

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.

GoblinSlayer• 7 years ago

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?

duxup4• 7 years ago

I mean it's Forbes so probably not a big loss.

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.

untog3• 7 years ago

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.

duxup4• 7 years ago

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.

y4mi• 7 years ago

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

nateberkopec• 7 years ago

Looks like you didn't read the article.

untog3• 7 years ago

I was responding to this:

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.

giancarlostoro3• 7 years ago

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.

humblebee• 7 years ago

Seems like it could be done with a checkbox and some cash. I'm sure someone could figure it out.

jgtrosh• 7 years ago

I believe using a checkbox element and the :checked selector alongside siblings matching would do the trick.

brlewis• 7 years ago

Could you just nest <details> elements?

fooddood• 7 years ago

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

everdev2• 7 years ago

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.

ashton314• 7 years ago

Yes, a JS enhancement that weighs less than 30 KB. I’ll take that any day over a >100 KB React app.

nkrisc2• 7 years ago

"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.

baddox3• 7 years ago

People are never impressed by my strict fasting-between-meals regiment̶.

zzzcpan• 7 years ago

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.

jlg23• 7 years ago

The author acknowledges that (see "Coming Clean").

The author also addresses your specific example (see "The Checkbox/Label Trick").

IshKebab• 7 years ago

I starting thinking that but having read the article he actually did use javascript in a couple of places.

arkh• 7 years ago

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.

fibonachos• 7 years ago

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.

yeahitslikethat2• 7 years ago

I've never used it because its not to the left of the comment header where it belongs. Voting should be on the right.

hansflying• 7 years ago

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.

krisrm• 7 years ago

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).

jrochkind1• 7 years ago

The date says 9 April 2019, but I swear I've read this article before, I think from HN even.

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

Tade03• 7 years ago

Meanwhile the checkbox hack went on to live a life of its own.

lytedev3• 7 years ago

Just wanna say that using Blender to create your illustrations (very in these days) is genius! Never would've crossed my mind!

aabbcc1241• 7 years ago

well, that website doesn't work without javascript

JeanMarcS• 7 years ago

And here I found out about detail and summary tags. Brilliant !

And next I find out it's not compatible with MS browsers. Sad.

intrasight• 7 years ago

I built front ends for industry for 14 years without JavaScipt. Nuclear power plants, battle ships, manufacturing plants, electric grids, air traffic control systems.

Pre-browser - ah, those were the days ;)

apo• 7 years ago

Ironically, the link only works with Javascript enabled.

IronCoderXYZ• 7 years ago

"Slimvoice - A Webapp Without JavaScript..."

"using as little JavaScript as possible"

Without, and as little as possible are mutually exclusive.

PedroBatista• 7 years ago

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.

It's tragically funny.

tmm84• 7 years ago

Abominations everywhere... The bloated JS site is the replacement for Flash.

mekane8• 7 years ago

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.

another_comment• 7 years ago

LOL this site does not even render with JavaScript disabled.

hlandau• 7 years ago

It is hugely ironic that this page is just a loading spinner if you don't have JavaScript enabled, so I have no idea what it says.

drej• 7 years ago

All of this is presented on a site where my browser downloaded a full megabyte of JavaScript. Lovely :-)

headcanon• 7 years ago

...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.

esaysimyan• 7 years ago

This is brilliant!!!

Building a front end with no JavaScript

Related Stories