
Building a front end with no JavaScript - dbnotabb
https://javascript.works-hub.com/learn/a-javascript-free-frontend-61275
======
jrochkind1
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](https://news.ycombinator.com/item?id=19367149)

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

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

~~~
giancarlostoro
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
Seems like it could be done with a checkbox and some cash. I'm sure someone
could figure it out.

~~~
pawelk
It could be done using `input:checked + sibling` selector e.g. like this:
[https://jsfiddle.net/6bgemn0s/](https://jsfiddle.net/6bgemn0s/)

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/](https://jsfiddle.net/6bgemn0s/1/)

~~~
hokus
[https://jsfiddle.net/gaby_de_wilde/ye95zcao/29/](https://jsfiddle.net/gaby_de_wilde/ye95zcao/29/)

------
andy_ppp
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](https://github.com/phoenixframework/phoenix_live_view)

~~~
FiddlyPack
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
Small correction: Phoenix is a web framework, not a UI framework.

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

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

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

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

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

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

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

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

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

------
PedroBatista
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
Abominations everywhere... The bloated JS site is the replacement for Flash.

------
cypressious
Ironically, the largest element of the website is the poorly optimized, almost
400kb hero image. After running it through
[https://tinyjpg.com/](https://tinyjpg.com/) I got it down to 75kb.

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

------
duxup
>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
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?

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

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

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

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

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

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

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

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

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

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

------
another_comment
LOL this site does not even render with JavaScript disabled.

------
ramon
Has anyone heard of [https://purecss.io/](https://purecss.io/) ??? Example:
[https://purecss.io/layouts/side-menu/](https://purecss.io/layouts/side-menu/)

~~~
wut42
This example uses some JavaScript

~~~
ramon
Did you see the JS?

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

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

------
IronCoderXYZ
"Slimvoice - A Webapp Without JavaScript..."

"using as little JavaScript as possible"

Without, and as little as possible are mutually exclusive.

------
intrasight
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
Ironically, the link only works with Javascript enabled.

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

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

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

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

------
aabbcc1241
well, that website doesn't work without javascript

------
esaysimyan
This is brilliant!!!

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

