Agreed. SPAs only make sense for few websites like Trello, for most other websites plain dynamic HTML with dash of ajax here and there are much better.
Yes, SPAs aren't required but they make it more likely that the site will use AJAX to request data instead of rendering the page with server data PHP-style.
SPAs can be a good thing when used internally in a business (ease of distribution, sandboxing, etc.), but I agree that any public-facing web site is probably best served by static HTML with minimal JS where it is absolutely necessary.
SPAs: reinventing the browser in the browser, and you get the bonus of doing it all in JavaScript!
I hate SPAs, so much more complexity and work. In MPAs you can still use JS and AJAX for a better experience, but SPAs just have so much needless extra work and are harder to maintain. They are also frustrating to use. They can be better to use when done well, but you don't often see that unless it's from someone quite big.
SPA isn't automatically the best solution for a page or site with frequent updates.
The updates are handled by JavaScript and http calls.
You can write a lot of that stuff in a dozen lines of JQuery with nicely refreshing content and ajax instead of throwing in large amounts of framework bloat.
The concept of a SPA is a total hack of web patterns. I predict in a few years we'll refer back to SPA's the way we do now to AJAX or DHTML.
We're getting closer to the best of both worlds, where we SSR pages and then "hydrate" them with JS components. The tooling around this isn't great yet, but it's definitely all there.
In my experience SPAs bring a lot of headaches that you just don't really need to think about with traditional HTML. Browser navigation, form handling, a lot of accessibility stuff comes out of the box for free, and there's one source of truth about what makes a particular object valid or how business logic works (which is solvable in the SPA world but brings a lot of complexity when you need to share logic between the client and the server, especially when they're in different languages).
Frankly out of all the things that make our architecture simple and efficient, I would say server rendered HTML is by far the biggest one.
The sort of garbage we ended up doing prior to SPAs justify SPAs.
Writing a server to dynamically create a HTML page that also includes first pass content as well as potentially dynamic javascript to make the page interactive in "later passes" is just an ugly mix of client side execution and server side execution in one spot.
The application just feels a lot more consistent when the client is just pulling data instead of being thrown away and recreated in the middle of a request made by a browser for a particular URL that is just one of a very long series of requests.
Doesn't it ever backfire though? I've used plenty of SPAs that shouldn't have been, forcing me to wait for the page to load twice and increasing frustration. If they'd just stuck some AJAX where appropriate the experience would be so much better.
While it would be nice if they provided HTML endpoints, there are valid reasons for using SPAs, even for text-heavy sites. That said, the loading bar is a bit mind-blowing IMO.
Most websites and web apps have use AJAX to dynamically update certain parts of the site. Even though few sites would need to use it for everything, once you introduce good tools for dynamically updating the DOM and hire some Javascript developers, it's easy to say "Let's just use this approach to everything".
It's fair to say it's a lazy approach. I've built many SPAs that probably would have been better as static sites, and would have benefited from better SEO. But hey, we got then shipped fast.
I fully agree with this. SPAs are for webapps, not websites.
For websites, you should always use progressive enhancement - there is no reason why you couldn't obtain the same performance gains by progressively enhancing your site with reload-less navigation. That's what AJAX and the HTML5 History API are for.
Especially don't forget that no, not all your clients support JS. And there's no reason why they should need to, for a website.
This feels like a strange argument to make when server-rendered HTML has been the norm for decades, and it's only been recently that SPAs have become popular.
Use what you're best at, and if you're paid to use something, use it. If you don't like what you're using at work, take your time to find a new job opportunity. I feel like SPA's are overrated they take away performance and stability from standard HTML websites with some AJAX capabilities thrown in. When I first heard of a SPA it sounded perfect: you download all the HTML you'll ever need once, and load content to the appropriate DIVs accordingly, but now you gotta take a hike and basically do more work to show a button, or a text box, or whatever. I mean no disrespect to people who love SPA web dev, all power to you, but unless I'm paid a lot more, or I'm working on some multimedia / social media type of site, I don't see the point. Sometimes SPA's I see are done poorly which is another pet peeve.
I never really thought the benefits of SPA apps were worth the trouble they cause. Hypothetically, you can account for all the inherent issues of a SPA app but you have to pretty much reinvent the wheel to achieve it.
Modern HTML and vanilla JavaScript are pretty good. I really think the optimal website is plain HTML and bits of JS sprinkled in as modules to add interactivity where needed.
I think that the front end web dev community needs to just agree on a good pattern to use that doesn't involve a convoluted library or framework.
reply