JavaScript hydration is a workaround, not a solution • Hacker News Board

Re: JavaScript hydration is a workaround, not a solution

#61

Post by zero_shift » Thu, Sep 01, 2022, 4:32 PM UTC

lucideer wrote: post #43

While the points against hydration are valid, the proposed solution sounds to me like it would have other (opposite) performance problems: i.e. hydration has an inherent startup overhead, and possibly a continuing memory overhead (though the latter doesn't seem inherent), whereas resumable sounds like it may start fast, run slow (and I can't see where they solve the mentioned memory overhead problem). I haven't teste…

No! That's not how it is. The way it is, is

- every app more complex than how I like to do things, is an overengineered mess

- every app less complex than how I like to do things, is an offensive relic from the distant past

Re: JavaScript hydration is a workaround, not a solution

#62

Post by phailhaus » Thu, Sep 01, 2022, 4:38 PM UTC

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…

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.

Re: JavaScript hydration is a workaround, not a solution

#63

Post by phailhaus » Thu, Sep 01, 2022, 4:40 PM UTC

swatcoder wrote: post #31

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 it's weird that most of the largest, most successful websites have mountains of tooling and frameworks to help them remain performant and reliable? I don't fully agree with the person you're responding too, but it feels like you're making their point for them with this. Users are engaging with a tool or some content for themselves and today . Startups are the ones dreaming of standing among the "lar…

> long-term concerns

And that's it. If you want to ever reach those long-term goals, you need robust tooling.

Re: JavaScript hydration is a workaround, not a solution

#64

Post by [deleted] » Thu, Sep 01, 2022, 4:40 PM UTC

SketchySeaBeast wrote: post #11

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…

> if we treated the browser as the dojo that it is I have no idea what this means. Isn't a dojo a place for learning or meditation? I don't understand how that fits the browser, the internet, or web development.

[deleted]

Re: JavaScript hydration is a workaround, not a solution

#65

Post by jessaustin » Thu, Sep 01, 2022, 4:41 PM UTC

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…

Authorization is in the browser...

I'm probably missing some details, but this seems like a Bad Idea.

Re: JavaScript hydration is a workaround, not a solution

#66

Post by jokethrowaway » Thu, Sep 01, 2022, 4:41 PM UTC

phailhaus wrote: post #13

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…

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

You can have simple websites without them being ugly

Re: JavaScript hydration is a workaround, not a solution

#67

Post by user3939382 » Thu, Sep 01, 2022, 4:41 PM UTC

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…

Re: JavaScript hydration is a workaround, not a solution

#68

Post by AngeloR » Thu, Sep 01, 2022, 4:41 PM UTC

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 haven't dug into Alpine.js, but I've been messing with HTMX on some personal projects for a few months now and am really pleased with it. It's honestly made it a pleasure for me to return to front-end work.

Re: JavaScript hydration is a workaround, not a solution

#69

Post by phailhaus » Thu, Sep 01, 2022, 4:43 PM UTC

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…

You're arguing that correlation does not imply causation. Fair. So tell me: how would you manage to build a website like Facebook without robust JS tooling?

The answer tends to be "wellll I hate most of these features anyways, let's get rid of them and then it can be as simple as HackerNews!" But obviously, millions of people use those features every day and like them. The tooling solves a real problem.

Re: JavaScript hydration is a workaround, not a solution

#70

Post by diceduckmonk » Thu, Sep 01, 2022, 4:44 PM UTC

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…

> 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 from a JavaScript background and personally think hate for the language is undue. V8 is also a marvel of engineering. We elected Go for our application language. It’s faster for our purposes but with SSR the domain language isn’t as important. We could use Haskell if it was fit for the problem domain. We empathize with how ideas such as “user-perceived latency” came about but SSR is a much simpler model and our philosophy is that “simpler is faster is faster”.