<story><title>Htmx Is the Future</title><url>https://quii.dev/HTMX_is_the_Future</url></story><parent_chain><item><author>RHSeeger</author><text>&amp;gt; We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace.&lt;p&gt;Plus we now get the benefit of people trying to &amp;quot;replace&amp;quot; built in browser functionality with custom code, either&lt;p&gt;The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check.&lt;p&gt;or&lt;p&gt;They&amp;#x27;re changing things because they&amp;#x27;re already so far from default browser behavior, why not? ... Scrolling broken or janky because the developer decided it would be cool to replace it? Check.&lt;p&gt;There is a time and place for SPA (mail is a great example). But using them in places where the page reload would load in completely new content for most of the page anyways? That&amp;#x27;s paying a large cost for no practical benefit; and your users are paying some of that cost.</text></item><item><author>obpe</author><text>It&amp;#x27;s kinda funny to me that many of the &amp;quot;pros&amp;quot; of this approach are the exact reasons so many abandoned MPAs in the first place.&lt;p&gt;For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It&amp;#x27;s a pretty shitty client experience if you have to do a network request for each and every validation of user input.&lt;p&gt;Also, there was a push to move the shitty code from the server to the client to free up server resources and prevent your servers from ruining the experience for everyone.&lt;p&gt;We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace.&lt;p&gt;But that isn&amp;#x27;t because of the technology, it&amp;#x27;s because all the devs writing shitty MPAs are now writing shitty SPAs. If this becomes popular, they will start writing shitty MPAs again. Nothing about this technology will stop that.</text></item></parent_chain><comment><author>yellowapple</author><text>&amp;gt; There is a time and place for SPA (mail is a great example). But using them in places where the page reload would load in completely new content for most of the page anyways? That&amp;#x27;s paying a large cost for no practical benefit; and your users are paying some of that cost.&lt;p&gt;Yep.  It&amp;#x27;s bonkers to me that a page consisting mostly of text (say, a Twitter feed or a news article) takes even so much as &lt;i&gt;a&lt;/i&gt; second (let alone multiple!) to load on any PC&amp;#x2F;tablet&amp;#x2F;smartphone manufactured within the last decade.  That latency is squarely the fault of heavyweight SPA-enabling frameworks and their encouragement of replacing the browser&amp;#x27;s features with custom JS-driven versions.&lt;p&gt;On the other hand, having to navigate a needlessly-elongated history due to every little action producing a page load (and a new entry in my browser&amp;#x27;s history, meaning one more thing to click &amp;quot;Back&amp;quot; to skip over) is no less frustrating.  Neither is wanting to reload a page only for the browser to throw up scary warnings about resending information simply because that page happened to result from some POST&amp;#x27;d form submission.&lt;p&gt;Everything I&amp;#x27;ve seen of HTMX makes it seem to be a nice middle-ground between full-MPA v. full-SPA: each &amp;quot;screen&amp;quot; is its own page (like an MPA), but said page is rich enough to avoid full-blown reloads (with all the history-mangling that entails) for every little action within that page (like an SPA).  That it&amp;#x27;s able to gracefully downgrade back to an ordinary MPA should the backend support it and the client require it is icing on the cake.&lt;p&gt;I&amp;#x27;m pretty averse to frontend development, especially when it involves anything beyond HTML and CSS, but HTMX makes it &lt;i&gt;very&lt;/i&gt; tempting to shift that stance from absolute to conditional.</text></comment>
<story><title>Htmx Is the Future</title><url>https://quii.dev/HTMX_is_the_Future</url></story><parent_chain><item><author>RHSeeger</author><text>&amp;gt; We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace.&lt;p&gt;Plus we now get the benefit of people trying to &amp;quot;replace&amp;quot; built in browser functionality with custom code, either&lt;p&gt;The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check.&lt;p&gt;or&lt;p&gt;They&amp;#x27;re changing things because they&amp;#x27;re already so far from default browser behavior, why not? ... Scrolling broken or janky because the developer decided it would be cool to replace it? Check.&lt;p&gt;There is a time and place for SPA (mail is a great example). But using them in places where the page reload would load in completely new content for most of the page anyways? That&amp;#x27;s paying a large cost for no practical benefit; and your users are paying some of that cost.</text></item><item><author>obpe</author><text>It&amp;#x27;s kinda funny to me that many of the &amp;quot;pros&amp;quot; of this approach are the exact reasons so many abandoned MPAs in the first place.&lt;p&gt;For instance, a major selling point of Node was running JS on both the client and server so you can write the code once. It&amp;#x27;s a pretty shitty client experience if you have to do a network request for each and every validation of user input.&lt;p&gt;Also, there was a push to move the shitty code from the server to the client to free up server resources and prevent your servers from ruining the experience for everyone.&lt;p&gt;We moved away for MPAs because they were bloated, slow and difficult to work with. SPAs have definitely become what they sought to replace.&lt;p&gt;But that isn&amp;#x27;t because of the technology, it&amp;#x27;s because all the devs writing shitty MPAs are now writing shitty SPAs. If this becomes popular, they will start writing shitty MPAs again. Nothing about this technology will stop that.</text></item></parent_chain><comment><author>com2kid</author><text>&amp;gt; The SPA broke it... Back button broken and a buggy custom implementation is there instead? Check.&lt;p&gt;MPAs break back buttons all the damn time, I&amp;#x27;d say more often than SPAs do.&lt;p&gt;Remember the bad old days when websites would have giant text &amp;quot;DO NOT USE YOUR BROWSER BACK BUTTON&amp;quot;? That is because the server had lots of session state on it, and hitting the browser back button would make the browser and server be out of sync.&lt;p&gt;Or the old online purchase flows where going back to change the order details would completely break the world and you&amp;#x27;d have to re-enter all your shipping info. SPAs solve that problem &lt;i&gt;very&lt;/i&gt; well.&lt;p&gt;Let&amp;#x27;s think about it a different way.&lt;p&gt;If you are making a phone app, would you EVER design it so that the app downloads UI screens on demand as the user explores the app? That&amp;#x27;d be insane.</text></comment>