Andrey Sitnik von
Evil Martians ist einer der bekanntesten russischen Namen im Frontend: Seine
PostCSS- und
AutoPrefixer- Projekte haben Zehntausende von GitHub-Stars. Aber da Andrei in New York lebt und um den ganzen Planeten reist, kann man ihn in Russland selten finden.
Im Mai wird er auf der HolyJS-Konferenz in St. Petersburg sein, und
Dmitry Dmitry Makhnev Makhnev und
Maxim Yuzva haben ihn im HolyJS-Programmkomitee ausführlich befragt. Warum glaubt Andrei, dass das Frontend stagniert und der Code unserer Projekte zu stark angeschwollen ist? Was sind die Unterschiede zwischen IT-Communities in verschiedenen Ländern? Wie man Englisch lernt und warum ist es weniger wichtig als es scheint? Wohin ging das auf der HolyJS vorgestellte Logux-Projekt im Jahr 2016?
Über aktuelle Projekte
Dmitry: Erzählen Sie uns zunächst kurz von sich - wo sind Sie und was machen Sie?
Andrey: Mein Name ist Andrey Sitnik, ich lebe in New York, aber ich versuche viel zu reisen. Meistens kennen sie mich durch Open Source und Performances - wie es heute populär ist, „eine Medienmarke im Bereich IT“ zu sagen. Ich kann nicht sagen, dass ich es wirklich verdient habe, aber das Glück hat zu mir beigetragen.
Neben Open Source fördere ich auch die sprachliche Vielfalt auf Twitter
@LinguoPunk , Wikipedia auf
@LostInWiki und den Kampf für
Sexualpositivismus .
Dmitry: An welchen Projekten arbeiten Sie gerade?
Andrew: In Open Source gibt es mehrere Support-Projekte, die bekanntesten sind PostCSS und Autoprefixer. Vielleicht wird PostCSS jetzt leicht aktiviert: Alexey Bondarenko
hat ein sehr großes Update an der API vorgenommen, sodass es möglicherweise bald eine große Veröffentlichung geben wird.
Und Autoprefixer unterstützt Releases. Das einzige, was wir jetzt aktiv sägen, ist die Grid-Unterstützung für IE 10-11, aber es läuft schlecht, weil Rachel Andrew
Widerstand geleistet hat, die Grid aktiv beworben hat. Sie ist eine sehr berühmte Person und sie mag keine Tools, die automatisch etwas in CSS tun - so einen religiösen Kampf. Und aufgrund seiner Opposition hat sich dieses Merkmal leider nicht besonders verbreitet.
Dmitry: Wie kann Rachel Sie davon abhalten, ein Instrument zu bauen?
Andrew: Das Tool stört nichts, es funktioniert. Bei Open Source geht es jedoch nicht um Programmierung, sondern um Gesellschaft und Sozialisation. Wenn niemand Ihr Produkt verwendet oder über Medien spricht, gibt es keine Motivation, dies zu tun. Infolgedessen trifft es die Motivation der Entwickler, die es getan haben und dies auch weiterhin tun. Nur wenige Menschen sprechen über ihren Heldentum, aber sie sind immer noch großartige Gefährten und echte Helden.
Tatsächlich haben wir alles realisiert, was wir wollten und konnten. Es gibt sogar eine verrückte Idee mit der Unterstützung von Auto-Grids, die mit dieser Spezifikation im Allgemeinen nicht möglich ist, aber die Jungs haben herausgefunden, wie dies mit einer listigen Kombination von Selektor-Magie zu tun ist.
Im Allgemeinen werden PostCSS und Autoprefixer unterstützt, es werden selten und meistens kleine Funktionen hinzugefügt, aber Logux entwickelt sich aktiv weiter. Und dieses Jahr möchte ich mich mehr Artikeln als einem bestimmten Open Source-Projekt widmen.
Dmitry: Sie haben viel geschossen, aber über Logux nach der
Präsentation bei HolyJS im Jahr 2016 hören Sie nicht wirklich, was mit ihm passiert ist?
Andrew: Das ist eine gute Frage, weil sie ein sehr interessantes Thema aufwirft. Tatsache ist, dass es verschiedene Möglichkeiten gibt, Software zu verteilen.
Die Verwendung von Open Source ist keine rationale Entscheidungsfindung. Softwareentwicklung wird am besten von der Modebranche beschrieben. Die technische Wahl ist vor allem Mode, Hype und ähnliches.
Daher gibt es verschiedene Strategien zur Förderung neuer Lösungen. Wenn zum Beispiel etwas erscheint, funktioniert es immer noch nicht so, wie es sollte, aber aus Angst, etwas Großes zu verpassen, steigen die Leute schnell in einen Hype-Zug, beginnen zu sägen und bringen es in einen funktionierenden Zustand.
In guter Weise wurde mehr als die Hälfte der beliebten Open-Source-Projekte nur ekelhaft geschrieben. Vielmehr widerspricht der Hype um sie völlig der Qualität des Codes und dem Grad der Unterstützung durch die Organisatoren. Aber da viele Leute sofort im Hype-Zug saßen, überlebte das Projekt und bestand weiter.
Beispielsweise haben Babel-Plugins keine Asynchronität. Sie können keine asynchronen Funktionen in Plugins ausführen, und dies ist ein schreckliches Problem. Ich weiß nicht, wie es in die Produktion kam, da es die riesigen Babel-Anwendungsmärkte schrecklich einschränkt. Aber so wurde er geschrieben, so ist seine Architektur. Babel hat viel Spaß.
Dies ist eine Möglichkeit, sich zu verbreiten: zu sagen: "Alles ist weg, wenn Sie nicht bis morgen lernen - alles, der Markt braucht Menschen mit dreijähriger Erfahrung in dieser Technologie." Aber es gibt noch einen anderen Weg. In React haben sie es beispielsweise anders gemacht: Zuerst haben sie in ihrer Umgebung „gekocht“ und dann ein Projekt vorgestellt, das mehr oder weniger produktionsbereit war. Die offene Frage ist natürlich, wie genau er für die Produktion bereit war, aber es ist klar, dass Frameworks nicht zu 100% vorbereitet sind.
Logux ist ein Client / Server-Kommunikationssystem. Die Idee von Abfragen, ob GraphQL oder Ajax, ist nicht für instabiles Internet gedacht und funktioniert unter solchen Bedingungen nur ekelhaft - dies ist ein bekanntes Problem der meisten Websites. Logux ist ein anderer Ansatz und daher technisch eine sehr große Lösung. Die Idee ist nicht neu, es gibt viele solcher Lösungen, und sie sind gescheitert, und es hat mich beunruhigt. Sogar GraphQL wurde mit einem schrecklichen Knarren erstellt, und das hätte etwas lehren sollen.
Meiner Meinung nach funktioniert der Hype-Zug für diese Art von Aufgabe nicht. Wir können keine Entscheidung treffen, damit alle darauf stoßen und alles geht. Wenn wir die Lösung sofort für das Frontend und das Backend liefern, führen Versuche, alles im Hype-Zug herauszunehmen, zu einer Konfrontation zwischen den Communities.
Daher habe ich beschlossen, dass wir dies mit Logux nicht tun werden, aber wir werden vorsichtig und langsam vorgehen und es innerhalb des Projekts vorbereiten. In den ein oder anderen Jahren haben wir Logux in
Amplifer gekocht, es für verschiedene Projekte verwendet und beobachtet, wie Backders reagieren. Ich habe versucht zu erklären, zu zeigen, und jetzt wird Dima Salakhutdinov zum Ruby-Confu gehen, um über Logux zu
sprechen , damit wir sehen, wie sie reagieren, wie wir es dem Backend geben werden. Weil es falsch ist, ihnen zu sagen, was wir den Front-End-Anbietern im Sinne von „It's Hype“ sagen, funktioniert es dort nicht.
Dmitry: Warum funktioniert es nicht?
Andrew: Das Backend hat auf ein System der Stagnation oder Unterstützung umgestellt: In den letzten Jahren gab es praktisch keine Entwicklung. Infolgedessen haben sie unterschiedliche Prioritäten: Wenn Sie nicht alle sechs Monate neue Frameworks haben, wirkt sich dies auf Sie aus. Sie sind irgendwo in Rust oder Go, aber Ruby - was ist neu? Infolgedessen konzentrieren sich die Menschen auf den anderen. Natürlich vereinfache ich das stark und das Backend-Backend ist anders.
Ich möchte dies korrekt im Backend und auf dem Client verteilen. Ich möchte eine vorgefertigte Lösung finden, die wirklich funktioniert und die wir wirklich in der Produktion getestet haben. In den Jahren 2017-2018 hatten wir bereits eine funktionierende Version von 0.2, aber es gab keine Skalierbarkeit. Wir hatten eine Idee, wie man skaliert, und für PR wäre es genug, aber tatsächlich ist es falsch.
Stattdessen beschäftigen wir uns eher mit den Problemen der realen als der theoretischen Skalierbarkeit, wenn dies für Sie unverständlich ist und Sie nicht wissen, zu welchem Zeitpunkt. Und in Logux haben wir das System ernsthaft gepumpt: Zum Beispiel können wir den Server problemlos auf mehreren Servern gleichzeitig und mit einem Befehl erhöhen, um deren Anzahl zu erhöhen.
Es ist sinnlos, dies zu tun, bis Sie echte Analysen haben. Denn ohne sie werden Sie nicht verstehen, woher Sie den Stecker haben. Sie können so viel skalieren, wie Sie möchten, aber es stellt sich heraus, dass es einen Ort gibt, der nicht skaliert. Daher haben wir einen Code, der wirklich skalierbar ist, und eine Vielzahl von Analysen: Wie und wie viel Zeit aufgewendet wird, wie viele Anfragen eingehen, können Sie sehen, wo der Plug beginnt. Zum Beispiel durch die Anzahl der Vorgänge pro Sekunde oder durch die Anzahl der Benutzer, und all dies auf dem Server wird unterschiedlich gelöst.
Dmitry: Das klingt interessant genug. Und wie ich es verstehe, sind die Pläne groß genug für die nahe Zukunft?
Andrei: Ja, wir haben die Pläne für die praktische Anwendung bereits abgeschlossen. Ich werde jetzt 0.3 veröffentlichen und Docks schreiben, die für die Massenanwendung nicht ausreichen. Und der Code ist gut.
Über Nano ID und Fast Internet
Dmitry: Sie haben das Thema Internetverbindung angesprochen: Jeder ist daran gewöhnt, dass unser Internet stabil und gut ist, aber tatsächlich ist alles völlig falsch. Und hier ist es unmöglich, nicht auf die Größe von Bundles und anderen Dingen zu achten. Denken Sie an Ihre Projekt-Nano-ID. Warum stört es dich so sehr? Beginnen wir mit der Größe.
Andrei: Scheint es mir nicht so, als würde es "bei Spielen sparen", wenn jeder ein normales Internet hat? Gute Frage.
Nano ID ist eine 141-Byte-Bibliothek, die IDs generiert. Als wir es von 200 Bytes reduzierten, ergab dies keinen praktischen Sinn, sondern war ein "politisches Manifest", dass es Zeit war, darüber nachzudenken.
JS-Größe ist ein interessantes Thema. Erstens lösen Compiler das Problem nicht, aber umgekehrt: Die meisten Bundler kombinieren es falsch, erhöhen die Größe erheblich oder verwenden es ineffizient.
Und die Tatsache, dass die Geschwindigkeit von Internetverbindungen zunimmt, ist wahr und gleichzeitig nicht. Sobald sich das Internet beschleunigt, erklären sich die Länder zu einem Ort, an dem alles sehr schlecht ist - zum Beispiel in Zentralafrika. Und es entstehen auch neue Märkte - zum Beispiel mobile. Und es gibt ein kniffliges Problem: Die Download-Geschwindigkeit steigt, aber Websites werden nicht schneller geladen. Sie können einige LTE überprüfen, die schnell alles öffnen sollten, wenn Sie die Seitengröße der Site durch die Netzwerkgeschwindigkeit teilen.
Das Problem ist, dass die tatsächliche Ladegeschwindigkeit des Standorts von anderen Parametern abhängt. Zum Beispiel die
Anzahl der Hin- und Rückfahrten . Tatsache ist, dass zwischen Anforderungen und den ersten Bytes unweigerlich einige Zeit vergeht, wenn das Signal eintrifft und zurückkehrt. Diese Zeit ist sehr lang, bis zu
500 ms . Erstens ist die Ausrüstung aufgrund der Lichtgeschwindigkeit langsam. Und wenn sich Ihre Dateien gegenseitig laden, wird die Site langsamer.
Glücklicherweise haben wir dieses Problem vor langer Zeit entdeckt und gelernt, es zu lösen. Aber sie ist nicht die einzige. Kürzlich sind wir auf ein anderes gestoßen: Es stellt sich heraus, dass das Problem nicht im Internet liegt, sondern in der Kompilierungsgeschwindigkeit. Tatsache ist, dass 1 Megabyte Bilder einfach heruntergeladen und angezeigt werden kann und 1 Megabyte JavaScript für den Browser 2-3 mal schwerer ist, da es kompiliert werden muss. Und die Anzahl der JS wächst. Und dies ist ein objektives Problem von Standorten mit niedriger Geschwindigkeit.
Sie können sich der Frage des Studierens der Site mit der
Entropiemethode geschickt nähern. Wir haben eine Website, die 1 MB wiegt. Es gibt das Konzept der "Informationsmenge". Ein Megabyte ist nicht nur die Anzahl der Zeilen, sondern auch, wie viel Sinn in diesem Code enthalten ist. Und wie komplex sollte eine Site sein, um 1 MB zu benötigen? Gibt es wirklich so viele Benutzerfälle auf der Website, dass es so viel Code geben muss, um sie abzudecken?
In der Tat gibt es nur wenige solche Fälle. Es wird so viel im Linux-Kernel benötigt, aber nicht auf Websites. Und deshalb haben wir eine Menge redundanten Codes.
Die Nano ID-Bewegung bedeutet nicht, jedes Byte zu speichern, sondern zu denken: „Was habe ich im Bundle? Was zum Teufel habe ich dort 1 MB? Ich kann keine Aufgaben haben, bei denen ein solches Volumen erforderlich wäre. “ Auf den meisten Websites werden 75% des Codes nicht verwendet. Nano ID ist eine Bewegung gegen uns, die Benutzern diesen Code sendet.
Wenn wir darüber nachdenken, warum so viel Code nicht verwendet wird, verstehen wir, dass ein Megabyte Code nicht manuell geschrieben werden kann, wenn es sich nicht um ein großes Team handelt. Dies ist mehr als der herkömmliche „Krieg und Frieden“, der über die Jahre geschrieben werden kann, und der Code ist aufgrund von Abhängigkeiten viel schwieriger zu schreiben.
Und meistens handelt es sich bei diesem Band um Bibliotheken. Die berühmte Geschichte mit Moment.js: Sie verbinden sie und aufgrund der Besonderheiten des Webpack-Vorgangs wird
jede Sprache auf Ihrer Website geladen. Und es gibt viele ähnliche Fälle.
Einmal musste ich in Logux eine eindeutige ID generieren, nahm eine Bibliothek und stellte dann fest, dass sie 100 KB wiegt. Warum brauche ich so viel, um eine zufällige ID zu generieren?
Solche Größen sind meistens darauf zurückzuführen, dass Bibliotheksentwickler sie falsch buchstabieren. Daher besteht die Hauptidee darin, die
Größenbeschränkung zu verwenden, damit Bibliotheksentwickler die Größe ihrer Projekte steuern können. Wie ESLint, nur für die Bibliotheksgröße. Und wir sehen sofort, dass eine große Anzahl von Bibliotheken halbiert werden kann.
Dmitry: Scheint es Ihnen nicht so, dass die Frage nicht nur die Größe des Codes betrifft, sondern auch die Ansätze von Entwicklungswerkzeugen? Wenn ich meine Bibliothek als Objekt anstelle einzelner Funktionen exportiere und den Google Closure Compiler nicht auf eigenes Risiko verbinde, schneidet mich niemand ab. Könnte das Problem tiefer liegen als nur das Schreiben von Code?
Andrew: Ich würde nicht sagen, dass das Treeshaking-Problem wirklich relevant ist, da es in JavaScript nicht funktioniert. Jeder glaubt, dass Trichashing das Problem lösen wird, aber nein. Das häufigste Problem ist anders: Was macht das Paket? Sie verwenden ein
Rollup , packen das gesamte Projekt in eine Datei und es stellt sich heraus, dass beispielsweise Abhängigkeiten dort gepackt sind. Dies ist ein großes Problem, und mit Hilfe von Size Limit haben wir eine Bibliothek stark reduziert, da wir die Abhängigkeiten entfernt haben, die sich wahrscheinlich in jedem Projekt wiederholen.
Das zweite Problem ist, dass sie versehentlich eine API von Node.js verwenden. Zum Beispiel gab es eine Bibliothek
choo.js - "compact JS-Framework", in der eingehende Argumente mit dem Node.js-Modul assert überprüft wurden. Und es lädt fast 4 KB. Und für eine winzige Bibliothek versenden wir zusätzlich 4 KB.
Und solche Probleme sind viel häufiger als das, wofür Baumshaking verwendet wird.
Die beste Empfehlung für das Trishaking ist, die Dateien in der Assembly zu teilen und separate Funktionen in separaten Dateien zu verwenden. Meistens ist das Problem jedoch anders. Führen Sie einfach Size Limit mit der Option --why aus und sehen Sie, wie viel Müll das Webpack bei der Verwendung Ihres Moduls einbettet.
Maxim: Dann stellt sich heraus, dass die Verwendung von Webpack für die Montage schlechte Manieren ist?
Andrew: Beobachten, worüber man reden soll. Wenn Sie eine Bibliothek erstellen, wird höchstwahrscheinlich kein Webpack benötigt. Sie haben weniger als 1% der Benutzer, die eine separate Datei wünschen. Gleichzeitig ist es besser, sie zur Verwendung von Webpack zu zwingen, da sie Ihre Bibliothek als Link zu einer anderen Datei einfügen und die Site langsamer wird.
Aber von welchen Benutzern Ihre Bibliotheken gesammelt werden, von welchen Personen Websites gesammelt werden - in der Tat kein Unterschied. Wir sind es im Frontend gewohnt, dass, wenn Sie die Bibliothek falsch verwenden, alles schlecht wird. Wenn Sie heute nicht von Webpack zu Parcel wechseln, ist alles auf Wiedersehen, Sie sind ein schlechter Entwickler. Nein, um ehrlich zu sein, kümmern Sie sich nicht um die Werkzeuge.
Es gibt viele Probleme mit dem Webpack. Dies ist ein schlechter Bundler. Wenn es jedoch für Sie funktioniert, arbeiten Sie daran. Ich habe Projekte gesehen, bei denen er hilft, Probleme zu lösen, obwohl dies eines der am meisten aufgegebenen Projekte ist. Zum Beispiel wird der CSS-Loader dort von
einer Person aus Russland unterstützt. Dies ist ein echter Held, aber wenn er beschäftigt ist - das ist es, niemand wird Ihr Problem beheben, aber es gibt viele Probleme.
Wenn ich sage, dass Sie das Webpack nicht mehr verwenden sollten, dann nur, weil es bessere Sammler gibt. Versuchen Sie es jedoch erneut mit einem neuen Projekt und ändern Sie nicht das alte. Wir masturbieren viel mit Frameworks und Tools, obwohl sie tatsächlich keinen Einfluss darauf haben, wie wir den Code erstellen.
Warum Hype Train und Aristokraten schlecht sind
Maxim: Sie haben gerade darüber gesprochen, Webpack zugunsten kühlerer Bundler zu vermeiden. Vielleicht liegt ein Problem darin, dass solche Empfehlungen von Leuten Ihres Niveaus Hype erzeugen? Anstatt zu empfehlen, etwas Neues zu verwenden, sagen Sie vielleicht einfach "Lassen Sie uns das Webpack wieder großartig machen"?
Andrew: Gute Frage. Einerseits gibt es wirklich ein Problem, wenn solche Kommentare wahrgenommen werden, ohne den Kontext zu verstehen. Aber es gibt noch ein anderes Problem: Ich fürchte Stagnation.
Tatsache ist, dass das Frontend stagniert. Bis zum Ende unseres Lebens werden wir unter der Schirmherrschaft von React leben - kein einziger neuer Rahmen kann ihn verdrängen, weil die kritische Masse gewonnen wird. Es ist wie in Backend-Sprachen: Alte Sprachen werden nicht durch neue besiegt, da es keine kritische Masse und keine Übergangsbedingungen gibt, außer bei einigen engen Aufgaben. Jetzt hat das Frontend begonnen.
Die Stagnation von Frameworks und Build-Systemen bedeutet ein sehr großes Problem: die Stagnation von Menschen, die uns das Leben beibringen werden. Wir sehen dies jetzt, weil die Sterne des Frontends immer noch dieselben sind und daher keine neuen kommen werden. Und Stagnation von Menschen bedeutet auch Stagnation von Ideen. Wir sehen dies bisher an indirekten Parametern, während es genügend Trägheit gibt, um neue Ideen einzubringen. Aber Sie kommen zur Konferenz, und alle sind gleich, und es bedrückt mich wirklich. Meiner Meinung nach ist es an der Zeit, die Front-End-Welt zu stürzen.
Es ist wie in Java - ein riesiger Markt, in dem alles in Ordnung ist, aber es gibt nichts Neues. Wie ich mit diesem Problem umgehen soll - ich weiß es nicht. Aber das ist einer der Gründe, warum ich für kleine Projekte ertrinke und sie ständig berate.
Ehrlich gesagt ist Webpack sehr schwer umzuschreiben, und sein Entwickler kümmert sich nicht um die DX-Qualität, er schreibt es für sich selbst und kommuniziert wenig mit den Benutzern. Darüber hinaus gibt es architektonische Probleme, die das Umschreiben wirklich erschweren. Es gibt Leute im Webpack-Team, die ehrlich versuchen, es gut zu machen, aber es gibt Schwierigkeiten, die uns daran hindern.
Es gibt eine Community, und wo man sie bewegen kann - um alte Tools zu stabilisieren und hinzuzufügen oder neue zu verwenden - habe ich keine Antwort.
In einer idealen Welt werden wir nicht das Gefühl erzeugen, dass die Verwendung alter Tools schlecht ist, sondern wir werden neue für neue Projekte verwenden. Und ich weiß nicht, wie ich es erstellen soll. In der Tat werden die falschen Empfehlungen ausgesprochen, und die Menschen beginnen, andere dafür zu vergiften, dass sie die „falschen“ Dinge verwenden.
Maxim: Ist es Ihrer Meinung nach möglich, dass große Unternehmen wie Microsoft und Facebook anfangen, große Open-Source-Projekte wie Webpack und Babel zu kaufen?
Andrew: Zu kaufen - nein. Dies ist für sie nicht vorteilhaft, solange die Community neue Ideen einbringt, und dies ist ein echter Geschäftsvorteil. Sie kontrollieren sie, es funktioniert anders.
Leider ist dieses Problem bereits im Frontend aufgetreten, aber es drückt sich nicht in der Tatsache aus, dass das Unternehmen etwas gekauft hat, sondern in der Tatsache, dass wir einige Sterne haben, die sich nicht ändern werden. Sie werden immer oben sein und sagen, wie wir werden Code schreiben. Sie kennen sich, es fällt ihnen leichter, sich einander zu nähern und sie zu bitten, etwas zu tun. Daher ist ihre Meinung wichtiger als die Meinung anderer Menschen. Dies ist ein klassisches System zur Schaffung von Eliten in der Gesellschaft.
Ohne ein System sozialer Aufzüge führt dies dazu, dass Eliten erhalten bleiben und Ideen alt werden. Und das Problem ist nicht, dass die Unternehmen sie kontrollieren, sondern dass wir eine sehr kleine Gruppe von Leuten haben, die entscheiden, welches Frontend wir haben werden. Wie der Browser funktioniert, hängt ganz von einer sehr kleinen Gruppe von Personen ab, die an Chrome arbeiten. Wenn Chrome immer beliebter wird, wird es ein großes Problem geben.
— , . , - , : , . , , , , . , , .
: « » - , ?
: . , , — . , ,
[] . ?
: , . - , , - , .
: , . , — , ,
37signals DHH .
, , , . , , , - . , , .
, . , IT .
DHH , , : , , , . , .
: . -, - - , , ?
: Vue.js. , React, , React. , : , .
« , , », , 20–30% . — . , , Google .
Google , , . , - Instagram Facebook, , , , . . , Vue : , React .
, Vue , . , , . — , , win/win. - .
, , , -, - , , , , - .
: , .
: . : , , -.
, — : , , . « ». , , , , .
-, , 99- . , Size Limit,
, , , , Size Limit .
, : - , , , , , , . , , . .
. — « , Google», « , Google, , 99% ».
, , . , , . : , , .
, - pull request Babel, , - . , , — , .
, , - . , , . , .
— - . , PostCSS , , CSS-. Autoprefixer , Compass, , Compass , , , , Opera .
, , , . Accessibility, , URL, , . , — , . , , , Autoprefixer.
, , , , , , , .
: ? , , , JavaScript , , . , ?
: , , — , . — .
: . , , , .
: , , , , , . , . , .
- , … PostCSS , , . , , . - -, , , , , .
: ?
: , , .
: , , , ?
: , , , , - , , , , , . : «
Open Collective , , ».
, . . . , , , . « , , . Open Collective, , . , , , ».
, Babel webpack. : « , . issue,
Open Collective , ». , . , — . , , . , .
, , . -, issue, , maintainer, , , , . , issue, : «, , , . . , , ?» . , «», . , , .
: - , - ?
: . . , JavaScript , . , Ruby , JavaScript. . - , . , , JavaScript.
: , pet project . , , : , , -, , . , , ?
: - . , . , , .
« ». . , . , . — , , maintainer , , - .
, . , , . , , , issue, - , , , .
, ? . , , , . , , .
: , ?
: , .
. . , .
: , , . , . , -, , . , , .
, . , 10, , , , , .
: , , ? , - : « , ».
: , , , . , . , . «» — , , — . , , - PostCSS. .
, - , . - : , , , , , .
— . , , , , , , . , . — , . , .
,
Dmitry: Sie sagten, dass PostCSS beim Reisen hilft. Wie viel reist du und wie kombinierst du das mit Arbeit?
Andrew: Ehrlich gesagt ist die Arbeit noch besser. Ich bin gerade nach einer kurzen Reise in New York angekommen. Es ist eine schwierige Reise, es gibt schlechtes Internet in Marokko, es ist unmöglich zu arbeiten, aber in Wirklichkeit habe ich jeden Tag etwas Nützliches getan: Ich habe einen Artikel geschrieben, zwei Websites mit einer völlig neuen Technik erstellt.
In New York angekommen, sitzend, YouTube schauend. Ich reise normal und effizient zur Arbeit. An einer Stelle werde ich sofort zu einer Waffel, die auf der Couch liegt. Ich reise, um produktiver zu sein, daher ist das Kombinieren einfach.
Die einzige Regel: Denken Sie nicht, dass Sie es an einem Tag in einer neuen Stadt sehen können, die arbeitet. Komm mit einem riesigen Spielraum. Denken Sie nicht, dass Sie überall hingehen werden, Sie werden wirklich genauso arbeiten. Sie werden ein gewöhnlicher türkischer Freiberufler sein, der aufwacht und arbeitet, auf der Straße isst, arbeitet, Fernsehsendungen sieht und schläft. Wenn Sie die Stadt nicht mehr als einmal alle zwei Wochen wechseln, ist alles in Ordnung. Es gibt keine besonderen Probleme.
Maxim: Jeder versteht, dass Englischkenntnisse notwendig sind, aber es ist nicht so einfach, gut zu lernen. Hattest du einen guten Hintergrund? Woher hast du gutes Englisch?
Andrew: Lachst du? Ich habe ekelhaftes Englisch. Ich spreche dieses Thema bei Lingvopank an. Wir sind es gewohnt zu lernen, dass Sprache die Regel ist, besonders in der giftigen russischen Kultur, in der wir ständig verschiedene Menschen kritisieren. Wir sind daran gewöhnt, dass alles schlecht ist, wenn Sie sagen und einen Fehler machen.
In der Tat ist Sprache ein Kommunikationssystem, und solange Sie verstanden werden, ist alles in Ordnung. Wir verstehen nicht, wie Sprache ein doppeltes System ist. Es ist wie eine CD oder ein QR-Code. Sie wissen, dass ein QR-Code größtenteils zerstört werden kann und dennoch lesbar ist? Weil es spezielle Algorithmen zum Duplizieren von Informationen gibt. Der Punkt ist, dass Sie die Sprache nicht gut kennen müssen, sondern in der Lage sein müssen, darin zu kommunizieren.
Mein Hauptfortschritt in der Sprache geschah, als ich einfach aufhörte, Angst zu haben. Wir haben alle Angst, weil wir in der Schule und im Internet ständig gemobbt werden - ein schreckliches russisches Twitter, bei dem sie uns mehr für einen Tippfehler als für eine Anti-Idee verantwortlich machen. Tatsächlich haben die Russen gutes Englisch. Beginnend mit der Tatsache, dass es sich um eng verwandte Sprachen handelt: nicht um Chinesisch, bei dem Sie im Allgemeinen ein anderes Sprachsystem haben. Wir können uns nicht vorstellen, dass es dort im Rest der Welt noch schlimmer ist.
Russland ist auf einem normalen Niveau. Natürlich schlimmer als Norwegen und ähnliche kleine Länder, die einfach die Sprache lernen müssen, weil es keinen Inhalt gibt. Aber der Rest der Russen spricht gut Englisch, es gibt keine Probleme. Die Hauptregel - keine Angst haben, einfach kommunizieren, zur Gebärdensprache wechseln, vor der Diskussion etwas trinken (dies hilft zu verstehen, dass einfache Dinge wirklich wichtig sind).
Die zweite Point-Watch-Serie mit Untertiteln hilft wirklich.
Reisen, einfach die Sprache lernen.
Und vor allem - versuchen Sie zu sprechen.
Wir haben Angst vor der Sprache, weil es in Russland ein Problem gibt: Wir kommunizieren sehr wenig mit der Außenwelt. Einerseits ist dies gut, da es einen Binnenmarkt gibt, auf dem einige kleine Leute herauskommen können. Da Yandex aufgrund der Sprachbarriere aus dem Monopol von Google herausgewachsen ist, gibt es auch eine große Anzahl von sozialen Aufzügen, die ein Programmierer besteigen kann, was im Westen niemals passieren würde.
Aber im Gegenzug gibt es ein Problem, dass der Markt geschlossen ist, wir nicht nach draußen schauen und alle Menschen, die aufgestiegen sind, wirklich gute Typen, nicht in den Westen gehen, weil sie Angst vor Englisch haben. Meine Empfehlung ist, zwei Twitter-Konten zu haben, auf Russisch in einem zu schreiben, um Ihrer Kultur zu helfen (dies ist auch wichtig), und Englisch zum Üben. Wenn Sie auf Englisch schreiben, werden Sie verstehen, dass es nicht schwierig ist. Das einzige ist, dass nur wenige Leute Sie lesen werden, denn im Westen gibt es genug eigene, aber die kritische Masse nimmt trotzdem zu, Sie werden Ihre 150-300 Leser gewinnen.
Nehmen Sie an englischsprachigen Treffen in Russland teil, es ist nicht beängstigend, niemand wird Sie beleidigen, alles ist in Ordnung.
Dmitry: Empfehlen Sie, für eine Weile irgendwohin zu ziehen, um die Sprache zu lernen, wenn ja, wo?
Andrew: Um die Angst loszuwerden, ist jede Reise genug. Aber wie man weiter lernt, ist eine gute Frage. Ehrlich gesagt, ich weiß es nicht, ich kenne die Sprache nicht gut. Aber ich kann sagen, wenn Sie auf einer Kundgebung in New York sprechen, auch wenn das Publikum Ihren Akzent kaum wahrnimmt, dann trotzdem, weil die Hälfte des Publikums aus Indien, die andere Hälfte aus China.
Und ich kann noch etwas sagen. In Russland gibt es eine populäre Erzählung, die beschuldigt werden muss, und überall ist gut: "In Russland ist alles schlecht, ich werde wegwerfen und ich werde glücklich sein." Ehrlich gesagt - das ist die Motivation, sich besser nicht führen zu lassen. Weil die Erzählung sehr alt ist und wir historisch wissen, dass sie vom 18. bis 19. Jahrhundert nicht funktioniert. In anderen Ländern nicht grundsätzlich besser. Es gibt grundlegende Managementprobleme, die jedoch früher oder später in jedem Land auftreten.
Wenn Sie eine Aufgabe haben, gibt es ein Problem der Wahl, das auf unterschiedliche Weise gelöst wird. Zum Beispiel wollen wir, dass die Straße gereinigt wird, und dafür brauchen wir tatsächlich eine zentralisierte Gesellschaft. Um dies zu tun, ist es notwendig, jeden zu unterdrücken, der falsch denkt, wie in den Vereinigten Staaten. Es gibt ein sehr strenges System interner Regeln und Abwägungen darüber, wer wie denken sollte, und tatsächlich ähneln die Vereinigten Staaten in dieser Hinsicht China. Es ist nur so, dass die Regeln unausgesprochen sind und der Staat dies nicht tut - die Gesellschaft tut es.
Ich würde nicht sagen, dass es eine definitive Lösung gibt, wo es besser ist - wo die Straßen kaputt sind oder wo die Gesellschaft sagt, wie Sie denken sollten. Dies ist jedoch keine binäre Lösung, sondern eine Frage der Politik und Soziologie. Und die allgemeine Gliederung: Oft sind andere Länder in gewisser Weise besser, weil an anderen Orten schlechter.
Es ist besser, sich nicht sofort zu bewegen, sondern die Welt zu bereisen, und dann werden Sie feststellen, dass es im Allgemeinen wichtig ist, welche Dinge Sie bereit sind zu geben, um andere Dinge zurückzubekommen. Mit diesem Verständnis können Sie das Land auswählen, in das Sie umziehen möchten. Und sich dann normal bewegen.
Aber um ehrlich zu sein, werden Sie nicht glücklich sein, denn die erste Auswanderungswelle besteht immer darin, schreckliches Leid zu erleben, depressiv zu sein, nach dem Umzug verlieren Sie Ihren gesamten sozialen Kreis.
Dmitry: Ich würde gerne wissen, was der Unterschied in der russischen Entwicklergemeinschaft in anderen Ländern ist.
Andrei: In Bezug auf die Staaten ist dies eine interessante Situation. Erstens gibt es wirklich ein starres System, um eine Philosophie durchzusetzen. Sie war es immer, sie haben ein strenges Bestrafungssystem, zum Beispiel öffentliche Belästigung. Aber das System ist ziemlich alt und funktioniert im Allgemeinen. Ehrlich gesagt verwendet sie meistens die richtigen Ideen, um sich zu verbreiten, und die falschen, na ja, Exzesse vor Ort.
Die Hauptidee ist, dass es in der Kultur ein sehr stereotypes Denken gibt, um gute Praktiken schnell zu verbreiten. Dort macht eine große Anzahl von Programmierern keine dummen Fehler, weil jedem gesagt wurde, er solle so schreiben, jeder schreibt so. Stattdessen ist es ziemlich schwierig, Ihre Ideen zu fördern.
Und es gibt eine spezielle Kultur des Smalltalks - Mobbing für falsche Ideen führt zu sozialen Spannungen, und in den USA gibt es eine große Anzahl von Nationen, und sie wissen nicht, wie sie widersprüchliche Kommunikationsthemen führen sollen, ohne Mobbing zu betreiben. Deshalb haben sie eine Liste mit Stoppthemen.
Dies ist der wichtigste soziale Unterschied in der Gemeinde. Von den Vorteilen - sie sind leicht zu besteigen und sorgen wirklich dafür, dass die Menschen nicht leiden. Du kommst, jeder ist freundlich, alles ist in Ordnung, solange du ein gewöhnlicher Mensch bist, der nach den Regeln spielt.
Das zweite interessante Merkmal ist, dass sie oft für Mitaps bezahlen, ein symbolischer Preis von 5-10 Dollar, der für Lebensmittel verwendet wird. Wieder weil der Kapitalismus.
Dmitry: Und wenn nicht die USA, aber andere Länder?
Andrew: Zweitens, so wie ich die Gemeinde studiert habe, ist dies China. Es gibt eine interessante Funktion in einer großen Anzahl von Entwicklern, und andererseits haben sie ein interessantes Format - sehr wenig Netzwerk. Es ist normalerweise geschlossen, Sie werden zu einem "besonderen Frühstück" eingeladen, das mit Gemeindevorstehern stattfindet. Auf der anderen Seite kommen die Teilnehmer der Meetings wirklich, um über komplexe Themen zu sprechen und neues Wissen aufzunehmen. Ehrlich gesagt sind all diese Funktionen kein Rahmen. Die Gemeinde ist vielfältig und es gibt genug Anarchisten in China. In Amerika spuckte eine große Anzahl von Menschen auch auf Verbote. Nun, in Russland gibt es gastfreundliche, höfliche und gute, nicht kleine Kritiker.
Ein weiteres interessantes Merkmal Chinas ist, dass sie geschlossen sind und eine separate Welt haben. Dies ist sowohl ein Plus als auch ein Minus. Sie haben eine große Menge ihrer Erfolge, weil es einen Ort gibt, an dem sie sich entwickeln können. Andererseits leiden sie schrecklich unter der Tatsache, dass sie ihre Entwicklungen nicht wie in Russland durchführen können. Alle chinesischen Top-Sprecher haben Angst, Englisch vom Wort "allgemein" zu sprechen, obwohl sie normalerweise Englisch sprechen.
Als nächstes kommt Japan. Trotz der Tatsache, dass dies ein solches Computerland ist, eine Supermacht mit fortschrittlicher Technologie, wird die Programmierung als schlechter angesehen als das Management. Es wird angenommen, dass das Programmieren im Gegensatz zu Managern wenig Arbeit kostet: Sie sagten es der Person und er schreibt den Code. Infolgedessen gibt es keine Community, und die IT wird nur schrecklich entwickelt. Startups werden unvergleichlich schlechter entwickelt als die Fähigkeiten des Landes. Es gibt kein Tal, "Genies-Programmierer", das ist alles. Und aufgrund der traditionellen Gesellschaft gibt es in der IT weit weniger Frauen als in China. In China ist damit alles in Ordnung - es gibt viele chinesische Frauen mit interessanten Ansichten und Erfahrungen, obwohl es auch Raum zum Wachsen gibt.
Es gibt eine gute brasilianische Gemeinschaft. Hispanische Länder haben es nicht, da sich jeder an Amerika orientiert. Frankreich hat auch eine gute innere Gemeinschaft.
Aber in Sri Lanka ist alles ziemlich schlecht mit der IT-Community, denn wenn sie ein Mädchen heiraten, meistens durch ihre Familie, fragt ihr Vater: „Womit arbeiten Sie?“ Und es gibt eine weiße Liste mit „richtigen“ Berufen, auf die sich Programmierer noch nicht eingelassen haben. Daher gibt es nur sehr wenige Programmierer, obwohl es viele potenzielle Vorteile gibt: Geld, die Möglichkeit der Einwanderung. Ein guter Vater würde es begrüßen, wenn er seine Tochter in guten Händen halten würde, aber dies geschieht nicht, da die Liste noch nicht aktualisiert wurde.
Ich rate Ihnen, auf chinesischen und indischen Konferenzen zu sprechen: Es ist einfach, dorthin zu gelangen (sie akzeptieren gerne eine Person von außerhalb), und Sie üben auf Englisch in einer Umgebung, in der Sie keine Angst haben, weil niemand wirklich Englisch kann und jeder mit Fehlern spricht.
Ideale Konferenzen
Dmitry: Wenn wir über Konferenzen gesprochen haben, was ist der entscheidende Faktor für die Teilnahme als Redner?
Andrew: Für mich ist die Verfügbarkeit von Konferenzen der entscheidende Faktor. Obwohl ich manchmal, wenn mein Weg durch einige Länder führt, Konferenzen zustimme, die für Menschen nicht sehr zugänglich sind, nur um den Bericht zu pumpen.
Ich denke, es gibt ein großes Problem, dass die Konferenzpreise sehr hoch sind. Ich verstehe, dass Konferenzen Geld verdienen müssen, es gibt kein Problem damit, aber es gibt einige JSConf, die fabelhafte 500 Dollar kosten und ehrlich gesagt für die Dinge ausgeben, die gespart werden können. Zum Beispiel zum Abendessen die stärkste Afterparty, obwohl ich ehrlich gesagt lieber ein unangenehmes Bier trinken würde, aber damit es interessante Leute gibt.
Und die enormen Preise führen dazu, dass die Redner nicht an einer Kommunikation mit dem Publikum interessiert sind. Es ist manchmal schwierig, das Thema zu unterstützen, da auf der Konferenz nur Mitarbeiter großer Unternehmen, der gleiche Schöpfer der besten CRDT JS-Implementierung,
Viktor Grishchenko, nicht kommen konnten, weil das Ticket sehr teuer ist. Es gibt viele Möglichkeiten zu sparen, und sie müssen angewendet werden, teure Tickets sind falsch. Die Konferenz sollte zugänglich sein.
Ich bin oft damit einverstanden, zu einem kleinen Meeting zu gehen, damit jeder normalen Zugang zum Netzwerk hat. Und bei vielen Meetings ist der Dialog besser als bei Konferenzen mit einem hohen Ticketpreis. Das ist mein Ansatz.
Dmitry: Ohne was kann eine Konferenz nicht gut sein? Es ist bereits klar, was Vernetzung, Zugänglichkeit und was noch ist.
Andrei: Nun, als Redner schätze ich es sehr, wenn ein Timer vor der Bühne steht. In dieser Hinsicht ist bei HolyJS alles sehr professionell, ich mag die Organisation von Aufführungen. Im Allgemeinen ist Networking eine Schlüsselsache. Menschen besuchen Konferenzen nicht aus Wissensgründen. Es ist einfacher, einen Artikel als einen Bericht zu lesen, sondern aus Gründen der Zugehörigkeit zur Community.
Gemeinschaft ist das Wichtigste, was auf Konferenzen passiert. Das Gefühl, dass du redest und etwas in dir geändert hat, du weißt etwas. Es ist eine gute Idee, dass unsere Gesellschaft kein Verständnis für das „Warum“ hat. Wir gehen zu Konferenzen, um zu verstehen, warum wir das alles tun. Und eine gute Konferenz wird dieses Problem wahrscheinlich lösen.
Dmitry: Sie sagten "nicht für Wissen", dies ist ein sehr kontroverses Thema. Würden Sie zu einer Konferenz gehen, auf der eine Sammlung von Menschen mit sehr grundlegenden Themen, aber aus sehr unterschiedlichen Gemeinschaften, zusammengestellt wird?
Andrei: Ja, das würde natürlich viel Spaß machen.
Dmitry: Und es wäre interessanter als eine Konferenz, auf der es ernsthafte und aussagekräftige Berichte gibt?
Andrei: Ich denke, beide Ansätze sind gut und hier gibt es kein Problem.
Dmitry: Wahrscheinlich die letzte Frage. Was erwarten Sie von HolyJS?
Andrew: Gute Party! Im Jahr 2016 wurde es direkt gutgeschrieben, eines der besten in meinem Leben, und dann war alles sehr gut organisiert.
Dmitry: Was würden Sie dieses Mal empfehlen, um es noch besser zu machen? Lust auf eine Party?
Andrew: Ich würde versuchen, mich mit den lokalen Mitaps zu organisieren. Wir haben viele lokale Treffen, und es stellt sich als ziemlich cool heraus, wenn sie die Möglichkeit haben, etwas selbst zu tun - es gibt viele Initiativleute, Sie müssen ihnen die Gelegenheit geben. Und es wäre cool, wenn die Organisatoren aller lokalen Kundgebungen oder ihre Hauptredner eine Freikarte oder irgendeine Art von Hilfe erhalten würden, das wäre großartig.
Beim nächsten HolyJS (St. Petersburg, 24.-25. Mai) wird Andrei mehr über die Förderung von Open-Source-Projekten sprechen . Neben ihm wird es viele weitere bedeutende Persönlichkeiten des JS Open Source geben: von Ryan Dahl (Node.js, Deno) bis Michel Weststrate (MobX, Immer). Alle Details zu ihren Berichtsthemen finden Sie auf der Website , Tickets können dort gekauft werden und werden nach und nach teurer.