“Your library, like your child, can go to a direction unexpected for you”: interview with the creator of MobX

What is the life of the creators of popular open source libraries? Of course, it's nice when the result of your work helps many people around the planet. But don't you get overwhelmed with tasks that are not even your main job? How to deal with it? How well can you delegate authority?

Michel Weststrata is well aware of all this: his MobX library has more than 17,000 stars on the githaba, the number of its contributors has long exceeded one hundred. Soon Michelle will arrive in Russia to perform at HolyJS, so the guys from the program committee of the conference (Dmitry DmitryMakhnev Makhnev and Eugene bunopus cat) detail questioned him, and about open source in general, and specifically about MobX, and conferences.

Evgeniy: Can you talk a little about yourself for those who do not know you?

- Yes of course. My name is Michelle Weststrate (which is too difficult for most people to say), I'm from Holland. Most often I am known for my work on MobX or immer . I work for Mendix. We make software that makes software: an application development platform that many consulting companies use. We automate a large number of banking insurance companies and similar systems. I do the technical side - that is, what I like. And about two years ago I got involved in the world of open-source, from that moment I was active and specifically in the React-community, and in general in the JS-community.

Eugene: What exactly do you do in Mendix, are you there technid?

- Yes. I have several different roles there, and the main one is technical. In essence, this means that I am responsible for choosing the technical solutions of one of our “tribes” . Thus, I am working on a product that is an environment for mobile applications. We are working on it with four teams, and basically I am engaged in making the right architectural and technological solutions. Besides, I'm still programming. This is one part of my work.

And the other is participation in the open source community. This is a “bilateral” activity. On the one hand, we are doing cool technical things that I want to share at conferences, and I speak myself or encourage colleagues to speak. On the other hand, frequent attendance at conferences is good and the opposite: you discover something that can be useful for us, then we study it and include it in our stack.

Eugene: OSS refers to Evangelism in your Twitter description . What is it and why is it important to you?

- The first reason why this is important: I found that if you translate your development into an open source, it does not save you time at all, but it helps a lot in testing and improves quality. Because a library like MobX is used in completely different conditions. And I think that in this sense, open source gives an advantage that is very difficult to obtain in another way.

And the second: I believe that our “low-level” developments do not define a company, so why not share them. I mean that the company makes a product more or less competitive, which is made on the basis of its technologies - and not these technologies in themselves. And everyone benefits from the collaboration, it allows the development as a whole to accelerate.

Evgeniy: Sometimes they say that a “moneyless” open source is actually a very expensive pleasure. Projects like Linux require a lot of money from the giants of the scale of Oracle and Microsoft. This is true? Can an open source community exist without big vendors and money?

- I think it depends on the specific situation. There are small libraries that could exist like this. But projects like the mentioned Linux kernel or React Native are so complex, and so many people depend on them that they need a reliable financial model. In this case, without large sponsors it would be very difficult. But I do not think this is a problem. I think it’s more important that companies learn to take responsibility than we learn to do without them.

Eugene: For example, if Facebook comes to you and says, "Let us buy MobX or will we sponsor the development to go under our brand"?

- Well, actually, they are already sponsoring! Even fun, but Facebook is one of the MobX sponsors at the Open Collective . So in a sense, this has already happened. In my opinion, the Open Collective is a great example of how we can improve the financial situation of open-source. It allows companies to sponsor the development of the appropriate way, because there is a financially serious approach, with invoices and the like.

In Mendix, I, in fact, are pretty much being paid for working on MobX, so I'm not interested in fully switching to Facebook. I understand that it may be of interest to someone else, but I don’t see a problem with that. In my opinion, if the license remains open source, there is nothing to worry about the product being released under the brand name of the main sponsor. It's like watching football on TV: if everyone can see the game, then there is not much difference, which is the logo on the T-shirts.

Yevgeny: If a large company sponsors a library, can it not say “Since we are paying so much, then please let us do this in it”?

- Do not come across this, at least, so that it becomes a problem. If I'm not mistaken, in the webpack they use such a model, it is possible to pay for features there. So there is some risk, but I think the responsibility of the maintainers here is to ensure that the project remains true to its philosophy. But within this philosophy, there is likely to be a lot of room for maneuver. And besides, in the open source, if suddenly something goes completely wrong, at least there is the possibility of a fork.

Eugene: Developing open source software is like a curve: first you make a library that no one else needs, then people start using it, then it gains thousands of stars on a githaba and so on. When an open source project becomes popular, it can begin to take a lot of time. How much do you spend on MobX?

- Recently, not very much. MobX is pretty stable now. In the past I spent a lot, of course. It was very different. I think during the first couple of years it was a few evenings a week, and many more minor moments when you just answer a minor issue or questions on Twitter. These little things are not felt as a significant investment of time, but I think that in total they add noticeably. However, it is very difficult to measure. It's like checking work mail - you check the issue and quickly send the answer.

Evgeniy: How to be productive in a situation when you are a developer, created a library, it became popular and requires more and more time? You are lucky, you have the opportunity to do it during working hours. But if you already have a job and a hobby, and the project becomes more popular?

- Well, when I started working on MobX, it was also only in my spare time, the work was added when the project became popular. But I have some tips. I noticed that there are a few rules that helped me.

First: monitor the relevance of the documentation. If you received the same question three or four times, be sure to record the answer in the documentation. Because it ultimately saves you time.

Second: be very picky about what issue you are taking. At the very beginning, as soon as you are informed about the error, you try to reproduce the problem, based on the description. And in some cases you find out that this is impossible, and the time has already been spent. So now I demand from the issue something that I can directly run, whether it is the code in the sandbox or a pull-request with unit tests. Something that allows me to determine where the problem is in the library or on the user side. This is very important, because it allows me to save time and make sure that the author of the issue is ready to invest his time. Some people say, “I don’t have time to help in playing the bug,” and the feeling comes out, “Well, then I don’t have time to help solve your problem.” After all, a person is probably paid for the job in which he uses my library - why then should I invest my free time in his problem? In general, such selectivity helps, although it makes you feel somewhat less responsible, because you want to help everyone in general. But I found that “helping everyone” is simply unrealistic.

And also, since I work on several libraries, I don’t respond to all of the issue instantly, but “jump” from one library to another: I work alternately for several days on each, and then move on to the next. And I can answer you in a matter of minutes if you have written about the one you are doing now, but I can not answer in days if your turn has not yet reached. It helps me to switch context less often.

All these tips help when your library starts to gain popularity.

Evgeniy: When the creator of a popular library responds, “I can’t reproduce, write a unit test,” doesn’t it make people feel “he is arrogant and doesn’t want to help”?

- I came across this effect, but very rarely. I think the user usually understands that the maintainers are quite busy, and that the problem is with a high probability on his side. I think if you use the Lodash filter and you have a problem, then there will involuntarily be a feeling that “probably, I have something wrong, because Lodash is used by everyone”. So most people understand that they need to be careful about questions.

Evgeny: When a library becomes popular and takes more time, how much does it cost to share your role as a contributor, giving rights to other community members?

- This is a great idea, I usually give the rights of the distributor, as soon as I see from one person several good pull-requests (or even one pull-request if it is large). In my opinion, it works great. For example, in the MobX-state-tree the main part of the work is now done by other people, not by me. And there are other parts of the code base that people understand better than me, and it's great that everything has come to such a state. For the “main” MobX, this is not required, because everything is already settled there, the algorithms have not changed over the past couple of years, so the support work is small. But in the case of the MobX-state-tree, I deliberately chose such people who create a lot of user libraries, and gave them the rights of the maintainer. After all, if you actively use the library in your daily work, you will stumble upon patterns or common problems, which I missed. And also, I think, it gives developers motivation and a sense of reliability - after all, they can help the library to work with what they encounter.

Evgeny: There is no feeling that the library, like a child, beats off hands? Perhaps you do not agree on how exactly other people develop it?

- Sometimes it happens a little. But I think that is normal. You had an excellent analogy with the children: over time they grow up, they become 18, and then you need to let them go, because the time has come for them to find their own way. I think to some extent with open source libraries as well. If they are successful, then you begin to face more difficult situations. You start to deal with cases that you don’t want to deal with. The code will no longer be the beautiful, clean and minimal code that you originally wanted. It's unavoidable.

MobX has a great example of this: I originally wrote for TypeScript, where decorators are very simple, and then people started using it with Babel, where there is a completely different implementation. As a result, some parts of the code base are very unsightly, because they are trying to determine whether you are using TypeScript or Babel. It sounds awful and it looks awful. But this is part of the job. It’s not necessary to love it, but make sure that everything works fine everywhere. And in this sense, your child can go in a direction that you have not intended, but this is normal, because ultimately it is important that people can successfully use the project.

Evgeny: Development is changing, much becomes easier than it was 10-20 years ago. What do you think in connection with these changes about the current situation in the open source, and what do you expect from the future? Will big companies run everything, or, conversely, enthusiasts?

- Complex issue. Not sure there will be a big change. And there are changes in both directions at once. I am particularly impressed with Facebook and Microsoft - how much they now open-source and to what extent they allow third-party developers to contribute. React Native is a particularly vivid example where a huge part of the work does not come from Facebook. On the other hand, for a loner, it’s probably never been easier to participate in an open-source project or create your own, as it is now. Tools are becoming more standardized, we have great online IDEs likeCodeSandbox and Gitpod . I’ve been working with Gitpod in recent weeks, and this is great: I can check pull requests without even doing anything locally. You can simply launch it in Docker in a browser and develop it there. So I do not know what the changes will be.

Eugene: Eight years ago, when I was a C ++ developer, there was no such open source community as it is now. And now in the world of web and javascript, I see that open source is evolving faster and faster. Will this growth continue?

- I think the movement will continue. One of the reasons, in my opinion, is the following: both companies and developers understand better and better that open-sourcing is not only useful to those who develop or use it, but also helps to find employees. Looking at the participation of a person in the open source, you can understand more about him than if you interview him all day. The way he responds to an issue or gets them started shows a lot. I think developers and companies are increasingly aware of the significance of this.

Yevgeny: So you think that the development of an open-source library can help at the interview?

- Exactly. If you are a company and you have such libraries that are not tightly tied to your API, this is great, because people will come to participate - and they may turn out to be just the ones you need. And if you hire one of your contributors, it will be easier for them to merge, and you will better understand what to expect. I think, for this reason alone, many interesting things were discovered.

Dmitry: We talked about the open source as a whole, let's move specifically to MobX. How and why did you initially start doing it?

- Good question. We in Mendix have long had a Windows application written in C #. A few years ago we decided to port it to the web and began to figure out which stack we should use. React was just beginning, Angular already existed for a while, Ember was quite popular. And rather quickly, we fell in love with React because of its component model and the layer of abstraction offered by it.

But then we discovered that we had a performance problem, it turned out that it was quite expensive to completely update the DOM, even in the case of React. In C #, we constantly updated the model and redrawn the entire canvas, and no one optimized anything, because everything was working very fast, so it wasn’t necessary to “approach rendering rationally”. But here we found that in the case of the DOM, you can't just redraw everything 60 times a second. So we thought about how to do it effectively. We thought about the immutable approach, but in our case it was not suitable for several reasons. One of them is how we worked with what data and how it was rendered. Same information rendered in various places. Our data is very difficult to normalize. And secondly, it seemed that it would still have to deal with too much detail.

But what if you want to write the same simple code as our C # code before, “render something”, and don’t want to bother with how it will change in the future? If you don’t want to say to the components “So, take this part of the data from here, and this part from there, and then you can render something”? We began to explore what technologies are currently available, and quickly came to the paradigm used in Knockout, Meteor, and (at least conceptually) even in Angular. Where you do not designate the relationship between data dependencies and components, nor what should be rendered when.

I began to understand why people often hate these approaches, especially when the application grows. And it turned out that most often people are worried about the lack of predictability and “debugging”, that something can be done too often, or too rarely, or not in that order. And I decided that we can handle better. We can pursue the same goal, but more intelligently approach implementation. And so MobX appeared. It does not just capture the relationship between observes and observables, but builds a whole dependency graph, so you can be sure that all observers are executed in the most efficient manner. In reactive programming, there is the concept of "glitch" - so, here it can not arise. In general, there was taken already existing, but with an attempt to make it more predictable.

Dmitry: So if I like some kind of approach, but the existing libraries are not good enough, you can just take and do better, and this can become popular?

- Yes it is! So I wrote it originally for our internal purposes, and then went to ReactEurope. It seems that it was 2015, and there was a lot of talk about Flux patterns. Then the Flux Wars raged. And I felt that people are investing a lot of energy into the problem that we have already solved. And then I thought "it is necessary to open the account." And it worked. Probably because it was not “another implementation of Flux,” but something completely different. It was helpful to many people.

Eugene: The original MobX idea was simple, and now there are a lot of code and features. Does the feeling that everything is too complicated?

- There is! I always have this feeling “I want to make MobX Lite”. In fact, you can make an analogue of MobX, having packed 200 lines of code. I even have a report where I like doing this. It implements the main reactive algorithms. Then you can add a few hundred lines to optimize everything and make the project faster in a variety of conditions. So it turns out the whole core of MobX. But I think that three quarters of the code are already things at the API level, like the implementation of decorators. There is a main idea, and there is everything around it that is designed to make the API as good as possible. For example, in MobX 5 compared to MobX 4, what is connected with Proxy has changed .

Dmitry: On the issue of Proxy. So far, most developers use them only in some development tools, and you have in production. Not without nuances?

- Sometimes it is not easy to be one of the first projects where they are used, but Proxy appeared a long time ago, stable implementation appeared about four years ago. And only a year ago they were implemented in all browsers. The basic implementation appeared in Chrome 8, but earlier their use meant significant overhead, but now it has changed.

Eugene: Let's talk about the state. We remember the days when jQuery was the king of web development, and then there was no talk about state on the client, we stored it in a global object or something. And now do not create an application without controlling the state of the library like Redux or MobX. What changed?

- I think there are two answers. One is that in the days of jQuery applications, we generally didn’t have much of a state on the client. I mean, jQuery was often used to add interactivity when everything was stored on the server. Now this is not a good practice because of the spread of microservices. But the more important reason for the transition from jQuery to a component-based model like React is that it allows you to think of self-contained, independent components, which is better suited for increasing the code base. This allowed us to simplify the creation of more complex applications. For example, in our case we use the same state definitions on the frontend and backend.
And I think state management did for the state what React did for the UI. State management allows you to separate your states into more cohesive patterns. You can use self-contained data sets and logic, unit-testing them without UI and better controlling them.

Eugene: What do you think about the future management of the state? We have already reached the point where there is nothing more to add to it?

- I think we have not reached it yet. Especially when it comes to state management focused on immutable values. I think one of the reasons why immer has become so popular this year is that it made the immutable states update more native to JS. But I think a lot more can be done in state management. For example, to divide information, most people use selectors orlenses , but it seems to me that this is not very convenient. I think that there are more and more approaches, for example, GraphQL is very interesting to mention, although it is not very convenient when you need to work with local states. So we still have room to grow ...

Eugene: Can you name a feature or two that you would like to add to MobX?

- There is one thing I would like to do, but I am afraid that far from everyone will need it. I would like to make the data conversion more reactive. I mean this: Imagine that you have a simple to-do list and you apply filtering to it. Your filter should show, for example, all unfinished todo. The problem is that if something has changed, the filter should go through all the todo-elements in the list, while you can only process the changed ones. And now there is no convenient way to express it. But in principle, data conversion can be made more reactive than they are now.

Dmitry: Authors of popular libraries are invited to speak at the conference and conduct trainings. I want to ask about the trainings. In Russia, they do not like, considering something for beginners. What is your attitude and what do you encounter in Europe?

- I really like trainings, and I consider them a great way to learn. I personally love to study in one of two ways: either I sit down and read a book from cover to cover, or I come to the training. Videos are not for me, they are forever either too slow or too fast. Although I created several video courses myself, I didn’t like it. When I started to get used to Docker, I went to the training. And since this is a very practical lesson, you immediately feel how everything works, what it is like in general, and how you can apply it. For me, training is not “for juniors.” In my opinion, the main thing in them is that this is the fastest way to master a new technology, with which you have not been particularly familiar. I think this is the main value, and you will not get this from a book. A book is more about a general picture by which you can understand how relevant something is for you at all. But if you really want to start working with something, or seriously think about this option, the training will be the fastest. There, in the breaks, people come up with specific questions about the specific difficulties that they have encountered, or ask about the application of the learned in their particular situation. This is an advantage of trainings: you can talk to someone, ask questions relating directly to your situation. I really believe in this form of mastering new technologies.

Eugene: Also, many (at least in Russia) believe that you should not go to conferences, because you can read texts on Medium or watch videos on YouTube. What do you think?

- I think, unlike training, the main goal of the conference is not in training. In any case, my personal opinion is. The main reason to go to the conference is to be inspired. What is happening in the industry, what people do ... Want to learn. Networking comes along with it. When you come to a conference with colleagues, try not to talk too much with them. You already know them. You know what problems they solve. Much more interesting to talk with random people, for example, standing in line for food. You can see what they are doing, what problems they solve, and what experience they have with the library, about which someone gave a report in the morning. And look for speakers if you have questions for them. Many people are afraid to approach the speakers, but for me as a speaker (and, I think, for most other speakers, speaking with the audience is an interesting part of the conference. Well, better not contact me five minutes before my appearance on the stage, but the rest of the time I try to be very accessible. So do not hesitate and contact.

Eugene: Great advice. You will find yourself in Russia for the first time - what do you expect from Moscow and from the conference?

- I definitely want to look at Moscow and I will definitely be shocked by it. And I also noticed that in Russia there are many MobX users. I see it on the tracker, on commits. So I hope to meet at the conference with many users of MobX.

You can see Michel and ask him questions at HolyJS 2018 Moscow , which will be held November 24-25 . There he will talk more about state management. You can see the description of the conference reports on its website .