SPA Also know as HTML/Javascript Web's Pros and Cons

I have found these two Articles for Single page Architecture




1st Article Extracted form http://programmers.stackexchange.com/questions/147423/pros-and-cons-of-an-html-javascript-only-web-app

Advantage: Working with Web Designers

The major advantage of this technique is that the Web designer, who knows some PHP but does not consider himself a programmer, can work unencumbered in the HTML and CSS without having to wade through countless lines of JSP, taglib tags, and other server-side markup that we've been told for years issupposed to make a front-end developer's life much easier.

Without all of the server-side markup, we've been more agile. The web designer has directly swapped out and revised his original design 3 or 4 times, with very few changes on my part.

His comment to me was that he felt like the HTML was alive in that he could edit it and then immediately see the changes on his machine with dynamic data. We've both benefit by this in that the integration is mostly automatic.

Server-side code and HTML/CSS Handoffs

In past projects, he's had to handoff the HTML and CSS to Java developers who would then take his HTML and CSS and completely rewrite it using JSP technology. This would take lots of time, and would usually result in subtle yet important differences in the actual rendering of the pages as well as it's validation in the W3C validator.

Overall, we're both quite happy with this technique, and I still have zero JSP pages or server-side code in my HTML pages.

Pitfalls of the REST/JSON Technique

Perhaps the biggest pitfalls are ones that we haven't encountered yet. I fully expect to have some disagreements with more experienced Java developers who have been brainwashed by what the Apache foundation and the Spring team have told them regarding how tag libraries make it easier for frontend developers to work with the code. I fully expect there to be a learning curve as this project expands and we take on more developers who might have to unlearn these outdated techniques that, in my experience,have made the Web designers' job more difficult.

Another pitfall is that the JavaScript code has become very massive. This is more of a problem perhaps because I'm using this technique for the first time, and because we've introduced some slight technical debt in working towards a rapid release. Perhaps picking a better framework would have helped alleviate a lot of the bulk of the code. In my opinion, none of this has been a showstopper, and I'm encouraged to continue using this technique and refine my skills in this area.

Advantage: Other Applications Can Be Built On the Platform

Lastly, I should mention a hidden advantage. Because there is a nice degree of separation between my backend RESTful Web services and my frontend, I've also created a platform that I can easily extend.

One of our operations guys wanted to try a proof of concept in another application, and thanks to my RESTful services, we were able to create an entirely different frontend to the application to solve a completely different problem. The rapidly developed proof of concept used it's own HTML, CSS, and JavaScript, but it used the RESTful services as the backend and datasource.

In the end, another project manager saw what I had done, and it became immediately clear that the feature needed to be more than just a proof of concept, so his team implemented it.

I can't emphasize enough how reusable this architecture is, both at the application level as well as the HTML/CSS/JavaScript level, and I would definitely encourage you to try this in your next project.

Second Article  - Extracted from http://devblog.supportbee.com/2011/08/10/the-pros-and-cons-of-developing-a-complete-javascript-ui/

Cons

Before we talk about the pros, lets get the cons out of the way.

Javascript Frameworks are still evolving

The javascript and javascript framework ecosystems are still in their infancy. Apart from Gmail and a few other apps, only lately have we seen an explosion in the number of single page apps. Similarly, even though jQuery and jQuery UI have been around for a while, only lately we have seen frameworks likeBackbone, Spine and knockout JS. Powerful frameworks like SproutCore that have existed for a while are only now focusing on developer friendliness. In some ways, Javascript ecosystem is where the Rails ecosystem was in pre Rails 1.2 days. While it’s exciting and shiny, it’s not for the weak hearted.

Developing two applications instead of one

Building a single page app is like developing two applications instead of one. It’s like building the Twitter backend (API) and a client app (like TweetDeck) at the same time. Unlike a conventional webapp, where some javascript is sprinkled on the UI, the javascript code in a single page app can get pretty complex and needs to be well tested. Pivotal Tracker’s architecture post talks about the challenges in building a single page client. Its not unfair to say that a single page app is almost always going to take significantly more effort than building a conventional webapp (with some AJAX thrown in).

Pros

Even though you can build a conventional webapp and throw in javascript to make it pretty snappy, I believe the single page app approach has some inherent benefits that are worth the extra work

Well thought out and tested API

Since your client code talks to the server using an API, you are forced to work on an API from day one. When you come out with the first version of your product, you will have a well tested and thought out API. In fact, you backend will be pretty much just an API. Also unlike APIs that are added to products much after they have been released, your API will have a 100% feature coverage since everything that’s being done using your UI is backed by an API.

Not only is an API great for getting third party developers to build stuff for you, it is also useful for bringing in new developers and interns and have them work on your mobile app etc without getting bogged down by the complexity of your existing code. A half assed API limits these use cases. Thinking about and using your API from day one helps you come up with a great API. Even though Twitter did not start out as a single page app, I believe a powerful API has been very critical in their adoption. It will be critical in your app’s adoption too.

Your JS UI code as API reference

In the last section I talked about how if you choose to go this way, you end up developing two applications instead of one. Turns out that it’s also an advantage. When you release your API, you can easily open source the javascript frontend as the de-facto reference for your API. Depending on the license, people can also use bits of the code to help you come up with mobile apps etc. No amount of API documentation can match a working application using the API (and being updated as the API changes).

In summary, I think JS UIs are extra work but there are tangible benefits in doing them (apart from the UX benefits if done right). The ecosystem is also evolving very fast and there are new tools available each day to make the job easier.