14 ms·

I heard the word "hydration" so many times, I sort of get it, but always have question mark in mind that what's different between hydration and jquery approach?

kilburn 4y ago
Hydration only makes sense when you have a vdom that you have to "synchronize" with the initial state of the page (the html you got from the server). The act of performing this synchronization is what hydration is about (notice that this includes setting up event handlers too). What you do here is to reconcile the in-memory representation (vdom) with the actual contents of the page (the dom). In the jquery aprroach the in-memory model is built straight from what's on the page (the dom). This removes an entire class of problems (there's no mis-synchronization possible) but has its own set of issues (the model you build may not end up being what you expected while coding). More importantly, "hydration" use implies that the HTML that gets sent to the client is a Server-Side Rendered version generated from the same JS code that runs in the page. The very big advantage here is that there's a single place where the page's content is controlled from (the js/jsx/whatever code) instead of having to manually maintain the html/js relationship by hand like in the jquery case. Furthermore, the jquery approach is global in nature (you can manually scope jquery-fiddling, but if you make a mistake you may end up modifying stuff elsewhere on the page) whereas this cannot happen in the vdom approach. In general, the vdom approach makes code more manageable at the cost of runtime performance. That's why many people recommend react and/or other vdom-based frameworks for the complicated cases (lots of dynamic stuff on the page) but vanilla/jquery/etc. when the in-page interactivity is lower. Today's crop of "frontend frameworks" (such as nextjs, fresh here, etc.) are trying to achieve the benefits of the vdom approach while minimizing its' drawbacks (and full-page hydration is a big drawback because it takes "a lot" of time decreasing the page's Time-To-Interactive metric).
- Existenceblinks 4y ago
  So it's the same approach to generating html, except the part that belongs to client side (event/ui-state) is irrelevant to backend _anyway_. If you separate javascript code into 2 main parts, 1) what's only related to generating html 2) what's only related to DOM API, you get jQuery approach where on the back end javascript is just yet another backend language?
  - kilburn 4y ago
    > If you separate javascript code into 2 main parts The point is that you don't do this. You do: const App = () => { // Client-side counter const [count, setCount] = useState(0); useEffect(() => { setTimeout( () => {setCount(count+1)}, 1000 ); }, [count, setCount]); // HTML-rendering part return ( <div>Count: {count}</div> ); } The framework (next, fresh, whatever) grabs this and generates: - Some sort of "bundle.js" that contains the component (as well as the framework to render it). - An "index.html" that contains "<div>Count: 0</div>" (and references the above bundle). - When the "bundle.js" is loaded, it runs the App component in the browser and reconciles the in-memory vdom with the browser's dom (that has the div because it came in the .html) - From then on, the component runs normally (i.e.: the counter keeps increasing and you see it increase on the screen). In vanilla-land, you would: - Write "<div>Count: <span id="count">0</span></div>" in an index.html that also loads a "counter.js" - Write the counter.js file with something like: document.addEventListener('ready', () => { const count = document.getElementById('count'); let value = 0; setInterval(() => { count.innerText = value++; }, 1000); }); Less code, you don't need frameworks, hydration nor anything similar and it's probably much more performant. However: - If you want to change the counter's initial value, you have to update both the html and the js file - If another dev adds some element with id="count" to the html the whole thing breaks. - If you want to modify the generated html structure, you have to edit both the html and js file - When the logic gets more complex, you will have to implement it both in your backend-code-that-generates the html as well as in the js That is, even though it doesn't seem like it in a simple example such as this one, the developer ergonomics of having a vdom are much better when things get hairy. The million dollar question then becomes "how can we achieve a performance and code-size similar to the vanilla approach while keeping the ergonomics of the vdom".
    - Existenceblinks 4y ago
      So js framework separates the render function which renders html and the client-side only part (count event) for you. This akin to what I said earlier. The same missing piece here is effect (e.g. http) that actually transfer state from client to sever and persist to storage. The business logic for client-only is not going to be exactly business logic for behind-the-wall rules. Some may be shared but that's not really significant; it's going to be things like optimistic ui. vdom keeps being mentioned, but it doesn't matter here because it's implementation detail, other frameworks will do it differently. I don't see it's ended up being different than js as yet another backend language with a separate js for volatile state on ui.
rglover 4y ago
With jQuery, your rendering is 100% dynamic, meaning, you load your JS on the client/browser and when that code executes, it fetches some data and "injects" it into the DOM (technically a form of hydration). Hydration in context here means taking some HTML that was server-side rendered with JavaScript and then, in the browser, handing off subsequent rendering (in response to user interaction) to JavaScript running on the client. Think of it like those little dinosaur sponge toys that would inflate when you poured water on them. The dry sponge is your server-side rendered HTML and the interactive JavaScript is the water being poured on it.
- Existenceblinks 4y ago
  If you `s/Hydration/jQuery/` on your hydration description, I find it's still true.

kilburn 4y ago

Hydration only makes sense when you have a vdom that you have to "synchronize" with the initial state of the page (the html you got from the server). The act of performing this synchronization is what hydration is about (notice that this includes setting up event handlers too). What you do here is to reconcile the in-memory representation (vdom) with the actual contents of the page (the dom). In the jquery aprroach the in-memory model is built straight from what's on the page (the dom). This removes an entire class of problems (there's no mis-synchronization possible) but has its own set of issues (the model you build may not end up being what you expected while coding). More importantly, "hydration" use implies that the HTML that gets sent to the client is a Server-Side Rendered version generated from the same JS code that runs in the page. The very big advantage here is that there's a single place where the page's content is controlled from (the js/jsx/whatever code) instead of having to manually maintain the html/js relationship by hand like in the jquery case. Furthermore, the jquery approach is global in nature (you can manually scope jquery-fiddling, but if you make a mistake you may end up modifying stuff elsewhere on the page) whereas this cannot happen in the vdom approach. In general, the vdom approach makes code more manageable at the cost of runtime performance. That's why many people recommend react and/or other vdom-based frameworks for the complicated cases (lots of dynamic stuff on the page) but vanilla/jquery/etc. when the in-page interactivity is lower. Today's crop of "frontend frameworks" (such as nextjs, fresh here, etc.) are trying to achieve the benefits of the vdom approach while minimizing its' drawbacks (and full-page hydration is a big drawback because it takes "a lot" of time decreasing the page's Time-To-Interactive metric).

Existenceblinks 4y ago
So it's the same approach to generating html, except the part that belongs to client side (event/ui-state) is irrelevant to backend _anyway_. If you separate javascript code into 2 main parts, 1) what's only related to generating html 2) what's only related to DOM API, you get jQuery approach where on the back end javascript is just yet another backend language?
- kilburn 4y ago
  > If you separate javascript code into 2 main parts The point is that you don't do this. You do: const App = () => { // Client-side counter const [count, setCount] = useState(0); useEffect(() => { setTimeout( () => {setCount(count+1)}, 1000 ); }, [count, setCount]); // HTML-rendering part return ( <div>Count: {count}</div> ); } The framework (next, fresh, whatever) grabs this and generates: - Some sort of "bundle.js" that contains the component (as well as the framework to render it). - An "index.html" that contains "<div>Count: 0</div>" (and references the above bundle). - When the "bundle.js" is loaded, it runs the App component in the browser and reconciles the in-memory vdom with the browser's dom (that has the div because it came in the .html) - From then on, the component runs normally (i.e.: the counter keeps increasing and you see it increase on the screen). In vanilla-land, you would: - Write "<div>Count: <span id="count">0</span></div>" in an index.html that also loads a "counter.js" - Write the counter.js file with something like: document.addEventListener('ready', () => { const count = document.getElementById('count'); let value = 0; setInterval(() => { count.innerText = value++; }, 1000); }); Less code, you don't need frameworks, hydration nor anything similar and it's probably much more performant. However: - If you want to change the counter's initial value, you have to update both the html and the js file - If another dev adds some element with id="count" to the html the whole thing breaks. - If you want to modify the generated html structure, you have to edit both the html and js file - When the logic gets more complex, you will have to implement it both in your backend-code-that-generates the html as well as in the js That is, even though it doesn't seem like it in a simple example such as this one, the developer ergonomics of having a vdom are much better when things get hairy. The million dollar question then becomes "how can we achieve a performance and code-size similar to the vanilla approach while keeping the ergonomics of the vdom".
  - Existenceblinks 4y ago
    So js framework separates the render function which renders html and the client-side only part (count event) for you. This akin to what I said earlier. The same missing piece here is effect (e.g. http) that actually transfer state from client to sever and persist to storage. The business logic for client-only is not going to be exactly business logic for behind-the-wall rules. Some may be shared but that's not really significant; it's going to be things like optimistic ui. vdom keeps being mentioned, but it doesn't matter here because it's implementation detail, other frameworks will do it differently. I don't see it's ended up being different than js as yet another backend language with a separate js for volatile state on ui.

rglover 4y ago

With jQuery, your rendering is 100% dynamic, meaning, you load your JS on the client/browser and when that code executes, it fetches some data and "injects" it into the DOM (technically a form of hydration). Hydration in context here means taking some HTML that was server-side rendered with JavaScript and then, in the browser, handing off subsequent rendering (in response to user interaction) to JavaScript running on the client. Think of it like those little dinosaur sponge toys that would inflate when you poured water on them. The dry sponge is your server-side rendered HTML and the interactive JavaScript is the water being poured on it.

Existenceblinks 4y ago
If you `s/Hydration/jQuery/` on your hydration description, I find it's still true.