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

The Disadvantages of Single Page Applications (2014)

adamsilver.io

Post reply on HN
Print view View original

61–70 of 105 posts

Re: The Disadvantages of Single Page Applications (2014)

#61

Post by sulam »

It's really good to see an article like this. IMO the pendulum has swung too far towards massive JS "applications" that force you to download MBs of content to render anything at all. Yes, if caching works things can be fast, but then you do things like release a new version of your software and I have to download it all again. I use Asana (and love it), but I hate the fact that it can literally take a minute to download their web application. Once it's loaded it's incredibly fast and one of the best web apps I use, but the performance loading it makes it really, really painful at times. Not to mention that based on their blog posts they've also found it difficult to program.

And it's not just Asana, there are some very popular web applications that have had to make the same decision in order to reduce the time it takes to load things for their users, especially users who aren't on fast links (mobile, rural, and places like South America, Africa and Australia).

Re: The Disadvantages of Single Page Applications (2014)

#63

Post by crgt »

zkhalique wrote: post #33

This reads like a very good list of things to implement in your SPA. Having said that, you should also be supporting simply rendering the pages on the first request, and progressively enhance it, rather than a blank thing that then goes and fetches all the JS and render itself. The HTML/CSS should arrive and render as soon as possible. His reference to twitter's 2012 writeup is good. Having said that, take a look at…

Link doesn't work for me on iOS. I just get a blank page?

Re: The Disadvantages of Single Page Applications (2014)

#64

Post by EGreg »

crgt wrote: post #63
zkhalique wrote: post #33

This reads like a very good list of things to implement in your SPA. Having said that, you should also be supporting simply rendering the pages on the first request, and progressively enhance it, rather than a blank thing that then goes and fetches all the JS and render itself. The HTML/CSS should arrive and render as soon as possible. His reference to twitter's 2012 writeup is good. Having said that, take a look at…

Link doesn't work for me on iOS. I just get a blank page?

Which of the links?

Re: The Disadvantages of Single Page Applications (2014)

#65

Post by holofernes »

lftl wrote: post #40
holofernes wrote: post #2

Finally some love for the anti-SPA crowd. Subjective here, but there's something nice about Post Redirect Get and Plain Ol' Hyperlinks from a User Experience. Whenever I interact with a regular web application, I am relieved. Not every "forms over data" or ecommerce experience has to be Gmail. Even in mobile.. SPA just isn't that much nicer. Also, I think maintaining these SPAs is ridiculously more difficult. I don't…

From a development standpoint there are a lot of things I prefer from the old Post Redirect Get workflow. The biggest thing I don't miss is modeling complex data in a form. SPAs let me sidestep this because it's JSON, which is much richer for modeling data than a plain form, going both ways. If form JSON ( https://darobin.github.io/formic/specs/json/ ) was widespread I'd probably drop almost all my SPA usage immediat…

That is a good point. The hard part of programming is the modeling. And your point leads to another, easy modeling is why JSON as a format (and its programming interface, JavaScript) is so appealing. I guess it's a trade off: complex modeling and state transfer vs. sometimes inscrutable magic asset loading, client/server programming model, losing the natural behavior of the web, and all the other criticisms in the article and elsewhere.

Re: The Disadvantages of Single Page Applications (2014)

#66

Post by thebfed »

mattdeboard wrote: post #30
fizzbatter wrote: post #19

I must say i'm constantly surprised by the negativity towards changes in technology by the technology oriented crowd. More specifically, the pure negativity. So many (here included) constantly shout negativity towards these technology concepts (SPA, in this case), and thankfully also citing what they're negative specifically about. What i'm surprised to see though, is that so few focus on improving the tech concept (…

This isn't an anti-change thing. I have personally experienced the annoyance/pain of having to re-implement navigation in JavaScript. Sure, there are routing libraries that try to make this easier, but on the other hand, routing is kinda built in to the platform. The author of the post made his point pretty clearly: > [T]he application handles the browsing instead of the browser. Attempting to mimic the browser using…

This.

Re: The Disadvantages of Single Page Applications (2014)

#67

Post by PavlovsCat »

tomjen3 wrote: post #17
Justsignedup wrote: post #3

Other points of note: The whole history API exists to help the SPA experience (but others too). The site still needs to be able to render something like: www.foo.com/customers/10 even if www.foo.com is a SPA and via clicks can go to /customers/10. This may require more server work, so you're not exactly making life much easier for yourself. You still need to handle cases where a web crawler comes in without good java…

Not really - these days even googlebot can and does execute enough javascript to craw #/customers/10. Screen readers can do javascript and you can use ARIA to make it easy to browse for blind people.

> even googlebot

I would assume that's one of the more capable crawlers though; not the average, and surely not the lower bound.

Re: The Disadvantages of Single Page Applications (2014)

#68

Post by aaronem »

dfcowell wrote: post #55
arenaninja wrote: post #34

Earlier quoted context omitted.

Any idea why on https://gocardless.com/merchants/new , when the Email Address input has focus, Cmd+Left arrow do not navigate to the previous page? Once the input no longer has focus, I'm allowed to use the shortcut again.

Probably because Cmd+left arrow is the system shortcut for "jump to the start of the current line." You'll see this behaviour when a form input has focus on any site.

Which, in turn, is why Cmd+[ and Cmd+] are by default bound to "Back" and "Forward" in at least Safari, Firefox, and Chrome.

Re: The Disadvantages of Single Page Applications (2014)

#69

Post by aaronem »

holofernes wrote: post #2

Finally some love for the anti-SPA crowd. Subjective here, but there's something nice about Post Redirect Get and Plain Ol' Hyperlinks from a User Experience. Whenever I interact with a regular web application, I am relieved. Not every "forms over data" or ecommerce experience has to be Gmail. Even in mobile.. SPA just isn't that much nicer. Also, I think maintaining these SPAs is ridiculously more difficult. I don't…

Having had experience with both, I'm a lot happier implementing Ajax form submissions than POST-redirect-GET. Sometimes a form submission has a lot of state around it. Sometimes its result has a major effect on the state of the application of which it's a part. Sometimes you end up implementing half of the ideas involved in the SPA architecture, badly, a couple of years before it becomes a "thing" in the web dev community at large, because that's the only way to produce a halfway decent UX for your tens of thousands of users, and you know this because you've tried all the ways that revolve around POST-redirect-GET and none of them has worked well enough to be going on with.

Of course you're welcome to be as anti-SPA as you please. But those of us who've welcomed the concept with all the fervor of a relieved garrison generally have our reasons for so doing.

Re: The Disadvantages of Single Page Applications (2014)

#70

Post by aaronem »

henvic wrote: post #43

Senna.js is a blazing-fast single page application engine that provides several low-level APIs that allows you to build modern web-based applications with only ~8KB of JavaScript without any dependency. http://sennajs.com/ Most of the issues reported by this article are not a problem with it thanks to its approach. Disclaimer: I have contributed to the project.

That's nice. The blog example exhibits a lot of the problems identified in OP's article, especially those around history and scroll position.

Look, I'm all in favor of SPAs; I build them myself. But when I trip over something that does infinite scrolling, I groan, because I know that if I should happen, twenty pages in, to slip and left-click a link instead of right-clicking and "Open in New Tab", I'm going to lose my place and have to start over from page 1 and spend five minutes wearing out my scroll wheel to get back to where I was -- either that, or shrug and give up on whatever I was reading.

There are real problems in the space. They need to be either solved or avoided. (If you can't get infinite scroll to work right, then don't use infinite scroll.) Pretending they don't exist and refusing to address them is just foolishness.

Post reply on HN