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?<p>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?<p>(it's been a while since i've done traditional front-end web dev)
For reference, Miško Hevery, the author of this post, is the creator of <i>Angular</i>.<p>At the end of the article, there's his solution: <a href="https://qwik.builder.io/guide/overview" rel="nofollow">https://qwik.builder.io/guide/overview</a><p>> 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
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?<p>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.
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.<p>"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<p>React Server Components Documentation
<a href="https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html" rel="nofollow">https://reactjs.org/blog/2020/12/21/data-fetching-with-react...</a><p>Nextjs Blog on Server Components
<a href="https://vercel.com/blog/everything-about-react-server-components" rel="nofollow">https://vercel.com/blog/everything-about-react-server-compon...</a><p>Nextjs Documentation on Server Components (Alpha)
<a href="https://nextjs.org/docs/advanced-features/react-18/server-components" rel="nofollow">https://nextjs.org/docs/advanced-features/react-18/server-co...</a><p>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!"<p>With Server Components, there's zero client-side JavaScript needed, making page rendering faster.
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.
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).<p>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?
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.<p>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.<p>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.<p>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.<p>Creating new framework is way less impactful.
Sometimes you just have to laugh.<p>We've been doing SSR all along, folks: server side templates.<p>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.