10 ms·

Hydration is pure overhead

79 points by steve8708 4y ago

genzweedsmoker 4y ago
recursivedoubts 4y ago
Sometimes you just have to laugh. We've been doing SSR all along, folks: server side templates. Yeah, HTML was pretty hamstrung as a hypermedia, which made for mediocre UX, but that's been fixed by libraries like unpoly, hotwire, or, my own, htmx.
- daenney 4y ago
  htmx is the first thing that’s made me feel like I can build a useful front end again in years. Plain server side rendering of templates and a bit of sprinkles on top. It’s awesome and thank you!
- hunterb123 4y ago
  This is for enhancing CSR initial load times. For apps that need to work offline, have a lot of UI state, have sister native apps, etc. Yes we've had SSR, noone is disputing that, nor is it relevant. These are separate solutions for separate problems. I agree some people reach for the wrong tools sometimes, but that's a universal problem.
  - lf-non 4y ago
    Not that irrelevant. Traditional SSR involved a separation between templates which contain presentation logic, and controllers for mediating business logic, persistence etc. If your backend & frontend are in same language, or you use template engines with implementations in mutliple language like handlebars/pug/soy etc. you could easily render the same templates using JS and your client side can have as much ui state, interactivity etc. as you want. If we adopt incremental enhancement then the fetching of templates can be delayed - we primarily need the controllers which handle dom events to make the server-rendered ui interactive. This is easily achievable through libraries like stimulus where controllers can add complex interactivity to server rendered templates and re-render them if needed through templates which are fetched on demand. We can even preserve form element states by using libraries like morphdom for swapping content. However, what really breaks down all of the above is the concept of components as popularized by React etc. When we start writing react-style components then our rendering logic and associated behavior are tightly coupled and we need to pull in all the rendering logic for enhancing the server rendered content. React devs like to preach that traditional separation of concerns is not useful in practice and it is better to have rendering code colocated with behavior - but solutions like this just demonstrate that this separation did actually have some merit albeit at the cost of some indirection. What solutions like Qwik are attempting to do is enabling folks to keep writing component oriented code but now we need a fancy compiler tooling that deeply integrates with the stack. The approach does have its merits but it is just one path to address the problem.
  - layer8 4y ago
    > For apps that need to work offline I wonder if it’s a suitable approach at all for those, because when they’re offline they won’t be able to lazy-load the JS code they’re still missing.
- ushakov 4y ago
  the reason we need all this is so that Netlify and Vercel can make money there’s no other explanation it’s a capitalist game and if you want to stay sane, you shouldn’t play it
  - hunterb123 4y ago
    > there’s no other explanation Faster initial load times for PWAs? No conspiracy theory or capitalism rant needed.
    - ushakov 4y ago
      faster load times is achieved by not using javascript, (pre-) rendering content on server and caching with CDN this is how Wikipedia does it for the last 20(?) years and they sure won’t be changing that any time soon PWA is a whole different topic
      - hunterb123 4y ago
        > PWA is a whole different topic No it's not, as hydration is used to improve the initial load times for PWAs. Afterwards PWAs will load offline first. > faster load times is achieved by not using javascript, (pre-) rendering content on server and caching with CDN Yes you can make sites not using JS and should in certain scenarios, that's not relevant here. > this is how Wikipedia does it for the last 20(?) years and they sure won’t be changing that any time soon Wikipedia is a web site, not a web app. It works really well as a site and thus uses technologies meant for web sites.
        ushakov 4y ago
        > hydration is used to improve the initial load times for PWAs this very sentence sounds absurd how many websites out there need to work offline?
        hunterb123 4y ago
        You didn't address my last points but I'll still address this comment. > this very sentence sounds absurd Which part? "hydration", "improve the initial load times", or "PWAs"? Let me rephrase if you are confused. It renders a snapshot of the app on the server so when you first load the web app it's rendered already. Then the client picks it up from there. It's completely optional to do this. > how many websites out there need to work offline? Are you asking if it's useful to have access to information and entertainment offline? For me the answer is yes. It depends what you are making, but yes I think you should strive to make things work offline if you can. Also websites can work offline without CSR. That's not really what this is about. Hydration is about improving initial load times of CSR. I really don't know how to simplify this further.
- eyelidlessness 4y ago
  Is this condescension really necessary? I don’t think it helps the discussion generally, but particularly from authors of libraries in a similar space with a different approach. Lots of others in the space, many whose work would likely get a similar reaction, are quite welcoming to competing approaches and even speak highly of them. That said, I think you might want to consider looking more closely at how Qwik works. It produces markup metadata that’s not dissimilar to what I see in htmx. I don’t know if it’s a direct inspiration, but that similarity seems particularly odd to dismiss so bluntly. The major philosophical difference between the two is the authoring experience: Qwik annotates the HTML with a compiler, in htmx it appears the expectation is you write the annotations directly. Qwik’s server side templates just happen to be authored as JSX components. Both are completely valid! Probably more a matter of preference than anything. Personally, I prefer the Qwik approach. But I welcome yours as well and encourage people who would prefer it to choose it. Both are significantly better, in many cases, for users than the current outcomes from many other frameworks which appeal to the devs Qwik is targeting. Isn’t that also welcome given the state of web dev today?
  - recursivedoubts 4y ago
    that's fair, I was being too sardonic i've spent a bit of time today looking into qwik and I appreciate what they are trying to do not my bag, but i'm obviously a contrarian in the web world
    - eyelidlessness 4y ago
      Hey, thank you for this response though! It’s much more what I like/hope to see in the ecosystem. Also I’m an old curmudgeon so I relate, and sometimes need a nudge to turn the contrarian knob down to friendly :)
- cultofmetatron 4y ago
  don't forget LiveView!
  - mikl 4y ago
    LiveView is easily the best implementation of this concept, shame Elixir is not more popular than it is.
    - cultofmetatron 4y ago
      I built my startup on elixir. Its allowed us to do things in days that would take weeks in nodejs. Absolutely fantastic system overall. biggest gripe is that its hard to hire for.
chasd00 4y ago
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 directly to the browser? Is the idea to take advantage of the server's horsepower to get something on the screen fast by sending pre-rendered HTML and then wait while the browser runs the code to basically re-create the page for interactivity? (it's been a while since i've done traditional front-end web dev)
- chrischen 4y ago
  I think most importantly the server can cache requests (cache the generated HTML). This is especially important for public, mostly static pages that one might want to do SEO optimizations for anyways. Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser.
  - bacro 4y ago
    >Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser. Isn't this the other way around? I mean a server is supposed to be fast enough to handle a lot of requests.
    - hunterb123 4y ago
      An individual server is more powerful than one client, but your client computing power multiplies by your user base. Same reason DDoS attacks are generally more powerful than DoS attacks. Power in numbers.
    - chrischen 4y ago
      Well, servers often come with more but slower cores.
ushakov 4y ago
- matthoiland 4y ago
  I've been brainwashed by consumers – they demand and expect a certain experience on the modern web. Also, you can run Next.js on a Raspberry Pi and free Cloudflare DNS+SSL. :shrug:
  - ushakov 4y ago
    what are their demands? pretty sure my Raspberry Pi will just give up after pulling 2000 npm packages and building native modules
    - oblak 4y ago
      You're wrong. I used to run node + mongo on my 3B+ until it died on me one last time :( It could manage much, much more than that. Now, I haven't tried running Next on it but unless it's worse than Nuxt (which isn't all that fast, really), it should be fine. These little SBCs are only lacking at GPU tasks
      - ushakov 4y ago
        have you tried using a compiled language and a database that isn’t web-scale? this should fix your dead board /s
        oblak 4y ago
        No, I am not manly enough :( Pretty sad about it dying on me, though. This time it wasn't just a borked flash card. Been waiting for a 5 but it's taking ages
  - dham 4y ago
    The fallacy of our generation. Except they literally don't. They just don't want their computer to not run out of battery loading your resume driven developed site.
legym 4y ago
The company I work for is making a big deal about client-side hydration. We use nextjs for our sites. My director was asking about Svelte. "Something i wanted to mention is both the React team and nextjs team are aware of this and are working on a solution to address needing to load Javascript on the client. Its called React Server Components React Server Components Documentation https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html https://reactjs.org/blog/2020/12/21/data-fetching-with-react... Nextjs Blog on Server Components https://vercel.com/blog/everything-about-react-server-components https://vercel.com/blog/everything-about-react-server-compon... Nextjs Documentation on Server Components (Alpha) https://nextjs.org/docs/advanced-features/react-18/server-components https://nextjs.org/docs/advanced-features/react-18/server-co... We can try it out today on a platform that supports a node environment. This is from nextjs docs. I have a few thoughts on Svelte, but just wanted to point this out!" With Server Components, there's zero client-side JavaScript needed, making page rendering faster.
- grayrest 4y ago
  If you're into this sort of thing you should look into Marko. They're kind of obsessed about page load perf with the justification that it's good for e-commerce. They've also been into streaming, partial hydration, out of order rendering, etc for years as part of that general effort.
- ushakov 4y ago
  > React Server Components really? c’mon could we please ask the React folks to stop making simple things hard?
yboris 4y ago
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 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
- wwweston 4y ago
  > 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.
  - hu3 4y ago
    Experience is invaluable. He probably knows much more than those who didn't create a major front-end tool.
  - fleddr 4y ago
    That's a terrible mindset no matter how much you hate Angular.
  - eyelidlessness 4y ago
    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.
  - mst 4y ago
    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.
    - 4y ago
programmarchy 4y ago
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 make their decision to act, there's no extra delay to produce the next state. However, with a "just in time" event binding, now the user has to wait (slightly) longer after they've already made their decision, which seems worse.
- zanellato19 4y ago
  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.
  - deckard1 4y ago
    it's all to appease the Google black box. UX always takes a back seat to SEO. Because if there are no users, then no one to irritate with bad UX in the first place. If it weren't for SEO we would have all dropped SSR+hydration long ago. Absolutely no one likes unifying URLs and content and all that shit on two sides of a single app.
  - mst 4y ago
    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.
- lhorie 4y ago
  Haven't dug too deep, but my understanding is that this doesn't bind event handlers just in time, but instead sets up event delegation from a tiny blocking bootstrapping script, to attach a top-level event handler that catches all events as soon as the first chunk of HTML streams in. In addition, it sets up an intersection observer. Then depending on when an event happens, it might require downloading that one event handler piecemeal if the event occurred early enough during page load, or if the event is late enough, the action happens instantaneously because the intersection observer already downloaded the handler in anticipation that the user would interact with the element, it being visible and all. The trade-off is that the download of every other JS thing effectively gets deferred due to fragmentation of how JS gets loaded in the page, but the cleverness of the trade-off is that in typical scenarios, most of that deferred code is not going to be activated by the user in the first place (or at least not in quick succession so as to overload network).
wonnage 4y ago
This article complains that downloading stuff is slow and then goes on to propose a solution where you have to wait for stuff to download before firing a scroll handler.
- steve8708 4y ago
  Totally fair. The intended argument is that downloading (and parsing and executing) an entire page just for one button click to load is slow. But if you can hydrate granularity, and prefetch smartly (based on visibility, analytics, etc) things speed up a lot. If done right, there is no delay on interaction, and a lot less time and resources required to load a page, increasing lighthouse scores and TI specifically Thats what we’ve seen in the field too, the FAQs in the article link to some real world examples. Tho I can’t say our prefetching is as smart yet in practice as we want, so sometimes there is a delay on very first interaction. There is a straightforward way to improve this tho that we are working on
CreepGin 4y ago
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 it?
- BenjiWiebe 4y ago
  Tip: If you have a mouse with a scroll wheel, clicking with the scroll wheel (middle clicking) opens links in a new tab too.
- steve8708 4y ago
  Oops, thanks for catching. I implemented the client side routing there from scratch with partytown and must have forgot a check to make sure the ctrl/cmd/shift keys aren’t down when canceling the event for a client side routes. Will get that fixed this week
  - steve8708 4y ago
    confirmed - I foolishly did not include this check, PR sent for the fix, thanks again for mentioning!
scotty79 4y ago
It seems like just trading pre-loading for lag on first interaction and trading bundling stuff int as few requests as possible for many smaller requests with their respective headers. I mean it's fine to have choice about this trade-offs but you can do it right now just by splitting your application into parts and hydrating only the part the user interacts with. Which gives you additional flexibility of automatically hydrating the part the user is most likely to use and hydrating others in the background in the periods of user inactivity. Also this article focuses very much on event handlers, but main part of hydration is creation of dynamic structures that allow the application to re-render dynamically and efficiently, sometimes swapping out large parts of page contents that are not delivered with initial pre-rendered HTML. If you really wanted to improve the situation one could work on introducing partial hydration on demand into React and work on ways to serialize most of internal structures of React apps like virtual dom, so they can be passed along with the pre-rendered HTML to make the remaining requests lighter. Creating new framework is way less impactful.

79 points by steve8708 4y ago

Sometimes you just have to laugh. We've been doing SSR all along, folks: server side templates. Yeah, HTML was pretty hamstrung as a hypermedia, which made for mediocre UX, but that's been fixed by libraries like unpoly, hotwire, or, my own, htmx.

daenney 4y ago
htmx is the first thing that’s made me feel like I can build a useful front end again in years. Plain server side rendering of templates and a bit of sprinkles on top. It’s awesome and thank you!
hunterb123 4y ago
This is for enhancing CSR initial load times. For apps that need to work offline, have a lot of UI state, have sister native apps, etc. Yes we've had SSR, noone is disputing that, nor is it relevant. These are separate solutions for separate problems. I agree some people reach for the wrong tools sometimes, but that's a universal problem.
- lf-non 4y ago
  Not that irrelevant. Traditional SSR involved a separation between templates which contain presentation logic, and controllers for mediating business logic, persistence etc. If your backend & frontend are in same language, or you use template engines with implementations in mutliple language like handlebars/pug/soy etc. you could easily render the same templates using JS and your client side can have as much ui state, interactivity etc. as you want. If we adopt incremental enhancement then the fetching of templates can be delayed - we primarily need the controllers which handle dom events to make the server-rendered ui interactive. This is easily achievable through libraries like stimulus where controllers can add complex interactivity to server rendered templates and re-render them if needed through templates which are fetched on demand. We can even preserve form element states by using libraries like morphdom for swapping content. However, what really breaks down all of the above is the concept of components as popularized by React etc. When we start writing react-style components then our rendering logic and associated behavior are tightly coupled and we need to pull in all the rendering logic for enhancing the server rendered content. React devs like to preach that traditional separation of concerns is not useful in practice and it is better to have rendering code colocated with behavior - but solutions like this just demonstrate that this separation did actually have some merit albeit at the cost of some indirection. What solutions like Qwik are attempting to do is enabling folks to keep writing component oriented code but now we need a fancy compiler tooling that deeply integrates with the stack. The approach does have its merits but it is just one path to address the problem.
- layer8 4y ago
  > For apps that need to work offline I wonder if it’s a suitable approach at all for those, because when they’re offline they won’t be able to lazy-load the JS code they’re still missing.
ushakov 4y ago
the reason we need all this is so that Netlify and Vercel can make money there’s no other explanation it’s a capitalist game and if you want to stay sane, you shouldn’t play it
- hunterb123 4y ago
  > there’s no other explanation Faster initial load times for PWAs? No conspiracy theory or capitalism rant needed.
  - ushakov 4y ago
    faster load times is achieved by not using javascript, (pre-) rendering content on server and caching with CDN this is how Wikipedia does it for the last 20(?) years and they sure won’t be changing that any time soon PWA is a whole different topic
    - hunterb123 4y ago
      > PWA is a whole different topic No it's not, as hydration is used to improve the initial load times for PWAs. Afterwards PWAs will load offline first. > faster load times is achieved by not using javascript, (pre-) rendering content on server and caching with CDN Yes you can make sites not using JS and should in certain scenarios, that's not relevant here. > this is how Wikipedia does it for the last 20(?) years and they sure won’t be changing that any time soon Wikipedia is a web site, not a web app. It works really well as a site and thus uses technologies meant for web sites.
      - ushakov 4y ago
        > hydration is used to improve the initial load times for PWAs this very sentence sounds absurd how many websites out there need to work offline?
        hunterb123 4y ago
        You didn't address my last points but I'll still address this comment. > this very sentence sounds absurd Which part? "hydration", "improve the initial load times", or "PWAs"? Let me rephrase if you are confused. It renders a snapshot of the app on the server so when you first load the web app it's rendered already. Then the client picks it up from there. It's completely optional to do this. > how many websites out there need to work offline? Are you asking if it's useful to have access to information and entertainment offline? For me the answer is yes. It depends what you are making, but yes I think you should strive to make things work offline if you can. Also websites can work offline without CSR. That's not really what this is about. Hydration is about improving initial load times of CSR. I really don't know how to simplify this further.
eyelidlessness 4y ago
Is this condescension really necessary? I don’t think it helps the discussion generally, but particularly from authors of libraries in a similar space with a different approach. Lots of others in the space, many whose work would likely get a similar reaction, are quite welcoming to competing approaches and even speak highly of them. That said, I think you might want to consider looking more closely at how Qwik works. It produces markup metadata that’s not dissimilar to what I see in htmx. I don’t know if it’s a direct inspiration, but that similarity seems particularly odd to dismiss so bluntly. The major philosophical difference between the two is the authoring experience: Qwik annotates the HTML with a compiler, in htmx it appears the expectation is you write the annotations directly. Qwik’s server side templates just happen to be authored as JSX components. Both are completely valid! Probably more a matter of preference than anything. Personally, I prefer the Qwik approach. But I welcome yours as well and encourage people who would prefer it to choose it. Both are significantly better, in many cases, for users than the current outcomes from many other frameworks which appeal to the devs Qwik is targeting. Isn’t that also welcome given the state of web dev today?
- recursivedoubts 4y ago
  that's fair, I was being too sardonic i've spent a bit of time today looking into qwik and I appreciate what they are trying to do not my bag, but i'm obviously a contrarian in the web world
  - eyelidlessness 4y ago
    Hey, thank you for this response though! It’s much more what I like/hope to see in the ecosystem. Also I’m an old curmudgeon so I relate, and sometimes need a nudge to turn the contrarian knob down to friendly :)
cultofmetatron 4y ago
don't forget LiveView!
- mikl 4y ago
  LiveView is easily the best implementation of this concept, shame Elixir is not more popular than it is.
  - cultofmetatron 4y ago
    I built my startup on elixir. Its allowed us to do things in days that would take weeks in nodejs. Absolutely fantastic system overall. biggest gripe is that its hard to hire for.

chasd00 4y ago

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 directly to the browser? Is the idea to take advantage of the server's horsepower to get something on the screen fast by sending pre-rendered HTML and then wait while the browser runs the code to basically re-create the page for interactivity? (it's been a while since i've done traditional front-end web dev)

chrischen 4y ago
I think most importantly the server can cache requests (cache the generated HTML). This is especially important for public, mostly static pages that one might want to do SEO optimizations for anyways. Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser.
- bacro 4y ago
  >Servers are often weaker than many consumer computers anyways, so I don’t thin it’s because it can render faster than your own browser. Isn't this the other way around? I mean a server is supposed to be fast enough to handle a lot of requests.
  - hunterb123 4y ago
    An individual server is more powerful than one client, but your client computing power multiplies by your user base. Same reason DDoS attacks are generally more powerful than DoS attacks. Power in numbers.
  - chrischen 4y ago
    Well, servers often come with more but slower cores.

ushakov 4y ago

matthoiland 4y ago
I've been brainwashed by consumers – they demand and expect a certain experience on the modern web. Also, you can run Next.js on a Raspberry Pi and free Cloudflare DNS+SSL. :shrug:
- ushakov 4y ago
  what are their demands? pretty sure my Raspberry Pi will just give up after pulling 2000 npm packages and building native modules
  - oblak 4y ago
    You're wrong. I used to run node + mongo on my 3B+ until it died on me one last time :( It could manage much, much more than that. Now, I haven't tried running Next on it but unless it's worse than Nuxt (which isn't all that fast, really), it should be fine. These little SBCs are only lacking at GPU tasks
    - ushakov 4y ago
      have you tried using a compiled language and a database that isn’t web-scale? this should fix your dead board /s
      - oblak 4y ago
        No, I am not manly enough :( Pretty sad about it dying on me, though. This time it wasn't just a borked flash card. Been waiting for a 5 but it's taking ages
- dham 4y ago
  The fallacy of our generation. Except they literally don't. They just don't want their computer to not run out of battery loading your resume driven developed site.

legym 4y ago

The company I work for is making a big deal about client-side hydration. We use nextjs for our sites. My director was asking about Svelte. "Something i wanted to mention is both the React team and nextjs team are aware of this and are working on a solution to address needing to load Javascript on the client. Its called React Server Components React Server Components Documentation https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html https://reactjs.org/blog/2020/12/21/data-fetching-with-react... Nextjs Blog on Server Components https://vercel.com/blog/everything-about-react-server-components https://vercel.com/blog/everything-about-react-server-compon... Nextjs Documentation on Server Components (Alpha) https://nextjs.org/docs/advanced-features/react-18/server-components https://nextjs.org/docs/advanced-features/react-18/server-co... We can try it out today on a platform that supports a node environment. This is from nextjs docs. I have a few thoughts on Svelte, but just wanted to point this out!" With Server Components, there's zero client-side JavaScript needed, making page rendering faster.

grayrest 4y ago
If you're into this sort of thing you should look into Marko. They're kind of obsessed about page load perf with the justification that it's good for e-commerce. They've also been into streaming, partial hydration, out of order rendering, etc for years as part of that general effort.
ushakov 4y ago
> React Server Components really? c’mon could we please ask the React folks to stop making simple things hard?

yboris 4y ago

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

wwweston 4y ago
> 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.
- hu3 4y ago
  Experience is invaluable. He probably knows much more than those who didn't create a major front-end tool.
- fleddr 4y ago
  That's a terrible mindset no matter how much you hate Angular.
- eyelidlessness 4y ago
  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.
- mst 4y ago
  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.
  - 4y ago

programmarchy 4y ago

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 make their decision to act, there's no extra delay to produce the next state. However, with a "just in time" event binding, now the user has to wait (slightly) longer after they've already made their decision, which seems worse.

zanellato19 4y ago
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.
- deckard1 4y ago
  it's all to appease the Google black box. UX always takes a back seat to SEO. Because if there are no users, then no one to irritate with bad UX in the first place. If it weren't for SEO we would have all dropped SSR+hydration long ago. Absolutely no one likes unifying URLs and content and all that shit on two sides of a single app.
- mst 4y ago
  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.
lhorie 4y ago
Haven't dug too deep, but my understanding is that this doesn't bind event handlers just in time, but instead sets up event delegation from a tiny blocking bootstrapping script, to attach a top-level event handler that catches all events as soon as the first chunk of HTML streams in. In addition, it sets up an intersection observer. Then depending on when an event happens, it might require downloading that one event handler piecemeal if the event occurred early enough during page load, or if the event is late enough, the action happens instantaneously because the intersection observer already downloaded the handler in anticipation that the user would interact with the element, it being visible and all. The trade-off is that the download of every other JS thing effectively gets deferred due to fragmentation of how JS gets loaded in the page, but the cleverness of the trade-off is that in typical scenarios, most of that deferred code is not going to be activated by the user in the first place (or at least not in quick succession so as to overload network).

wonnage 4y ago

This article complains that downloading stuff is slow and then goes on to propose a solution where you have to wait for stuff to download before firing a scroll handler.

steve8708 4y ago
Totally fair. The intended argument is that downloading (and parsing and executing) an entire page just for one button click to load is slow. But if you can hydrate granularity, and prefetch smartly (based on visibility, analytics, etc) things speed up a lot. If done right, there is no delay on interaction, and a lot less time and resources required to load a page, increasing lighthouse scores and TI specifically Thats what we’ve seen in the field too, the FAQs in the article link to some real world examples. Tho I can’t say our prefetching is as smart yet in practice as we want, so sometimes there is a delay on very first interaction. There is a straightforward way to improve this tho that we are working on

CreepGin 4y ago

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 it?

BenjiWiebe 4y ago
Tip: If you have a mouse with a scroll wheel, clicking with the scroll wheel (middle clicking) opens links in a new tab too.
steve8708 4y ago
Oops, thanks for catching. I implemented the client side routing there from scratch with partytown and must have forgot a check to make sure the ctrl/cmd/shift keys aren’t down when canceling the event for a client side routes. Will get that fixed this week
- steve8708 4y ago
  confirmed - I foolishly did not include this check, PR sent for the fix, thanks again for mentioning!

scotty79 4y ago

It seems like just trading pre-loading for lag on first interaction and trading bundling stuff int as few requests as possible for many smaller requests with their respective headers. I mean it's fine to have choice about this trade-offs but you can do it right now just by splitting your application into parts and hydrating only the part the user interacts with. Which gives you additional flexibility of automatically hydrating the part the user is most likely to use and hydrating others in the background in the periods of user inactivity. Also this article focuses very much on event handlers, but main part of hydration is creation of dynamic structures that allow the application to re-render dynamically and efficiently, sometimes swapping out large parts of page contents that are not delivered with initial pre-rendered HTML. If you really wanted to improve the situation one could work on introducing partial hydration on demand into React and work on ways to serialize most of internal structures of React apps like virtual dom, so they can be passed along with the pre-rendered HTML to make the remaining requests lighter. Creating new framework is way less impactful.