As of today we have a new 9elements website. Whereas the old one was quickly put together to deliver an impression of our company culture, we put a lot more effort in developing this site. We now have a decent place where people see the cool projects we’ve worked on and also get an insight on how we work. But not only the content is fresh – with the release of our new website, we revamped our complete production toolchain.
ZOMG – It’s coffee all over the place!
The whole website is implemented as a single page webapplication, so far nothing special here. But we created our own coffee-script haml parser so that we can write our templates in haml and coffeescript. We love haml, we use it in all of our Rails work and we love CoffeeScript since day 1. When we took Backbone.js to create a single page webapp, we realized that there are many choices for templating, but most them force you to write plain HTML, which felt like a step in the wrong direction. On the other side there is already a Tim Caswells very inspiring haml-js library, but sadly this one forced us to write javascript instead of CoffeeScript. So in the end we decided to implement our own haml-coffee script parser to avoid pardigma breaks. It’s not perfect, but stable enough to build this website.
Last but not least we switched from Sass to Stylus, which is a little more radical and has tons of cool features. Stylus plays very nice with rails using the Stylus gem from Luccas Mazza.
So where do we go now?
When we developed the website we’ve realized that there is a lot of redundancy in the code. As example I’ll take the project model. So how do I get it to the client?
- You’ll write it in Rails, tweaking the as_json method since you’ll have to incorporate all images into the JSON hash.
- You’ll write a model for Backbone.js
- You’ll write a collection for Backbone.js
- You’ll create a view…
- …and a template where the data will be finally rendered.
If you repeat that steps for the other models you’ll get the feeling, that the web development is terribly broken at the moment. There must be a more DRY approach on realizing this. I’m thinking of switching from Rails to Node.js and implementing models that can be used on the server and on the client. But this is another step, for now we just established a very cool toolchain for views and templates.
Photo by puuikibeach. And for the big fans of our old page – you can view it here.
Check out KnockoutJS, it has a plugin for mapping JSON/JS to bindings and vice-versa
http://www.knockoutjs.com
Very interesting post. We’re using backbone at work and we’re struggling to find a good templating library. $.tmpl works in every browser but forces you to write html and doesn’t have any tag helpers. We tried haml js but that didn’t work in IE7-8. You mentioned you were using haml-js, did you manage to make it work in internet explorer?
Another question: coffee script looks very good, but I’m afraid to introduce more complexity to an already populous tech stack (same as your). Do you think the language improvements are worth the additional dependency?
I am with you on reducing development complexity, so I am avoiding js in favor of CoffeeScript. I like HAML and would like to use mustache for templating. I don’t know at this point how it all works out.
My Rails app is simple, and the client isn’t too complicated, but SASS, HAML, CoffeeScript, Backbone.js, Underscore, and JQuery are a bit overwhelming.
It is a steep learning curve. I try to introduce one thing at a time and try to make progress.
I will study haml-coffee and see it the helps me on my project.