What is a framework?

The title question made me struggle for months.

1. What is a framework?
2. What is the difference between a library and a framework?
3. If I use a framework as a library, does it make it a library?
4. Is Rails a framework?
5. Is Backbone a framework?

Can you help me with your answers?

Rails legacy applications

The topic of Rails legacy applications is becoming more popular recently.

We, at Arkency, sometimes receive questions whether we can take control over an existing application. It's never an easy decision.

Legacy apps contain legacy bugs, which can quickly become "our" bugs. They often have no tests, or just failing tests. If you're very unlucky, you can find some really shitty code.

What's the reward?

This is a story of one such project. We can proudly say that we successfully fixed the mess, not only that, we also created some beauty on top of that.

Let me just say that it was such a pleasant experience that we decided that Arkency should do more such projects.

Challenge accepted! We're looking for more such challenges, email me if you have an old Rails app that needs to be fixed.

Read the slides of Michał Łomnicki to learn the details.

Having fun with legacy apps from Michał Łomnicki

Thanks to Michał and Paweł Pacana for the awesome work!

Let me know if you want to learn more about what we did and I will convince Michal to blog about it :)

Is CoffeeScript better than Ruby?

If you are subscribed to our Arkency newsletter (we send an email every week or two with some interesting links and our comments), you probably noticed that there is an ongoing debate in our team - whether CoffeeScript (actually JS) has a good standard library.

I have recently watched an interview with DHH about his opinions on Single Page Applications.

DHH was explaining why they don't go the SPA way with their new 37Signals applications. They chose to generate JS and HTML on the backend and send it back to the client.

One of the DHH's arguments was that they prefer the Ruby stack (with Rails) than the experience of writing CoffeeScript application, with the server being just for JSON API.

Overall, I think that DHH makes some good points, but I don't agree with the assumption that it's better to work with the Ruby stack than with CoffeeScript. Sure, the patterns are not so mature as with a typical Rails app, so sometimes it takes more time to do the same thing, however their approach of sending JS is also not the most trivial one and it creates a complex architecture, IMO.

First, the syntax of CoffeeScript is better to me, than the Ruby syntax. This is subjective and I'm not expecting everyone to agree. To me, it's enough that the code is mostly shorter while still very elegant.

Second, the libraries. Yes, JS stdlib is almost non-existing. It's almost always better to avoid the existing stdlib and rely on sugarjs or underscore. Ruby is winning here. Now. With the growing JavaScript communities, we'll see a huge improvements very soon. The sugarjs library is already awesome and I don't feel I'm sacrificing anything by using it, compared to the Ruby libs.

You can improve the libraries, but it's hard to improve the syntax.

I may agree with DHH, that the SPA environment is not yet at the same level as Rails is now. Even DHH says that the situation happening with JS MVC is a huge shift. In my opinion (and not only mine), we see a revolution that can be only compared to Rails in 2004-2005. Back then, Rails also wasn't that mature, but we were able to use it and have a really well working applications (my first production Rails app was released in April 2005 and was used by hundreds of users every day).

Back to the title dilemma. Is CoffeeScript better than Ruby? 

We need them both. The trend of SPA will be growing and we can't use Ruby there. On the other hand, it's not easy to use CoffeeScript on the backend (nodejs based solutions are nowhere near the stability of Ruby solutions) and Ruby is a great choice in there. In most of the apps that I'm currently working on, I spend like 80% of my time with CoffeeScript on the frontend and 20% on Ruby on the backend. That's my answer :)

JS frontends are like desktop apps

I noticed a trend recently, among developers, that we need to learn how to work with JS frontends. Obviously, it's great that people want to improve their skills, but is it really something new that we need to learn?

I suppose, that many of us at some point have been working on a desktop application. Was it a Java Swing app or a .NET Windows Forms or maybe Delphi app, doesn't matter that much.

What's important is that a JS frontend is very similar to a desktop applications.

Yes, they are not completely the same, we can do a few things that are easier in the browser than on the desktop app. Those differences don't influence the way we architecture the JS apps.

If you haven't had a chance to work on a desktop app then you're missing a lot, but still, it's much better to read about the desktop patterns, than to try the new shiny JS framework.

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).