Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hydration is pure overhead

builder.io

Post reply on HN
Print view View original

61–70 of 84 posts

Re: Hydration is pure overhead

#61

Post by hu3 »

wwweston wrote: post #38
yboris wrote: post #7

For reference, Miško Hevery, the author of this post, is the creator of Angular . At the end of the article, there's his solution: https://qwik.builder.io/guide/overview > Qwik is a new kind of web framework that can deliver instant loading web applications at any size or complexity. Your sites and apps can boot with less than 1kb of JS

> is the creator of Angular. Welp, that's reason enough for me to ignore him entirely. Especially on the topic of "overhead." Angular was an inexcusable atrocity.

Experience is invaluable.

He probably knows much more than those who didn't create a major front-end tool.

Re: Hydration is pure overhead

#62

Post by eyelidlessness »

chasd00 wrote: post #4

This is confusing to me. From the article it sounds like the javascript is run on the server producing markup. That markup is sent to the browser for rendering then the javascript is requested by the browser. When the javascript arrives it is run again on the browser to re-generate the DOM with event handlers attached. If that is correct then why is the javascript run on the server to begin with and not just sent dir…

What you’ve described is a complete and accurate description of the “hydration” approach which the article (also correctly) describes as pure overhead. The approach proposed in the article/implemented in Qwik dispenses with re-running the JS which already ran on the server and just carries on with the state it produced.

The SSR/hydration approach:

- Benefits SEO

- Usually benefits initial content on the screen

- Has a bunch of performance penalties after that as JS is loaded, parsed, and (usually blocking) recreates the data structure representing its initial state

Qwik’s approach (at least conceptually) skips that third point for everything until an interaction needs to respond to some state change based on an interaction, and does that with only the information needed for that event.

In a tweet thread, I described my mental model of this as effectively developing like I’m building an app where all the server/client UI code is shared, but the UX is like I wrote plain HTML with some jQuery or whatever to make a few elements interactive. What Qwik does is determine which parts of the server code need to be the compiled jQueryish code, but only calls it when needed.

An equivalent React codebase would re-render the entire page (well mount point) even if most of it will have no meaningful effect.

Re: Hydration is pure overhead

#63

Post by eyelidlessness »

wwweston wrote: post #38
yboris wrote: post #7

For reference, Miško Hevery, the author of this post, is the creator of Angular . At the end of the article, there's his solution: https://qwik.builder.io/guide/overview > Qwik is a new kind of web framework that can deliver instant loading web applications at any size or complexity. Your sites and apps can boot with less than 1kb of JS

> is the creator of Angular. Welp, that's reason enough for me to ignore him entirely. Especially on the topic of "overhead." Angular was an inexcusable atrocity.

I was surprised when I saw his name attached to this project too. But goodness, having followed it for some time, are you ever wrong. If anything Qwik has reminded me professionally that people really can learn from their experiences and surprise you. Angular was in fact terrible. Qwik is not Angular or like it in any way.

Re: Hydration is pure overhead

#64

Post by sergiomattei »

ushakov wrote: post #39
chrischen wrote: post #10

Earlier quoted context omitted.

You don’t need dependencies like webpack, react, or even any javascript at all to show static pages… and it would be a poor use of them just to write static html. But if you want interactive elements like image editors, rich text edition, fancy tables, then you start needing smarter and smarter build tools to bundle it all together and support the maintenance of interactive complex web applications. I'd also argue th…

why do i need React for any of this? most template engines have partials and some have macros (Jinja2) React-based static site generators are so slow that they’re unusable for any website that has more than a couple pages

You don’t. Then don’t use it. Nobody’s forcing you to use React.

Static site generators are alive and well: Hugo, Pelican, etc.

Re: Hydration is pure overhead

#65

Post by mst »

wwweston wrote: post #38
yboris wrote: post #7

For reference, Miško Hevery, the author of this post, is the creator of Angular . At the end of the article, there's his solution: https://qwik.builder.io/guide/overview > Qwik is a new kind of web framework that can deliver instant loading web applications at any size or complexity. Your sites and apps can boot with less than 1kb of JS

> is the creator of Angular. Welp, that's reason enough for me to ignore him entirely. Especially on the topic of "overhead." Angular was an inexcusable atrocity.

The original Angular was, for its time, absolutely fantastic.

The state of the art has absolutely moved on but provided you were willing to understand its model (just like these days you need to understand React's model) it provided a power to performance ratio that nothing else in its class was capable of at the time.

Re: Hydration is pure overhead

#66

Post by mst »

zanellato19 wrote: post #15
programmarchy wrote: post #9

If I'm understanding correctly, this is binding event handlers "just in time" instead of when a component initializes. Isn't that just a tradeoff between working the CPU at load time vs. working the CPU on user interaction? This doesn't seem like a great tradeoff to me. Sure, maybe you save time during component initialization, but while that is happening the user is digesting the information anyway. Then once they m…

Yeah... This screams of people who never had bad networks. If you are going to add interactivity as a JIT thing, what happens when the user has a shitty connection? You give the impression that the page loaded to the user, but it didn't really load. This is just increasing by a lot the amount of connections the user will have to make. Its _more_ overhead with a bunch of http calls.

The goal here, as I understand it, is to make sites that can be built using fully interactive tooling whose main purpose is to be read, so fast initial readability is paramount and the alternative to JIT interactivity would be a page transition so the network problem doesn't actually make anything worse.

It may not be the best possible set of trade-offs for any particular application but it seems like a set of trade-offs worth exploring.

Re: Hydration is pure overhead

#67

Post by wwweston »

mst wrote: post #65
wwweston wrote: post #38

Earlier quoted context omitted.

> is the creator of Angular. Welp, that's reason enough for me to ignore him entirely. Especially on the topic of "overhead." Angular was an inexcusable atrocity.

The original Angular was, for its time, absolutely fantastic. The state of the art has absolutely moved on but provided you were willing to understand its model (just like these days you need to understand React's model) it provided a power to performance ratio that nothing else in its class was capable of at the time.

I was on a team that sunk 9 months into its model for a major project and what I saw bears no resemblance to what you're describing.

It's a framework that hated the idioms of its host language, as if the problem with front-end development was that it didn't have the ceremony of Java and the attendant abstractions/"patterns" of a static manifestly typed language. The conceptual overhead alone was ridiculous (as famously described here: http://codeofrob.com/entries/you-have-ruined-javascript.html ), and the payoff in terms of performance was negative on mobile no matter what we did. The fact that I had to know what the digest cycle was is a testament to the leaky nature of the abstractions. The tooling, wow, as far as I could tell batarang was actively broken for a good chunk of 2014 and 2015 and nobody had better suggestions.

I've used a lot of libraries/frameworks/languages with their own baggage but I've never had an experience where the differential between what I was hearing and the actual experience was that large, to the point where it's one of the first things I think of when it comes to the hazards of social proof.

If I wanted something that heavy again circa 2014, I'd tell myself to just use Ember. Hell, I'd rather use jQuery than Angular.

Re: Hydration is pure overhead

#68

Post by simulate-me »

codercatdev wrote: post #55
simulate-me wrote: post #34

Earlier quoted context omitted.

One reason I like SSR is that you need some form of SSR for public-facing websites anyway. Website previews (like in iMessage, Twitter, etc.) rely on Open Graph tags in the HTML, and these services expect the OG tags to be available without executing any JavaScript. Since you already need this step, you can make loading pages much faster if you inline any data you might have fetched from the client at view time.

Just one side note here you could also just use SSG, and never need to hit a server unless you rebuild the page in some fashion

This doesn't work if the content is coming from a dynamic source like a database.

Re: Hydration is pure overhead

#69

Post by BenjiWiebe »

CreepGin wrote: post #46

While we are on the topic of browser event handlers and "embracing how browser actually work", I can't help but mention that the builder.io website's top navbar cannot handle ctrl + clicking (for opening links in a new tab). It's actually quite subtle. Sometimes it works, sometimes it doesn't, depending on which page you are on, what you've already clicked, etc. All part of the fun of frontend web development, ain't…

Tip: If you have a mouse with a scroll wheel, clicking with the scroll wheel (middle clicking) opens links in a new tab too.

Re: Hydration is pure overhead

#70

Post by culi »

wwweston wrote: post #38
yboris wrote: post #7

For reference, Miško Hevery, the author of this post, is the creator of Angular . At the end of the article, there's his solution: https://qwik.builder.io/guide/overview > Qwik is a new kind of web framework that can deliver instant loading web applications at any size or complexity. Your sites and apps can boot with less than 1kb of JS

> is the creator of Angular. Welp, that's reason enough for me to ignore him entirely. Especially on the topic of "overhead." Angular was an inexcusable atrocity.

Whatever actual criticisms you have of Angular, do you really think there's anyone around who would be even more painfully aware of those criticisms than him?
Post reply on HN