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

JavaScript hydration is a workaround, not a solution

thenewstack.io

Post reply on HN
Print view View original

161–170 of 239 posts

Re: JavaScript hydration is a workaround, not a solution

#161

Post by jozzy-james »

chrismccord wrote: post #128
jozzy-james wrote: post #123

Earlier quoted context omitted.

liveview still uses JS, its just rather out of the way in what it does edit: livewire in laravel land does a similar approach - tho not as fast currently, leverages alpine.js under the hood

While we use JS and websockets, even with js disabled or curling the page will send all the HTML. So the initial render is strictly a regular html page with all your expected content.

right, i get that - and liveview is a sick piece of kit, so congrats. just saying that for what most would use it for - it is still using some JS

Re: JavaScript hydration is a workaround, not a solution

#162

Post by FalconSensei »

paulirish wrote: post #151
onion2k wrote: post #37

...get a PageSpeed score of 100/100 I'm slowly coming around to the idea that PageSpeed (or Lighthouse, or Core Web Vitals, or whatever Google has invented this week) is what drives a lot of the complexity in web app dev. People refuse to throw out what they've learned, so every time there's a new metric to chase in case you lose SERPS ranking for being slow! devs heap another layer of complexity on to the Webpack bo…

Speaking as the TL of Lighthouse and PageSpeed, I can comfortably say that adding complexity is antithetical to our goal. Quality UX and a reliably performant web is what we want for all users. Ideally, folks would use a thinner stack with _less_ JS, as that's rewarded across all the metrics. But in recent years, many teams build a "site" by building a SPA. As they're entrenched in that dubious decision, the only pat…

> Perhaps its the apparent conflict between UX and DX that leads to tooling complexity?

+ PMs wanting to run dozens of AB tests at once in every single page

Re: JavaScript hydration is a workaround, not a solution

#163

Post by ratorx »

onion2k wrote: post #37

...get a PageSpeed score of 100/100 I'm slowly coming around to the idea that PageSpeed (or Lighthouse, or Core Web Vitals, or whatever Google has invented this week) is what drives a lot of the complexity in web app dev. People refuse to throw out what they've learned, so every time there's a new metric to chase in case you lose SERPS ranking for being slow! devs heap another layer of complexity on to the Webpack bo…

Frontend frameworks often have better developer experience. I want to use one because it’s less annoying to do thing like template HTML with editor completions, than using HTML.

Another theoretical advantage is that you can get better colocation of content, style and functionality.

Basic JS is pretty annoying to write. It reminds me of using goto for control flow. It’s a lot cleaner to be able to put functionality alongside the document structure.

Of course, you can use HTML + CSS + JS but you can also use Assembly for all code. But the end solution here is not Frontend frameworks.

I think it’s time browsers give us a better abstraction to HTML + CSS + JS. Webassembly and friends are nice, but I think the 3 fundamentally need to be replaced together in a performant way such that the simple case of no client side code is well optimised. Frontend frameworks are just a symptom of the problem which is that Web devs have to use the only abstraction creation mechanism available to get nicer development properties.

Re: JavaScript hydration is a workaround, not a solution

#164

Post by jozzy-james »

jozzy-james wrote: post #161
chrismccord wrote: post #128

Earlier quoted context omitted.

While we use JS and websockets, even with js disabled or curling the page will send all the HTML. So the initial render is strictly a regular html page with all your expected content.

right, i get that - and liveview is a sick piece of kit, so congrats. just saying that for what most would use it for - it is still using some JS

i suppose i should have prefaced with liveview uses JS...if you intend to use JS or dynamically update anything

edit: much like the SSR being described

Re: JavaScript hydration is a workaround, not a solution

#165

Post by jozzy-james »

oblak wrote: post #136
jozzy-james wrote: post #122

Earlier quoted context omitted.

realistically speaking, if done correctly - SSR would allow the site to work without JS. Now, in practice, that comes down to what is required on the client side for interactivity - which is a case by case basis, and if your site doesn't require JS on the FE at all, why would you use it for the backend

Yeah, but at the same time, who the hell would use nuxt/next for the type of site that is perfectly usable without js.

i ask myself the same question, but apparently they're out there

Re: JavaScript hydration is a workaround, not a solution

#166

Post by jozzy-james »

chrismccord wrote: post #128
jozzy-james wrote: post #123

Earlier quoted context omitted.

liveview still uses JS, its just rather out of the way in what it does edit: livewire in laravel land does a similar approach - tho not as fast currently, leverages alpine.js under the hood

While we use JS and websockets, even with js disabled or curling the page will send all the HTML. So the initial render is strictly a regular html page with all your expected content.

hate replying to something i already did - but i also never said liveview required JS, just...it still uses it if there. Liveview is a really slick answer to this whole thing, and I recommend readers of the thread to check out. And now I have nothing.

Re: JavaScript hydration is a workaround, not a solution

#168

Post by bot41 »

onion2k wrote: post #37

...get a PageSpeed score of 100/100 I'm slowly coming around to the idea that PageSpeed (or Lighthouse, or Core Web Vitals, or whatever Google has invented this week) is what drives a lot of the complexity in web app dev. People refuse to throw out what they've learned, so every time there's a new metric to chase in case you lose SERPS ranking for being slow! devs heap another layer of complexity on to the Webpack bo…

> Just make something that works with with HTML and CSS alone, and enhance it with JS

If you do this and have a sufficiently complex application... you will end up where the modern frameworks are. They exist for a reason.

Re: JavaScript hydration is a workaround, not a solution

#169

Post by qudat »

ratorx wrote: post #163
onion2k wrote: post #37

...get a PageSpeed score of 100/100 I'm slowly coming around to the idea that PageSpeed (or Lighthouse, or Core Web Vitals, or whatever Google has invented this week) is what drives a lot of the complexity in web app dev. People refuse to throw out what they've learned, so every time there's a new metric to chase in case you lose SERPS ranking for being slow! devs heap another layer of complexity on to the Webpack bo…

Frontend frameworks often have better developer experience. I want to use one because it’s less annoying to do thing like template HTML with editor completions, than using HTML. Another theoretical advantage is that you can get better colocation of content, style and functionality. Basic JS is pretty annoying to write. It reminds me of using goto for control flow. It’s a lot cleaner to be able to put functionality al…

> Frontend frameworks often have better developer experience. I want to use one because it’s less annoying to do thing like template HTML with editor completions, than using HTML.

Agreed. As I've been developing a service (https://prose.sh) with no javascript and only go templates, the biggest downside is autocomplete.

Re: JavaScript hydration is a workaround, not a solution

#170

Post by qudat »

thethirdone wrote: post #26
dmix wrote: post #7

The recent evolution of JS frameworks has been really nice. Performance is basically getting identical to desktop. The three recent developments I've noticed: - "Islands" in Deno https://fresh.deno.dev/ and https://remix.run/ where only small isolated parts get hydrated, instead of the whole page - Using http://linear.app style data-flows ala Replicache ( https://replicache.dev/ ) where JSON data is preloaded for all…

> The recent evolution of JS frameworks has been really nice. Performance is basically getting identical to desktop. Web browsers in general are not able to match applications on the desktop. Additionally, typical JS frameworks come with at least a 2x performance penalty compared to hand-optimized vanilla JS (Not a commonly done thing). Being excited about getting reasonable performance with a great development envir…

> but deluding yourself into thinking that its great performance is not.

What's the actual issue though? Sure on HN we care a lot about performance. But outside these walls performance has to be really bad for someone to actively avoid it. Even then, if the product has a stronghold on its userbase, you have to really degrade performance for engagement to falter.

Post reply on HN