
A JavaScript-Free Front End - bibyte
https://dev.to/winduptoy/a-javascript-free-frontend-2d3e
======
roebk
It's perfectly possible to do some nifty tricks with CSS alone. The one thing
this author has omitted is the impact this has on accessibility. Sure, I can
open a modal without the need of JavaScript, but my focus isn't trapped within
the modal and with no standard keyboard shortcut (ESC) to dismiss the modal,
it provides a sub-standard experience for all users.

Be sensible and use JavaScript when it's appropriate. Please don't think it's
cool to create some fancy JS-less widgets and forget about accessibility.

~~~
gambler
You can trivially add keyboard shortcuts to this solution after it's
implemented - with 0 rework. Moreover, the is absolutely no guarantee that an
arbitrary JS library for modal popups will have better usability. And I have
yet to see one that will not fail if I block JavaScript, creating horrible
user experience for everyone who does so. Funny how usability concerns go out
of the window when NoScript/uBlock users are involved.

Personally, I try to avoid modal popups altogether. There is almost always
better ways to structure things. The whole concept of "modal" UI doesn't map
well to the "document" nature of web elements.

~~~
roebk
This is not simply about modals. Using VoiceOver and Chrome I cannot access
the pop up menu to navigate the site. These CSS tricks are cool but they
shouldn't be used in a production environment without basic usability testing.

More specifically, no you cannot add keyboard shortcuts "with 0 rework". How
are you returning the users focus to the active element before they opened the
modal? The key is not to use an "arbitrary JS library for modal popups" and to
use or create a modal library that has superior usability baked in. Sure,
maybe there's a superior workflow than to use a modal.

For anyone that is interested MicroModal
([https://micromodal.now.sh/](https://micromodal.now.sh/)) ticked a lot of
boxes last time I checked.

~~~
gambler
_> These CSS tricks are cool but they shouldn't be used in a production
environment without basic usability testing._

The same can be said about any JS library that interacts with page controls.

The wast majority of modal dialog implementations on the web do no follow the
standards you're referencing. Do you routinely criticize websites on this
basis, or is this criticism only reserved for ones that use vanilla HTML+CSS
for core functionality?

 _> More specifically, no you cannot add keyboard shortcuts "with 0 rework"._

Yes, you can. 0 rework != 0 work. Anything that unchecks that checkbox on Esc
will close the modal. To implement that you don't need to change the structure
of what you've already done. Progressive enhancement.

 _> How are you returning the users focus to the active element before they
opened the modal?_

Focus management has absolutely nothing to do with where the state of the
modal is stored. You can implement all of the usability features you want on
top of Checkbox + CSS solution with the added benefit of not screwing everyone
who can't run your scripts or completely breaking the website for everybody if
something in your JS gets broken.

~~~
cfv
> The same can be said about any JS library that interacts with page controls.

Difference being JS, if written by an averagely competent individual, can be
changed once and this change will apply to any instances where it's called,
and this cute pattern will need to be manually updated in any number of places
where it's applied, one by one.

> Yes, you can. 0 rework != 0 work.

Rework meaning you have to go back over the "done" thing and then do more to
cover the technical debt. On each and every instance of the thing.

> if something in your JS gets broken

As opposed to replacing the cute styling trickery for browsers that don't
really support it, which is somehow better?

------
onion2k
_Since I 'm caching and gzipping everything, each subsequent pageview is
around 6 KB; far smaller than the SPAs I've seen with equivalent
functionality._

That's ace. But my internet connection has a 2 second latency so I still have
to wait an annoyingly long time every time I interact with your app. My
connection is terrible too, so it drops every 10th request, and now I'm seeing
_a lot_ of broken pages. If only you'd written an offline-first PWA and used
background-loading and prefetching with some intelligence to retry failed
requests in order to deliver content _before_ I actually need it this would
have worked so much better.

But hey, the app is perfect for you on your robust wifi, so it _must_ work out
there in the real world, right?

Snark aside, there's a good reason to build web software in a variety of
different ways. Pick the one that suits your users. Don't assume everything
works perfectly and every internet connection is strong, fast wifi. That just
means a lot of users (especially poorer ones in rural communities) are going
to struggle with what you're selling.

~~~
timw4mail
I keep hearing offline-first trumpeted, but I have seen no examples of what
that means.

Terrible connections exist. But I fail to see how adding more scripting will
always help with that. Service workers are definitely promising, but
documentation for common use cases is still lacking.

Even with a terrible connection, I would still trust a server-side app to load
correctly on a refresh more than a SPA.

If anything, the minimal use of Javascript is as inclusive as a web app can
be.

~~~
tedunangst
I think they're talking about mobile twitter, where every time I visit I see
the message "something went wrong". Then I tap retry and get the same message.
It's very offline first. Then I reload the whole page and get the online
version.

~~~
snazz
It seems to have to do with blocking their trackers:
[https://news.ycombinator.com/item?id=19130667](https://news.ycombinator.com/item?id=19130667)

------
ddoolin
These are handy tricks, even in JS at scale, and I'd recommend their usage if
you can (big if, business requirements come first for most of us). That said,
I don't really buy into the no JS/purism movement for load/execution speed.
For bite-sized apps or simple pages, sure. However, it's completely possible
and not that hard to develop full-blown web application suites using full JS
for everything (structure, style, and function) and not have issues with load
or speed. I'm not sure if there's a footgun here, but the issue falls squarely
on the developers.

~~~
smokeyj
The whole thing is a solved problem. You can easily render React apps on the
server and send HTML down the wire, then lazy load the rest of the JS. Author
could have installed next.js and called it a day.

If you put your app logic in something like Redux it'll work on server-side
rendering, client-side rendering, and can be included in react-native down the
line.

In the time the author re-wrote his app, I could have gotten the same benefits
with SSR and ported it to react native. But yeah, javascript bad REEEE

~~~
tomca32
> Author could have installed next.js and called it a day.

Not a day, but probably a week of debugging. Each and every suggestion you
made in your comment makes the deliverable tremendously more complex, is very
expensive, will need ongoing maintenance, and is ultimately not needed.

Javascript apps are tremendously complex, why would do this if you don't have
to?

~~~
smokeyj
Imagine you have a team of rails developers and you're asked to create a
simple portal. Rails as a tool may be "overkill" but what does it matter?

If you already know Rails I'd say use that. If you only knew ruby then
reaching for rails would be overkill. But if your business requirements need
the features of Rails, learn rails instead of rolling your own framework..

~~~
tomca32
I completely agree with you, which is why I think that telling people to "just
install next.js" is a terrible advice. If they are JS devs, experienced in
next, sure, go right ahead, but I don't think that's the case here.

I'd be fine to just use Rails for something like that since I'm quite familiar
with Rails, but I would never recommend it to someone who doesn't know it.

~~~
smokeyj
> If they are JS devs, experienced in next, sure, go right ahead, but I don't
> think that's the case here.

The author is clearly experienced in UI development. The app was already
written in React/Redux. So honestly, yeah, just install next.js and fix your
routes.

This solution would be a complete non starter for any professional project in
terms of accessibility - there's a few issues screen readers would run into
with this. Not only that, but good luck getting other developers to sift
through your spaghetti code.

But the main thing is, the authors goals are somewhat pointless. If you don't
want a SPA then just use jQuery. The author ended up using plugins anyways so
the whole story was aimed at people who don't know front-end but latch onto
this idea of _javascript is baaad_. Don't be that guy.

So to recap. If you don't know javascript, and you don't want to learn the
standard tooling - please don't roll your own framework and blog about it.

Edit: looks like someone already commented this on his blog. This is all you
need to know:
[https://dev.to/isfotis/comment/9c7k](https://dev.to/isfotis/comment/9c7k)

------
kabes
> I built the first version of Slimvoice on Angular 1 with a Node.js backend
> and MongoDB in 2014 (those were all the rage back then). In 2015 I decided
> to completely revamp the UI and redesigned and rebuilt it in React.

Maybe you should make decisions based on requirements instead of hype. Oh
wait:

> Don't follow the hype

But using less javascript is the hype today...

> Plain Old HTML and CSS

This section only shows some very basic UI elements (dropdown, expansion
panel, ...). This isn't what libraries like react solve.

> Absolutely nothing is complex about my code

I wouldn't label CSS hacks with invisible checkboxes under "simple and self-
explanatory code".

> I found myself wishing for more innovation in the HTML spec

I don't think adding even more bloat to even more web standards than a browser
already has to support is the anwser.

~~~
pier25
> But using less javascript is the hype today...

I don't know, the hype is usually In React, Vue, etc.

------
hliyan
This is totally true. We've recently started to discover this paradox
ourselves: when styling and layout is all done via CSS, and JS + other assets
are cached, HTML is just as light weight as JSON over the wire. As ashamed as
I am to admit it, our newest innovation appears to be "multi-page apps"!

~~~
gambler
I remember there was some ridiculous article here where the author claimed to
build world's fastest web app with PReact. It was a hierarchical list of HTML5
features with some tick-boxes. Out of curiosity I converted the giant JSON
blob to <ul><li> list. HTML was about 15% smaller than JSON. You could also do
most of the "logic" of the app via styling and normal HTML controls.

~~~
Geee
The benefit of JS comes in incremental updates. When you update that list with
a new item, you can use optimistic update and small payloads in JS, while in
HTML you have to load the whole page again, which is slower.

~~~
mercer
The main issue I have with this idea is that in practice I've almost never
found the difference in payload to matter all that much, even on bad
connections.

In some cases, even sending the _entire_ HTML document and diffing on that
using morphdom (because redrawing _does_ bring noticeable cost rather quickly)
was a viable strategy even compared to the most optimal json payload.

I'd very much like to see some examples that prove me wrong though, because
while I've done some experiments, I might be underestimating how complex many
web apps are. It's mostly that the apps I built in hindsight were often better
off with a more old fashioned server-side, morphdom, turbolinks (or maybe
intercooler?) type approach.

~~~
Geee
It's not the payload size that matters really, but the latency of requests
which you have to wait between interactions, making the UX synchronous and
slow.

Good examples are, well, almost any modern and popular app. Like Trello for
example. Users spend lots of time on the same page making micro-interactions,
creating cards, moving cards around, adding tags, etc. You want to make the
in-app experience as flawless as possible in these types of apps, and the
initial JS size doesn't matter so much especially when it's cached. There's
also lots of shared state and you might be saving multiple things on the
server at the same time or uploading multiple files in the background while
editing other parts. You might want to store data offline and sync later to
the server. Once you have decent complexity, JS app with framework such as
React help a lot.

~~~
mercer
> It's not the payload size that matters really, but the latency of requests
> which you have to wait between interactions, making the UX synchronous and
> slow.

I'd use websockets if that was an issue. That said, Trello is a good example
where I do agree a web app is a great solution.

------
superkuh
This write-up mostly highlights the loading speed and bandwidth benefits but
not requiring javascript is far better than just that. In the age of spectre
and with browsers exposing more and more bare metal functionality the idea of
running arbitrary code on every random site I go to is absurd. There's dozens
of us that simply don't run JS. Sites like these (and, say, the way chicago
public media does fallback for no JS) show that there can still be pretty,
functional sites without the modern equivalent of opening that .exe attached
to a random email.

Thanks and keep up the good fight.

~~~
pault
> There's dozens of us that simply don't run JS

Was this intentional? It gave me a bit of a chuckle.

~~~
roryokane
I saw some actual statistics recently on a link from a blog with a lot of
posts about accessibility (I forget which). It said that 1 in 98 users (1% of
visitors) didn’t load JavaScript in a page, and 0.2% of visitors didn’t load
the script because they had explicitly disabled JavaScript, as opposed to
other reasons such as a poor network connection.

------
kaffee
I like the slogan "JavaScript-free"! Finally something to rally around.

I don't mind projects which use a tiny bit of hand-coded, vanilla ES6. Would
be nice if there were a slogan that included these.

Looks like it actually does use JavaScript for the "select2" case. This is
exactly the case I'd be happy to special case.

edit: added paragraph

~~~
mrec
[http://vanilla-js.com/](http://vanilla-js.com/)

It's got a badge and everything.

~~~
kaffee
This is cool. But it needs to be updated for ES6. The "Code Examples" could
look even better now.

------
tracker1
Honestly, a lot of this comes down to ignorance on a lot of points. You can do
a lot with CSS2.x+ selectors, and it's awesome. That said, JS/JSS and
component systems aren't bad either. It depends on what you're creating and
who your audience is.

Most of this stuff isn't new, it's about a decade+ old at this point. Backend
developers often tend to turn up their noses on web front ends, so they don't
bother to actually learn anything meaningful, and just sit complaining
constantly.

------
duchenne
How do you guys achieve this in practice?

I made my home page without javascript, and it is blazing fast. But as soon as
I try to make something more complicated I bumped into practical problems.

\- Components. I want to have the same navbar on all my pages, but I don't
want an un-maintainable copy-pasted code on all my pages.

\- Data. I need to display some data that is different for each user. How do I
embed it in my webpage without ajax calls?

\- Dev tools. I need debugging / bundler / source maps.

Some possible solutions could be:

\- PHP. It has components through "require". You can embed the data easily.
But, I do not know good dev tools: If I debug the javascript in the chrome dev
tools, can I edit directly the php script? Can I minify/babel the output of
the php code? And I cannot use the same php code on both front-end and back-
end.

\- Vue-SSR. Nice one-file components. Data can be provided within express. I
can re-use the same code on the front-end. I have not tried yet, but it seems
very interesting.

\- EJS. It has require and data from express. It is very simple too use. But
the tooling is lacking: no source map.

~~~
pdimitar
Err, isn't everything you are worried about also served quite well by all
server-side rendering frameworks since forever?

I legitimately cannot understand your issue.

~~~
duchenne
You just probably know things that I don't know. That's why I am asking.

Which SSR framework do you prefer?

------
_bxg1
"Why can't we have a standard search element that filters a list on the client
side (similar to how ng-repeat | filter: worked on Angular 1)?"

It's pretty new, but: [https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/da...](https://developer.mozilla.org/en-
US/docs/Web/HTML/Element/datalist)

"Wouldn't a standard HTML element for drag-and-drop sorting be awesome?"

There is a standard drag-and-drop API, but unfortunately (bafflingly) it's
imperative/event-based, not declarative. Seems like it would be simple for
them to add HTML hooks that use the same underlying code.

~~~
chrisrickard
And a Datalist polyfill in the meantime [https://github.com/mfranzke/datalist-
polyfill](https://github.com/mfranzke/datalist-polyfill) (somewhat seems to
defeat the nojs point though)

------
gambler
This is pretty much how I develop most of my web stuff. I do use JS, but it
comes in afterwards, in discrete packages. It process specific HTML attributes
to make the page do extra stuff, or accelerate certain operations, or stich
pages together via AJAX. All scripts are stateless, because all state is
stored in HTML.

The key is to represent your data and _UI state_ via sane HTML. This article
demonstrates this well with the modal popup example. Once you represent
popup's state with a checkbox, you can manipulate that checkbox in any way you
want and you can style it in any way you want and _your styling will not have
any dependencies on the methods of manipulation_.

------
RobKohr
I think this ignores one of the main benefits of JS based page rendering.

In the days where I worked on PHP apps, all rendering was done on the server,
and that came at a great cost regarding server side processing and the
complexities of peak load times, along with some pretty hairy test cases.

With everything rendered in js, you are mostly just transferring static
assets, so the browsers are doing the heavy lifting for you. The only things
that end up taking up server CPU cycles and system memory were API calls that
are easy to test, debug, and optimize. Also, those API calls can be cached,
and become static assets for high traffic apis such as ones accessed on the
front end.

If you do it all on the backend, you are doing all the rendering work, and it
is hard to split off and optimize processing time for things.

Finally, for testing, it is really easy to unit test an API, and for
javascript frontend work, there doesn't seem to be the code regression type
bugs that are so time consuming, but when you mix the data api stuff with the
front end rendering, unit testing becomes a big mess.

Bloat needs to be thought about, especially for limiting bandwidth, but just
for curiosity, I checked out my own website which was using React and a bunch
of libraries, and it was only 500K. This is about half the size of the banner
image on that article. Some libraries are much larger than React, but going JS
free and losing the power React gives you doesn't seem like a good trade off.

Of course if you get some happys from being an ultra-purist, then I get that,
and that is priceless. From a practical perspective though, this seems
misguided.

------
sbr464
Nice work, I definitely appreciate the focus on simplicity/speed. I just
signed up to check it out.

I noticed on the invoice page, on mobile, the number inputs (qty, price, etc)
showed the full alpha keyboard on input. I think you can add a few attributes
to optimize, without using JS also.

Great work, thanks for sharing.

This link has been helpful for me:

[https://developers.google.com/web/fundamentals/design-and-
ux...](https://developers.google.com/web/fundamentals/design-and-
ux/input/forms/)

~~~
winduptoy
Thank you! I had no idea that iOS required the pattern="\d _" attribute. Those
inputs require a decimal, so that pattern won't actually work (something like
pattern="\d_\\.?\d*"). If I can get my hands on an iPhone to test that, I will
deploy it shortly!

~~~
sbr464
Awesome!

Definitely a few hacks involved. I’ve seen different combinations of using
pattern, type=number, step=“0.01” etc, but you may need support for longer
decimals in qty/price.

I’m always on the lookout for form best practices, but it’s definitely hard to
stay up with all of the current trends.

There are a few mobile preview tools, not sure which is currently best, for
testing on different virtual devices:

Google search: test site with iphone online

------
anthony_doan
There is something like that the Elixir web community is trying to do with
Liveview, Texas, Morphling and Whistle. Several competing libraries doing the
same thing I believe, I've only seen Texas and Liveview in action.

The whole point, iirc, is to manipulate the DOM on server side and push those
changes via a websocket. So the DOM manipulation is on server side and the
code is server side language Elixir.

There was a demo for Texas and Liveview which show pretty good performance.
I'm not sure if it is good enough performance but it looks promising.

Video for Texas:
[https://www.youtube.com/watch?v=NWgwUKfR8Xg](https://www.youtube.com/watch?v=NWgwUKfR8Xg)

Video for LiveView: [https://dockyard.com/blog/2018/09/12/liveview-project-at-
eli...](https://dockyard.com/blog/2018/09/12/liveview-project-at-
elixirconf-2018)

~~~
mercer
I've played around with sending html strings via Phoenix channels and using
morphdom to change only what needs to be changed. I'm quite happy with the
results, even when sending an entire page for every significant change, and
can't wait for LiveView to be released (estimated later this month, IIRC).

------
Justsignedup
It is hard to argue against using JS. I tried that no-js approach as much as
possible in the past, and hated it. Using React for front-end development and
keeping bundle sizes small through good build processes is amazing. I
genuinely enjoy building web front-ends now because of it, where as before I
avoided it like the plague.

------
roywiggins
A nice way to progressively enhance something like this is to use
Intercooler.js when you do want to update only part of the page. You're still
just slinging HTML back to the browser but it lets you update only part of a
page without using iframes or something, and since you're just adding data-
attributes to links and forms, you don't write any javascript.

~~~
slow_donkey
I would suggest using Vue progressively at that point. Refactoring our
endpoints after using intercooler was not fun and using Vue/react without
going full SPA let's you move on way easier

------
stcredzero
_Slimvoice - A Webapp Without JavaScript is a series where I document how I
rebuilt my app, Slimvoice, using as little JavaScript as possible._

Here's a recurring story in the programming field.

A new variation on technology is highly successful. The field starts using it
enthusiastically, but doesn't keep track of the costs and cost/benefit. The
new tech gets rather overused. Some people come out with optimizations.
(Usually involving what amounts to caching.) Other insightful contrarian
people take a minimalist approach. Rinse and repeat.

Once aware, one can spot this cycle happening. It is left as an exercise to
the reader, how this can be used to profit.

~~~
mercer
While I'm not a full-on no-js developer, my move to the back-end and less
javascript has been one of the biggest reasons why I've started enjoying my
job again.

Unfortunately, at least judging by the many jobs I get offered, the market
around me is still very much on the 'make everything a web app' train. I
really hope the minimalist, or at least a less js-heavy approach actually
becomes a new cycle, job-wise.

~~~
stcredzero
Funny, but the Smalltalk Seaside webapp framework was once _criticized_ as old
fashioned for this kind of server-centric, javascript minimal approach. And
that wasn't that long ago.

------
ryanmarsh
While I understand the concern about bloated frontends, I do not understand
the throw-the-baby-out-with-the-bathwater mentality of JavaScript-free front-
ends.

Furthermore I feel like there's a misplaced sense of pastoralism or nostalgia
about the-web-before-JavaScript. The fact is there was a very brief period
where the World Wide Web was both widely accessible to the public and
JavaScript free. I built my first website without JavaScript in 1995. By 1997
I was building incredibly interactive single page apps in IE4 with JavaScript
and DHTML (as it was called at the time). By 1998 my full time job was writing
cross-browser JavaScript. That's twenty years ago folks. jQuery didn't hit the
scene until 2006. Why was jQuery created? Was it a revolutionary new tool that
gave us the ability to create applications that heretofore had never been
seen? Or, was it created to tame the horrendous mass of JavaScript that had
__already __accumulated?

We can talk about bloat, but let's be honest about what the web browser is
now. Chrome is an application container. The web hasn't been purely hypertext
for a long time. Back when it was we complained about the bloat... of __images
__

------
andrewfromx
100 percent agree. Use as little JS as possible on front end. And then
definitely use zero JS on backend.

~~~
tracker1
Definitely...only use C on the backend, any other language is just a hack.

~~~
sixstringtheory
I get the snark, but Java, Rust, Erlang are all better options than an
interpreted language for backends IMO

~~~
tracker1
Define better... Scripted languages can be run without the need for a
compilation step, if you're scaling horizontally anyway, you can do nearly as
well with node, and node can handle 100k+ connections per core with minimalish
memory overhead. Functions are first class, functional approaches are easy and
flexible, and when you're just passing bytes to another system or database,
JS/Node works well.

As to interpreted languages, JS/V8 has probably seen more optimization than
any other interpreted language. As to Java, you don't need a 400-500mb base
image either. Rust takes much longer to develop against, as does erlang even
if you're familiar with it. If you're parsing JSON into concrete objects, the
overhead is often larger with compiled languages than interpreted, where JS
just works. I can generally get stuff working in around 1/8 the time it takes
for peers to use a compiled language to do the same.

Go is probably a better option than the three you suggested, even then more
often than not, I would choose node, just because of the flexibility I get
with npm and the larger community. If I, in turn need to eek more performance,
or have a process that requires more compute per request, then I'll often
reach for another language and/or even choose a Function as a Service wrapper.

~~~
drenvuk
Why not C++17 in combination with h2o? I don't know why the compilation step
is an issue if compilation and linking takes less than a second which is less
time than switching back to the browser. I can pass around lambdas with ease
and my lines and functions have become much more succinct with the newer
versions especially when dealing with web related stuff. In addition, the
[https://github.com/nlohmann/json](https://github.com/nlohmann/json) lib make
json just work.

No one seems to get that the C++ still works and in nearly all cases is
faster, compiles very fast and is very quick to develop with now that everyone
has shared their code and since functional algos have been added to the stl.
This all happens with the memory safety people require since we have shared
and unique pointers and Intel's thread building blocks. My fully featured
application is 3.7 MB and takes 12-15 MB of ram to run and handles 100k+
requests per second from my laptop. Those stats aren't even that good with the
exception of the rps.

If going fully native isn't your game then how about nginx with the plethora
of 3rd party modules that are supplied by other developers? Maybe you just
really like js? Maybe js isn't the best but you're going to use it anyway
because you know it and other people have already written a lot of your code
for you? Maybe you just feel like wasting money on more machines instead of
one vps instance and a cache-everything cdn?

You do you I guess.

~~~
tracker1
Who says I need multiple machines? I just said if you're going to design for
horizontal scale, then it becomes less of an issue. Also, there's a lot to be
said for most of the code available already written. My time is worth far more
than paying a couple extra $ a month to run an app on a second server/vps.

I just said that JS isn't so bad, and that language snobbery is worse when it
means you're far less productive.

------
brlewis
I like this article, but the title is misleading.

"I did actually use some JavaScript on the new Slimvoice, but only when an
interaction could not be replicated in any other way."

Overall, the article does point in a good direction.

------
julioneander
Gotta shout out to the song linked in the article. Got me laughing good

[https://www.youtube.com/watch?v=Yx6k6WR8GRs](https://www.youtube.com/watch?v=Yx6k6WR8GRs)

------
coldtea
One of the most inspiring web-related posts I've read in a long time...

------
t0astbread
This "no-JS" movement is cool and I love CSS hacks (in production?) but I also
love the component mentality these JS-frameworks provide and not having to
host frontend servers (other than for static files). Are there any good "pure"
solutions for that?

------
ignaloidas
To see more of this - sourcehut[0] uses most of these tricks and is open
source so you can check out how they are used

[0] [https://sourcehut.org/](https://sourcehut.org/)

------
MarkMyWordsMan
Is it popular to hate on JS these days? Kudos to the author for creating the
stuff but would you build the next Amazon.com avoiding JS? More often than
not, I see Backend developers taking pride on not using JS rather than vice
versa. Also, FB and GOOG aren't naive to spend enormous capital and manpower
on React and Angular projects.

Probably will get downvoted but just because someone writes pure C does not
make him/her a better developer than someone who just writes Javascript.

~~~
x3ro
I'm still trying to grasp why these discussions so quickly spin into extremes.
The author clearly states her intent in the first paragraph:

> With the new version I wanted to prove that it was possible to deliver an
> amazing user experience with a great design while drastically reducing the
> complexity of the code, maximizing reliability, and minimizing the cost to
> the end user.

She goes on to show us what she did, where it worked and where it didn't. The
most important points I take away from her article are:

1\. It's quite possible to build nice-feeling (YMMV), non-single-page web-apps
without (a ton of) JavaScript

2\. Critically evaluate if you need the complexity that an enormous JS
framework brings

> You probably don't need a "Progressive Web App." Seriously evaluate if your
> app needs such complexity.

This has nothing to do with FAANG. Nobody disputes that there are use cases
where it's a really good idea to use React+Redux+Jest+Enzyme+XYZ et al. But
_maybe_ (and in my personal experience, in projects significantly smaller than
Amazon.com, often) you simply do not need that amount of additional complexity
and challenges.

It'd be so nice to just accept that the author provides an interesting data
point (it can work without JS) in a community strongly biased towards starting
projects by importing ~1000 node modules.

------
freeopinion
> I wanted to prove that it was possible to deliver an amazing user experience
> with a great design while drastically reducing the complexity of the code,
> maximizing reliability, and minimizing the cost to the end user.

...

> The Website Obesity Problem is not getting any better for the web at large.

These are both important points. But remember that 50MB of CSS stylesheets is
still very obese and very complex. Replacing bloated JS with bloated CSS is of
arguable value.

Just saying...

------
jypepin
I had fun building our wedding website without any JS just to see how much I
could push the boundaries of CSS and HTML. That was fun and a good learning
experience. I'll now be able to build better apps _with JS_ knowing where it
makes sense to push CSS/HTML and where it makes sense to use JS.

I recommend any front end engineer to go through that exercise, but it is not
a good solution for real production systems.

------
ritty
I admit it, I hate single page apps. I see very few that actually work well. I
don't hate JavaScript, it has its place, but you don't need to make an entire
website an SPA. Stuff like the main Spotify, Slack, or Discord pages, and even
things like Google Docs, and email front ends are fine for SPA. But you don't
need to also embed all the FAQs and other crap into the SPA. You know what
isn't an SPA? Hacker News. You know what else isn't? Google, GitHub, Amazon,
and Stack Overflow. I've disabled the SPA version of Reddit. I've built SPAs
and they are so much harder and take so much longer to develop and maintain
than traditional web sites. I wish they'd just die. Sadly, everyone else at my
work orgasms about SPAs, pushing every damn thing into it. We have stuff that
works perfectly well and no one has ever complained about it? Screw it, let's
spend $50k turning that feature into an SPA. I know many of you disagree with
me and I'll get off my soap box now. </vent>

------
blue4
wow this is excellent, <details>/<summary> are good tricks

~~~
technotarek
Except for the "works everywhere" suggestion...

[https://caniuse.com/#feat=details](https://caniuse.com/#feat=details)

And here I thought Edge was a modern browser.

~~~
dictum
It's a basic DOM element — a block of content. Without native support, it's
simply shown by default, instead of hidden by default, so nothing is broken,
and even the default on non-supporting browsers can be changed with JS and
CSS.

If anything, this is the _works everywheriest_ of things that "work
everywhere" in post-2010 web development. Some other stuff actually breaks
accessibility by default.

~~~
technotarek
Thx. Good to know. In that case, selective usage seems like good policy.

------
kmlx
it’s actually easy to do no-js websites when all you’ve got are forms, text
and some images.

but there are a lot of use cases where js is essential.

it all comes down to what you’re building.

~~~
winduptoy
Author here.

Absolutely, and a ton of commenters (mostly on Reddit) seem to be missing that
point. Use the right tool for the job. In the article I explicitly state that
I couldn't have built the drag-and-drop invoice editor without JavaScript
(although I wish that I could!).

------
cfv
So I decided to try and figure out this specific trick about toggling content
and how well this would actually work in, say, a tab panel. I mean, it is a
cute trick right? I made this:
[https://jsfiddle.net/sr8z1mob/6/](https://jsfiddle.net/sr8z1mob/6/)

Yes, it is a cute trick. Yes, it CAN be made more accessible, and kinda sorta
avoids the most obvious problems with like tabindexes and so on, although it
did take a lot of work on my end for such an insignificant demonstrator, and I
can't still set the active tab by hand in any way in here.

Which is a rather important cue about it's capabilities.

There's other things I cannot do:

\- Use this as an actual component! I would have to set up an editor expansion
to type all this stuff each time I wanted a tablist, and I cannot globally
modify how all of them work. Making this into some kind of custom tag would be
GREAT, but it could also probably mean going back to .htc files which is not
so great.

\- Track user interaction! It's important to us to know what the user is doing
with our product so we can make it better. \- Auto-select the first tab's
content in all tablists without contorting my brain into a cramp \- Load the
tab contents lazily. Maybe you don't need the King James Bible (replace with
any other long blob you like) loaded in there by default, just when you
actually want to go look at the thing. \- Skin the scrollbar easily (OSX for
instance is a major PITA I'd like to have auto-solved for me) \- Tell the
server when the tab was scrolled to the bottom \- Did I mention I cannot mark
the current tab as open in any real meaningful way?

This is a fun experiment. But really, it all boils down to requirements and
development times. Do you have the time and energy to spare to twist the
browser into doing this kind of things? That's awesome!

I, more often than not, don't. That's sort of the reason why we use a
development framework that puts us into a mindset we can work better with to
cover more ellaborate scenarios (like being able to mark the currently open
tab as exactly that without having to think about doing it).

------
honkycat
The very-immature Phoenix LiveView kind-of fits this use case.

It looks AWESOME and I'm excited to watch it mature over time.

Basically, LiveView is an Elixir library that allows SPA-style web page
interactivity with server-rendered pages.

------
cannedslime
Im not sure how elegant I think the CSS hack is compared to just making a
simplistic script for it. Would a user really notice the parsing time for such
a simple javascript application?

~~~
HelloNurse
I object to considering the techniques in the article "hacks". They all employ
minimal markup, without extra boxes or complicated classes, and the CSS side
is very simple.

~~~
cannedslime
I give you that its not a verbose or complicated hack. but I still would say
that a hidden checkbox acting as the middle man for modals etc is pretty hacky
:). A hack doesn't need to be complicated, most times its not. But after all I
can't imagine anyone thinking about this as a feature when they implemented
checkbox inputs back in the days.

~~~
winduptoy
Author here.

I agree that it's a hack and I can't say that I like it. Blame the W3C and
browser vendors for providing incomplete/barely functional standards like
<dialog>.

------
ryanolsonx
This is pretty inspiring. I'm pretty interested to see their approach on the
backend rendering. I've had some good experience in the good ol' days with
server rendering.

------
erikpukinskis
I don't see how you go from "giant JS payloads that can render your whole site
are bad" to "don't use Javascript to hide a DIV".

Maybe the CSS hack is faster than onclick="document.getElementById('zip-code-
modal').style.display = 'none'" but it's quite likely not.

------
NightlyDev
I totally agree that js is used way too much and dependencies are often
included without ever considering the consequences.

But Javascript itself isn't bad. Just use it when it makes sense, and minimize
it. Remove any dead code so phones won't have to spend cpu and data on it.

------
asdfasdfdavid
This is beautiful!

------
twoquestions
I gotta get better at CSS, I'm somewhat horrified by what I've done in
JavaScript that it turns out I didn't need.

Does anyone know of a good book on intermediate/advanced CSS to help avoid
excess JS usage/complexity?

~~~
zanny
MDN already has a bunch of courses on css:

[https://developer.mozilla.org/en-
US/docs/Web/CSS](https://developer.mozilla.org/en-US/docs/Web/CSS)

If you are already familiar with basic CSS skipping to the middle is fine. A
lot of modern CSS is just discovery of what you can do since none of it is
really all that intuitive, but I generally end up googling "how can I do X
effect in CSS" and seeing what the consensus is.

Just as some examples, you can do responsive bars that move all over the page,
change their contents, have togglable collapse menus, have dropdown menus in
those menus, etc all in plain CSS, but you can't have multiple columns of
arbitrary sized elements in left to right top to bottom order.

Learning CSS is really just learning the contemporary limits of what you can
do and then ruining your lovely responsive grids and flexboxes with absolute
positioned px garbage when you have to support IE as penance for your crimes.

------
kgthegreat
This is interesting and corresponds with the post
[https://builtwith.com/detailed/slimvoice.co](https://builtwith.com/detailed/slimvoice.co)

------
syphilis2
Maybe this is nonsense, but I wish I had a way to lazily load content (images)
without JavaScript. The JavaScript solution is very minimal, but maybe an
HTML/CSS option would also be simple.

------
masswerk
Last year, I relaunched my website with just CSS – and I'm not missing
anything. JS is used just for the error pages, featuring a game as optional
content. :-)

------
bilater
Naive question - but how could you do any interactions (login, add/edit stuff
that talks to a server) without using Javascript?

~~~
crooked-v
Form posts to the server, just like the old days.

Of course, then you need a full page reload every time you edit something.

~~~
mrec
Not necessarily a full _top-level_ page reload. You can POST to an iframe.

~~~
crooked-v
If you want to see the final status of the submission without JS, you still
need at least part of the page to visibly reload.

------
KorematsuFred
It is all about trade offs. We had a good application developed as a SPA and
worked well. However we had a monetization flow where we took users credit
card details and bunch of information. We developed this flow as a separate
stand alone HTML pages and micro optimized, reduced css, used vanilla js and
put it on CDN.

That did bump up conversions by good percentage points. It is all about
choosing the right hammer and nail for the job.

------
robmccoll
I'm amused by the Javascript mouse tracking used to rotate the phone image on
the first page.

~~~
buzzerbetrayed
I thought the same thing. Of all the places that javascript could have been
cut out, that had to be the most obvious.

------
cmclaughlin
I've been using intercooler.js
([http://intercoolerjs.org/](http://intercoolerjs.org/)) on a project recently
and absolutely love it... basically, it's allowed me to develop a web app with
a modern feel without writing any JavaScript. Highly recommend it!

~~~
ngrilly
Why the downvotes?

~~~
cmclaughlin
Can't imagine anyone that's tried intercooler.js would actually downvote. It's
really nice and, in my opinion, totally addresses the author's concerns.

------
shove
This is really great but I was really surprised by that 230k number. Expected
~150k

~~~
winduptoy
Hey, author here. Just for reference, 180k of that is fonts. The rest is super
tiny. Of course, once you've loaded it the first time, it's cached.

~~~
theandrewbailey
Have you tried minimizing that? Are you using WOFF2? Have you eliminated extra
character sets/ranges? I know of a tool that can help:

[https://www.fontsquirrel.com/tools/webfont-
generator](https://www.fontsquirrel.com/tools/webfont-generator)

~~~
winduptoy
Yes it's WOFF2, served over gzip. I do not think that I can eliminate extra
character ranges because Slimvoice is used all over the world.

------
ghostbrainalpha
A website without JavaScript is like this comment.

------
jordache
well some needs to create a framework around this concept. Have the build
process spit out only HTML and CSS that employ these exotic strategies.

It's entirely unsustainable to have a team build an app using these patterns.

------
d0bby
Need to bump this. I hate JS.

------
BornLikeThat
weird flex, but okay

~~~
buzzerbetrayed
I think you missed the entire point of the article. Your account also has 2
comments, and both of them are "weird flex, but okay". You are in the wrong
place if you expect those comments to be appreciated.

------
zachguo
What JS does can be reduced to several things:

\- storing states, and conditionally passing states around

\- toggling things on or off

\- element reuse

\- dealing with events

\- ajax

Unfortunately it's unlikely HTML & CSS would support all these.

~~~
lhorie
The paradigm shift here is that most of these things would be done in the
server using traditional techniques: ajax, events, state are all handled via
form submissions. The only things in this list that are really "frontend-ish"
are element reuse (which, for styling purposes, is accomplished via CSS
methodologies) and toggling things on/off, which in the CSS-only corners of
the web is accomplished using a radio box CSS trick.

Behavioral augmentation that these days is encapsulated via componentization
(e.g. tabs, carousels) is also something that has been explored to death in
traditional paradigms, e.g. unobtrusive js

~~~
zachguo
We all knew these tricks and started from there back in the day. Don't you
think they are way too hacky? and cause too many page refreshes? Have you ever
maintained codes mixing server-side templating and JS scripts?

And there are so many edge cases popping up so that you have to use JS anyway.
Then you may ask why don't I use JS for everything then?

JS is inevitable no matter how you and I hate it. "JS-Free" only makes sense
for simple presentations.

~~~
lhorie
Some things like the radio box trick are hacky, I agree, but many things are
not. Personally, I like to strike a balance between old-school techniques and
new technology (e.g. use CSS for hovers instead of instagram-style DOM
manipulation via JS)

To me, this whole thing about JS-Free is a backlash against overdoing things
in JS, and it's as good time as any to rethink today's status quo, especially
in regards to how many babies we have thrown out w/ the bath water when
adopting JS-first technologies.

