Javascript – Is there something a `Promise` can do that `async` cannot

I'm confused by your SVN requirement. I've never heard of a JS framework, tool or library causing problems for version control. It's all just static files typically.

The most important tool in any front end arsenal is a tool to eliminate crossbrowser woes and DOM API cruft at the source. jQuery is an excellent choice on that front.

jQ, runs on a design philosophy that everything on the front end should follow, IMO. It stays out of your way when you want it out of your way and it plays nicely with others.

I tend to be less impressed with JQ's libraries and plug-ins but I would leave those choices to your devs.

EXTJS, is the exact, diametric opposite. It is a heavy-handed framework that is very difficult to reverse engineer owing to an obtuse anti-pattern cascading inheritance scheme, it does awful things to the DOM and throws CSS at absolutely everything, right down to redefining the box-sizing CSS for EVERYTHING on the page and adding IDs to just about everything that doesn't already have one. I do not recommend EXT. We've been wanting to strip the last vestige of it out of our app for a year now but it's been too much of a pain to give it the proper time commitment. It cracks me up that the guys who wanted to create a JS library that is less than open source wrote the worst one to ever enjoy any popularity of the lot.

My impression of bootstrap is that it's a designer tool. Let your devs and designer decide if they want it. The JS components it provides are nothing special and it's written by people who handle decidedly lower levels of complexity than it sounds like you plan on dealing with. What I dislike about it is that it relies overly much on non-standard HTML attributes (now considered okay in HTML5, but still making HTML harder to read in my book) and hooks into pre-defined classes that describe styles rather than component types or content hierarchy. It's okay to have hooks in the HTML but I find it's best when the framework or library lets you set them.

I have not used backbone, but it's very popular. The turnoff for me was seeing it described as a lock-in framework by which the article's author meant that if you ever decide you want to move on and use something different, it's going to be hard to port your existing functionality out of it. I've had too many headaches of that nature with dismantling EXT to see that as an acceptable tradeoff for any benefit.

What I would seriously recommend is that you get your client-side team assembled first, then decide on tools in context to what you're using on the back-end and what your own front end experts consider a good idea for creating an easily extended app with code written for the long rather than short-term. In spite of the plethora of JS architecture frameworks, UI widget and pre-styled HTML libraries out there nowadays, my personal choice, when I have the choice, is to write my own UI, and wrap the jQuery soup in DIY architectural object schemes with ease of implementation and debug in mind. I also find I like the MVC pattern more for its general principles than exact implementation in a strictly client-side context.

In a complex front end app scenario, any tool that produces components that aren't easy to modify, sets restrictions on or otherwise pollutes the client-side environment as a whole, or poses the prospect of making it really hard to ditch the framework in the future is big no-no in my book. But take that with a barrel of salt. I'm a bit of a curmudgeon and hard to please when it comes to my tools, partially because I've had to put up with some really bad ones (CMSes in particular).

At the end of the day though, nothing I'm aware of has the same flexibility as DIY (except jQuery which really just eliminates UI boilerplate) but make sure you have a dev team that can get behind some sort of consistent architecture or they may indeed be better off with backbone or knockout, or JS MVC.

Since what you are really talking about here is a stylistic/readability issue (at least, that's the way I read it), you might be a little out of luck, because all the all alteratives I can think of aren't great.

Really you have two options, write multiple distinct functions like you have done above, or use closures to bring it all "inline" (as it were), where you will quickly run into issues with keeping the horizontal whitespace sane.

That being said, if you really do want to keep it all in a single block that looks like one procedure, I would probably go with the closure option:

function(){
    command1;
    var x1 = something;
    async_function(x1, function (data){
        var x2 = command2(data);
        async_function2(x2, function (data1){
            command3(data1);
        });
    });
}

Which could of course be spaced out like this, quite close to your desired example:

function(){
    command1;
    var x1 = something;
    async_function(x1, function (data){
    var x2 = command2(data);
    async_function2(x2, function (data1){
    command3(data1);
    });});
}

...but personally I would probably try and stick to the first version.

In general though I wouldn't do either. I would keep it broken down into small and obviously named routines, I find it makes for much more readable code in the long run and any sane IDE will allow you to jump from function call to function definition and vice versa, so navigation shouldn't be too much of an issue.