This is a translation of Daniel’s post which can be found here

In my day to day work as a deveveloper I spend a large amount of time working on the Frontend. To tell the truth I am far more interest perfectly working screens and users satisfied with the simplicity of those screens; than working on algorithms and complex problems in the backend.

I like Rails a lot because it gives me relatively simple tools to build flexible and powerful backends and stilll allows me to focus on the frontend. I don’t have any big gripes with web development with rails on the backend side these days but I do think the frontend part still has a lot of work

Problems with frontend development

Just to give an example, ideally you ‘compile’ CSS & javscript into a single file to reduce the number of requests. With this in mind, which Patterns you use best to avoid namespace pollution and collisions in projects with +200 screens? How do you organize your files so a designer can quickly find them? How do you organize CSS so it’s maintanable How do you create sprites with CSS without spending lots of time calculating positions?

This are only a few problems which frontend developers encounter. There are solutions to handle all of these problems (Sprockes, Asset Packager, CSS frameworks, SCSS,…) but there aren’t any real standards or conventions Ultimately you end up putting your own adhoc framework together containing dozens of external dependencies.

I think it’s more difficult to make mistake drawing polygons on a rectangular piece of paper. Conventions help avoid mistakes. In the case of CSS & javascript, we don’t really have something solid like we have Rails. Todays' javascript & CSS frameworks don’t resolve the problems.

Neither CSS, HTML nor javascript provide the necessary tools to solve these problems on their own. To compile CSS and javscript into single files or create “helpers” for things like sprites, the ideal is to have a tool available on the backend which handles things & caches the results in production.

Fixing the problems with CSS

In the case of CSS I believe the problems is solved by using Sass.

I personally always disliked Sass original syntax because from my point of view creating a new DSL for something which already works is not a solution. CSS, by itself, is not a bad language but to fix the issue which I mentioned we need a backend which adds the functionality to make maintenance less painful. We need helpers, mixins, requires and nesting. Some examples below:

// require/import

@import "shared/global";

// nesting e mixins

h2 {
  font-size: 15px;
  padding: 10px;

  @include border-radius(4px, 4px, 4px, 4px);
  @include background-gradient(#5a656b, #404d55);
  @include text-shadow(1px 1px 1px #404d55);

  a       { color: #7EDAFF; }
  a:hover { text-decoration: underline; }

  .button, .dangerButton, .positiveButton {
    position: absolute;
    top: 2px;
    right: 3px;
  }
}

With the “new sintax”, Sass (SCSS) became a superset of convencional CSS and I believe that the problems are sold without creating any new ones. (like having to convert CSS from vendored plugins like fancybox)

In other words, everything you know about CSS can be applied, your tools and editors continue to work the same way, vendored products also continue to work with conversions and you can benefit from the processing happening on the backend.

What is still missing are strong conventions for organizaton of your files, classes and ID’s without messing up the precedence order when it all comes together at compile time. I believe conventions within your team solve this for now. (In the future I’ll write a post on how we do this in Objetiva)

Fixin the problems with javascript?

Atualmente, para frontend, as duas maiores alternativas que temos é Action Script (encapsulado dentro do FlashPlayer) e Javascript disponível nos browsers.

The best two solution we have available today for frontend development are Action Script (encapsulated within FlashPlayer) and Javascript made available by browsers.

Tools for frontend behaviour?

Honestly I don’t consider neither AS3 nor javascript to be fantastic languages.

Most people throw stones at AS3 and Flash without ever having build an application with them. Trying to be as pragmatic as possible, lets looks at some advantages and disadvantages.

The flash community already understands and uses good UI patterns. Something which the javascript community now is developing and formalizing. To give an example, AS3 developers know the difference between the Bubble and Capture phases of events and use this knowledge to create highly decoupled components. There are dozens of frameworks available to help with keeping layers separated.

Then again, I think ActionScript is a bureaucratic language and has a week object model (I spend the last 4 years working with Ruby, which is pure object oriented). ActionScript also doesn’t have any functional characteristics so from my point of view it doesn’t do anything interesting with modern programming paradigms.

Add to that static typing, lack of a testing culture, lack of reflection, lack of dynamism and absolutely no meta programming make the language very inflexible. Even being based on events it doesn’t have closures like we have in Ruby or Javascript. Because of all that, I think flash is a which works well for very, very specific use cases. (but for those it fits like a glove: TreinaTom )

On the ohter side we have Javascript. It’s pretty cool to see it’s community is evolving and creating phenomenal tools like Raphael.js or Backbone.js. Another nice thing is the growing interest in studying and actually understanding the language. But from my point of view that doesn’t make a language brilliant.

I think it’s important to keep your excitement to learn new things separate from real facts.

It’s today you see people wearing the Javascript hat and calling it a wonderful language. I completely disagree, I think it’s powerful and flexible but I find it totally ugly.

With AS3 it’s pretty to have applications with thousands of lines of code spread over hundreds of files With tools like Backbone.js and Sprockets this is totally doable but it’s still much more complex than for example in ruby.

From my point of view javascript has some pretty annoying problems. Problems like it’s global scope together with the lack of a simple ‘require’ mechanism. It’s quite easy to create horrible code and a community without a testing culture kind of aids with that. It looks like that’s changing though.

It has some really cool features too, like Prototype based inheritance, dynamic typing, closures and functions being first class object (which makes a lot of sense for an event based frontend).

I also think its API’s offer an advantage for something which runs native in browsers and a final advantage which I find crucial is not having to come up with anything special to facilitate acceptance testings.

For these reasons (and for not having other options) Javascript is my go to solution for most of my frontend work. Because of this it was my goal to fully control the language and learn to focus on it’s good parts, rather than it’s disadvantages

Coffeescript e Sprockets

All I’ve up to now is only my personal opinion. The only problem that really is incontestable with Javascript with bigger projects is how to archictect dozens of files in a coherent way and compile it all. For this problem we have a tool call Sprockets

Including sprockets in rails makes it clear that Javascript no longer is a dark spot in the applications but also code in need of quality and attention. We will be able, by convention, organize javascript in a smart way and use things like “requires”, version comments, compilation and reuse of assets. This and othere will allow to create an excelente organization

So, frontend (which appears to be the driving force behind rails 3.1) adopting Sprockets appears a really good idea.

Another thing which is coming with rails 3.1 is coffescript being the default, which can influence a lot of factors.

First, we always had RJS in rails. I think it was very interesting but also relatively weak because it was not possibel to write everything with RJS. Coffeescript resolves this perfectly and fills the gap RJS leaves in Rails.

A problem I’m seeing with Coffeescript, different than SASS, it’s not a superset of Javascript so you need to adapt your tools and learn a new language. I don’t see this as a big problem because it’s very similar to Ruby.

Another fact is that event being the default, it’s entirely optional. If you don’t like it you can easily turn it off but a lot of people will use it by default. This is important for consultants. You might adopt a codebase which set out using coffeescript, so it’ll definately help if you study it.

The last point is whether CoffeeScript, as a language, is valid or not. This really is just a matter of personal taste but I try to stay open for anything that allows me to make my code more expressive and maintanable. I tried HAML four times before deciding I didn’t like it. For this reason I’m already studying Coffee (and I like it) and it fixes a few things which me annoy me with Javascript (e.g. Strings, heredocs can be used as templates)

// CoffeeScript
author = "Wittgenstein"
quote  = "A picture is a fact. -- #{ author }"
sentence = "#{ 22 / 7 } is a decent approximation of π"


// Javascript
var author, quote, sentence;
author = "Wittgenstein";
quote = "A picture is a fact. -- " + author;
sentence = "" + (22 / 7) + " is a decent approximation of π";
loadrun: sentence

If CoffeeScript isn’t for you (like HAML isn’t for me) you can simply remove it. I don’t see any reason for the whole controversy.

Conclusion

I don’t think adding CoffeeScript is something bad or absurd. Rails is a full stack framework but on the frontend it’s still lacking. I think these are steps towards a more robust frontend layer in the future. Even though the framework gains some weight I think it’s valid and for good reasons. If you don’t like it, disable but atleast take a look at it first.