"Stop writing only SPAs" is advice in the same way as "stop making only left-hand turns". This article stops short of convincing me to stop biasing towards SPAs because it appears only to reiterate known challenges about SPAs and calls out bad practices (tons of unused javascript libraries). SPA frameworks are pretty damned good and they really can and ought to be used wherever you feel the need because some SPA frameworks are very quick to get started with and can be customized to significantly reduce bloat.
Single Page Application Is Not a Silver Bullet
11–20 of 111 posts
Re: Single Page Application Is Not a Silver Bullet
#12One thing that doesn’t get mentioned is that writing an SPA feels more like programming. Writing jquery feels like idk...not quite like programming.
It’s a lot more like writing a native mobile app, that’s for sure. You manage data and state with a much more long-term mindset. A bad line of JS is equivalent to a crash if it halts the whole SPA from working and requires a refresh.
Re: Single Page Application Is Not a Silver Bullet
#13> broken “open in a new tab” behaviour – people like to handle links in onClick handler, and browser can’t recognize it as a link (even if the majority of the links are valid, sooner or later you’ll encounter a non-link “link”) This one annoys me the most, but I will say an analogous problem is fairly common on non-SPA web sites, where reloading a URL doesn’t work as expected.
That's usually just a lack of basic engineering practices common to well-implemented SPAs. All requests below the SPA's root should be forwarded to the SPA root, which appropriately then routes the request to the proper views and controllers. Proper usage of resource IDs in these URLs allows a newly initialized application model to populate and serve the appropriate content for the appropriate views.
The point is that browsers already have built-in code to interact with links and such in a predictable and straightforward manner, and your suggestion that "a lack of basic engineering practices", implying all SPAs need to reimplement that functionality, shows just how absurd the situation is.
Re: Single Page Application Is Not a Silver Bullet
#14I always thought the decision was: - Content site = NOT single-page-app - Application = single-page-app Maybe there's more of a gray area between content sites and applications these days, but I think it's still pretty obvious: If most of the user's time is spent reading content, it's a content site.
That's a good starting point. I'd drill down even further and ask "what does the user do with the application?"
If the user needs to look at multiple screens at a time (e.g. like a mail client or something of similar complexity), then they're a candidate for an SPA. If the user does not need to do that, the app is probably simple enough to not be an SPA.
Re: Single Page Application Is Not a Silver Bullet
#15TBH most of the cons stated in this article are just because of bad programming, not because it's a SPA
> broken “back” button (sometimes it works properly, but in general people don’t trust it)
If your UX is good, the user will notice data is refreshed when going back. All current top tier SPA Frameworks have support for correct HTML5 routing.
> broken “open in a new tab” behaviour – people like to handle links in onClick handler, and browser can’t recognize it as a link (even if the majority of the links are valid, sooner or later you’ll encounter a non-link “link”)
Again, most up-to-date frameworks have a fallback by adding a normal href so you can still CTRL-Click it.
> sometimes broken “refresh” button – after refreshing you end up in a different UI (usually slightly, but still different)
I don't see a real disadvantage here, since you can simply store your state by manipulating the URL or even localstorage. So you even have the possibility to not store your state...But again, application design, not SPA
I do agree with TTI (at least on the first load) and bad performance on low end devices.
Re: Single Page Application Is Not a Silver Bullet
#16One thing that doesn’t get mentioned is that writing an SPA feels more like programming. Writing jquery feels like idk...not quite like programming.
I'd about say the opposite.
Organizing all your jQuery into meaningful classes and keeping the whole thing organized and orchestrated is very much the essence of programming. It's a rare skill (as a trip through many large jQuery code bases reveals).
Filling in some templates causing magic to happen behind the scenes on the other hand, not so much.
That being said, 1) are we interested in feeling like programmers or in pumping product? 2) if "pumping" is the answer, best tools depends on what is being done. All in favor or SPAs (when needed), but no, they aren't cooler than jQuery and are often big fat pigs that just shouldn't be used in that situation.
Re: Single Page Application Is Not a Silver Bullet
#17Earlier quoted context omitted.
That's usually just a lack of basic engineering practices common to well-implemented SPAs. All requests below the SPA's root should be forwarded to the SPA root, which appropriately then routes the request to the proper views and controllers. Proper usage of resource IDs in these URLs allows a newly initialized application model to populate and serve the appropriate content for the appropriate views.
The point is that browsers already have built-in code to interact with links and such in a predictable and straightforward manner, and your suggestion that "a lack of basic engineering practices", implying all SPAs need to reimplement that functionality, shows just how absurd the situation is.
The fundamental difference between a SPA and traditional website is that the routing and compositing of views is generally handled by the client rather than the server.
It doesn't make sense to call something that doesn't respect that design a SPA. A poorly implemented SPA is what I would call that.
Re: Single Page Application Is Not a Silver Bullet
#18Great to see the article posted on a "classic" (static) website built w/ jekyll. Find more open source (ready-to-fork) themes @ https://drjekyllthemes.github.io Build your own "classic" websites / blogs :-).
Re: Single Page Application Is Not a Silver Bullet
#19TBH most of the cons stated in this article are just because of bad programming, not because it's a SPA > broken “back” button (sometimes it works properly, but in general people don’t trust it) If your UX is good, the user will notice data is refreshed when going back. All current top tier SPA Frameworks have support for correct HTML5 routing. > broken “open in a new tab” behaviour – people like to handle links in o…
No. Because it is an SPA, it means there is more work to restore the default behavior of the back button. That's the way he should have articulated his point.
You also mention HTML5 routing.. Ok now you have to configure your web server to properly parse the URL and understand what it's conveying.
Re: Single Page Application Is Not a Silver Bullet
#20Earlier quoted context omitted.
That's usually just a lack of basic engineering practices common to well-implemented SPAs. All requests below the SPA's root should be forwarded to the SPA root, which appropriately then routes the request to the proper views and controllers. Proper usage of resource IDs in these URLs allows a newly initialized application model to populate and serve the appropriate content for the appropriate views.
The point is that browsers already have built-in code to interact with links and such in a predictable and straightforward manner, and your suggestion that "a lack of basic engineering practices", implying all SPAs need to reimplement that functionality, shows just how absurd the situation is.
Most SPA's don't, because most frameworks have some built-in functionality for this.