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

101–110 of 239 posts

Re: JavaScript hydration is a workaround, not a solution

#101

Post by anotheracctfo »

dntrkv wrote: post #93
lhorie wrote: post #86

Earlier quoted context omitted.

One story that comes to mind was when I was still relatively early in my career and the COO of the company came to me asking for some help getting some jquery ui tab widget thingie to work. And as if the words "COO" and "jquery ui" in the same sentence weren't enough to raise eyebrows, what came next was probably one of the most mind bending software engineering episodes I'd ever witness. It turned out he was trying…

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.

Re: JavaScript hydration is a workaround, not a solution

#102

Post by joshmanders »

waboremo wrote: post #14
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…

Do you have any proposed solutions for the problems that exist? Going back to fundamentals doesn't eradicate the problems, it will only recreate them in a slightly altered state. One of the most commonly proposed solutions is we keep the web to only static content. Well now we've just shifted all the media-heavy interactive content onto a dedicated app instead of the browser, shifting all the same exact problems onto…

> Well now we've just shifted all the media-heavy interactive content onto a dedicated app instead of the browser

And then they complain because "This could have just been a PWA, why do I have to install an app for every website I use!?"

Re: JavaScript hydration is a workaround, not a solution

#103

Post by jozzy-james »

jeffy90 wrote: post #75
michaelchisari wrote: post #41

Earlier quoted context omitted.

Simplicity is almost always best, but the hardest part is pushing back on management and product that often only care whether feature requests are possible and aren't as concerned with what goes on under the hood.

Speed and uptime are also features. If customers like speed/uptime (they do) we need to make sure management prioritizes them and understands how certain features will work against speed/uptime.

been a juggling act for me for some time, and always comes down to - they'd rather take a performance hit vs. harm the branding/interactivity. tho we're in a very niche market that doesn't seem to mind (i do my best to make it as efficient as can be)

Re: JavaScript hydration is a workaround, not a solution

#104

Post by graboid »

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 Vue which we otherwise use for complex UIs and do the whole page with HTMX and nothing else. And it worked.

It took me longer, thats for sure, but also because I had to get a feeling for how to approach many things I would have just routinely plumbed together with Vue. And the feeling at the end was really satisfying, a fast-loading, complex interactive page, powered by ~10kb of Javascript, with all filtering logic, validation etc. completely server-side (we use ASP.net). And I have confidence it will work exactly as it is years from now. With our Javascript tooling, I expect things to break by that time.

That said, I certainly pushed the library in parts, and the vote is still out on how easy it will be to understand the flow of interaction if some time has passed.

Re: JavaScript hydration is a workaround, not a solution

#105

Post by readams »

strongpigeon wrote: post #79
diceduckmonk wrote: post #70

Earlier quoted context omitted.

> Time to Interactive, First Input Delay and (coming soon) Interaction to Next Paint Having worked on one of the most bloated SPAs at Google and doing an SRE rotation to optimize exactly these metrics, I couldn’t agree more on the hypothesis that this is where complexity, jank and fragility arises. This is why our startup set out to build the best-in-class frontend for cloud computing and making a bet on SSR. I’m fro…

> Having worked on one of the most bloated SPAs at Google [...] Let me guess. Google Ads?

I would say gmail is the most bloated SPA pretty much in existence much less at Google.

Re: JavaScript hydration is a workaround, not a solution

#106

Post by bern4444 »

efields wrote: post #96

Incoming rant: I’ve had to do more hands-on hydration work as I explore static site generators and I’m just deeply unhappy with the state of front end tooling. I now have a taste for * directory based routing and opinionated defaults that give you the basics to string together html pages with reusable partials and be production ready in minutes (think rails) * postcss (css tooling) * reusable and compostable componen…

Take a look at remix.run. It has most of what you list and the rest can be easily added on.

Re: JavaScript hydration is a workaround, not a solution

#107

Post by jollyllama »

lhorie wrote: post #86
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…

One story that comes to mind was when I was still relatively early in my career and the COO of the company came to me asking for some help getting some jquery ui tab widget thingie to work. And as if the words "COO" and "jquery ui" in the same sentence weren't enough to raise eyebrows, what came next was probably one of the most mind bending software engineering episodes I'd ever witness. It turned out he was trying…

COO invents caching. Relatively harmless in the grand scheme of things.

Re: JavaScript hydration is a workaround, not a solution

#108

Post by cultofmetatron »

lhorie wrote: post #86
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…

One story that comes to mind was when I was still relatively early in my career and the COO of the company came to me asking for some help getting some jquery ui tab widget thingie to work. And as if the words "COO" and "jquery ui" in the same sentence weren't enough to raise eyebrows, what came next was probably one of the most mind bending software engineering episodes I'd ever witness. It turned out he was trying…

If the data doesn't change often and there's no further changes on the data after its created, seems perfectly valid. Optimizing queries takes time; in some cases, building new tables for amortizing parts of the computation. And of often you don't know whats worth optimizing till later so its easy to spend a lot of time optimizing the wrong thing.

I mean he basically cached the results for viewing later. As cringy as it seems, it was probably the optimal solution.

personally, I would have probably built out a materialized view and added memcache to generate json to make it easier to refactor additional output formats over time but that's just me. It still wouldn't have loaded as fast as sending a pre-generated html file.

Re: JavaScript hydration is a workaround, not a solution

#109

Post by ItsTooMuch »

grey-area wrote: post #100
phailhaus wrote: post #62

Earlier quoted context omitted.

People want to be able to author and share docs, directly in the browser and share with no effort. You cannot do this without JS, and the level of complexity is sufficient that you need robust tooling in order to manage it.

<contenteditable

Sure. And now you need thousands of lines of JS to make it cooperative in real time.
Post reply on HN