EmberJS & EmberConf

The first official ember.js conference was held on March 25-26 in Portland, OR and my company was a sponsor. I was excited to be a sponsor because I think ember.js is a step in the right direction for web development and I’d say it has the potential to be the first viral JavaScript web framework. I’m pretty impressed with the framework and the people behind it. And at the end of the day, it aligns with my belief that the web browser will be the focal point of many forthcoming innovations; anything that moves it and its development platform forward will be a priority for me.

As someone who has built many web applications, I’ve seen the benefits that great frameworks can have on communities, ecosystems, and technology. To speculate on the impact ember.js could have on web development, I wanted to write about Ruby on Rails. I believe there are parallels to the two frameworks.

I like to study products and why some win and some fail so I thought it would be fun to apply some thought to why Rails has had success. Great products are often viral in some nature and the key to virality is an experience that gets better as the number of users interacting increases. I think Rails may have been the very first viral web application framework. (I think ember.js could be the next one)

Over the last decade, web frameworks started popping up at higher frequencies and one of them was Ruby on Rails. Ruby was a relatively unknown programming language. Modern web frameworks were in bad shape. Building web applications was not as easy as Rails would soon make it. First, Rails popularized Ruby. Then Rails promised, and delivered, the reduction of massive boilerplate web application code. Ultimately, Rails had this powerful combination: building web applications were curiously simple & instantly gratifying. Since its release, Rails has become one of the most widely used web application frameworks.

The act of building a web application has become… fun. New ideas can be built in minutes and days rather than months. Rails made building web sites more approachable (and it sped things up heavily). Beyond the build, though, Rails was open source so you could add more features to it, which made the experience of building even better for others. When you combine a great experience around building a web application with a framework that is constantly expanding, enabling you to do more with less, you ultimately have an community that was constantly improving. I call this improvement pattern the cyclical improvement vortex. While Rails started to evolve rapidly, the greater ecosystem was getting pulled into the storm and all of these other frameworks were being rapidly improved (and many new ones created). The end result was far superior options for developers and better tooling across the board. We had more choices. We started to have more fun.

Here are a few examples that highlight how this cyclical improvement vortex attracts innovation inside and outside of the frameworks and around the community. A popular framework can become an opportunity for a new business to launch, a technology to become popular, and a generation of people to learn to code.

Heroku.com is a hosting platform that launched to support seamless deployment of Ruby on Rails applications to the cloud. Developers could build their Rails applications and then easily put that code up on to the Internet in seconds. Previously, you’d typically have to purchase a web hosting server and customize that server and then upload your code and do all of these manual steps. Heroku made everything simple and developer-friendly. Fast forward: they now support almost every popular framework and programming language and thousands (and thousands) of companies rely upon them for deployment.

Asynchronous JavaScript (Ajax) is a programming technique for web applications to communicate with the server behind the scenes. Microsoft created the components that would make Ajax possible around 1998 but it went relatively unused for years. Rails baked Ajax into the framework and really encouraged (and pushed) many web applications towards taking advantage of the somewhat neglected technology. Today, you’d be hard pressed to find a web site not using Ajax; Rails didn’t create Ajax but it helped put it on the map.

Ruby, the programing language, has continued to benefit from the popularity of Ruby on Rails. It’s gotten faster, scales more efficiently, and is easier to work with. Thousands of companies have realized Ruby as a language of choice for building software. It will live on with or without Rails. I’m glad about that.

Beyond the infrastructure and technology, though, Ruby on Rails also had an impact on education in web programming. Folks felt it was so easy to get started with that Rails became the center focus of curriculum in many high schools, colleges, and developer boot camp programs (2-6 month learning engagements) . It is an approachable framework with a fair amount of educational literature on. A vibrant community of software engineers, designers, and educators can build ideas using Rails and that’s pretty awesome.

So to tie this back to ember.js…

ember.js is one of the newer frameworks on the block and is similar to Ruby on Rails. The difference is that it is built on top of JavaScript instead of Ruby. JavaScript very well may be the language of the future given every web browser understands it and we’re building more and more of our web applications to run in the web browser. Like Ruby long ago, JavaScript needs a popular framework that is going to drive innovation. I think ember.js is JavaScript’s Rails and I believe it is part of the next wave of forward-thinking technology and will make web development better. Some of the folks involved with ember.js were also involved with Ruby on Rails. Yehuda Katz, for example, is a core contributor to both frameworks and is all about building great communities. I think ember.js has the technical and social ingredients to be a popular, widely adopted framework. It very well may be the next viral web framework.

Thanks to Loren A, Tian D , Andrew L, Ethan K for taking peeks at this piece as it evolved.

What’s New in Rails 3 & What I’m Excited About

Rails 3.1.0 was released on 8/31/2011, and as such marks a great day for the Rails community. For a while Rails felt stagnant (think 2.3.11 to 3.0.1RC) and so this is something I’ve been looking forward to. As I’ve been using Rails 3 for over a year now, and I’ve been following along in the change sets, I wanted to point out some of the features I think are really going to be game changers.

Sprockets, and the Asset Pipeline

Previously done through third party libraries, the Asset Pipeline is a built-in framework for managing your assets and writing these assets in other, some say more friendly languages, like CoffeeScript for JavaScript and Sass for CSS  style sheets. It’s a very large change to Rails because it introduces a new mix of options for how you can write your JS/CSS and it moves the serving of these components to the Rack middle-ware. Your asset resources now can be pre-processed, minified, and compressed in one swoop. This process is done by Sprockets. I won’t go into any further detail but you should know this is worth reading up on, so go check out the Asset Pipeline introduction by the RoR team. (You can disable this feature if you don’t want to use it. So don’t freak out!)


Although it requires Ruby 1.9x to run, HTTP streaming has finally been added. Part of the confusion I often hear about Rails is why this feature was not there from day one. To be honest, I’m not sure but my hunch is that it didn’t make sense in a prototyping stage to have to stream content. Further, it’s very very error prone compared to building your response and then shipping it over (i.e. if computational errors occur mid stream you’re dead in the water and the page will never finish loading). Further, Ajax helped mitigate this need by loading a light HTML shell and then using asynchronous calls to fetch your users’ data. At any rate, I’m very excited for this feature because the last two years of PHP coding has had me used to buffering output and I really do see the value in being able to use streaming to show progress without making lots of asynchronous calls.


ActiveResource now defaults responses to JSON, as opposed to XML.


Is now the default JavaScript library bundled with Rails 3. Further, RJS has been factored out as a gem.

Basic Authentication

Rails 3 comes with a quick and easy way of doing Basic Authentication (Username/Password) in your Controllers. Read up on Base.http_basic_authenticate_with – Check out the example here

Pluralize Names for Models

Yup! You can now set, on specific models, whether you want them pluralized or not. From within your controller class you’d set: self.pluralize_table_names = false

BCrypt Passwords

You now have a model attribute has_secure_password that will take care of password hashing/encryption.

Continue reading →