Live data from Hacker News

Single Page Application Is Not a Silver Bullet

blog.bloomca.me

1–10 of 111 posts

Re: Single Page Application Is Not a Silver Bullet

#2
> 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.

Re: Single Page Application Is Not a Silver Bullet

#3
One of the ways that I prefer to judge a JavaScript framework is (1) what is the minimum payload to use it, and (2) how nicely does it play with a hybrid app?

In practice I’ve found VueJS does pretty well in this regard. Rather than build a full SPA I can sprinkle a few components here and there on pages that are highly interactive. The rest of the mostly static screens on my app are perfectly happy to be rendered from the server.

It can be hard to strike the right balance between developer friendliness (ie maintainability and extensibility) versus user experience (ie speed and backwards compatibility) these days, but as always it’s important work to deliver the best user experience we can, and I agree with the author that SPA are not always the right choice in this regard.

Re: Single Page Application Is Not a Silver Bullet

#5
I've worked on a number of SPA's over the years and I always run into the problem of getting my team to give a shit about performance. "We're not Google," they protest. Frankly for a lot of people it's the trade-off of slow client performance for development velocity. It's much easier to just throw on another state for new functionality than it is to consider what parts of the page can be static and how they can be rendered.

Re: Single Page Application Is Not a Silver Bullet

#7
post #2

> 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.

Re: Single Page Application Is Not a Silver Bullet

#8
Half-expecting this article to itself be SPA, and was pleasantly surprised that it isn't.

I agree completely with the author; there's some things (games and such come to mind) which certainly deserve to be SPAs, but the majority of the time it's a horrific waste for every single visitor to have to process MBs of data just to display a few KB of text and hundreds of KB of images (at most). Why? Just so developers can show off that feeling of how awesome they are for using some incredibly complex framework. That, and the ridiculous rate of churn, are probably what most irks me the most about the whole web development community (and why sites like HN appeal to me so much.)

I'm not sure what's responsible for this "love of bloat", but IMHO we should be teaching developers how to do more with less, and not the complete opposite as seemingly happening today.

Re: Single Page Application Is Not a Silver Bullet

#9
I 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.

Re: Single Page Application Is Not a Silver Bullet

#10
The problem with SPAs in the sort of cases that the author is talking about is that people don't think clearly about what requirements they are satisfying when writing a new one. If your app actually needs to switch between various screens without a refresh so your users can most efficiently get their work done, then yes, by all means, make an SPA. That requires knowing clearly who your users are, what they want to do, and what constraints they are under (e.g. if they all work on desktops with good internet access, maybe it doesn't matter that your app is bloated and slow on mobile). I think most people don't do that thinking step first. They want to play with the new shiny, either as a sort of fun or so they can add it to their resume.

This I think is made worse by the unparalleled decadence in which the modern, first-world developer now lives. It is absolutely excessive to have to download 2.6 MB just to show a blog or some simple textual information, but thanks to broadband everywhere and terabyte hard drives, nobody under the age of 30 who isn't working in embedded systems thinks about this anymore.

Post reply on HN