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 .
Before we talk about the pros, lets get the cons out of the way.
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.
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.