Live data from Hacker News

A JavaScript-Free Front End

dev.to

21–30 of 215 posts

Re: A JavaScript-Free Front End

#21
post #8

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

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

Re: A JavaScript-Free Front End

#22

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

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

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

Re: A JavaScript-Free Front End

#23
post #3

wow this is excellent, / are good tricks

Except for the "works everywhere" suggestion... https://caniuse.com/#feat=details And here I thought Edge was a modern browser.

Given that Edge has less than 5% marketshare globally (depending on the source of the information), I would say that fretting over compatibility with it is not a priority. And given that MS is moving Edge to Chromium rendering engine, I assume this will solve the compat problem.

Re: A JavaScript-Free Front End

#24
post #3

wow this is excellent, / are good tricks

Except for the "works everywhere" suggestion... https://caniuse.com/#feat=details And here I thought Edge was a modern browser.

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.

Re: A JavaScript-Free Front End

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

Re: A JavaScript-Free Front End

#28
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

Re: A JavaScript-Free Front End

#29
post #14

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 wri…

> so I still have to wait an annoyingly long time

> it drops every 10th request

If the app saves data to a server, that's gonna happen regardless anyways (and one could argue that techniques like optimistic updates might make the experience even worse)

Also remember that HTML can be streamed and partially rendered even if it's not fully downloaded, and the investment required to enable this is minimal. The same cannot be said about a SPA's data fetching/rendering strategies.

Having worked on bloated apps before, I despise when people throw around the word "prefetching" as if it's some sort of magic spell. At best it eats my battery and bandwidth needlessly, and at worst, it's weasel wording for slowing down time-to-first-pixel :(

Re: A JavaScript-Free Front End

#30
post #24

Earlier quoted context omitted.

Except for the "works everywhere" suggestion... https://caniuse.com/#feat=details And here I thought Edge was a modern browser.

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.

Thx. Good to know. In that case, selective usage seems like good policy.
Post reply on HN