12 ms·

Or, rather than being some great conspiracy, SSR (or as we used to call it, just rendering) makes a great deal of sense. What goes around, comes around. It has

Or, rather than being some great conspiracy, SSR (or as we used to call it, just rendering) makes a great deal of sense. What goes around, comes around. It has always felt like the front-end frameworks, from things like Backbone to React always failed to learn the lessons of history. Preoccupied with being "new" in an area that's rapidly gaining capabilities via the browser. Re-inventing the wheel isn't difficult. Improving it is.

Aerbil313 3y ago
True. The drive to SSR is caused by the rise of battery-constrained mobile devices with unreliable wireless connections, along with the rise of cloud computing. I recently used a Windows 10 machine after years and I suggest you try it. It could not be more evident that Microsoft is fully betting on Web and Cloud. Windows is increasingly a thin client. Even the mail app isn’t an actual mail client now.
6510 3y ago
Someone some day should write an article about frameworks with examples that show it's advantages. I just try different things in vanilla depending on the load. In terms of speed nothing can beat just serving a page rendered on the server. If you really need dynamic updates replacing dom nodes is good up to some very limited number, virtual dom and cloned nodes increase this number by a tiny irrelevant amount. If you need to update more than 100 nodes, from what I've tested, nothing beats replacing the parent node content with a html string. Sometimes inline onclick="" handlers are great compared to creating 1000 listeners one by one. Sometimes you put the listener on the parent and figure out what was clicked when it happens. I've even had cases where iframes are wonderful. At times I also put some or many hidden nodes in the html document and display them when needed. Writing this I'm curious what the performance is for <output>.... https://jsfiddle.net/4ajzcfw9/ https://jsfiddle.net/4ajzcfw9/ (Didn't feel like doing it right)
- sirsinsalot 3y ago
  This is the basis of HTMLX, a framework for tree replacement with server-side rendered HTML

Aerbil313 3y ago

True. The drive to SSR is caused by the rise of battery-constrained mobile devices with unreliable wireless connections, along with the rise of cloud computing. I recently used a Windows 10 machine after years and I suggest you try it. It could not be more evident that Microsoft is fully betting on Web and Cloud. Windows is increasingly a thin client. Even the mail app isn’t an actual mail client now.

6510 3y ago

Someone some day should write an article about frameworks with examples that show it's advantages. I just try different things in vanilla depending on the load. In terms of speed nothing can beat just serving a page rendered on the server. If you really need dynamic updates replacing dom nodes is good up to some very limited number, virtual dom and cloned nodes increase this number by a tiny irrelevant amount. If you need to update more than 100 nodes, from what I've tested, nothing beats replacing the parent node content with a html string. Sometimes inline onclick="" handlers are great compared to creating 1000 listeners one by one. Sometimes you put the listener on the parent and figure out what was clicked when it happens. I've even had cases where iframes are wonderful. At times I also put some or many hidden nodes in the html document and display them when needed. Writing this I'm curious what the performance is for <output>.... https://jsfiddle.net/4ajzcfw9/ https://jsfiddle.net/4ajzcfw9/ (Didn't feel like doing it right)

sirsinsalot 3y ago
This is the basis of HTMLX, a framework for tree replacement with server-side rendered HTML