Every day, I have to work with two applications developed this way, with the "Javascript UI" pattern. It's the most frustrating period of my day, bar none.<p>When you build one of these things, you spend most of your dev time running it locally, and as a result it's snappy. You can do things like loading a blank page for your task list, then flowing in tasks via Ajax and it will render pretty much instantly. It's so fast that you'll even consider loading those tasks one at a time.<p>For the rest of us, using an application like YouTrack or Flow (getflow.com) is sheer torture. View an item, hit the back button, wait 10 seconds for the list page to come back up, reload its content, and rebuild the page before your eyes before you can even start trying to scroll back to where you were.<p>Compare that to the old user experience where that list page would be a chunk of HTML generated at the server in 50ms and handed to you across the wire. Your browser would cache it, so the back button operation I describe above wouldn't even involve a trip to the server most of the time. Your browser would remember its previous scroll position. It was fast and it worked. It never occurred to any of us that people would decide to throw it out and replace it with something worse.<p>So if you're considering building one of these things, step one needs to be spinning up an EC2 box on another continent to act as your "dev" server. Latency is suddenly your number one priority in life, with your app being secondary. Please don't complain about this fact, since it's something you chose for yourself.<p>Thanks.
Like many others, having dealt with both issues of 1) building one of these single-page frameworks on the client side, and 2) the prospect dealing with two application, I've always been wondering "is there a better way?"<p>Now, if you go with a service oriented approach, as has Twitter and Facebook, you can build an API your JS client can talk to. One issue with this is, developing these kinds of services assumes a sort of stability, which can't be taken for granted in the earlier stages of application development.<p>Of course, there are frameworks that help speed this sort of thing up, but it makes it difficult to leverage libraries outside of the framework, as they're intended for single page applications. And you're still stuck with writing a client for each of your target platforms (JS/Static/Mobile Web/Mobile API).<p>When I first encountered Mustache, the dream of having one view rule them all tantalized me. So I started playing around with it, and have been working on an experiment I call "Marionette". It's basically the antithesis of something like SproutCore, in that the client is fairly dumb, and more or less draws the same as the server using an exposed API, and any widgets would be added on top in the form of your regular MooQuery libraries. I have a lot of work to do with the execution (history navigation is broken, for starters), but I think the overall premise has merit.<p>I'd wanted to polish it up a little before showing it off, but this article has inspired me to get it out the door. "Release early...", and all that.<p><a href="https://github.com/bigbento/marionette" rel="nofollow">https://github.com/bigbento/marionette</a>
<a href="https://github.com/bigbento/marionette-demo" rel="nofollow">https://github.com/bigbento/marionette-demo</a>
The pros in this post do not seem terribly credible.<p>First, are there companies other than Twitter that have made an API strategy work? In other words, are there lots of examples of companies for whom their open API has been critical to adoption?<p>Second, it seems like requiring the developers to develop an API means that now they have two problems: designing a UI and designing an API. But in any case, are there modern MVC web frameworks that don't make providing an API as easy as creating views for XML and JSON as well as HTML?<p>Third, has any website released their UI code as open source to help people code against their API? Is this a sensible way for people to learn how the API works?<p>Overall, I think there is something compelling about a single page, complete Javascript UI, but parts of this feel a bit like back-solving a justification. Are the better arguments all really UI-related and not backend-related?
I've ben working on an extjs app for the past few years. My experience is slightly different. I've found development actually speeded up. The extjs components are pretty mature, which is probably part of the reason. Benefits so far are the ones listed in the article, and also a structurally lower cost to supporting different browsers (even ie6), and a much easier time validating the security architecture, because of the reduced surface between client and server. Oh, and our users are very enthusiastic about the improved usability of our apps. They keep asking when we'll move over our older apps to the new architecture.
Pushing JS, and HTML to the limit always feels like the biggest con of building javascript UI apps. The farther you move away from browser defaults the more hairy thing seem to get.<p>No doubt we are moving to a more dynamic client side, but I haven't seen the way forward yet.
The article does not mention the main problem with this approach: you're breaking the hypertext model of the web. All of a sudden your pages don't have URL's, you can't bookmark them, back and forward buttons in your browser don't work, page source does not reflect your document structure, etc. There are some cases when all this is not important, but in many, many cases I want my webpage to be just that - a webpage.
Another con: Unless you want to build three applications, going the JS-only route also means that your site is now only accessible for people with JS enabled.<p>We've seen how well such sites are received when HN was dominated by blogs ranting about the new Gawker design.<p>So to fix this, you'd have to do three applications:<p>1) the API that you use in the JS GUI<p>2) The JS GUI<p>3) The dynamically generated HTML for JS-less browsers<p>Or you change the JS GUI so it requests page fragments and work with history.pushState (PJAX) allowing you to skip the API again, though, of course, then you don't have an API.<p>I've reasoned about this last april: <a href="http://pilif.github.com/2011/04/ajax-architecture-frameworks-and-hacks/" rel="nofollow">http://pilif.github.com/2011/04/ajax-architecture-frameworks...</a>
I would argue that there are only two important questions when considering which of the two approaches to take: what are you building, and who you are building it for. Everything else falls behind. Points like "but than I will have to build two applications instead of one"... Common, It's just a matter of perspective. It doesn't really matter if you call it two applications or two modules or two battery staples, as long as it does what you imagined in the best possible way for the user.<p>If you are building an interactive web application that should be akin to classic desktop applications, you should really build a separate UI, just like if you were building a desktop application. If you are using a framework such as GWT, than it doesn't even have to "look" like two different applications from the developers point of view. Building a detached UI doesn't imply creating a nice public API at the same time.<p>On the other hand, if you are trying to create a content based site logically designed as linked pages of content, there really is no good reason to brake the classic web page layout and reinvent the wheel.<p>The problem, ofc, is what to do when your site is a hybrid between the two. Well, maybe a hybrid approach should apply also?<p>Most of the problems mentioned with the newer approach, js UI, are technical problems that must be solved (by us), not conceptual problems in the approach itself.
Building a JS front end only makes sense to me if you're leveraging a complete UI kit on the client side to ease handling of commonly-encountered UI problems: sortable, filterable, lists; autocomplete; tokenized inputs; etc.<p>The hassle of building a custom UI and event strategy without a pre-packaged UI kit seems like a recipe for headaches, but that may be a function of my own limitations in Javascript. I've tried it in Backbone and in Sproutcore 2 beta 2. Both are very promising, but I found myself dealing with so many common UI use cases that I really wished for plug-and-play UI kit modules.<p>Also, the online community for JS frameworks so young that it's hard to find other people's solutions. For instance, I wanted to hook into devise to authenticate users and store the current_user on the client-side. I ended up making my own solution, with no guidance from google. As a self-taught developer working alone on a few projects, I always feel better when I can at least find a random gist of another solution, if for no other reason than to see if I've missed a feature of the framework in my solution. Given how incredibly useful these JS frameworks are for imposing some structure and convention, I expect the online guidance to improve drastically over the coming year.
The main con in the article is that you are basically creating 2 applications in the same time (web API and JS Client).<p>But, this is also a pro in the same time. That way, you are forced to layer your application(s) appropriately, it is much easier to test and faster to develop (browser F5 instead of redeploy), and, as a bonus, you get nice rest API that you can expose to your clients or third-party developers.
From the headline and seeing that you are a customer support company, I was expecting to read about how the different approaches can benefit users. Boy was I wrong.
a big pro that wasn't mentioned in the article is that a javascript UI allows you to write the API in almost any language you desire. writing your dynamic pages in C++ or java can be very time consuming - whereas writing it all in ruby or php may require you to outsource resource heavy parts of your web application.