Why Meteor will ruin Ruby on Rails

From the translator: I translate not for the sake of holivar, I don’t know RoR myself, but I feel a positive attitude towards him from RoR specialists, I caught a glimpse of the beauty of the language and the framework itself, but this is not about it. The purpose of the translation is once again to draw attention to Meteor, which is developing by leaps and bounds - in early 2014 we are waiting for release 1.0. In the English-language Internet, everything is in full swing, but we have silence - only a few articles.

Why Meteor?

I remember starting Rails in 2004 - it was “magical time” - and, of course, I remember that I was asked at least once a week why rails should be used. I always answered the same: developers like this framework because it allows you to do work quickly and with pleasure. By this time, I had been working closely with Meteor for more than a month and was ready to answer the question: “Why is Meteor?”, Which I too often began to be asked.

Binding difficulties

When a client asks to create an application, this is usually a complex, interactive application with a lot of JavaScript for a rich interface. The problem is that for applications created on something like rails, JavaScript is something like the third sleeve, sewn from the side, due to different times of technology development. Of course, you can spend a few days putting everything together in such a way that everything will suit the developers, but the rails have been created and received such a wide variety thanks to their configuration conventions. I worked on 4 different backbone applications, large and small, and they all were configured differently. If everyone makes their own settings for node.js, angular, etc., how can we then quickly be included in projects?

Meteor solves this problem by combining, together, "one of the most modern" collection of packages, and in a completely understandable and convenient way. jQuery, Handlebars, Node.js, websockets, mongoDB, and DDP - all in a well-organized tool that allows us to build applications quickly and efficiently. We launched the most important functionality (MVP) of an application in 3-4 weeks, whereas on rails it would take 4-6 weeks. We recently spent 2 days mating angular with rails for a completely new project - we had 12-16 hours to do the configuration, instead of doing what the client wanted. When you pay experienced developers $ 100 -200 $ per hour, these 12 hours are worth a lot if you only have $ 20 -25 $ thousand to create a product. In the worst case, you can spend 6% of the budget to pair two frameworks. And this does not include the cost of setting up such things, such as websockets, which allow two-way data exchange in real time. And all this for free at Meteor.
')

Attention switching problem

I hope everyone recognizes that multitasking is quite difficult for a person, losses occur when switching from one task to another? Yes, we all, good developers, know several languages ​​and can switch between them - but losses are inevitable when we have to switch from Angular to Rails and back. If I write a backbone or angular application, and there I need to get data from rails, I have to spend time writing the controller in rails, which would provide access to the data, via ActiveRecord. Pure water inefficiency is forcing my brain to switch back and forth to ensure proper validation both there and there.

What if you could work with one language and one framework, created from the very beginning for efficiency and ease of development? I do not want to look like a sales manager, but this is just an epiphany, to see a framework that all this can really do. I understand that Meteor still needs to be tightened in areas such as testing and scaling, but I have already seen how these issues were resolved in ruby ​​on rails, and therefore I am certain that there is a little time and effort, and everything will be done right.

Recruiting

Let's face it: JavaScript is the # 1 language on GitHub for an understandable reason - it's everywhere. Java promised us this in the 90s, but it turned out to be too big, bloated and inconvenient (I confess, I used Java only in college), although there was clearly an interest in a common language then. By “everywhere” I mean here, of course, the browser. Being the most popular language has its advantages, the main thing - very many people know it.

Recruiting becomes much easier when you have a large selection. I guarantee you that you can start Meteor project of any structure with the help of almost any JS programmer - he can very quickly learn everything and run the application. This is very important in the world of software development - an overly complex structure complicates the replacement of members of the development team and slows down the speed of development. No one likes to be tied to some developer or team, but it’s clear that the more options there are, the better.

Designers love him

Remember how in the advertising of flakes: "They like him, they REALLY like him!". Over the years I have worked with many designers, helping them to install Ruby, explaining the file structure, how to display static files, teaching them SASS / Less, etc. I have always liked to do this, because I have not yet met a designer who would like Less or SASS like less pure CSS. This has never happened before, so that I would not spend less than a few days helping designers when they begin to study rails. The structure is quite complex and takes time to realize all this.

Apart from jokes, but our designer (who was familiar with rails before) had fallen in love with Metero, that even on his own initiative, he created the template Meteor boilerplate, which we now use as a starting point for all our Meteor applications. In addition, tired of rails, he transferred the entire design of our site to Meteor, having done 40% of the work completely before disturbing someone from the developers with questions. Think about it.

A designer doesn't need a developer at all to create some code or set a file structure - for me it was just some kind of insight.

A solution created with the utmost attention

Meteor absorbed parts of many frameworks, and I think this led to the fact that a superior solution was created in all respects - they learned well what works and what doesn't. Handling events in Meteor strongly reminds me of a backbone - this is exactly what I love backbone for the most part! The package manager reminds me very much of NPM and Ruby Gems - I like the fact that someone can write code once and reuse it, and in Meteor it is very easy to do. They mixed all this with such advanced technologies as websockets and mongodb, which significantly speeds up development.

So why all the same Meteor?

Yes, because if someone from the early followers of the technology with might and main shouts about something, it will soon shoot. This does not mean that Angular, Ember or backbone will suddenly become extinct, no, they will take their place, mainly supporting existing applications with a rich interface. Every developer and entrepreneur should look very seriously towards Meteor. Time to market is reduced, and the pleasure of developing will increase tenfold.