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

121–130 of 239 posts

Re: JavaScript hydration is a workaround, not a solution

#121

Post by rglover »

The overhead is arbitrary if done properly. I did this in Joystick [1] and was shocked at how overcomplicated folks make it.

You're literally just saying "render to static HTML on the server, and on the client, have a way to render a root component to screen and attach event handlers." Without any serious thoughts about optimization (practically none yet), a no-cache refresh/mount takes 227ms to DOMContentLoaded and 696ms to a full load.

Here's the SSR I do:

https://github.com/cheatcode/joystick/blob/development/node/...

Here's the mount ("hydration"):

https://github.com/cheatcode/joystick/blob/development/ui/sr...

The only "magic" is that I embed the hydration logic into the built JS for the current page and it fires automatically on load (no need to add manual hydration code).

[1] https://github.com/cheatcode/joystick

Re: JavaScript hydration is a workaround, not a solution

#122

Post by jozzy-james »

beebeepka wrote: post #55

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…

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

Re: JavaScript hydration is a workaround, not a solution

#123

Post by jozzy-james »

firasd wrote: post #53

Anyone tried Phoenix Liveview recently? Seems like a solution to opt out of this kind of situation entirely.. I'll be exploring the framework

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

Re: JavaScript hydration is a workaround, not a solution

#124

Post by jozzy-james »

scrollaway wrote: post #5
aliqot wrote: post #2

Maybe I'm just getting old, but Javascript jumped the shark at some point. Hydration, lazy loading, managing flashes of unstyled content, a lot of this is built to address things that wouldn't be problems if we treated the browser as the dojo that it is and not be so dang wasteful. im sure someone with shinier boots than mine will pop in and tell me how im wrong, and perhaps youre right, but the web was a much better…

> Hydration, lazy loading, managing flashes of unstyled content, a lot of this is built to address things that wouldn't be problems if we treated the browser as the dojo that it is and not be so dang wasteful. What's your point here, exactly? That if random wordpress blogs and recipe websites were less wasteful, the problems these solutions are addressing would not exist? I can make you an extremely non-wasteful weba…

> FOUC would still be an issue.

hell, just using webfonts can cause FOUC - no JS needed.

Re: JavaScript hydration is a workaround, not a solution

#125

Post by jozzy-james »

quest88 wrote: post #21
scrollaway wrote: post #5

Earlier quoted context omitted.

> Hydration, lazy loading, managing flashes of unstyled content, a lot of this is built to address things that wouldn't be problems if we treated the browser as the dojo that it is and not be so dang wasteful. What's your point here, exactly? That if random wordpress blogs and recipe websites were less wasteful, the problems these solutions are addressing would not exist? I can make you an extremely non-wasteful weba…

I think the point is people should use the correct tool for the job. Instead, sites that should (or can) be static sites are unnecessarily using some JS framework.

i think you're conflating static sites with sites that lean heavily into JS frameworks. plenty of sites are not static, cause they need that whole session thing, and don't use JS frameworks

Re: JavaScript hydration is a workaround, not a solution

#126

Post by jozzy-james »

zozbot234 wrote: post #17
scrollaway wrote: post #5

Earlier quoted context omitted.

> Hydration, lazy loading, managing flashes of unstyled content, a lot of this is built to address things that wouldn't be problems if we treated the browser as the dojo that it is and not be so dang wasteful. What's your point here, exactly? That if random wordpress blogs and recipe websites were less wasteful, the problems these solutions are addressing would not exist? I can make you an extremely non-wasteful weba…

HTML has native support for lazy-loading images these days. No need for added JS.

it does, but when design and top brass say it needs to fade in - back to some JS you go

Re: JavaScript hydration is a workaround, not a solution

#127

Post by jozzy-james »

guipsp wrote: post #4
aliqot wrote: post #2

Maybe I'm just getting old, but Javascript jumped the shark at some point. Hydration, lazy loading, managing flashes of unstyled content, a lot of this is built to address things that wouldn't be problems if we treated the browser as the dojo that it is and not be so dang wasteful. im sure someone with shinier boots than mine will pop in and tell me how im wrong, and perhaps youre right, but the web was a much better…

I thoroughly agree, society was much better before computers came along.

agreed, wouldn't be able to read this comment

Re: JavaScript hydration is a workaround, not a solution

#128

Post by chrismccord »

jozzy-james wrote: post #123
firasd wrote: post #53

Anyone tried Phoenix Liveview recently? Seems like a solution to opt out of this kind of situation entirely.. I'll be exploring the framework

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.

Re: JavaScript hydration is a workaround, not a solution

#129

Post by naet »

Karellen wrote: post #89
tsimionescu wrote: post #82

Earlier quoted context omitted.

> Just make something that works with with HTML and CSS alone, and enhance it with JS. You don't need to be clever about it, especially if the level of interactivity on your website amounts to basically a form. A big problem with this is that html is extraordinarily limited as a widget framework. You only have a handful of widgets available, and many of them offer very little (if any) customizability from CSS. For ex…

> For example, say you wanted a checkbox, but you wanted to use a custom color instead of the browser default. Well, tough luck. From HTML you'll have to put the checkbox inside a label, add an empty span next to it, and from CSS make the checkbox invisible and then get creative with drawing some boxes that look like a checkbox [0] (or, more realistically, load some custom graphics). So, if you're doing all of this e…

"Just compromise your design", surprisingly, isn't a one size fits all solution. Especially when you can implement things yourself. Yes, it's harder than you think, but sometimes it needs to be done.

Re: JavaScript hydration is a workaround, not a solution

#130

Post by simonbarker87 »

I started in web dev 17 years ago, but didn’t get my first professional dev job until 3 years ago.

I had never had to learn angular, react, separated backend and frontend when writing code for my own stuff and my own company.

I would regularly process as much as I could on the server and ship the HTML and a JSON object to the browser and then just use native JS or more SSR from there.

My sites and apps were complex, just as complex as the stuff we were making in my first two dev jobs but the dev ex was so much nicer.

Shipping a heap of JS to the browser and getting that to do the heavy lifting of making the HTML etc just felt like an anti pattern but I went with it because “that’s the way we do it now”

Seeing Remix, Laravel, RoR still going, Astro etc is starting to convince me that perhaps separated FE and API isn’t the one true way and the old way might have been better.

Post reply on HN