<story><title>JavaScript hydration is a workaround, not a solution</title><url>https://thenewstack.io/javascript-hydration-is-a-workaround-not-a-solution/</url></story><parent_chain><item><author>dmix</author><text>The recent evolution of JS frameworks has been really nice. Performance is basically getting identical to desktop.&lt;p&gt;The three recent developments I&amp;#x27;ve noticed:&lt;p&gt;- &amp;quot;Islands&amp;quot; in Deno &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;fresh.deno.dev&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;fresh.deno.dev&amp;#x2F;&lt;/a&gt; and &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;remix.run&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;remix.run&amp;#x2F;&lt;/a&gt; where only small isolated parts get hydrated, instead of the whole page&lt;p&gt;- Using &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;linear.app&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;linear.app&lt;/a&gt; style data-flows ala Replicache (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;replicache.dev&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;replicache.dev&amp;#x2F;&lt;/a&gt;) where JSON data is preloaded for all sub-links and stored offline-first like a desktop app, so clicking on anything loads immediately w&amp;#x2F;o waiting for network requests to finish&lt;p&gt;- Now with &amp;#x27;resumability&amp;#x27; where the server-side framework was built with client hydration in mind and delivers the bare minimum event&amp;#x2F;DOM data necessary to make the page interactive (instead of just being a glorified HTML cache load before the usual JS activates)&lt;p&gt;For people not following JS these might all seem like constantly reinventing past lessons, but there is a logical evolution happening here towards desktop-style performance and interactivity on the web. Or pure server-side performance but with full JS interactivity.&lt;p&gt;The next set of frameworks is going to be as big of an evolution the way Angular&amp;#x2F;Backbone-&amp;gt;React&amp;#x2F;Vue was ~8yrs ago. But it&amp;#x27;s going to require new backend server frameworks, not just a new client framework. There&amp;#x27;s probably a big opportunity for the project that can combine this stuff properly.</text></item></parent_chain><comment><author>BeefWellington</author><text>&amp;gt; The recent evolution of JS frameworks has been really nice. Performance is basically getting identical to desktop.&lt;p&gt;It&amp;#x27;s getting much much better but performance is only &amp;quot;identical to desktop&amp;quot; if you ignore anything about its resource usage or speed increases in processors over the past decades.&lt;p&gt;&amp;gt; For people not following JS these might all seem like constantly reinventing past lessons, but there is a logical evolution happening here towards desktop-style performance and interactivity on the web. Or pure server-side performance but with full JS interactivity.&lt;p&gt;For people following JS these &lt;i&gt;are&lt;/i&gt; examples of constantly relearning past lessons.
I&amp;#x27;m not sure how anyone could reliably expect 100+ms round-trip time (on a good connection) to offer the same experience as something local but I think what it actually means is that the people writing JS-based software haven&amp;#x27;t actually used a native desktop app for years and have done mostly web-based things.&lt;p&gt;You could be forgiven it since HTML&amp;#x2F;JS as a user interface design language appears to have taken over completely, to the point where even the most popular code editors are now web browser-based.&lt;p&gt;Seriously though, go load up any natively compiled app on your OS of choice and compare the speed of it doing any given task to what you get out of web-based versions, electron versions, etc. There isn&amp;#x27;t a comparison.&lt;p&gt;My griping aside, I recognize JS as a language is here to stay and it&amp;#x27;s important to stay on top of its developments and improvements.</text></comment>
<story><title>JavaScript hydration is a workaround, not a solution</title><url>https://thenewstack.io/javascript-hydration-is-a-workaround-not-a-solution/</url></story><parent_chain><item><author>dmix</author><text>The recent evolution of JS frameworks has been really nice. Performance is basically getting identical to desktop.&lt;p&gt;The three recent developments I&amp;#x27;ve noticed:&lt;p&gt;- &amp;quot;Islands&amp;quot; in Deno &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;fresh.deno.dev&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;fresh.deno.dev&amp;#x2F;&lt;/a&gt; and &lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;remix.run&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;remix.run&amp;#x2F;&lt;/a&gt; where only small isolated parts get hydrated, instead of the whole page&lt;p&gt;- Using &lt;a href=&quot;http:&amp;#x2F;&amp;#x2F;linear.app&quot; rel=&quot;nofollow&quot;&gt;http:&amp;#x2F;&amp;#x2F;linear.app&lt;/a&gt; style data-flows ala Replicache (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;replicache.dev&amp;#x2F;&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;replicache.dev&amp;#x2F;&lt;/a&gt;) where JSON data is preloaded for all sub-links and stored offline-first like a desktop app, so clicking on anything loads immediately w&amp;#x2F;o waiting for network requests to finish&lt;p&gt;- Now with &amp;#x27;resumability&amp;#x27; where the server-side framework was built with client hydration in mind and delivers the bare minimum event&amp;#x2F;DOM data necessary to make the page interactive (instead of just being a glorified HTML cache load before the usual JS activates)&lt;p&gt;For people not following JS these might all seem like constantly reinventing past lessons, but there is a logical evolution happening here towards desktop-style performance and interactivity on the web. Or pure server-side performance but with full JS interactivity.&lt;p&gt;The next set of frameworks is going to be as big of an evolution the way Angular&amp;#x2F;Backbone-&amp;gt;React&amp;#x2F;Vue was ~8yrs ago. But it&amp;#x27;s going to require new backend server frameworks, not just a new client framework. There&amp;#x27;s probably a big opportunity for the project that can combine this stuff properly.</text></item></parent_chain><comment><author>doix</author><text>The things you have listed minimize the impact of network latency, they don&amp;#x27;t affect the rendering performance which is still a big deal. Apps that need to render large amounts of data still kind of suck, you&amp;#x27;ll see many apps &amp;quot;virtualize&amp;quot; things. So rather than having 10,000 elements, you have however many fit in your viewport + N and as you scroll they get reused. The tearing hurts my soul.&lt;p&gt;Compare the scrolling in Excel 97 + Windows NT to Google Sheets&amp;#x2F;Office 365. It&amp;#x27;s night and day. The webapps that render everything with WebGL do preform better, but then you have non-native widgets.&lt;p&gt;I hope this problem gets solved one day.</text></comment>