“Your library, like your child, can go in the 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 across the globe. But aren't you overwhelmed with tasks that are not even your main job? How to deal with it? How boldly 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. And soon Michel will come to Russia to speak at HolyJS, so the guys from the conference program committee (Dmitry Dmitry Makhnev Makhnev and Yevgeny bunopus Kot) asked him in detail: about the open source in general, and specifically about MobX, and about conferences.



Eugene: 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 became involved in the world of open-source, from that moment 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 we want to share at conferences, and I speak myself or encourage colleagues to speak. On the other hand, in frequent visits to conferences, the opposite is true: you discover something that can be useful for us, then we study it and include it in our stack.



Eugene: In the description of your Twitter mentioned " OSS- Evangelism." 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 a company makes a product more or less competitive, which is made on the basis of its technologies - and not these technologies on their own. And everyone benefits from collaboration, it allows the development as a whole to accelerate.



Yevgeny: 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.



At 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 this may be of interest to someone else, but I don’t see any problem in this. 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.



Eugene: 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 remains the possibility of a fork.



Evgeniy: 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 start 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, be it 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 reproducing the bug,” and the sensation “Well, then I don’t have time to help solve your problem.” After all, a person is probably paid for the work 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 for 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 such an 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 is it worth sharing 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 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 are actively using the library in your daily work, you will stumble upon patterns or common problems that I have 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 wouldn’t like 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.



Eugene: Development is changing, much is becoming 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 by Facebook and Microsoft - how much they are 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 like CodeSandbox 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 developing 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.



Eugene: 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 someone from 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 abstraction layer it offers.



But then we discovered that we had a performance problem, it turned out that it was quite expensive to fully 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 worked very quickly, and so it wasn’t necessary to “render 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 many details. For example, you would have to write selectors for the data that you are rendering.



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 can you 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 way. 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. « ». . , « Flux», - . .



: MobX , . , ?



— ! « MobX Lite». , MobX, 200 . , . . , . MobX. , — API, . , , API . , MobX 5 MobX 4 , Proxy .



: Proxy. - , . ?



— , , Proxy - , . . Chrome 8, , .



: . , jQuery -, , - . Redux MobX. What changed?



— , . , jQuery- . , JQuery , . - . jQuery React , , , . . , state definitions .

, , React UI. . , - UI .



: ? , ?



— , . , immutable values. , , immer — , immutable states JS. , state management. , , , . , , , GraphQL, , . …



: -, MobX?



— , , , . . : , to-do list . , , todo. , - , todo- , . . , .



: . . , - . , ?



— , . : , . — , , . , . Docker, . , , , . — « ». -, — , , . , , . — , , - . - -, , . , , . : -, , . .



: ( , ) , , Medium YouTube. ?



— , , — . , . — . , , , … . . , . . , . , , . , , , , - . , . , (, , ) — . , , . .



: . — ?



— . , MobX. , . MobX.

HolyJS 2018 Moscow , 24-25 . state management. .