Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A JavaScript-Free Front End

dev.to

Post reply on HN
Print view View original

31–40 of 215 posts

Re: A JavaScript-Free Front End

#31

Post by reificator »

peterbraden wrote: post #18
onion2k wrote: 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…

Prefetching is going to waste data in a lot of the world where you pay by the megabyte. Everything is a tradeoff.

You prefetch what is required, and cache what is requested.

Assuming you aren't one of the sites that thinks it's appropriate to require `DOOM.WAD`, it can work out well.

Re: A JavaScript-Free Front End

#32

Post by technotarek »

blunte wrote: post #23
technotarek wrote: post #19

Earlier quoted context omitted.

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.

5% can still be a decent number of users, and tends to trend even higher in certain segments (state and local government, smaller "old economy" businesses)

Re: A JavaScript-Free Front End

#34

Post by Scarbutt »

sixstringtheory wrote: post #22
tracker1 wrote: post #15

Earlier quoted context omitted.

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

nodejs and expressjs are pretty solid stable tools these days. And there is always typescript if you are into that.

Re: A JavaScript-Free Front End

#35

Post by prophesi »

onion2k wrote: 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…

Did you try using the site with the inspector open with Poor 2G throttling? I was still able to interact with the page within milliseconds. Just had to wait for the font to download before text would appear. Then after that, all of the assets besides the HTML was cached.

I think that's pretty damn good; to solve the 2 second latency, I think the developer is better off using a CDN or Netlify's ADN so that your site is delivered from a server closer to the user.

Re: A JavaScript-Free Front End

#36

Post by timw4mail »

onion2k wrote: 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…

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.

Re: A JavaScript-Free Front End

#37

Post by pixelbash »

twoquestions wrote: post #7

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?

An approach I use is to try and build something in css first, if I can't find a way to make it work then I'll break out the JavaScript.

Css is surprisingly good in places, but it also drives me up the wall as soon as I let myself expect to be able to do more things in it. Yesterday it was gradient masks.

Re: A JavaScript-Free Front End

#39

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

Re: A JavaScript-Free Front End

#40

Post by tedunangst »

timw4mail wrote: post #36
onion2k wrote: 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…

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, t…

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.
Post reply on HN