Two years with Dart: how we write in a language that is “buried” every year (part 1)

“Is he not dead yet?” They ask us about Dart at each front-end conference. “How does Google support the language?”, “How do you hire developers to the team?”, “And why not TypeScript, if you need typing?”

We decided to combine the most frequent questions and ask them in an interview with Igor Demyanov, the development manager of Wrike .

Let's talk to him about why Wrike, with 2 million lines of code behind him more than two years ago, was not afraid to switch from JavaScript to Dart, how the migration went, how the product grew and the development team grew, how the language develops today, despite the talk about stagnation or even death.

Igor, the product is already more than 10 years old, but what happened before you started using Dart to design the Wrike frontend?
')
Before Dart, we wrote on ExtJS 3 and partially on ExtJS 4. Plus, we had a small self-made framework, which was written by one of the former employees. This "bicycle" now rather disturbs us, and we are slowly getting rid of it. At the moment, there are more than 2.5 million lines of client code in the project, we’ve been writing a darth for two years already and slowly getting rid of Legacy on ExtJS.

At what point and why did you understand that you should stop writing to JS?

It came when Wrike began to grow actively. When we had 11 people in our team, we could somehow use JavaScript, more or less understand who wrote what code, remember all the nuances of the old code. But now in the front-end team we have about 50 people, the developers are distributed over more than 10 scrum teams, and the rule of personal agreements is no longer working. There are many tasks, a lot of developers, a lot of code.

A lot of code is how much?

We are currently shipping about 10 megabytes of compressed code to the client, it was 5 or 6 earlier. And earlier this figure looked scary, now and even more so. But we can not do anything here - the product is actively growing functionally. Of course, we strive to ensure that individual pieces of code are loaded on demand, but in some cases you have to load all the code at once, so that all the functionality of Wrike is available to the client instantly.

So why Dart?

Dart compares favorably with the rest of the fact that it can throw out unused parts of the code, this allows us to live with such a huge legacy. When a project is large and there are many developers, it is very difficult to control what you use and what not. There is a code that lies in the code base - maybe it was just someone forgot to throw it out of the general assembly - and it still lives with us. And if we used JS with its collectors, this code would definitely come to the client. And Dart allows you to optimize and cut out unnecessary code. Plus, we are not dependent on any JS standards that are constantly changing and updating. When you make an enterprise product, it is very difficult to beat the business time for translation from one standard to another.

Choosing Dart, we took the path of slow migration: we first rewrote the core part, then the rest of the functionality. Now we are already loading a new code more than the old one. At the same time, the product is actively developing and new features have to be done very quickly.
From the point of view of the team, the process has also changed - the developers spend less time on the proceedings, which parameters are transferred to.

Yes, now approximately the same possibilities are at Typescript or JS + Flow, but we like Dart. The language has a simple and clear syntax, and most importantly, it allows us to concentrate on ideas, save time, which we would spend on refactoring or, say, switching from ES5 to ES6, frameworks, etc.



Is there some kind of development of product components on JS?

In some exceptional cases, we can make changes to the legacy code on JS if we see some critical bug. In other cases, the new code is written on Dart - it either replaces the old code or adds new functionality.

What framework do you use?

About a year ago, we switched from Polymer to Angular2. Now we are planning to switch to Angular3, and by the end of the year - to Angular4. In many companies, business in this regard is rather difficult to meet R'n'D - such migrations are accompanied by long disputes and convictions. The fact that we use the newest tools is not only the merit of front-end developers, but also our automation testers, who help us well with regression tests and QA Manual. When we switched to Dart, we received the support of all the technical teams of Wrike, so this transition was relatively painless to us. Similarly with Angular - we predict that the transition between versions will drag on for 1-2 months, hardly more.

Now they know little about the language of Dart, but 2 years ago there was no information at all. How did you manage to redo everything on a living project? It is hard to imagine that the business has gone to this at all.

I myself started using Dart from version 0.8, when it was still in beta. At the time of introduction into Wrike Dart, the specification, standards, etc., have already been officially registered, that is, we were confident that nothing fundamentally changes in the language. We knew which language we would be dealing with, we analyzed everything and got the first results, which could convincingly prove the need for change. The main argument in favor of darts was Tree Shaking - the ability of darts to cut unused code down to the methods. And this is with our volume legacy critical.

Why not typeScript?

If we, for example, ported Wrike to TypeScript, it would probably be "cheaper." On the other hand, we have so much code that porting to TS, most likely would not have given us anything - the same volume of loaded Legacy would remain, only on TypeScript. Dart forces us to write concisely and correctly, and does not allow simple mistakes in the design, this is his plus, but this, of course, is its rigor.

If you go back to business, then yes, here we received support. Our CEO Andrei Filev is a developer himself, and the conversation with him can be done in the same language. Plus, Google’s reputation as a language developer says a lot. In the end, these changes were necessary for the business itself to quickly develop and release features that allow us to remain one of the market leaders. In general, the business supported, and now we are moving very fast, and the business is satisfied with our speed.

But those 11 people who wrote on JS and were forced to switch to Dart, probably, didn’t so happily accept this news?

The guys who worked with some other language besides JavaScript, very easily switched to Dart. On the contrary, they were pleased that Dart solves their problems with someone else's code and simplifies communication. Of course, there were those who knew only one JavaScript, and, like any "old believer", perceived the changes with hostility.



Now in the JavaScript world there is a rather low threshold of entry, there is a lot of newbies in the community who are learning the language, but they hardly understand how large products are designed. My colleague Evgeny Gusev has a report on this topic , which not so long ago caused considerable controversy among JS developers.

Any language can be considered only in the context of its application, therefore, disputes and holivars are meaningless here. For example, JavaScript is all good for prototyping - no matter how you write the code in JS, you will most likely run it. There is no “bad javascript” concept - either it works as you need, or it does not work as you need, that's all.



With Dart harder. You, as in Java and as in .net, have an analyzer that tells you: “You know, friend, no matter how wrong. So you can not do. You cannot create dynamic classes, etc. ” That is, the language simply does not allow himself to shoot in the foot, no matter how you want.

If you look, many of the creators of Dart, have worked with serious object-oriented languages, V8 did, even someone from Java they have. They approached language design from the point of view of large applications, therefore Dart is a language for medium, large, and very large applications. He offers one default, but the most effective solution, and it comes out of the box. You can do a one-click delayed download / download on demand, the language itself will “cut out”, optimize the code - these are the bonuses that are needed for large applications. On small applications, you practically will not see any noticeable effect compared to JS.

How the language develops, what's new in it to wait in the coming year, how willingly language developers from Google participate in community life and solve emerging problems, read in the second part of the interview in about a week.

We will be grateful for the questions in the comments and, if necessary, we will write more detailed technical articles about working with Dart based on them.