It wasn't because I didn't know JavaScript, it's just that I am a developer who cares about code quality and JavaScript coding was far from any "quality" areas (in my mind).
I felt safe with programming backends and I was more than happy with Rails. Rails is a framework that is really good at abstracting the frontend problems. It gives you a set of view helpers, so that you can do almost everything in Ruby.
Whenever I had a project that involved more JavaScript (because the UX designer required it) it was a painful experience to me. I just couldn't find a good way of structuring the JS code. I didn't know how to test it well (and yes, I knew Selenium, thank you).
Now I love working on frontends.
Why the change?
I realized that my mental model of a web applications, that I had in my mind, was wrong. I'm guilty of not thinking it through harder in the past. The Rails framework created an illusion for me that the frontend is the View part of the MVC architecture. It's not and Rails is not MVC. It's not only a Rails problem, I think that in most web frameworks we see a similar illusion.
The View part is another application, that Rails happens to generate quite nicely.
The mental process of moving the View from the backend app to a separate application is quite interesting and I hope to cover it another blog post if anyone is interested [UPDATE: I blogged about this process]. I see a similar pattern of transition among my fellow developers.
Once I realized that the JS is in fact another application it was like a whole new world of programming opened to me. With the rise of CoffeeScript it became even more cool. I'm able to use all the patterns from my desktop apps experience (I've been working a lot with Java/Swing apps and on an .NET Windows Forms app with IronPython).
A CoffeeScript (or JS) application can embrace the original vision of MVC. There are new architectural patterns like DCI, which put use cases in front of everything, that fit perfectly well into this kind of apps. There are some concepts from AOP that come back (even Twitter uses them) and are great for domain - gui separation.
Even more, the backend is now an optional part (a plugin) of my project, it's possible to run the frontend application without a Rails backend.
We live in exciting times. The Single Page Applications are becoming more and more popular. I'm no longer a backend-only programmer and I am very happy with that!
If you read this far you should
and subscribe to my RSS.
16 comments:
Totally agree with this.
Moreover, all this, in my experience, has had a very positive impact on backend.
Pablo: Exactly, I'm feeling the same. I'm a better backend developer thanks to my frontend work.
Nice post -- I also strongly agree. Moving the V to the client is the way it was meant to be, and it's probably gaining so much popularity because of all the fantastic JS frameworks (Backbone, Ember etc.)
I agree. All my web apps are two separate GIT repos.
Backend will usually consist of templates and a RPC or Rest interface.
My current app doesn't even generate HTML serverside. The static HTML file is part of the frontend repo and all communication is through a REST api. Of course everything is AJAX.
I treat the server like a service and everything is better for it.
Anonymous:
"I agree. All my web apps are two separate GIT repos. "
That's the point - very good decision!
"I treat the server like a service and everything is better for it."
Yep, exactly.
Thanks for your comment, I really appreciate it.
I had a very big comment where I had one question. And when I finally was finished I got an "aha" moment. So all thats left to say is:
I agree!
:)
From the design standpoint it is certainly cool.
What I'm afraid is piracy. If the app is downloadable JavaScript program and backend serves only for data storage, it is easy to stub it with your own and deliver pirated version of the whole app. Goodbye SAS ;-)
Stefan: Haha :) Thanks for your comment, anyway ;)
qertoip: Interesting side-effect... A backend is still needed, though, so it's not that easy to copy.
Ember.js is the only tech that gets me excited to work on the front-end :)
May I suggest you to take a look at Serenade.js or Knockout.js? Since you think like me it is likely that you'll also enjoy those tools.
For testing you might enjoy my latest article on the subject, although I'm about to write a new test runner for replacing Jasmine, built on top of Buster.js:
http://rosenfeld.herokuapp.com/en/articles/programming/2012-06-03-client-side-object-oriented-programming-and-testing
May I suggest you to take a look at Serenade.js or Knockout.js? Since you think like me it is likely that you'll also enjoy those tools.
For testing you might enjoy my latest article on the subject, although I'm about to write a new test runner for replacing Jasmine, built on top of Buster.js:
http://rosenfeld.herokuapp.com/en/articles/programming/2012-06-03-client-side-object-oriented-programming-and-testing
Sorry for the doubled comment. I didn't notice the message that my message has been posted. I found this comment system quite confusing and I have the habit of copying my comments before posting them to prevent losing my comments :P
Rodrigo: Thanks for your comment. I will have a look at the frameworks you mention and at your blog post.
Sorry about the commenting system, it's the blogspot default and I have no idea how to improve it...
No problem, pal :)
So true. Rails definitely creates the illusion of having views be part of the application. I really like to push the idea of RIAs even when using rails. Where the backend is a rails application passing up data either as XML or JSON, then my frontend application html, css, and javascript handles retrieving and presenting the data.
Post a Comment