“It's time to get out of the frontend”: Andrei Sitnik about the stagnation of the community, the open source and not only

Andrei Sitnik from Evil Martians is one of the most famous Russian names in the frontend: his projects PostCSS and Autoprefixer have GitHub-stars for tens of thousands. But since Andrei lives in New York and travels around the planet, it can be seldom caught in Russia.

In May, he will be in St. Petersburg at the HolyJS conference, and about this he was asked in detail by the participants of the HolyJS program committee Dmitry Dmitry Makhnev Makhnev and Maxim Yuzva . Why does Andrew think that the front end is stagnating, and the code of our projects is too swollen? What are the differences of IT-communities from different countries? How to learn English and why it is less important than it seems? Where did the Logux project, presented at HolyJS, disappear in 2016?

About current projects

Dmitry: First, tell us briefly about yourself - where you are and what you do.
')
Andrei: My name is Andrei Sitnik, I live in New York, but I try to travel a lot. Basically, I know from open source and performances - as it is now popular to say, “media brand in the field of IT”. I can not say that I really deserved it, but luck helped me.

In addition to the open source, I promote linguistic diversity in a @LinguoPunk twitter account, wikipedia in @LostInWiki and the struggle for sex positivism.

Dmitry: What projects are you working on now?

Andrei: There are several support projects in open source, the most famous are PostCSS and Autoprefixer. Perhaps PostCSS is now slightly activated: Alexey Bondarenko made a very large API update, so there could be a big release soon.

And Autoprefixer is on supporting releases. The only thing out there that we are now actively sawing is Grid support for IE 10-11, but it is going badly because of the resistance of Rachel Andrew, who actively promoted the Grid. She is a very famous person, and she doesn’t like any tools that automatically do something in CSS — such a religious struggle. And because of its opposition, this feature, unfortunately, has not particularly spread.

Dmitry: How can Rachel stop you from making a tool?

Andrew: The tool does not interfere with doing, it works. But open source is not about programming, open source is about society and socialization. If no one uses your product or speaks about it in media, there is no motivation to do it. As a result, it hits the motivation of the developers who did it and continue to do so. Few people talk about their heroism, but they are still great and real heroes.

In fact, we implemented everything that we wanted and could, there is even a crazy idea with the support of auto-grids, which can not be done at all in this spec, but the guys came up with how to do it with the cunning combination of magic selectors.

In general, PostCSS and Autoprefixer are on support, features are rarely added and mostly small, but Logux is actively developing. And this year I want to devote myself more to articles than to a specific open source project.

Dmitry: You did a lot of hard shots, but you couldn't hear much about Logux after the presentation at HolyJS in 2016 - what's wrong with it?

Andrei: This is a good question, because it raises a very interesting topic. The fact is that there are different ways of software distribution.

Using open source is not some kind of rational decision making. Software development is best described by the fashion industry. The technical choice is, first of all, fashion, hyip and similar things.

Therefore, there are several strategies to promote new solutions. For example, when something appears, it still does not work, but due to the fear of missing something huge, people quickly get on the hype train, start sawing and bring it to working condition.

In an amicable way, more than half of popular open source projects were simply disgusting. Rather, the HYIP around them is completely at odds with the quality of the code and the level of support from the organizers. But since a lot of people immediately sat down on the hype train, the project survived and continued to exist.

For example, Babel plugins do not have asynchrony. You can't do asynchronous functions inside plugins, and this is a terrible problem, I don’t know how it got into production, because it terribly restricts the huge markets of Babel. But it was written this way, such is his architecture. Babel has a lot of fun.

This is one way of spreading: to tell "everything is gone, if you don’t learn by tomorrow - everything, the market will need people with three years of experience in this technology." But there is another way. For example, in React they did it differently: at first they “cooked” in their environment, and then they presented a project that was more or less ready for production. Of course, an open question is how exactly he was ready for production, but it is clear that the frameworks are not 100% ready.

Logux is a client / server communication system. The idea of ​​queries, whether GraphQL or Ajax, is not intended for an unstable Internet and works in such conditions just disgusting - this is a known problem of most sites. Logux is a different approach, and, as a result, a technically very large solution. The idea is not new, there are many such solutions, and they failed, and it worried me. Even GraphQL was produced with a terrible squeak, and it had to teach something.

My opinion is that hype train does not work for this type of task. We can not make a decision to get it all up and go. When we deliver the solution immediately for the frontend and backend, attempts to take it all to the hype train lead to community opposition.

Therefore, I decided that with Logux we would not do so, but let us go carefully and slowly, preparing it inside the project. All this year or two, we boiled Logux inside the Amplifier , used it on different projects and watched how backeders react. I tried to explain, show, and now Dima Salakhutdinov will go to the Ruby-konfu to tell about Logux, so that we can see how they react, how we promote it to backend-vendors. Because to tell them what we are saying to the front-tenders in the spirit of “this is hyip” is wrong, it does not work there.

Dmitry: Why does not work?

Andrei: Backend switched to a system of either stagnation or support: in recent years there has been almost no development. And as a result, they have other priorities: when you do not have new frameworks every six months, this affects you. They are somewhere in Rust or Go, but Ruby - what's new there? As a result, people are focused on something else. Of course, I greatly simplify, and backend backend strife.

I want to correctly distribute this on the backend and on the client, I want to come up with a ready-made solution that will really work, which we really checked on the production. In 2017-2018, we already had working version 0.2, but there was no scalability. We had an idea how to scale, and for PR this would be enough, but in fact it is wrong.

Instead, we deal with the problems of real, not theoretical scalability, when you have a strange buggy and you don’t know at what point. And in Logux, we seriously pumped the system: for example, we can easily raise a server on several servers at once, and increase their number by one command.

It is meaningless to do, as long as you do not have real analytics. Because without it you will not understand where you plug. You can scale as much as you like, but it turns out that there is some one place that does not scale. Therefore, we have a code that is really ready for scaling, and a huge number of analytics: how and how much time is spent, how many requests come in, you can see where the plug-in begins. For example, by the number of operations per second or by the number of users, and all this on the server is solved differently.

Dmitry: It sounds quite interesting. And, as I understand it, are the plans big enough for the near future?

Andrei: Yes, we have already finished our plans for practical use, I will now release 0.3 and write docks, which are not enough for mass use. And the code is good.

About Nano ID and fast internet

Dmitry: You touched on the topic of Internet connection: everyone is accustomed to the fact that our Internet is stable and good, but in fact everything is completely different. And here it is impossible not to pay attention to the size of bundles and other things, remember your project Nano ID. Why does it bother you so much? Let's start with the size.

Andrei: Doesn't it seem to me that this is “saving on matches” when everyone has a normal internet connection? Good question.

Nano ID is a 141 byte library that generates an ID. When we reduced it from 200 bytes, it didn’t have a practical sense, but was a “political manifesto” that it was time to think about it.

JS size is an interesting problem. First, the compilers do not solve it, but on the contrary: most bandlers do not properly combine, significantly increase the size or use it inefficiently.

And the fact that the speed of Internet connections is growing is true, and at the same time not. As soon as the Internet accelerates, countries declare themselves where everything is very bad with it - for example, in Central Africa. And also there are new markets - for example, mobile. And there is also a tricky problem: the download speed is growing, but at the same time sites do not load faster. You can check on any LTE, which should quickly open everything, if you divide the page size of the site by the speed of the network.

The problem is that the actual download speed of the site depends on other parameters. For example, on the number of round trips . The fact is that between requests and the first bytes inevitably passes some time when the signal comes and returns. This time is very long, up to 500 ms . Firstly, due to the speed of light, and secondly, the equipment is slow. And if your files upload each other in turn, the site will slow down.

Fortunately, we discovered this problem for a long time and learned how to solve it. But she is not the only one. Recently, we faced another: it turns out, the problem is not on the Internet, but in the compilation speed. The fact is that 1 megabyte of images is easy to download and display, and 1 megabyte of JavaScript is 2-3 times harder for the browser, because it needs to be compiled. And the number of JS is growing. And this is an objective problem of low speed sites.

You can slyly approach the issue of studying the site by the method of entropy . We have a website that weighs 1 MB. There is the concept of "amount of information." A megabyte is not just the number of lines, this is how much sense there is in this code. And how complicated should the site be to require 1 MB? Is it really so different users on the site that to cover them should be such a volume of code?

In fact, such cases units. So much is needed in the Linux kernel, but not on sites. And, therefore, we have a lot of extra code.

The meaning of Nano ID-movement is not to save every byte, but to think: “what do I have in the bundle? What the hell have 1 MB in there? I cannot have tasks where such a volume would be required. ” On most sites, 75% of the code is not used. Nano ID is a movement against the fact that we send such code to users.

When we begin to think why so much code is not used, we understand: if it’s not about a huge team, don’t write one megabyte of code manually. This is more than the conventional “War and Peace”, which can be written for years, and at the same time it is much more difficult to write code due to interdependencies.

And most often this volume - the library. The famous story from Moment.js: you plug it in, and because of the way webpack works, it loads every language onto your site . And there are many similar cases.

At one time I needed to generate a unique ID in Logux, I took the library, and then I found out that it weighs 100K. Why do I need so much to generate a random ID?

Such dimensions are most often due to the fact that library developers write them incorrectly. Therefore, the main idea is to use Size Limit so that library developers control the size of their projects. Like ESLint, only for library size. And we immediately see that a huge number of libraries can be halved.

Dmitry: Do not you think that the question is not only in the size of the code, but also in the approaches of the development tools? If I export my library with an object instead of separate functions, and I don’t connect Google Closure Compiler at my own risk, then no one will cut me. Maybe the problem is deeper than just writing code?

Andrei: I would not say that the problem of treeshaking is really urgent, because it does not work in JavaScript. Everyone thinks that trishikeking will solve the problem, but no. The most common problem is something else: what the package is doing. Any Rollup is used , the entire project is packed into one file, and it turns out that dependencies are being packed there, for example. This is a huge problem, and with the help of Size Limit we have greatly reduced one library, because we removed the dependencies, which in each project will most likely be repeated.

The second problem is that they randomly use some API from Node.js. For example, there was the choo.js library - the “compact JS framework”, where they checked incoming arguments with the help of the Node.js module assert. And it loads almost 4 KB. And for the sake of a tiny library, we will ship an additional 4K.

And such problems are much more common than what treeshaking is used for.

The best recommendation for trishishing is to split the files in the assembly, let there be separate functions in separate files. But most often the problem is different. Just run Size Limit with the --why option and see the huge amount of garbage that webpack embeds when using your module.

Maxim: Then it turns out that using webpack for assembly is moveton?

Andrei: It depends on what to talk about. If you make a library, most likely, webpack is not needed. You have less than 1% of users who want a separate file, and it’s better to force them to use webpack, because they insert your library as a link to another file, and the site will slow down.

But what users collect your libraries, than people collect sites - in fact, without a difference. We are accustomed to the front end that if you use the library incorrectly, everything will be bad, if you don’t switch from webpack to Parcel today, then goodbye, you’re a bad developer. No, frankly, do not care about tools.

There are enough problems in the webpack, this is a bad bandler, but if it works for you, work on. I saw projects where he helps to solve problems, despite the fact that this is one of the most abandoned projects. For example, the css-loader there is supported by one person from Russia. This is a real hero, but if he is busy, everything, no one will fix your problem, but there are many problems.

If I say that you have to stop using the webpack, then just because there are better collectors. But, again, try on a new project, but do not change it on the old one. We have a lot of jerking on frameworks and tools, although in fact they don’t have any effect on how we create code.

Why hype train and "aristocrats" - bad

Maxim: You are now talking about leaving the webpack in favor of steeper bandlers. Maybe there is a problem that such recommendations from people of your level create hyip? Instead of recommending that you use something new, maybe you just say “let's push it and make webpack great again”?

Andrei: Good question. On the one hand, there really is a problem when such comments are perceived without an understanding of the context. But there is another problem: I fear stagnation.

The point is that the front end stagnates. Until the end of centuries, we will live under the aegis of React - no new framework will be able to shift it, because the critical mass has been gathered. It is like in backend languages: old languages ​​are not defeated by new ones, because there is no critical mass, conditions for transition, except in some narrow problems. Now it has begun in the frontend.

The stagnation of frameworks and build systems means a very big problem: the stagnation of the people who will teach us how to live. We see it right now, because the frontend stars are all the same, and, as a result, the new ones will not come. And the stagnation of people means the stagnation of ideas. We see this for now by indirect parameters, while there is enough inertia for new ideas to flow. But you come to the conference, but all are the same, and it really depresses me. In my opinion, it's time to get out of the world of the frontend.

It's like Java - a huge market where everything is good, but there is nothing new. How to cope with this problem - I do not know. But this is one of the reasons why I drown for small projects and constantly advise them.

Honestly, the webpack is very difficult to rewrite, and its creator doesn't care about the quality of the DX, he writes it for himself and communicates little with the users. In addition, there are architectural problems, because of which it is really difficult to rewrite it. There are people in the webpack team who honestly try to do well, but there are difficulties that prevent them from doing so.

There is a community, and where to move it - to stabilize and append old tools or use new ones - I have no answer.

In an ideal world, we will not create the feeling that using old tools is bad, but at the same time we will use new ones in new projects. And how to create it, I do not know. Indeed, the wrong recommendations are made, and people are starting to persecute others for using the “wrong” things.

Maxim: In your opinion, is it possible that big corporations like Microsoft and Facebook will start buying major open source projects like webpack and Babel?

Andrew: Buy - no. It is not profitable for them, as long as the community brings new ideas, and this is a real business benefit. They control them, it works differently.

Unfortunately, this problem has already arisen in the frontend, but it is not expressed in the fact that the company has bought something, but in the fact that we have some stars that do not change, they will always be at the top and say how we will write code. They know each other, it is easier for them to approach each other and ask them to do something. Therefore, their opinion is more important than the opinion of other people. This is the classic system of creating elites in society.

Without a system of social elevators, this leads to the fact that the elites are conserved, ideas become old. And the problem is not that companies control them, but that we have a very small group of people who decide which front-end we will have. The way the browser works is completely determined by a very small group of people working on Chrome. If Chrome continues to grow in popularity, there will be a big problem.

The main problem is the creation of aristocracy, not corporate control. And this is one of the things because of which I believe that it is time to bring down from the frontend: the aristocracy has already formed, and we can do nothing. For example, in the Western market, it does not matter how cool you are and what a great idea you are promoting is not likely to break through. Older stars have an order of magnitude more subscribers, media influence and their ideas will be much more important than yours.

Dmitry: "You will not break through" from the point of view of open-source and report of some global ideas, and not from the point of view of working in a large company?

Andrei: Yes. Listen, you say that working in a big company is a blessing. Of course not, this is [obscene] galleys. What are we talking about?

Dmitry: I think there may be different feelings. Someone feels that this may change the world in this way, because along with the business there is some kind of support if we move a little away from the development.

Andrew: The fact is that the business is different. I believe that really good companies are, for example, 37signals and DHH .

The funny thing is that now I look at the front-end with a very unpleasant feeling that we really lost a lot because we made the wrong decisions. It was very cool at the beginning, when there were a lot of ideas, we constantly accepted them, went somewhere. But in the end, the whole idea of ​​startups that grow instantly on the investments of large companies turned out to be terrible.

These companies become monopolists, sell our data and make horrible decisions. I don’t really like what Valley does with IT.

DHH has a good idea that a startup should grow naturally, without large money injections: as soon as big money starts to flow, completely different conditions arise, and they have a bad effect not only on society, but also on the whole development of our movement. I absolutely do not like what happens with large corporations.

Dmitry: If you go back to the social elevators. In your opinion, if you still get together and come up with something cool, is it possible to seriously engage in open-source without the support of the elites, or is it completely blocked?

Andrei: There is a good example with Vue.js. This is an awesome project, but it will never defeat React, although it has decided everything that we criticize React for. It doesn't matter what project you write: as long as there is a monopoly, the user will simply have no reason to switch.

We so believe in the mantra "I should write just as they write everything, in no case should not depart from the mainstream" that this mantra holds you back even if you offer a product 20-30% better. The exception is unoccupied markets. For example, Yandex won in Russia, because Google was not.

Google can not be shifted, no matter how good your search engine is. It can only be defeated either in new markets, like some Instagram or Facebook, or in new language markets, for example, Yandex in Russia. The same with frameworks. The only reason why Vue normally exists: he won in the market of China and others, where React had not yet come.

On the other hand, Vue was started as a project of its own, and then corporations came and joined. I do not think it is shameful to ask the company for money, and companies are happy to give it if you ask correctly. Therefore, finding support from companies is normal, it really works, this is a win / win situation. Companies very rarely intervene and create some problems for open source.

The problems here are marketing, because there is a very small group of elites, which defines how web development is conducted, and it’s very difficult to offer something new there, because you won’t gain as many readers, as many media influences as they, if not enter a completely new market.

Is it worth it to go to open source

Dmitry: The question arises whether to do this.

Andrei: This is a good question. Immediately I say: no, do not do, do not create new open-source projects.

The main reason why they are created is advertising: make open-source, and you will become as famous as the stars. But in reality it is a “survivor’s mistake”. There is Dan Abramov in the West, I am in Russia, and in fact, under this tip of the iceberg there are hundreds of people who made the projects no worse, but nobody knows.

In a good way, even if you make a perfect project, with a 99 percent chance you will fail. For example, I once did Size Limit, and we just decided to write a good article first , where we will promote it, and during this time another dude did a project, and everyone told about it, and Size Limit lost.

Most likely, you will also end up: someone will write a project, maybe later, it may be worse, but he is friends with famous people, and famous people will immediately write about him, that's all. It looks like an open source, it is actually a graveyard of people who make cool projects and don't get media influences. All the media influence merges into a very small group of people.

It's like startups. Startups are not really "a wonderful situation when people create Google", but a situation "in order for Google to appear, you need 99% of people to ruin their lives."

Therefore, if you want to be happy and famous, do not make open source. If you want to be hired, do not do the open source. Because there are much better ways to get these things: speak at meetings, correct documentation in already large projects, write articles.

If you come to the company, and you have some kind of pull request in Babel, it looks much better than if you have a project with ten stars. And this, most likely, will be so - no matter how well you write it.

If you just want to influence, it is more important to write basic articles where you chew some basic things from an unusual point of view. It really works well, media people will repost it, because they say the same thing. New ideas will not repost, because they also do not understand them.

There is only reason to start open source - if you want to change something in this world. For example, PostCSS started because I wanted more CSS tools. Autoprefixer was because I wanted to kill Compass, but then, when Compass was killed, it advanced, because I wanted American programmers to stop writing sites only for American browsers, ignoring Opera and so on.

If you have such tasks, the most funny thing is, the articles do not work. All these articles about Accessibility, about using buttons instead of links, if there is no URL, do not work at all, because they don’t remember them. What really works is the automatic tools that check all this. There were a million reports on how to write prefixes, and none of them worked until Autoprefixer appeared.

If you want to write open source, have a good clear goal, what you want to change in this society, and this goal will keep you afloat when you will have to wait for failure, when people will not use your developments, when the stars ignore you, that they do not personally know you.

Dmitry: How strong should this swing be? For example, I want, God forgive me, add types in JavaScript, it is clear that this is already overkill. Where is the edge on which to stay?

Andrei: If you are satisfied that the world will change, and no one will know about you, then this is a good point to start doing the open source. — .

: . , , , .

: , , , , , . , . , .

- , … PostCSS , , . , , . - -, , , , , .

: ?

: , , .

: , , , ?

: , , , , - , , , , , . : « Open Collective , , ».

, . . . , , , . « , , . Open Collective, , . , , , ».

, Babel webpack. : « , . issue, Open Collective , ». , . , — . , , . , .

, , . -, issue, , maintainer, , , , . , issue, : «, , , . . , , ?» . , «», . , , .

: - , - ?

: . . , JavaScript , . , Ruby , JavaScript. . - , . , , JavaScript.

: , pet project . , , : , , -, , . , , ?

: - . , . , , .

« ». . , . , . — , , maintainer , , - .

, . , , . , , , issue, - , , , .

, ? . , , , . , , .

: , ?

: , . . . , .

: , , . , . , -, , . , , .

, . , 10, , , , , .

: , , ? , - : « , ».

: , , , . , . , . «» — , , — . , , - PostCSS. .

, - , . - : , , , , , .

— . , , , , , , . , . — , . , .

,

: , PostCSS . , ?

: , . - . , , , - : , .

-, , YouTube. , . , . , , .

: , , , . . , , . , , , , . , , . .

: , , . ? ?

: ? . «». , — , , . , , .

, — , , . , . - QR-. , QR- , ? . , , .

, . , — , , . . , : - , . , , .

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

— , .

, .

— .

, : . , , , - . Google - , , , .

, , , , , . — Twitter, , ( ), . , , . , , , , 150-300 .

, , , .

: - - , — ?

: , . — . , , . , -, , , , .

. , , : « , ». — , . , , XVIII-XIX . . , .

, , -. , , , , , , . , , . , , , . , — .

, , — , , . , . : - , .

, , , , , . , . .

, , , — , , .

: , .

: , . -, . , , , . , , . , , — , .

— , . , , . .

small talk — , , , , -.

. — , , . , , , , .

— , 5-10 , . , .

: , ?

: , , — . , , — . , « », . , . , — . , , . , , .

— , , , . , , . , , , . «», .

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

. , . .

- - , , , , : « ?». «» , . , : , . , , , .

: ( ), , , .

Dmitry: If we talk about conferences, what factor for participation as a speaker is decisive for you?

Andrew: For me the decisive factor is the availability of conferences. Although sometimes, if my path goes through some countries, I agree to conferences that are not very accessible to people, just to pump the report.

I think there is a big problem that the prices at conferences are greatly overstated. I understand that conferences need to earn money, there are no problems with this, but there are some JSConf that take fabulous $ 500 and, frankly, they spend it on those things you can save on. For example, for lunches, the most powerful afterparty, although I, frankly, would rather have a bad beer drank, but that there were interesting people.

And the huge prices lead to the fact that it is not interesting for the speakers to communicate with the audience, it is sometimes difficult to support the topic, because at the conference only employees of large companies, the same creator of the best JS CRDT implementation, Viktor Grishchenko could not come because it was a very expensive ticket. Ways to save a lot, and they need to apply, expensive tickets - wrong. The conference should be accessible.

I often agree to go on a small mitap, just so everyone has normal access to networking. And on many meetings, dialogues do better than at conferences with a high ticket price. Here is my approach.

Dmitry: Without which, a conference cannot be good? It is already clear about networking, accessibility, and what else?

Andrei: Well, I, as a speaker, really appreciate when there is a timer in front of the stage. In this regard, HolyJS has everything very professional, I like the organization of performances. In general, networking is the key thing, people go to conferences not for knowledge, it's easier to read the article than a report, but for the feeling of belonging to a community.

Community is the most important thing that happens at conferences. The feeling that you talk, and something has changed in you, you have learned something. There is a good idea that in our society there is a lack of understanding why. We go to conferences to get an understanding of why we all do it at all. And a good conference surely solves this issue.

Dmitry: You said “not for knowledge”, this is a very debatable question. Would you go to a conference where a collection of people with very basic topics, but from very different communities?

Andrei: Yes, of course, that would be very fun.

Dmitry: And it would be more interesting than a conference, where are serious and powerful reports?

Andrei: I think that both approaches are good, and there is no problem here.

Dmitry: Probably the final question. What do you expect from HolyJS?

Andrei: Good tusich! In 2016 I was directly credited, one of the best in my life, and then everything was very well organized.

Dmitry: What would you recommend to do this time to make it even better? Wishing for a party?

Andrei: I would try to get organized with local mitapami. We have a lot of local meetings, and it’s pretty cool when they have the opportunity to do something themselves - there are a lot of initiative people, we need to give them the opportunity. And it would be cool if the organizers of all local meetings or their key speakers were given a free ticket or some kind of help, that would be great.

At the nearest HolyJS (St. Petersburg, May 24-25), Andrey will tell more about the promotion of open-source projects. And besides him, there will be many other significant figures of JS-open source: from Ryan Dahl (Node.js, Deno) to Michelle Weststrate (MobX, Immer). All the details about their topics of reports are on the website , tickets can be purchased there, and gradually they become more expensive.