JavaScript for Line of Business Applications

Initially, we were wondering how interesting and far-out the stack could be before management got nervous, but our concerns were addressed in an early meeting with Joel, when he said “Use things that are going to work great in two years.

So we did. We have consistently opted for promising (and often troublesome) new technologies that would deliver an awesome experience over more mature alternatives. We’re about a year in, and it’s been a lot of fun.

Trello started out as a pure JavaScript project on both client and server, and stayed that way until May, when we experimentally ported a couple of files to CoffeeScript to see how we liked it. We loved it, and soon converted the rest of the code over and started coding CoffeeScript exclusively.

The Client:

* Backbone.js (client-side MVC)

* HTML5 pushState

* Mustache (templating language)

 The Server:

* node.js

* HAProxy

* Redis

* MongoDB

Back in the bad old days, not so very long ago, lots of development teams had to support IE6. One of the major problems of writing large javascript applications in antediluvian versions of Internet Explorer was that memory would leak very easily, and you’d suddenly find that your initially snappy application was slowing your whole machine to a crawl if left running for any significant period of time. What made it worse is that IE6 wouldn’t even reclaim some leaked memory when you reloaded the page.

That particular leak gained a great deal of infamy and you can find a lot of information online about the DOM/JS circular reference memory leak.

Mike Byrne provides the lowdown on a simpler way to structure your JavaScript – that should help prevent it fragmenting into messy, brain-bashing gobbledygook

Getting away from jquery is attractive even if you have an existing application where its use is more controlled so that it's only ever used once. When your code isn't coupled to jquery, it's much easier to spin out the reusable pieces so you can publish them to package repositories like npm. When it's harder to split out reusable pieces, those pieces tend to calcify and become tightly coupled to your application.

But jquery is genuinely very useful and familiar to lots of folks! Fortunately browsers have taken notice and the DOM itself is a pretty friendly place too these days.

Here is a list of common jquery features and their raw DOM replacements:

This blog post compares the same twitter search application written with both Knockout and Kendo in order to highlight the strengths and weaknesses of each framework. I’ve always been a big fan of Knockout, most likely because it reminds me of Silverlight (rest in peace).

More recently I have been dabbling with the use of Knockout for writing mobile applications. Because Knockout is an MVVM framework and doesn’t have any UI components of its own, I used a combination of jQuery Mobile (jQM) and Knockout. I must admit, the integration of these two frameworks wasn’t entirely painless!.

It is the integration pain I experienced with jQM and Knockout that has resulted in my interest in KendoUI.

Backbone.js is a popular, super lightweight JavaScript framework which helps you structure your code MVC style. If you're building JavaScript applications of any reasonable size, you might have heard of it and you might have even given it a try. But if you have used it in anger, then you may have found that a backbone only gets you so far. As your application gets bigger, so does the complexity of your boilerplate code and structure. Let's kick this complexity to the curb, and string up our backbone on a marionette(.js).

In classical OO languages like C and Java, `this` is a useful keyword for referring to the current instance of something.
...

* Callbacks

* Call, Apply, and ES5's Bind

* Issues in Async code