Just about 2 weeks ago I have been bitching about the #rubyonrails channel (no need to look it up as this article will negate that anyways). Fortunately (for everyone I guess 
some prominent rails guys came after me, gently kicked my ass and challenged me to check out #rubyonrails again (after leaving a bit pissed off about 2 years ago), claiming that the atmosphere has changed drastically.
So, I took their advice, joined the channel, and was indeed pleasantly surprised. During my 2+ weeks of stay, I can’t remember any incident (ok, except the constant trolling on TextMate vs Vim, Mac vs Linunx, Shoulda vs rSpec, jQuery ftw, how RJS sucks, how Java sucks (well, initiated by me ;-)) and found most of the people very friendly and helpful. Also made a few friends and had some great fun.
I also discovered some great #rubyonrails stats by @radarlistener and persuaded him to add a little feature to it: display then number of thanks per all messages. It’s not a huge feature, but we can find out some interesting stuff with it - for example, the signal to noise ratio off different guys: which of them are helping out the most on average (we could probably dig out the reverse info too - a.k.a. help vampires, but that’s outside of the scope of this post).
So, without further ado, here is a top 30 list (the number behind the nick denotes “lines per thanks”, i.e. how much lines the given person had to enter to receive a “thank you”):
- pet3r: 69
- stympy: 70
- octopod: 83
- mikeg1a: 90
- mf_irc: 97
- koppen: 105
- noodl: 120
- eljo: 120
- topfunky: 126
- leeo: 128
- fcheung: 129
- chippy: 137
- rainmkr: 138
- gerhardlazu: 139
- blj: 142
- madrobby: 142
- darix: 154
- toretore: 158
- minam: 162
- thread: 162
- donomo: 166
- halorgium: 168
- sonofslim: 169
- don-o: 170
- claudio: 176
- melvinram: 180
- bitsweat: 180
- ddfreyne: 181
- archetypo: 183
- jacobat: 185
Hey where’s lifo and rsl? Wtf?!!11!1! My script must be buggy… need to spend more time on #rubyonrails to learn this Ruby thingy properly.
Thanks to @radarlistener for his great work on the stats, as well as other great #rubyonrails bots.
I am sure almost all of you heard the now classic advice from the Pragmatic Programmer: Learn at Least One New Language Every Year! Since it is a beginning of a new year, I have seen a lot of bog posts by various people acting upon the advice and choosing to learn a language - this year I decided to follow suit, and learn … Javascript.
I can almost feel the disappointment mounting: What the #&$%^&#@ why not Erlang? Or Clojure? Haskell? Scala, Lua… ? Why Javascript? That’s so 1990s…
Why Javascript?
The answer is easy: right now I am a Rails web developer (not a distributed system architect, monad detective, human parenthesis parser etc), and though I know enough Javascript to get by in majority of the cases, I’d like to take it to the next level.
Don’t get me wrong: I understand that the rationale behind learning a new programming language is not (necessarily) the ability to put the newly acquired knowledge to use tomorrow, but rather to discover new patterns / schemes (no pun intended). Thankfully, Javascript means the best of both worlds: you will find a lot of new stuff in there (unless you happen to know some other esoteric languages - Javascript is a dialect of ECMAScript based on Self and Scheme) - for example, unlike most of the mainstream OOP languages (which are class-based), Javascript is prototype-based - while at the same time you get a powerful tool enabling you to create more effective web applications.
Using a Motorized Wheelchair Because you’re too Lazy to Walk
Why do you, as a Rails developer need Javascript? There is Prototype. And script.aculo.us. And RJS. And jQuery. And Dojo. And MooTools. And…
I really have to agree with Adrian Holovaty (of Django fame): “(Relying on server-side frameworks to generate JavaScript) is like using a motorized wheelchair because you’re too lazy to walk”.
So true. I am tired of seeing people doing stuff like:
- Simulating even the most trivial things like $(’element’).toggle(); with RJS
- Using oberve_field for everything. The problem is that observe_field in it’s vanilla form sends a request to the server every time you hit a key. It’s easy to replace it with a bit of Javascript knowledge and stop hogging the bandwidth.
- Instead using Javascript functions like setInterval / setTimeout they are simulating the desired behavior with Prototype / RJS
- Trying to create great AJAX sites without much clue about Javascript (and just minimal knowledge about Prototype/RJS - spending a week or so on #rubyonrails was enough to experience this in it’s full glory ‘hey plz help bro cuz Im new to AJAX’)
- Doing all of the above obtrusively - who cares about the totally littered HTML, just get it done somehow
And I am talking about trivial/mundane tasks above - what if you’d like to create your own custom widgets? Optimize your code? Rely on the browser for various things not supported by rails out of the box (e.g. in-browser caching)? Manipulate the DOM? Prototype/RJS won’t do everything instead of you.
(Don’t get me wrong, I am a big fan of jQuery, and application development would be painful and slow without it - I am talking about the fact that in some cases falling back to Javascript is unavoidable and/or ineffective)
Ok, I’ll Still Stick with RJS and I Like it Obtrusive!
Ok, you have been warned. Suddenly It seems not I am the one stuck in the 1990s… but whatever. Ignore JS in your Rails apps at your own peril.
However, Javascript is usable in many other settings too. It’s a general purpose programming language, roughly comparable to Python or Ruby, so it’s a misconception to believe that JS is just some obscure mini-language only good for some browser hacking (similarly as Ruby is believed to be a scripting language, or a language invented to power Rails). So you can do just about anything with Javascript that you would do with, say Ruby.
If you want some interesting specialized usage: building Firefox extensions. Judging by the current trends, browsers are becoming more and more important, according to some people to the point of taking over the place of an operating system. While currently I find that theory a bit far-fetched, it is sure that as a Web developer, you can’t ignore building Firefox extensions. You need a lot of Javascript to do that.
Then there is DOM scripting. You would be amazed to know how powerful DOM manipulation can be once you learn the ropes.
Obviously, you are using a Javascript framework (Prototype, jQuery, mooTools…). Though you can get by quite well with any of them without knowing too much Javascript per se, your effectiveness will go up with the amount of JS knowledge. It’s like learning Rails and ignoring Ruby. You can do it, but sooner or later you’ll hit a wall.
Let’s Hit the Waves
Douglas Crockford’s site looks like a good starting point.
On the book front, I am planning to get these titles (I am not using any referral crap, those below are plain amazon links):
If you have any suggestions, comments, ideas on how to do this thing better, please leave a comment.
Oh, and be prepared for some Javascripts posts in the future