Read our latest: The year so far & 1.0 update.
If you're interested in JavaScript then it's highly likely that you'll have seen the really interesting discussion on the Ghost github repo regarding what framework they should use to rebuild their Admin UI; Angular, Ember, React and Backbone + marionette and many more were suggested. A few days ago Hannah Wolfe - the Ghost CTO and co-founder - announced they had decided to go with Ember.
After avidly following the github discussion, providing some input and reading the announcement blog post, the key statement for me was:
we don't want to spend time discussing and deciding on the best structure, designing a framework & creating documentation and guidelines so that new contributors can get up to speed
The focus is getting the job done, done in a timely manner, and done well. Productivity is frequently key when there is a clear end goal; when the end goal isn't to develop for development's sake, but to develop driven by creating a real product. There are a number of factors that can affect productivity and, as you can tell from the above quote, here's what the Ghost team were looking for:
I found the Ghost discussion and decision really interesting because we've been considering related points while open sourcing BladeRunnerJS (BRJS).
The process of open sourcing - and reading great discussions like the "Ghost: Ember v Angular v Backbone + Marionette v React" one has reinforced our belief that BladeRunnerJS is more about following proven practices, convention and adhering to a good application structure than it is about the libraries you choose when building functionality. Of course, those choices do matter, but experience has taught us that when building large JavaScript applications you need to split your application up into vertical slides of functionality (Blades) and have an architecture that promotes loose coupling. In BRJS one Blade can't directly access functionality exposed by other Blades. They instead need to communicate using services such as the EventHub. That - supported through tooling and application foundation libraries - ensures you have a well structured app that can be maintained, extended and worked on by numerous developers, designers, QAs, teams or even companies.
Open sourcing has also lead to us peeling back the layers of BRJS in order to increase accessibility. At conception BRJS was a reasonably complex offering. This is because it was created to solve many complex problems posed by large front-end JavaScript apps. However, all of these problems and associated solutions won't be relevant to every application. So in order for BRJS have to a better chance of being a successful open source project the initial learning curve can't be too steep. It's the same with most products!
For example, we use a UI library called Presenter when we build trading applications. However, the need for a "semantically rich set of controls" may not be initially obvious and an additional new library dependency does increase the gradient of that learning curve.
Instead we've decided to make Knockout the default for our open source solution. Although this isn't as popular as Angular, Backbone or Ember it has a strong following, is very well documented, is actively developed and is probably the best MVVM framework out there. Presenter (built on top of Knockout) will instead be exposed as a tool for a more specific job (more details to come).
Here's a work-in-progress representation of what you get with BRJS:
A big thanks to the Ghost team for demonstrating that open sourcing is about much more than simply sharing code; it's about open discussion, sharing ideas and an opportunity for everybody involved to learn.
A final note to say that the BladeRunner v0.4 release is imminent. Please keep your eye on Twitter for an announcement during QCon London.