|
1234567891011121314151617 |
- title: Two articles on SPA or SPA-like sites vs alternatives
- url: https://piperhaywood.com/two-articles-on-spa-or-spa-like-sites-vs-alternatives/
- hash_url: d46752726e00de301573576176df1f1c
-
- <p>I missed these two articles by Tom MacWright from last year.</p>
- <p><a href="https://macwright.com/2020/05/10/spa-fatigue.html">Second-guessing the modern web</a>, 10 May 2020<br>
- <a href="https://macwright.com/2020/10/28/if-not-spas.html">If not SPAs, What?</a>, 28 October 2020</p>
- <p>In both, he outlines few upsides and downsides about the single page app (SPA) approach to websites and has a few points that I have really struggled to articulate in the past.</p>
- <p>From “Second-guessing”:</p>
- <blockquote>
- <p>There is a swath of use cases which would be hard without React and which aren’t complicated enough to push beyond React’s limits. But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are trying to get you closer to <em>the performance you would’ve gotten if you just hadn’t used so much technology</em>.</p>
- </blockquote>
- <p>I’ve dabbled with React and Vue in small side projects and experiments. But the point above is the big reason I’ve never taken the time to sit down and learn either of them properly. For almost every client site I’ve ever done, it just didn’t make sense to make it an SPA.</p>
- <p>And I’m not 100% sure, but I think this might contribute to longevity. Some of my clients are still working with the same sites I built for them nearly 10 years ago, a few with just minor security-related updates in the meantime and no other maintenance strictly required. That’s not to say that those sites couldn’t use a “lick of paint” to bring them in to the 2020s; the point is that they <em>work</em>. And for organizations working on really tight budgets, or budgets that fluctuate wildly due to public funding, stability is really important. They can’t afford a developer on retainer to keep things running smoothly.</p>
- <p>But of course the SPA vibe is pretty attractive, particularly for cultural orgs. MacWright has some decent alternatives suggested in “If not SPAs” including <a href="https://github.com/turbolinks/turbolinks">Turbolinks</a>, <a href="https://barba.js.org">Barba.js</a>, and <a href="https://instant.page">instant.page</a>. Will also mention <a href="https://github.com/MoOx/pjax">MoOx/pjax</a> since I’ve used it before for page transitions with very good results, but probably won’t use it in the future as it hasn’t been updated in a while.</p>
- <p>And again, there’s the rub. The more non-native scripts, plugins, etc I use in a project, the more likely that it’s going to be a major headache (and thus major time/money for the client) for me to change things down the line if or when that bit of tech is no longer supported or has changed significantly.</p>
- <p>So it’s not even so much about being wary of React or Vue, it’s about not making assumptions, being cautious and cognizant of future needs or restrictions when proposing a tech stack. <em>Any</em> tech stack you choose will ultimately become a ball-and-chain, not just those based on JavaScript frameworks. It’s just that the ball can sometimes be heavier than it needed to be, and you can anticipate that with a little foresight.</p>
|
