From backend to frontend - the mental transition

Recently I blogged about my thoughts on the idea that frontends are in fact separate applications.

Today, I'd like to describe the transition of my mental model in thinking about views and frontends.

I thought that it was only me who went that path, but this excellent Backbone introduction slide deck helped me realize that it's a common process for backend developers.

This process consists of the following steps:

1. No-JavaScript phase

No JavaScript at all, or using it through some kind of backend plugins (like the ones Rails gives - link_to_remote etc.)

2. JQuery explosion

This happens when you use straight JQuery, there is lots of JQuery plugins updating different views, replacing html and using some simple Ajax.

3. Page and Widget objects


It's basically the same as phase 2, but this time you wrap all the JS code into nice objects/classes, so that you start unit-testing them. You also start packaging them as "pages, "widgets" or "components". You're still rendering the html on the server side and the data is either in the html or in some pre-rendered JavaScript files. You're switching to CoffeeScript. This phase can be "fine" for many applications.

4. Single Page Application

Single page application is the phase in which you move all of the html generation from the server to the client. There are no full page reloads. Of course, there might be phases between 3 and 4, where some of your html is rendered here, some is rendered there. Luckily, you prefer consistent solutions, so you end up quickly in phase 4.
It's this phase where you think about the frontend as a separate application. All the data you get, come from API requests. You know the difference between MVC here and Model2 on the backend. You explore the different techniques for designing the domain - gui communication.

Any other phase?


In the Sarah's slides you will also find a next phase here - Frameworks. I'm not putting it here, as I think we choose frameworks too early. It's a topic for another blog post.

I'm in the 4th phase for quite a while now and I don't feel any need of a framework.

There's also an interesting area to explore, where you have several mini-application in your web app.

In my next blog posts I'm going to help you learn how to solve typical frontend problems without using a full framework.

Just to be clear, I'm fine with Backbone or AngularJS or others. It's just that I think, that those frameworks can be limiting to our projects very early on.

Which phase are you in?



 If you read this far you should and subscribe to my RSS.

Frontend is a separate application

Despite my experience with working on desktop applications, I've been avoiding any frontend (here meaning JavaScript/html) for years.

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.

How to waste time on TDD

This blog post was originally written by Piotr Włodarek on his TheSingularity.pl blog. I liked it so much that I translated it to English, so that it can reach a broader audience.

 Some people argue that TDD slows down the development process. If you want to follow this opinion here's what you should do:

1. Write tests after writing the production code.
2. Waste no time thinking about designing, simply jump straight into the TDD loop and do 100% of the design work there. You'll have a chance to change your code and tests structure over and over again. 
3. Learn how to write test scenarios completely on your own, don't bother watching any screencasts and don't read any books on the topic. 
4. Make sure your tests load at least half a minute before they actually start testing anything. You can easily achieve that by loading the whole framework and working with your old crappy HDD. 
5. Make sure all the features are tested through the GUI (by driving a web browser or desktop GUI window). 
6. Make sure all your tests depend on the database. 
7. Manually find the corresponding test file and the production code. 
8. Navigate between desktops, windows, tabs only to find the tests starting script. 
9. Try to write as few classes as possible to ensure every class has multiple unrelated responsibilities. These are guaranteed to be a testing nightmare. 
10. Write beautiful step definitions in Cucumber even if your customer doesn't care about reading your specs (or perhaps you don't even have a customer yet).