If you have been following our blog, it’s easy to tell that we have been developing a single page ticketing app for SupportBee. A lot of my developer friends and I often discuss the pros and cons of doing a complete JS UI. The JS UI ecosystem is still maturing and it’s certainly a lot of work to build one. Nevertheless, I believe that it’s a good idea to consider. In this article I am going to talk about some of the pros and cons of developing a complete JS UI . I will only be talking of things from a technical/development perspective and not from the usability point of view .
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 like Backbone, 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.
Update: Really good comments on HN on this article.
The pros and cons of developing a complete Javascript UI
If you have been following our blog, it’s easy to tell that we have been developing a single page ticketing app for SupportBee. A lot of my developer friends and I often discuss the pros and cons of doing a complete JS UI. The JS UI ecosystem is still maturing and it’s certainly a lot of work to build one. Nevertheless, I believe that it’s a good idea to consider. In this article I am going to talk about some of the pros and cons of developing a complete JS UI . I will only be talking of things from a technical/development perspective and not from the usability point of view .
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 like Backbone, 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.
Update: Really good comments on HN on this article.