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

131–140 of 239 posts

Re: JavaScript hydration is a workaround, not a solution

#131

Post by AnIdiotOnTheNet »

tsimionescu wrote: post #97
Karellen wrote: post #89

Earlier quoted context omitted.

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

The idea that all apps should use some kind of system style that dictates shape for every single control is... Odd. I don't know of any system that operates like this - certainly not Firefox on the Android phone I'm typing this from, nor the Windows box IT wants me to use for work, nor the Linux VM running inside that. Especially for web apps, writing them so that they look good on every browser with default styling…

> The idea that all apps should use some kind of system style that dictates shape for every single control is... Odd. I don't know of any system that operates like this

We came damn close to every OS operating like this in the late 90s. Sadly the future arrived.

Re: JavaScript hydration is a workaround, not a solution

#132

Post by yuretz »

graboid wrote: post #104
samwillis wrote: post #23

While I think the "resumability" that Builder have developed for Qwik is very clever, I increasingly prefer the approach taken by HTMX and Alpine.js. Move back from JSON apis and render your html fragments on the server (you need to anyway!). It removes so much duplication of logic, simplifies your tool stack and reduces your risk of vulnerabilities. I would even be tempted to say, both "Hydration" and "Resumability"…

I just had to do a site which involved a fair amount of interactivity. A sidebar with different types of filters, a search bar at the top, and a complex boolean filter builder inside a modal (think like infinitely-nestable AND/OR filters, where each filter involved 5 dropdowns interacting with each other). Then some area to collect the results and do some operations on them. I was feeling brave and decided to skip Vu…

Just curious, if it's pure htmx, doesn't this mean that most of UI interactive actions do a roundtrip to the server to update the app state? Or have you used hyperscript for some parts?

Re: JavaScript hydration is a workaround, not a solution

#133

Post by dntrkv »

anotheracctfo wrote: post #101
dntrkv wrote: post #93

Earlier quoted context omitted.

The purpose of the more complicated solutions is to build something that will be maintained for a long time where complexity will grow, and usually, require multiple contributors. I can bang out a basic landing page site in a few hours that will be extremely performant while pulling in zero libraries. But I would never want to maintain that over any extended period of time or added complexity.

The purpose of more complicated solutions is to prevent devs from becoming bored and leaving. In my experience, KISS results in the easiest solution to maintain. Then I get a litany of complaints from devs that "this isn't programming" or "this is a dead end to my career" and then they leave. Which paradoxically makes it more difficult to maintain, as I have no maintainers lol.

What are you working on? Without knowing your use-case or what your codebase looks like, I have no idea if the problem is with other devs, or you are just blind to the insanity that is your codebase.

Not saying that latter is the case here, but I've ran into devs maintaining some monstrosity and then complaining about others pushing for off-the-shelf solutions not realizing that nobody wants to spend time learning some bespoke system they created that's not actually as great as they think it is.

Re: JavaScript hydration is a workaround, not a solution

#134

Post by tsimionescu »

AnIdiotOnTheNet wrote: post #131
tsimionescu wrote: post #97

Earlier quoted context omitted.

The idea that all apps should use some kind of system style that dictates shape for every single control is... Odd. I don't know of any system that operates like this - certainly not Firefox on the Android phone I'm typing this from, nor the Windows box IT wants me to use for work, nor the Linux VM running inside that. Especially for web apps, writing them so that they look good on every browser with default styling…

> The idea that all apps should use some kind of system style that dictates shape for every single control is... Odd. I don't know of any system that operates like this We came damn close to every OS operating like this in the late 90s. Sadly the future arrived.

I don't think that is actually a good thing. I much rather have people less tied to one particular ecosystem, and preventing barriers to moving from one OS to another.

Re: JavaScript hydration is a workaround, not a solution

#135

Post by AnIdiotOnTheNet »

tsimionescu wrote: post #134
AnIdiotOnTheNet wrote: post #131

Earlier quoted context omitted.

> The idea that all apps should use some kind of system style that dictates shape for every single control is... Odd. I don't know of any system that operates like this We came damn close to every OS operating like this in the late 90s. Sadly the future arrived.

I don't think that is actually a good thing. I much rather have people less tied to one particular ecosystem, and preventing barriers to moving from one OS to another.

Instead they get to learn new ways of doing things with every single application they use regardless of platform and still have to deal with platform issues. Yay for progress?

Re: JavaScript hydration is a workaround, not a solution

#136

Post by oblak »

jozzy-james wrote: post #122
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

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

Re: JavaScript hydration is a workaround, not a solution

#137

Post by graboid »

yuretz wrote: post #132
graboid wrote: post #104

Earlier quoted context omitted.

I just had to do a site which involved a fair amount of interactivity. A sidebar with different types of filters, a search bar at the top, and a complex boolean filter builder inside a modal (think like infinitely-nestable AND/OR filters, where each filter involved 5 dropdowns interacting with each other). Then some area to collect the results and do some operations on them. I was feeling brave and decided to skip Vu…

Just curious, if it's pure htmx, doesn't this mean that most of UI interactive actions do a roundtrip to the server to update the app state? Or have you used hyperscript for some parts?

Yes, no hyperscript, and yes, all interactive actions do a roundtrip.

I tried not to get too detailed with the updates, so e.g. when you are in the filter builder dialog, and change the value of a select (and now the other selects have to change their data accordingly), the whole dialog is fetched again from server, instead of just the other selects. I felt that, while more selectively updating the UI would be more performant (htmx has to switch out less elements and the request payload is smaller), I don't want to cluster up my server with lots of small endpoints that return bits of HTML. All in all it was like 10 new endpoints returning HTML for that site, which was okay in my book. Could probably have been less if I had been more clever.

What I learned was to really pay more attention to make my HTML "leaner" than normal, because I noticed that if I don't pay attention to that, payloads can get big quite faster than when using JSON.

Re: JavaScript hydration is a workaround, not a solution

#138

Post by wruza »

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…

Go back to fundamentals … if the level of interactivity on your website amounts to basically a form

What if it doesn’t? I mean by requirements from various departments/analysts and user’s common sense.

Re: JavaScript hydration is a workaround, not a solution

#139

Post by spion »

cxr wrote: post #36
phailhaus wrote: post #13

Earlier quoted context omitted.

"Am I out of touch? No, it is the children who are wrong." This is an old, tired take that boils down to "we should be ashamed for wanting nice things." If only everyone would just accept simple websites like HackerNews! This is backwards, it is user-blaming. It turns out that the web is an incredible platform that has revolutionized the world, and thousands of people have worked hard to build tools that make it easi…

> "Web fundamentals" can't give you Google Docs. There's real irony in this statement, since you can't get much more fundamental than that. WorldWideWeb.app (Nexus) was created as a read-write client for both navigating and authoring content. Not only are modern Web apps not a necessary precondition for that, but neither JS nor any form of mobile code are necessary, either. (The thing that Docs does wrong where "fund…

I presume it didn't have realtime collaborative editing or comments?

Re: JavaScript hydration is a workaround, not a solution

#140

Post by blep_ »

naet wrote: post #129
Karellen wrote: post #89

Earlier quoted context omitted.

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

It is for things like checkboxes. If your design requires checkboxes to be special and different from everyone else's checkboxes, your design is wrong.
Post reply on HN