Hacker News Reader

> A more granular approach—termed resumability by Qwik and as I understand it the forthcoming version of Marko—works by treating the server-generated HTML as the initial state. The code executed from there is much more isolated than a full component.

Is that sort of what Phoenix LiveView does? Return a fully server-rendered page on initial load, then set up a "template" on the client side that can receive any values that change server-side over a websocket and patch them into the DOM?

This sounds conceptually similar, albeit maybe more similar to React Server Components? I’m really not familiar enough with Phoenix to get that specific though. Even in the JS ecosystem there’s a lot of nuance between seemingly similar approaches (hence why even commonly referenced concepts like hydration can be confused for what they actually do).

I think what Fresh is doing now is more similar to Server Components, shipping full components to the client. With LiveView, once it's set up on the client, the updates it sends over the wire are much smaller. https://fly.io/blog/how-we-got-to-liveview/ shows some examples of the idea.

Yeah this looks much more similar to Qwik. It even looks like they have a similar view serialization approach.

> The big difference now is the convergence of code written for both server and client, and compilers which help strip down and optimize what happens in the client.

I understand the spirit of your comment, but this was/is also true of Google Web Toolkit (GWT).

I’m going to have to take that on faith, their site doesn’t appear to ship the JS necessary to open the nav menu. But clicking through a few links confirmed what I recall: the major difference (apart from language) is the component/templating approach. Not that one is inherently better than the other (though I do personally prefer JSX), but bringing this concept to a dev environment which thus far mostly lacks it is a good thing for users. And with more flexibility in variety, there’s better odds users will get that experience.

> Hydration in the current sense is re-running most of what the server already did, to recreate the runtime state it already had.

It’s interesting that the problems with hydration is in some sense caused by the insistence on one-way data binding (deriving the view from the state). I imagine that with two-way data binding then you’d just need to attach event handlers and then the state would be derived from the view on the next interaction. Maybe.

It's really easy to make the states diverge this way. That's why the one-way binding is popular.

OTOH if there were a way to produce a two-way implementation from a one-way description, that could be great for performance. But this is already more CS than engineering.

How do the states diverge?

I think you can have a two-way binding with a controlled update procedure, akin to one-way data-binding. I’ve read some people claim to do it by producing a kind of one-way directionality under-the-hood (?) from two-way bindings. The goal being that views can update state (and other views).

I think it was here I read it:

«‘2-way’ shouldn't be a problem if a component reports user events (perhaps transformed/mapped) to the domain model without changing it's own core state (disregarding throttling etc.) and only changes its core state in response to events from the domain model.« — peerreynders @ https://dev.to/peerreynders/comment/1objn

I’m not sure that gets you much. You still have to know which parts of the code are implicated in executing those event handlers, which very likely close over other state and call into other logic. To an extent you can get that with static analysis (as Qwik does, with one-way binding), but highly dynamic code is tricky no matter what.

For all the improvements pioneered by Marko, why is eBay still so slow (compared to equivalent ecommerce sites in Next.js and similar)?

My guess, the bottleneck is in the data layer.

Honestly it's unfair to compare a small e-commerce site made with Next to one of the biggest websites on the internet.

If Ebay was made with Next it would probably be much slower. React is the slowest at SSR of the modern frameworks. Amazon considered using it but it was too slow for them so they keep using Java + sprinkled JS.

What's the story behind Amazon's SSR?

https://twitter.com/amilajack/status/1484970825568505856

I’m not sure why you’re asking me, but I just did a quick “how slow does eBay feel” on my really spotty mobile connection and it didn’t feel slow at all. Faster than HN, which is usually my fast baseline that responds even when I’m not coaxing my network settings.

> Serializing server state to HTML and sprinkling in interactivity to pick up where it left off is exactly where we should be headed.

Ironically we were already doing that 15 years ago years with PHP/ASP/Java/Rails + jQuery.

This is neither ironic nor correct. But I will say I’ve described my mental model of Qwik as effectively that UX, but the compiler writes the jQuery for you.

if the code is the same on the server, one could serialise the state and transfer it with the html, right?

You still have transfer the JS.

ITT, it was finally proven that JS is not code.

I don't think anyone believes JS is a great language. It's just what we're stuck with.

How I wish something, anything better could've taken over. .NET was beautiful to work in. Maybe the native apps for iOS or Android are cleaner (I dunno, never tried).

But browsers are what the world use, and they only speak HTML and Javascript (sadly). So we're stuck unless something else manages to create a sea change in how the world uses the internet.

Right, but not all of it. The way Qwik serializes it is (this is from memory and probably overly simplistic, but conceptually approximate):

- Primitives already present from the server render are serialized directly into the HTML, and the compiled code reads those values from the DOM

- Everything else is split into fine grain chunks, assigned a special identifier (Qwik uses URLs) which is serialized to the HTML to fetch (which can be eager or on-demand) and activate interactivity as needed

My understanding is that currently Qwik serializes more than necessary—i.e. can be optimized further to eliminate non-interactive chunks from consideration—but that they’re focused on reducing JS cost first.

That's how it works.

The way I read it, you might have lots of javascript to compute and render your e.g. counter control but you can keep that on the server side, only return the (much smaller) piece of HTML code and ONLY the JS needed to make the control interactive.

I don't know whether this means that it doesn't work as SPA any more since if you want to keep the best of both, you will end up creating more4 complexity, a new framework to learn and probably get marginal improvements at best.

that’s how it works, but you also need to attach event handlers and set up the state for the framework on the client-side (for subsequent interactions).

I meant the state for the framework, as I understood it the same framework was used on the serverside.