IMHO the whole advantage of single-page apps is about separating the UI and the data + using the browser as a cross-platform UI toolkit, runtime and deployment engine. The reason for SPAs to exist is that browsers are the only way to deploy an app that runs on every OS, looks pretty, automatically updates in an instant every time you run it and can be discovered and ran by everybody in a single click. Just imagine a world where something like WPF was made a truly free standard with full-featured 100%-compatible open-source implementations available on all the major OSes (Windows, Mac, Linux, Android, iOS) from the beginning and packed with efficient support for apps to be ran straight from a URL.
I love when people try to point the finger at a technology when in reality it is 100% the people who are using and implementing the technology. It's their fault. 99% of developers I know who create terrible SPA's have a long list of terrible things they've created. It's a mixture of incompetence, laziness, and poor management.
I like the hybrid approach - sprinkle SPAs where page reloads should be avoided. Have many SPAs in your product. Just keep them small and assign each SPA a distinct use case or area.<p>Let's take a CMS as an example. The "Edit blog post/page" function can be its own SPA avoiding page reload when the post is modified. Managing the list of posts/pages can be another. A page reload in between steps is fine. Nowadays internet speed is fast and latency is pretty low. Browsers are also very efficient and vive caching. If you keep your SPAs small, the user won't see the lag going from one page to another.<p>Multiple SPAs also allows you to keep things modular. Different teams can own different parts.<p>Do not however bundle the entire CMS into a single SPA. It will most likely contain a lot of code and resources to load. That will kill performance and slow down development over time.
I think SPAs fail because a lot of teams just don't know what they need to do. It looks like a web page but needs to handle complex interactions/workflows and probably maintain state as well. The people with web dev expertise are used to dealing with pages and forms, and the people with experience developing sophisticated UIs (either complex or elegant) are used to working with UI frameworks that are knowable and predictable.
While I appreciate the commentary, I do disagree on a few points.<p>Starting towards the end. The comments about JS Framwork cadence doesn't nearly apply today as much as a few years ago. I mean Backbone was released in 2010 (8 years ago) and was probably the first JS SPA "framework" to gain significant traction. There have been many since then. Angular and Ember were also in 2010. React was first released in 2013 (over 5 years ago) and Vue was 2014.<p>Those have been the heavy hitters imho. All of which are pretty mature at this point. There are many others, of course, but that's been true of even desktop platforms. Yeah, Angular 2 was a big shift, but React, Vue and Angular are really the main players in this space. Most others take some queues from those three. Given that, it's a poor argument, and the language is more dated than the frameworks in question at this point.<p>Personally, I find SPAs are great for Line of business apps that need more complexity than a typical CRUD app can offer. Also, front end development <i>IS</i> DEVELOPMENT. Many snobby backend developers turn up their noses and feel it doesn't deserve the same level of consideration as backend development. They don't follow the same practices, consider use or lean on application designs already established in a number of toolkits.<p>Personally, I currently lean on React + material-ui. For the most part it has me covered, and I can find third party controls that at least match the styling. Read the Material Design guidelines. It isn't that hard and just try to follow the rules. Think about other applications you've used and push back on all features, punting as much as you can for as long as you can.<p>Avoid complexity at all costs. Break stuff apart into smaller pieces, and write code that's easy to replace.<p>Everything said and done, I think I'm just cranky at these types of articles that just indicate to me a point of view of someone unwilling to learn new things, or try new tools. I keep an eye on so much, and have for over two decades in dealing with web-based applications. I'm surprised how much the attitudes of some haven't changed in two decades.
Great read! There’s a lot of truth to this, but in my 18 years of being a dev, the major reason <i>anything</i> fails usually comes down to poor understanding and miscommunication from the higher-ups. Customers either don’t know what they want or are too lazy to articulate it. Management is usually technology-clueless and, as the article points out, has no idea how much time, money, and effort is truly required to build a high-quality maintainable app. Add to that the sea of frameworks, libraries, “tech stacks”, standards, and trends, and you have a recipe for disaster.<p>Technology is also becoming increasingly layered and interdependent on brittle infrastructure. Abandoned projects can be a huge time waster as well, especially when they break. For example I’ve been working on trying to fix an abandoned web application written in an odd combination of languages and frameworks with a testing suite filled with old libraries and test scenarios that no longer make sense.. This thing is not broken, it’s shattered. It’s taken our team two entire sprints to get it somewhat working again. That’s the reality of modern software engineering.
My go to point on this subject is even if you have the perfect front end it won't save you from a slow DAL. I'm not sure why we aren't allowed to be full stack developers anymore because having a say in both the front and back end is a great way to prevent frivilous work from being done.
I'm convinced SPA are the future -- they're more than about fitting all your stuff on to a "single page", the concept of a page doesn't go away in SPAs, it's just the implementations and strategies for loading and state management that are different. A better way to think about them is as "client side rendered" applications. The reason I think SPAs are the future, the premises are simple:<p>- Processing power of client devices will only grow, compute will cheapen but communication costs (speed of light/fiber/etc) are cheapening at a much slower rate.<p>- Repeatedly sending layout is wasteful, given site architectures that render the same page repeatedly<p>- Separation of UI and data is generally a good idea<p>- Sufficiently advanced SPAs offer Server Side Rendering (SSR), which makes them almost equivalent and yet more reusable than the alternatives (Java's JSP stuff, ASP.NET's ASPX mess, Ruby's ERB + layouts + partials stuff, Django's Jinja + layouts + partials stuff)<p>Mark my words, when wasm is widely accepted and lots of languages start compiling to it, people are going to start porting the SSR alternatives (JSP, ASPX, etc) to run on the frontend to achieve this same exact goal. I can't wait to see someone post on HN about "JSP in the browser".<p>There are of course a few things to keep track of, If sophistication in quantum communications grows faster than everyone expects, the landscape changes drastically. As a complete layman it seems possible to me to imagine arrays of entangled atoms being used at ISPs (possibly forced to be closer together) to reduce RTT to effectively near zero which fallback to regular over-the-wire communication for error correction or whatever else.<p>Almost 100% of the problems I've seen expressed with SPAs is from tooling or developers doing it wrong. Maybe that's it's biggest weakness, along with being an approach prone to accidental complexity.
For the most part all you need to ask yourself is this:<p>Must full page reloads be eliminated?<p>(That's the real defining characteristics of SPAs)<p>For 95% of businesses a PWA with occasional full page reloads will be fine.<p>But for 5% of (mostly large) businesses, a kick ass SPA will be necessary.
Summary: inexperienced developers create bad software. Who knew.<p>Our SPAs are thouroughly tested (TDD, near 100% coverage). We make them mobile-first offline-first so they can be embedded in a phone app as well.<p>For CRUD, things that need to be searchable and things that need to work withoutJS, we usually have a rails/node app that renders views the classic way: server-side.<p>For static websites, we try to use static page generators like jekyll
Again? Single page apps refresh and respond faster than their HTML counterparts. Sounds like a mad backend dev posting hate for the evolving front-end world because they don't want to learn new stuff.
I'm building something that's very single-page app for the first time. A project to use flask, sqlalchemy, and ajax and really just do some fun flashy things, not necessarily practical things, but I do feel like the SPA space is much better than last I'd looked. I definitely see how it's easy to create something bad in a SPA doing it all yourself. My code right looks like that horse, with 500 lines of jquery full of repeating functionality still in snippet form. But really, the horses face is just as ugly as his ass.
Last year, I wrote a small single-page app engine that takes a JSON representation of HTML, and writes it to the DOM to build the page in the browser. The entire app is described in one JSON document, so it's quick to download and needs no network to change pages. I'm slowly starting to develop it again. The demo site is still up (with a SPA builder) at <a href="https://sparational.com" rel="nofollow">https://sparational.com</a> and you're welcome to suggest any improvements.
What about using an iframe and refreshing it with links targeting it ? Use <link rel="preload" ...> to make it really fast. Do so for any subcomponent of your page that can be updated independently of the rest of the page. Use browser caching for code assets/dependencies.<p>Pros: cheap & fast (?)<p>Cons: obviously the logical structure of your app must (somehow) follow the structure of nested iframes in the page.
The problem is that there is a lot of immaturity within the JS world at the moment. And that makes the complexity go "BOOM".<p>Thing about it. Should things really get more complex just because we are moving more of the computation to the client rather than having it sit at the server? Done right it remains the same.
My ability to rationalize and manage SPAs dramatically improved once immutable data and functional programming techniques were introduced.<p>But that can probably be said for any programming environment.
Going from little jQuery scripts to full JS applications is difficult. People with desktop UI experience know this, but many JS devs don't.<p>Another problem is that we still haven't figured out the best way to write JS SPA applications. Even the React team is improvising as they go along. If you need any more proof just look at the new hooks api.
This remembers me the timeless "Do Things that Don't Scale" by @pg.<p><a href="http://paulgraham.com/ds.html" rel="nofollow">http://paulgraham.com/ds.html</a>
>Single-page web applications damage businesses.<p>plus some good points<p>p.s. I thought vue came before react, but it's the other way around. Interesting
TL;DR: try not to suck.<p>Seriously, if you're committing mistakes 1, 3, and 4, then your multi-page website is going to be awful, too. "SPA or not SPA" is far down the list of questions you need to be asking yourself.
This misses the main reason for SPAs which is separation of concerns. Keep your biz logic out of your UI. Test your tiers independently. Refactor your tiers as required and if you did it right you can rewrite you api without messing with your UI and the same the other way.<p>Want to change your backend from C# to go? Easy. Want to change from angular to vue? Easy.<p>But programming is hard, and doing things for the long game is harder, and finding people with the skill and experience to pull it off is harder still.<p>Or... you could put all your biz logic in stored procedures and wrap it all with a nice .net Razer frontend, throw in a bunch of third party controls and call it a day.