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

81–90 of 105 posts

Re: The Disadvantages of Single Page Applications (2014)

#81

Post by jalfresi »

adamors wrote: post #74
Sanddancer wrote: post #71

Earlier quoted context omitted.

At which point, the question becomes, "why is this a website?" if you're building an application, usually languages like C#, Objective-C, etc offer far more powerful tools for making an application.

Because a web based application doesn't need installation, it's cross platform and accessible by everybody.

Then surely all the effort being put into make browsers not browsers would be better directed towards solving those goals, without bastardising the web?

I always thought that the SPA crowd would settle on a custom content-type to handle web apps. That way they aren't hamstrung by the limitations of HTML and web pages and can really do things right by web apps.

Re: The Disadvantages of Single Page Applications (2014)

#82

Post by renke1 »

StillBored wrote: post #16

I've always assumed that if you need a back button, your application wasn't really a good candidate for a SPA anyway...

Is that so? – As far as I know on Android the back button was or is an integral part of most applications and the whole Android UI as a whole – and I would say a SPA is something that is pretty similar to an Android app.

Re: The Disadvantages of Single Page Applications (2014)

#83

Post by jalfresi »

nkassis wrote: post #37
JustSomeNobody wrote: post #12

Earlier quoted context omitted.

Why would users not care about the stop button working? If something in the browser is not loading, I want to hit stop so I can wait a while before trying again.

What would a stop button in Word be like? It really depends on the type of webapp and experience you are trying to create.

IT would probably be like the time when everyone used Flash to create web apps and reproduced the browser functionality like back and stop, confusing users and breaking the web.

Rule #1 of the web: Don't break the web

Re: The Disadvantages of Single Page Applications (2014)

#84

Post by jalfresi »

qu4z-2 wrote: post #60
nkassis wrote: post #37

Earlier quoted context omitted.

What would a stop button in Word be like? It really depends on the type of webapp and experience you are trying to create.

Word also doesn't generally lock up when it can't access the network, and sit there spinning though. (Although I'm sure that feature is on the road-map). I feel like a lot of the people making SPAs just haven't used a dodgy internet connection in five years or more.

I get the impression they are all too young to remember the dark old days of Flash web apps. We've been here before. It sucked.

Re: The Disadvantages of Single Page Applications (2014)

#85

Post by LoSboccacc »

freyr wrote: post #52
stevedomin wrote: post #15

As with everything, if you're going to do SPA, you should do it well. So far, one of the best SPA website I've seen is https://gocardless.com (disclaimer: I work there). Once loaded it's probably one of the fastest website I've browsed, and it doesn't have any of the drawbacks you mentioned: navigating to a new page is quick: ✓ navigating back is quick: ✓ remembering scroll position: ✓ cancelling navigation: ✗ but we…

I just wrote a post condemning the use of SPAs that emulate multi-page websites and basic browser functionality, but you provided an interesting counter-example. In fact, it goes to an extreme by being an "app" with minimal user interaction beyond basic navigation across pages. It is quite fast, which is nice. One of my concerns about SPAs that emulate MPWs is that you're sacrificing speed for complexity, which gener…

I'm building a multi page app that has a single page which is extremely complex (it's an image based marketing tool, the complex page is the visual editor) and I'm finding browser extremely finicky in their memory management.

I don't know how making a real single page app could be possible for overly complex applications. More than once I managed to crash the chrome javascript engine in a way that could not be recovered even when reloading the page and nothing short of a task manager kill could restore functionality

we are probably abusing too much canvas (we use fabric.js for image maniulation), but adding and removing the canvas from the dom should be safe enough, as we make sure not to store anything outside the dom itself specifically to avoid leaking resources

everything in memory is attached to data entries or in event handlers and browsers should be able to clean up them when the nodes are removed, except they dont.

Re: The Disadvantages of Single Page Applications (2014)

#86

Post by mobiuscog »

stevedomin wrote: post #15

As with everything, if you're going to do SPA, you should do it well. So far, one of the best SPA website I've seen is https://gocardless.com (disclaimer: I work there). Once loaded it's probably one of the fastest website I've browsed, and it doesn't have any of the drawbacks you mentioned: navigating to a new page is quick: ✓ navigating back is quick: ✓ remembering scroll position: ✓ cancelling navigation: ✗ but we…

It would be extra nice if it had a fallback to work without Javascript (menus...).

Re: The Disadvantages of Single Page Applications (2014)

#87

Post by augustl »

JustSomeNobody wrote: post #38
nkassis wrote: post #37

Earlier quoted context omitted.

What would a stop button in Word be like? It really depends on the type of webapp and experience you are trying to create.

Ah, but see, the stop button, back and forward, scrolling down, etc. are how the web worked. And best practice has always been, "don't break the web". Now... people break things. We went from having a consistent UI experience in the browser to everyone just making stuff up. Not good.

If browsers had hooks for "the page has now finished loading" (to display a loading indicator while the page loads with XHR etc) and "callback for stop button click" I'm sure lots of SPAs would put them to good use :)

Re: The Disadvantages of Single Page Applications (2014)

#88

Post by monort »

stevedomin wrote: post #15

As with everything, if you're going to do SPA, you should do it well. So far, one of the best SPA website I've seen is https://gocardless.com (disclaimer: I work there). Once loaded it's probably one of the fastest website I've browsed, and it doesn't have any of the drawbacks you mentioned: navigating to a new page is quick: ✓ navigating back is quick: ✓ remembering scroll position: ✓ cancelling navigation: ✗ but we…

If I click on "learn more" then "find out the basics" and then click back, popup window stays on top.

Re: The Disadvantages of Single Page Applications (2014)

#89

Post by stevedomin »

mandeepj wrote: post #39
stevedomin wrote: post #15

As with everything, if you're going to do SPA, you should do it well. So far, one of the best SPA website I've seen is https://gocardless.com (disclaimer: I work there). Once loaded it's probably one of the fastest website I've browsed, and it doesn't have any of the drawbacks you mentioned: navigating to a new page is quick: ✓ navigating back is quick: ✓ remembering scroll position: ✓ cancelling navigation: ✗ but we…

>Since gocardless.com is entirely static, we're able to deploy and serve static HTML Source - https://gocardless.com/blog/how-we-built-the-new-gocardless.... May be this is why your site is so fast. SPA apps are not entirely static.

It's kind of a combination between a SPA and a static website.

We generate all the HTML pages so that they can serve as entrypoints, so when you go to https://gocardless.com/features we serve a fully rendered page to the browser, plus we load the rest of the website (that's why it's super snappy after the initial page load).

If you don't have javascript enabled, you'll still get fully rendered page.

Re: The Disadvantages of Single Page Applications (2014)

#90

Post by stevedomin »

amelius wrote: post #32
stevedomin wrote: post #15

As with everything, if you're going to do SPA, you should do it well. So far, one of the best SPA website I've seen is https://gocardless.com (disclaimer: I work there). Once loaded it's probably one of the fastest website I've browsed, and it doesn't have any of the drawbacks you mentioned: navigating to a new page is quick: ✓ navigating back is quick: ✓ remembering scroll position: ✓ cancelling navigation: ✗ but we…

Looks good. What kind of design patterns are you using to achieve this?

Not sure what you mean by design pattern? It's a SPA, built with React, and pre-rendered.

You can check the source code here: https://github.com/gocardless/splash-pages

Post reply on HN