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

51–60 of 239 posts

Re: JavaScript hydration is a workaround, not a solution

#51

Post by andrewmcwatters »

azangru wrote: post #48
andrewmcwatters wrote: post #45

Earlier quoted context omitted.

If you try and tell inexperienced employees this in an interview for a job when you have well over a decade or more of experience—you’re not getting the job. I agree with you, but there’s some sort of complexity agreement in corporate environments, because people aren’t willing to accept that you don’t need a large build process, or any at all these days, maybe outside of a build pass for JSX.

> If you try and tell inexperienced employees this in an interview for a job when you have well over a decade or more of experience—you’re not getting the job. Good. An interview is as much you assessing your potential employer as your potential employer assessing you.

True! Just a sort of unfortunate aspect of our field.

Re: JavaScript hydration is a workaround, not a solution

#52

Post by nawgz »

ClumsyPilot wrote: post #35
phailhaus wrote: post #19

Earlier quoted context omitted.

This is an incredibly broad statement based on practically nothing. You don't think it's weird that most of the largest, most successful websites have mountains of tooling and frameworks to help them remain performant and reliable? All these tools either help the user directly, or solve real problems for companies to help them build more quickly. I also think you grossly overestimate the average user's abilities. The…

You don't think that it's weird that most of the largest, most successfull companies have mountains of office politics? Clearly this means that office politics is good for your company Largest economies in Europe have the oldest and most drafty, poorly insulated housing stock. Therefore shitty housing stock must be good for the economy. Largest economies in the world have the most pollution. Therefore pollution must…

Strawman

He argues tooling is a necessary but not sufficient* condition to performant web apps that solve meaningful user-facing problems

You argue he claimed correlation is causation

*Edit: had necessary and sufficient backwards

Re: JavaScript hydration is a workaround, not a solution

#54

Post by dmix »

BeefWellington wrote: post #33
dmix wrote: post #30

Earlier quoted context omitted.

> Seriously though, go load up any natively compiled app on your OS of choice and compare the speed of it doing any given task to what you get out of web-based versions, electron versions, etc. There isn't a comparison. I highly recommend trying out Linear.app, it's as fast as any desktop app I use. Replicache made a clone demo https://repliear.herokuapp.com/ the production linear app is even faster But if you're com…

That demo literally shows a brief "Loading..." screen for the first open issue, which was pretty much my point. I'm not sure what other desktop apps you use but for something as simple as viewing a single database record I've not seen loading screens since about 2000 on any native apps.

> That demo literally shows a brief "Loading..." screen for the first open issue, which was pretty much my point.

Yes when you open a desktop app that has to load the data from the internet it has to load first... You can't get around that fact unless you have zero data remote? Which defeats the purpose of a collaborative B2B app.

After that first load, strictly the first time you open the app, you never see another loading screen.

Saying desktop apps don't do the same thing is disingenuous.

And as I mentioned, that's a simple demo for a new framework in beta hosted on a free Heroku instance. Linear's production app is even faster. Especially when you download the desktop version.

Re: JavaScript hydration is a workaround, not a solution

#55

Post by beebeepka »

I've been trying to stay away from doing public facing web apps for a decade, so, from my point of view, hydration doesn't make any sense.

Authorization is in the browser, meaning I get to serve the login page "real fast".

That said, I get the reasons people do it, but frankly, it doesn't sit well with me. It's guaranteed that the whole process is unreasonably complicated as opposed to serving a few static files that can be cached and everything.

I'm theory, it could benefit people browsing without JS but I am not sure if things work out this way. Do next next require js on the client to display whatever was "rendered" on the ui server?

Re: JavaScript hydration is a workaround, not a solution

#56

Post by commandlinefan »

the__alchemist wrote: post #34

> In web development, Hydration is a technique to add interactivity to server-rendered HTML. It’s a technique in which client-side JavaScript converts a static HTML web page into a dynamic web page by attaching event handlers to the HTML elements. This is how I use JS. I may be misunderstanding something, but this is a nice way to use JS to add targeted interactivity to a page while keeping load times and interaction…

That's how everybody used Javascript when it first came out, coming up on 30 years ago. This is how it was designed to be used in the first place.

This seems to happen with everything - somebody solves a problem, somebody else gains a very partial understanding of the solution, adds unnecessary hacks on top of the solution that they thought they needed because the didn't spend any time understanding how the solution actually worked, and somebody else comes along and adds back the things that were already in the original solution on top of the hacks so that it works the way it always worked, but much slower and in a way that will break in surprising ways when you least expect it.

Re: JavaScript hydration is a workaround, not a solution

#57

Post by [deleted] »

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…

[deleted]

Re: JavaScript hydration is a workaround, not a solution

#58

Post by pupppet »

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…

I've had clients and self-professed SEO gurus carve out useful content in order to chase that 100 pagespeed score. I wish Google would just come out and state how content vs speed is weighted.

Re: JavaScript hydration is a workaround, not a solution

#59

Post by notriddle »

cxr wrote: post #47
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…

> For people not following JS these might all seem like constantly reinventing past lessons, but there is a logical evolution happening here towards desktop-style performance Funny, my desktop itself is already written in JS, and supports/integrates with apps written that way, too, (and also that aren't), and that's been the case for a while now. And the same has been true of apps from the Mozilla platform lineage fo…

> Firefox has been an Electron-style app for 100+% of its lifetime

That's technically correct, which is the best kind of correct, but horribly misleading.

Firefox has always been mostly written in JavaScript, but not HTML [1]. A bunch of features that are being standardized now, like Web Components [2], are pretty similar to stuff that Firefox has used in non-standard form for decades.

[1]: https://en.wikipedia.org/wiki/XUL

[2]: https://briangrinstead.com/blog/firefox-webcomponents/

Re: JavaScript hydration is a workaround, not a solution

#60

Post by pwdisswordfish0 »

the__alchemist wrote: post #34

> In web development, Hydration is a technique to add interactivity to server-rendered HTML. It’s a technique in which client-side JavaScript converts a static HTML web page into a dynamic web page by attaching event handlers to the HTML elements. This is how I use JS. I may be misunderstanding something, but this is a nice way to use JS to add targeted interactivity to a page while keeping load times and interaction…

I thought that was called "progressive enhancement". I like that too
Post reply on HN