Mobile Zone is brought to you in partnership with:

I'm a writer, programmer, web developer, and entrepreneur. Preona is my current startup that began its life as the team developing Twitulater. Our goal is to create a set of applications for the emerging Synaptic Web, which would rank real-time information streams in near real time, all along reading its user behaviour and understanding how to intelligently react to it. Swizec is a DZone MVB and is not an employee of DZone and has posted 63 posts at DZone. You can read more from them at their website. View Full User Profile

Single Page Web Apps: The Worst of Both Worlds

11.15.2012
| 25360 views |
  • submit to reddit


Server memory span, xkcd

Source: xkcd

Single page web apps are the promised land of modern javascript MVC frameworks like Backbone or Ember.

Deliver a dynamic experience right to the browser, they said, use the server like a smart database, they said. Your site will be quicker and your users will love it, they said. Page loads in the blink of a second, static content via CDN, no more flickery full page reloads … they said.

All of those promises are true.

Servers should handle data. They’re very good at that and having a central authority to handle data consistency amongst clients is perhaps the simplest distributed system architecture one can think of. Sure, it gets a bit complicate when “A server” becomes a few tens of boxes spread out in data centers across the globe, but that’s still not the client’s problem.

Conversely, clients are exceptionally good at presenting data! It’s practically all they do. They give some data to the user, then they sit quietly in the user’s face waitingscreaming to be poked so they can send some changes back to the server.

This separation makes sense.

Makes organising teams easier, separating talent becomes a walk in the park, it’s even friendlier for the user who doesn’t have to wait for a signal to travel halfway around the world just to open a menu!

Win-win-win!

Not really.

Trello - perhaps the best web app I've seen

Trello – perhaps the best web app I’ve seen

Good single page web apps are a bitch to develop. A bitch with a few screws loose, to put it mildly.

In traditional web development the one thing you can count on is everything being stateless. A request comes in containing everything you need to know, maybe you have to fetch a few things from a database. Once you’ve answered the request, that’s it, you don’t care about the client until a new request comes in.

This is easy. Easy to reason about, easy to make robust, easy to test and easy to avoid strange errors. You’re basically ensuring a clean slate every time.

In traditional app development, you know for a fact everything is stateful. You keep things in memory and you know that’s where they will remain until the app is closed and reopened. Nothing will randomly go missing and nobody seriously expects you to maintain state across sessions.

Yeah yeah, sometimes gunk can accumulate when an app is left running too long. A restart either of the machine or the app usually solves the problem and even though many apps and even OS’s have started experimenting with cross-session state it still isn’t expected.

A lot of people don’t even want to restore tabs!

This clear divide between websites and apps helps in a lot of ways. Mostly it separates developers into those who don’t have a problem re-imagining their universe around every request from those who prefer dealing with accumulating memory gunk.

And then come modern web apps. Sitting confusingly on the fence between both worlds.

Very simple in theory – the server is stateless and the frontend is stateful.

But think about it. The frontend is stateful in the sense that very complex things can happen when the user clicks around. Data changes in memory and we expect the data to stay there, javascript being asynchronous aaaaalmost creates all the same problems traditional developers deal with in regards to multi-threaded code and it’s very easy to accumulate all that gunk and start producing some very strange errors.

Then your user clicks refresh.

Sometimes right after losing wi-fi signal in the middle of sending a request to the server … or they closed the browser. Maybe it’s not even the same user because they shared a link!

Bang! Your app stateful just lost state.

After a refresh the user expects to see exactly the same things they saw before. That’s how the web works, right? You click around and you send a link to somebody and it’s the same thing. You don’t expect to sometimes get the homepage and sometimes a blog post when going to /blog/some-title-of-a-post

As developers we’ve found ourselves in a situation where we must assume our app is both stateless and stateful. Every URL still points to a unique page, but if you got there after a reload, all the models must be refetched from server – preferably the server would bootstrap them into place – all open sockets must be re-established and a bunch of other minor things have to be taken care of.

All in all, you get at least double of the complexity and for what? A shinier and smoother experience for the user … which is exactly what we want.

I would love to propose a good solution for this problem. But I can’t. I am left sitting here, wondering, hoping for a humane solution to this conundrum. My Google searches are coming up short.


Published at DZone with permission of Swizec Teller, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Michele Mauro replied on Thu, 2012/11/15 - 12:33pm

There are many ways to code an application so that what you describe doesn't happen. Also a single-page application doesn't imply that your application is stateful.

Loren Kratzke replied on Thu, 2012/11/15 - 8:46pm

 I think he is saying that state is in the browser. Three clicks into the page and the URL hasn't changed but the display is entirely different. That is an example of state.

For me, much of the coolness of the single page app is cancelled out by the work arounds required to obtain a link that I can send in email which can rebuild the page as I saw it.

Esteve Avi replied on Fri, 2012/11/16 - 4:31am in response to: Loren Kratzke

Hi,


Just to point that Javascript libraries like AngularJS handles the single page link problem in a very easy and powerful way.

It also has it's HTML5 link version control.

Regards,

Esteve

Marco Patania replied on Fri, 2012/11/16 - 5:24am

I I've found a solution using sammyjs which maps each url hashtag (but it works also with normal url) with javascript binded functions or events sammyjs.org.

in this way it is possible to design the application as a normal webapp to which a url corresponds to the state of the page

Michele Mauro replied on Fri, 2012/11/16 - 6:06am in response to: Loren Kratzke

Linkability is not always a requirement, or doesn't always make sense. So, it may be a problem sometimes. But your rephrasing is much more focused, clear and precise that the whole article.

Lund Wolfe replied on Sat, 2012/11/17 - 7:22pm

Application state and complexity exist somewhere, either on the client or the server.  The question is where you want to handle this complexity and in what language and framework.

I think the author believes the programming complexity will scale better on the server.  I totally agree but there are disadvantages, like the obvious slow performance user experience and work load on the server.

Caspar MacRae replied on Tue, 2012/11/20 - 9:23am

Erm I don't understand this at all, I don't see problems here, just missing technology. 

In my experience the sensible use of two items below eliminate all the problems outlined in the post, absolutely.

URL management - use push and pop state, the single page app's functionality can now be mapped to URLs https://developer.mozilla.org/en-US/docs/DOM/Manipulating_the_browser_history

Client State - offline storage.

For client browsers that are too old to support these features - present the main site.  It's not like they won't be used to a crap web 1.0 experience.

Let clients get rich but not fat  (only presentation logic, data is fine as long as only presentation logic manipulates it).

Jeff Schwartz replied on Wed, 2012/11/21 - 10:24am in response to: Loren Kratzke

"For me, much of the coolness of the single page app is cancelled out by the work arounds required to obtain a link that I can send in email which can rebuild the page as I saw it."

I'd suggest that isn't as big a problem as you suggest. I've frequently had to do just as the above and it is just a matter of providing the right url in the email that expresses the exact state that the page is supposed to express when it is rendered. The answer lies in REST which, when it comes down to it,  allows us to use a url in a semantically expressive form, trading verbs for nouns, with additional parameters hacked on that act as advise to the server. Using a RESTful URL in such a manner allows it to represent any resource(s) and its(their) state.

So the solution you are looking for already exists and it doesn't come from any framework or programming language. It comes from the principle and implications of REST.

Anas Khan replied on Thu, 2012/11/22 - 6:08am

An impressive share, I just given this onto a colleague who was doing a little analysis on this. And he in fact bought me breakfast because I found it for him.. smile. So let me reword that: Thnx for the treat! But yeah Thnkx for spending the time to discuss this, visit http://www.technewspaper.net I feel strongly about it and love reading more on this topic. If possible, as you become expertise, would you mind updating your blog with more details? It is highly helpful for me. Click here  Big thumb up for this blog post!

Anas Khan replied on Fri, 2012/11/23 - 8:31am

It’s hard to find knowledgeable people on this topic, but you sound like you know what you’re talking about! Thanks 

josef betancourt replied on Sat, 2012/12/08 - 11:24am

The "web app" link at the start of this post goes to a strange Wikipedia page.

There is another category of single-page-application, https://en.wikipedia.org/wiki/Single-page_application.  I thought you were going to mention these.  Unfortunately, this type, most notably TiddlyWiki, cannot run on mobile device easily, afaik.



Jeff Schwartz replied on Sat, 2012/12/08 - 12:07pm

If the user is 3 links into the page and the url hasn't changed then that is an implementation issue because the url should be changed to reflect the state of the page. Common use case is to use hashtag/history tagging on the url. Those additional tags appended to the url will not be sent to the server as the browser ignores them. They are, however, very useful for expressing state and when used in a restful manner (even the code that runs in your web page benefits from using rest based semantics) provides the solution to this issue. 

Caspar MacRae replied on Mon, 2012/12/10 - 1:24pm in response to: Jeff Schwartz

Argh, will everybody commenting here about sodding hashtags etc please just read about pushState and popState.   This feature alone renders this entire blog post an obsolete throwback.

https://developer.mozilla.org/en-US/docs/DOM/Manipulating_the_browser_history


PLEASE READ MY PREVIOUS POST - the x2 issues the author has are entirely solved by push/popState, and chuck in the other bits mention previously and ... vola Single Page WebApp that works perfectly (also works for search engines).


Pedro Mendes replied on Wed, 2013/01/30 - 9:17pm in response to: Loren Kratzke

What happens in the old fashioned server side web frameworks when the container is restarted ? All the in-memory objects are lost, right? How to avoid this kind of behavior in client side web frameworks ? Web Storage, maybe? I now that 5 or 10 MB aren't a HDD but maybe it will be enough to keep a few links and some user actions persistent for a future state recovery of your SPA...

Bryan Copeland replied on Wed, 2013/10/09 - 2:27pm in response to: Caspar MacRae

The post is still relevant because push/pop state is device-dependent, and likely wouldn't work well with a large number of legacy browsers still in use "in the wild", because many do not support that Javascript Browser History API, or if they do, they support it differently and you still need a framework to handle the differences.

Also, relying on Javascript to be available and enabled on a browser/device still doesn't fly for Enterprise applications that have to work no matter how they are accessed (i.e. SLAs often guarantee at least a barebones experience for non-supported browsers).

Relying on hash tags for something that HTTP itself was designed for (fetching content) is a bad idea in alot of cases, a good idea in others. Also, with the high cost of Mobile Network Data (especially in the developing world) loading an entire site's content in a single-page can be a really unnecessary and inconsiderate thing to do to your users, they may only want 5kb worth of data but end up with 800kb per visit, through misuse of big Mobile frameworks like jQuery Mobile (which I love btw, when used right), SenchaTouch, jqTouch, Titanium, M-project, etc...

A solution for mobile that I'd propose is to always at least place the content (whether that be a news article, blog post, video clip, music stream, directory entry, portfolio item, etc) on its own dynamic Content "view page", and keep that content view separate from the Main and Search views in the very least (also lets Search engines link in to your mobile search capabilities). Then, do some basic server-side detection and if they have a more modern smartphone browser let them see the "prettied-up version" ripe with JS framework stuff like animations, gesture detection, in-page hash linking with side-loading using pushState, etc...if they have an older relic device or just haven't kept their software up-to-date, well at least they can see the basic MAIN page, SEARCH page and load a single piece of CONTENT at it's own URL.


Sushant Saraswat replied on Wed, 2013/11/13 - 11:50am

Really enjoyed your style of writing. completely radical and different but still hard hitting.

Single Page design has been gaining interest in the web designing community recently.  With many people accessing net on mobile devices, single page apps have emerged as the new significant shift in web design.In my quest to learn more about the SPA, I have registered for a webinar on Benefits of developing Single Page Web Applications using AngularJS, it looks a promising one http://j.mp/1a9aK6t

Caspar MacRae replied on Tue, 2013/11/19 - 7:43pm in response to: Bryan Copeland

Bryan - with the greatest respect, this article is about single page apps and not websites with graceful degradation.  So while you're entirely correct you're also off topic.

Bit tired of saying this, but ...

This article focuses solely on perceived deficiencies of stateful webapps most/all of which can be dismissed by HTML5's features, specifically offline capabilities: persistence of distribution (code, media) via cache/app manifest and persistence of data via IndexedDb.

Complaining that refreshing kills a single page app is nonsense, given offline capabilities previously mentioned (and besides the onbeforeunload event handle has been around for ages).  Losing a connection to a server affects every single remote client regardless of implementation.  Think I've banged the pushstate/popstate drum enough already, but not all URLs point to static media and quite a few encode state.


Ay Webtech replied on Sat, 2014/01/25 - 7:57am in response to: Loren Kratzke

 Linking is not always necessary or not always meaningful. Therefore, it may be a problem at times. But you rewrite more focused, clear and accurate, and the entire article.

AY Webtech

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.