Lazy Loading components is type of code splitting (sometimes used with the term Progressive Hydration). The idea there is that you can send the code to the browser as you need it or as it comes into view etc. In so it can sometimes be possible not to send some JavaScript. But it reflects the shape of your app. Like if it's a SPA you are still sending the majority of the code.
Partial Hydration suggests that certain components never make it to the browser ever. That you strip out the parts that will never be needed. If the vast majority of the page is static you never ship that. A manual Islands architecture would have you add components as these Islands in static HTML. To achieve something similar.
A Partial Hydration solution would have you write a single app the way you would a normal React App. All the templating would use the framework and you could use components freely. However, it would automatically figure out which of those components will never be sent to the browser. That is how Marko works.
Personally I feel this is really powerful abstraction because it frees you from making the client/server mental hop most of the time when structuring your application. Sure there are decision points, but you write your app as if it were a client side MPA app for the most part and it is just optimized automatically.
Partial Hydration suggests that certain components never make it to the browser ever. That you strip out the parts that will never be needed.
However, with careful effective lazy loading, wouldn't you achieve the same result? For example, if there are two pages in an SPA, page A and page B, whereby page B contains unique components such as a modal, which is not in use by page A; if a user visited page A, wouldn't the two components (pageB, modal) also never make it to the browser if one lazy loaded the routes? That's in effect the same as partial hydration, right?
With a SPA Partial Hydration doesn't really work since you basically need everything below the client side router in the browser. You can make some small gains, but with an MPA it can be more drastic. The best you can do with a SPA is code Splitting since you may need page B in the browser eventually. You may never load Page B so you save the enduser where they don't but that JavaScript chunk for it contains all the code to render Page B.
Partial Hydration is looking at a page and going well the footer has no events or state we don't need to ship it, and neither does the header but some navigation links. Actually for our whole product page the only part this is interactive is that "Add to Cart" button. Even though I wrote my app with a bunch of re-usable components (since the Header/Footer is used on all product pages) I'm only going to ship the Add To Cart button to the client. The rest of it never needs to be shipped.
What's nice about it being a single app experience is if there is no need for any client side JavaScript it sends none. Which is what I was trying to show in the Hackernews example. I just wrote some pages and components as normal and it never sent any JavaScript bundle to the client. It does on the article page because there is some JS needed to toggle the collapsing of comments. But I wasn't doing anything differently as the developer.
But this is different than Code Splitting. Code splitting is a super powerful tool. But if I know that a certain <div> is never going to be rendered in the browser I can just not include it in any bundle. Not the JS code, not the template. Partial Hydration isn't about deferred loading but only sending the parts of the code that actually need to be in the browser. The next version of Marko is looking at making this even more granular and sending not whole components but only parts of components that need to be in the browser.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Lazy Loading components is type of code splitting (sometimes used with the term Progressive Hydration). The idea there is that you can send the code to the browser as you need it or as it comes into view etc. In so it can sometimes be possible not to send some JavaScript. But it reflects the shape of your app. Like if it's a SPA you are still sending the majority of the code.
Partial Hydration suggests that certain components never make it to the browser ever. That you strip out the parts that will never be needed. If the vast majority of the page is static you never ship that. A manual Islands architecture would have you add components as these Islands in static HTML. To achieve something similar.
A Partial Hydration solution would have you write a single app the way you would a normal React App. All the templating would use the framework and you could use components freely. However, it would automatically figure out which of those components will never be sent to the browser. That is how Marko works.
Personally I feel this is really powerful abstraction because it frees you from making the client/server mental hop most of the time when structuring your application. Sure there are decision points, but you write your app as if it were a client side MPA app for the most part and it is just optimized automatically.
I'm curious about this statement:
However, with careful effective lazy loading, wouldn't you achieve the same result? For example, if there are two pages in an SPA, page A and page B, whereby page B contains unique components such as a modal, which is not in use by page A; if a user visited page A, wouldn't the two components (pageB, modal) also never make it to the browser if one lazy loaded the routes? That's in effect the same as partial hydration, right?
With a SPA Partial Hydration doesn't really work since you basically need everything below the client side router in the browser. You can make some small gains, but with an MPA it can be more drastic. The best you can do with a SPA is code Splitting since you may need page B in the browser eventually. You may never load Page B so you save the enduser where they don't but that JavaScript chunk for it contains all the code to render Page B.
Partial Hydration is looking at a page and going well the footer has no events or state we don't need to ship it, and neither does the header but some navigation links. Actually for our whole product page the only part this is interactive is that "Add to Cart" button. Even though I wrote my app with a bunch of re-usable components (since the Header/Footer is used on all product pages) I'm only going to ship the Add To Cart button to the client. The rest of it never needs to be shipped.
What's nice about it being a single app experience is if there is no need for any client side JavaScript it sends none. Which is what I was trying to show in the Hackernews example. I just wrote some pages and components as normal and it never sent any JavaScript bundle to the client. It does on the article page because there is some JS needed to toggle the collapsing of comments. But I wasn't doing anything differently as the developer.
But this is different than Code Splitting. Code splitting is a super powerful tool. But if I know that a certain
<div>is never going to be rendered in the browser I can just not include it in any bundle. Not the JS code, not the template. Partial Hydration isn't about deferred loading but only sending the parts of the code that actually need to be in the browser. The next version of Marko is looking at making this even more granular and sending not whole components but only parts of components that need to be in the browser.