Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Single Page Application Is Not a Silver Bullet

blog.bloomca.me

Post reply on HN
Print view View original

61–70 of 111 posts

Re: Single Page Application Is Not a Silver Bullet

#61

Post by Udik »

nikkwong wrote: post #56

From a development perspective, in my humble opinion the single biggest hurdle with developing SPAs vs traditional server side applications are problems dealing with state consistency. The state model in non-spa apps is simple: when a pageload is requested, pull the latest state from the server. In SPAs the state has to be held on the client and server, and has to be able to react to state changes from the other side…

> The state model in non-spa apps is simple: when a pageload is requested, pull the latest state from the server. In SPAs the state has to be held on the client and server, and has to be able to react to state changes from the other side of the wire

My view is the exact opposite. Whenever you go through a page reload you lose the state on the client. And that has to be there, as it's what the user interacts with. You then need to send to the server a state which is not, strictly, an application state (it's a UI state) and that state needs to be taken in account by the server, and possibly merged with the application state, when generating the new page. A mess.

On the other hand, a spa never loses its UI state, so you never need to recreate it. The server is also usually stateless, and simply satisfies the requests of the client. Basically you go from developing two separate applications with partly overlapping concerns to developing a single one, running on the client and relying on a service layer to query and persist its data.

Re: Single Page Application Is Not a Silver Bullet

#62

Post by sago »

> [SPA Pro:] frontend is decoupled from backend

I was very surprised to read that.

Very often validation and context-sensitive behaviour needs to be performed on the client and (since you can't trust the client) on the server. You can certainly argue this is better user experience: you don't have to wait for a server round-trip before finding out an action is invalid, but it's hardly decoupled.

Isn't this a part of why node is so popular as a server platform? The stack is now so deeply coupled, it is very beneficial to reuse code.

Re: Single Page Application Is Not a Silver Bullet

#63

Post by Udik »

sago wrote: post #62

> [SPA Pro:] frontend is decoupled from backend I was very surprised to read that. Very often validation and context-sensitive behaviour needs to be performed on the client and (since you can't trust the client) on the server. You can certainly argue this is better user experience: you don't have to wait for a server round-trip before finding out an action is invalid, but it's hardly decoupled. Isn't this a part of w…

Repeated validations, while not DRY, aren't a case of coupling. They seem more a case of de-coupling, as they're needed for the application and the service layer to work independently from each other. While in non-spas your server receives from the client an extremely specific blob of page state plus user input and has to rebuild a specific new page with state updates and/or error messages.

Re: Single Page Application Is Not a Silver Bullet

#64

Post by photonios »

Some of the arguments the author mentions are not really good arguments. Basically it boils down to how much you care about the user experience. I designed and developed a SPA for a large real-estate portal in - Initial request is rendered server-side, so TTI is extremely low. Even if the JS hasn't kicked in, the website is already usable.

- Back button works perfectly fine. We use the HTML5 `history.pushState` method to add new entries to the history stack.

- Links are always rendered as anchor tags. So even if the onClick handler fails or the JS crashed, the link will still work.

- Compress the hell out of the bundle. Clocking in at 190KB compressed. (Edit: should do something about this, should be Basically, we have most of the advantages of rendering "static" pages, yet also get all of the advantages of an SPA. We can do pre-loading in search results for example. If you click a link in search results, we immediately render the page and use the data from the search result to show a basic page and then slowly enhance it.

This powers a large real-estate website that receives hundreds of thousands of visits a week. For this kind of business, a lot of stuff is important to get right. SEO related optimisations are extremely important. Hence, we server-side render everything to make sure the GoogleBot can read it all. The same applies to links. We keep our bundle size as small as possible to keep things speedy.

Oh, and I personally got a kick out of spending a weekend to make the website function perfectly well without JS.

Re: Single Page Application Is Not a Silver Bullet

#65

Post by mwcampbell »

For the problem of bundle size, it saddens me that Google's Closure Compiler (specifically the advanced mode) hasn't gained much traction. This provides fine-grained tree-shaking to minimize the bundle size. But this requires static analysis of the whole program, which is at odds with the dynamism of JavaScript. Maybe now that static typing is coming back into fashion, the Closure Compiler or something like it will gain widespread adoption.

Re: Single Page Application Is Not a Silver Bullet

#66

Post by hazza1 »

vincentriemer wrote: post #21

As an avid developer of SPAs (currently working on one for my own blog frontend) I'd say a lot if this stems from people being convinced SPAs 1) provide a faster development cycle, 2) they believe that they've offloaded all need for optimization on the framework they use and 3) "serious" development teams build SPAs. Anecdotally I find SPAs, while I'm more comfortable developing them, will take longer to build. You n…

Not sure many people think SPAs provide a faster development cycle, individual pages are always going to be more simple.

You'll get code reuse but that's trivial to get working elsewhere, you just save on redownloading shared code.

Re: Single Page Application Is Not a Silver Bullet

#67

Post by osrec »

We built one of our products as an SPA (https://usebx.com/app). I have to say it was a fairly enjoyable experience, and our users like it too (they often add it to their home screen and comment that it feels totally native). The only annoying thing was ios Safari, which has it's own little quirks in certain areas (but those are not limited to just SPAs but any kind of website).

Re: Single Page Application Is Not a Silver Bullet

#68

Post by chrisper »

osrec wrote: post #67

We built one of our products as an SPA ( https://usebx.com/app ). I have to say it was a fairly enjoyable experience, and our users like it too (they often add it to their home screen and comment that it feels totally native). The only annoying thing was ios Safari, which has it's own little quirks in certain areas (but those are not limited to just SPAs but any kind of website).

Your app is breaking the back button on Firefox beta. That's in the demo. I wasn't able to get back to HN.

Re: Single Page Application Is Not a Silver Bullet

#69

Post by jordache »

Can_Not wrote: post #43
jordache wrote: post #19

Earlier quoted context omitted.

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.

And all of that work is already done for you in all modern major SPA frameworks.

Server side too?

Client side routing? Have you seen the huge chapter dedicated to routing for angular? You make it sound like it's no work

Re: Single Page Application Is Not a Silver Bullet

#70

Post by osrec »

chrisper wrote: post #68
osrec wrote: post #67

We built one of our products as an SPA ( https://usebx.com/app ). I have to say it was a fairly enjoyable experience, and our users like it too (they often add it to their home screen and comment that it feels totally native). The only annoying thing was ios Safari, which has it's own little quirks in certain areas (but those are not limited to just SPAs but any kind of website).

Your app is breaking the back button on Firefox beta. That's in the demo. I wasn't able to get back to HN.

Yes, that's something we're looking to fix. I know it's annoying, but it's because of the somewhat unpredictable nature of onpopstate in a number of browsers (at least at the time of development). We'll probably do a full clean up of any related hacks in a couple of weeks and the issue should disappear!
Post reply on HN