Share
Addy Osmani, ein glänzender Star in der JavaScript-Community, hat sich nicht nur durch seine fabelhaften JavaScript-Artikel und Open-Source-Beiträge hervorgetan, sondern ist auch einer der freundlichsten und aufgeschlossensten Entwickler überhaupt.
Sein Blog ist eine Fundgrube an Front-End-Wissen und einen Besuch wert. In diesem Beitrag unterhalten wir uns mit Addy darüber, wie er in JS nass wurde und wir werden einige schwierige Themen in Bezug auf seine Arbeit in der Entwicklerbeziehung bei Google ansprechen.
JavaScript sollte eine große Rolle dabei spielen.
Ich habe etwas von meinem ersten JavaScript geschrieben, als Netscape Navigator der dominierende Browser war. Dynamische Front-End-Entwicklung wurde zu dieser Zeit nur langsam populärer, aber die Idee, etwas nur mit HTML / CSS / JS schreiben zu können und es überall funktionieren zu lassen, war mächtig. Ich war von dieser Idee fasziniert und bin seitdem dabei. Einige meiner ersten Kreationen waren Kleinigkeiten, über die Sie heute lachen würden - Taschenrechner, Passwortgeneratoren, nichts Besonderes.
Als Sprachenthusiasten mochte ich, dass JavaScript auf Prototypen basiert und wenig typisiert ist. Daher beschloss ich, es neben anderen Sprachen wie C ++ weiter zu lernen. Anfang der 2000er Jahre versuchte ich, die Sprachen zu überbrücken, indem ich einen kleinen Interpreter auf SpiderMonkey (Mozillas JavaScript-Engine) schrieb, mit dem ich Logik für meine Desktop-Apps in JS schreiben und UI-Komponenten mit C ++ definieren konnte. Es war eine dumme Idee, aber ich habe dabei viel über die Interna der JavaScript-Engine gelernt.
Ich habe viel Zeit damit verbracht, kleine Hobby-Sites zu bauen, aber als ich in meinem letzten Jahr auf der High School war, beschloss ich, mich in die Welt der Browser-Interna zu stürzen. Ich habe eine einfache Rendering-Engine, grundlegende HTML 4.01 / CSS 2.1-Parser, geschrieben und alle diese Teile in meinen eigenen kleinen Browser verpackt. Das Projekt war ein Albtraum, um zuverlässig arbeiten zu können, zum Teil aufgrund der Tatsache, dass lax Webentwickler mit der Einhaltung von Standards auf ihren Seiten befasst waren - es ist lustig, sich jetzt auf der anderen Seite des Zauns zu befinden! Zu den größeren Herausforderungen gehörten die Einhaltung von Spezifikationen, das Rendern großer Tabellen und das Beibehalten der Leistung beim Laden von Video-Plugins (kann sich jemand an gutes ActiveX erinnern?).
Während meines Studiums lernte und verwendete ich JavaScript als freiberuflicher Webentwickler. Ich schrieb langsam komplexere Websites und spielte mit Dojo. Erst als ich 2006 zu GMail eingeladen wurde, kam mir der Gedanke, dass der Browser die nächste Plattform für das Erstellen von Rich-Anwendungen sein wird. JavaScript sollte eine große Rolle dabei spielen, und ich entschied mich dazu, mich dauerhaft von der Entwicklung von Desktop-Apps zu entfernen.
Seitdem versuche ich, weiter zu lernen, und wo ich kann, die Front-End-Community durch mein Schreiben und meine Beiträge zu Open Source voranzutreiben. JavaScript ist heutzutage praktisch überall und es ist einer der Gründe, warum ich die Sprache liebe. Wenn ich einem meiner Kinder beibringen möchte, wie man JavaScript schreibt, kann ich einfach meine Browser-DevTools öffnen und ihnen zeigen. Es sind keine zusätzlichen Übersetzungsschritte erforderlich - das ist etwas ganz Besonderes.
Wenn Sie mit dieser Denkweise in ein nicht triviales Thema springen, müssen Sie es in einfache, leicht verdauliche Schritte unterteilen
Das Geheimnis ist, dass ich mich für etwas dumm halte. Ja wirklich. Wenn Sie mit dieser Denkweise in ein nicht-triviales Thema springen, müssen Sie es in einfache, leicht verdauliche Schritte unterteilen, um einen Sinn zu ergeben.
Es ist diese Perspektive, von der ich denke, dass sie mir das Schreiben zugänglich macht - ich versuche, die Konzepte oder Werkzeuge zu verstehen, die für den durchschnittlichen Entwickler anfangs ziemlich abschreckend wirken können. Es ist wichtig, dies auf Artikel und insbesondere auf Dokumentation anwenden zu können. Also, mach es einfach. Dies hilft, die Artikel fokussierter zu machen. Wie kann ich so viel Inhalt generieren, während ich das Material verstehe? Nun, ich mache Verständnis als Voraussetzung.
Mach es erst, dann mach es richtig, dann mach es besser.
Einstein hat dieses großartige Zitat: "Wenn Sie es nicht einfach erklären können, verstehen Sie es nicht gut genug" und es stimmt. Sie können nicht über ein Framework, ein Tool oder eine bewährte Methode unterrichten oder behaupten, es sei denn, Sie haben sich die Zeit genommen, es selbst zu verwenden. Diese Zeit zu finden, fällt mir in meiner jetzigen Position leichter, aber früher, als ich als 9-5-Ingenieur arbeitete, verbrachte ich viel Zeit beim Frühstück und Mittagessen, um das zu nutzen, worüber ich später am Wochenende schreiben würde.
Zeit zu finden, um alles zu erledigen, ist immer eine Herausforderung. In den letzten Jahren habe ich dieses Mantra, das ich versuche, auf jede Aufgabe anzuwenden - "
Sie können diese erste Iteration dann mit Ihren Kollegen teilen und ein Gefühl dafür bekommen, ob Sie in die richtige Richtung gehen oder ob die Idee es wert ist, verfolgt zu werden. Für mich ist das viel sinnvoller als Wochen für einen Entwurf oder einen Prototyp zu verbringen, bevor man nach Input fragt.
Es ist etwas Besonderes, Teil eines Unternehmens mit so hohen Standards zu sein.
Sowohl AOL als auch Google sind Unternehmen mit hervorragenden Ingenieurteams. In meinen Überlegungen zur Kultur geht es nicht um bestimmte Gruppen, eher um eine allgemeine Beobachtung.
Die Ingenieurkultur bei Google ist so, dass wir uns sehr um Politur und Versand kümmern, wenn wir das Gefühl haben, dass sie genau richtig sind. Es ist etwas Besonderes, Teil eines Unternehmens mit so hohen Standards zu sein.
Bei AOL war ich stolz auf eines der Produkte oder Anwendungen, die wir fertigstellten. Aufgrund der schnelllebigen Art von Geschäft und Wettbewerb war es jedoch nicht immer möglich, die Einführung oder Veröffentlichung von polnischen Produkten zu verzögern. Ich denke, dass dies für viele Unternehmen eine Realität ist, trotz des Wunsches, diese Kultur zu ändern.
Wenn es möglich ist, die Veröffentlichung zu verzögern, um, wie Google sagt, "richtig" zu sein, denke ich, kann dies einen großen Unterschied für die ersten Eindrücke Ihrer Benutzer aus Ihrem Produkt machen.
Ich bin zufrieden mit der Richtung, die TC39 in den letzten Jahren eingeschlagen hat.
Ich bin zufrieden mit der Richtung, in die TC39 in den letzten Jahren gegangen ist, was teilweise durch die Beteiligung von Rick Waldron und Yehuda Katz aus dem jQuery-Projekt unterstützt wurde. Sie haben sich intensiv mit den Mustern beschäftigt und die Bibliotheken, auf die die Entwickler sich stark verlassen haben, haben untersucht und untersucht, wie diese mit Plattformprimitiven besser gelöst werden können. Ich werde nicht speziell auf ES6 eingehen, aber ich freue mich darauf, Module, Klassen, "let" und zu sehen Object.observe () breiter verfügbar.
Was die JavaScript-Community betrifft: Wir sind an einem guten Ort, aber ich wünschte, wir würden kollektiv weniger Zeit damit verbringen, neue Frameworks zu erstellen und mehr Zeit in die Verbesserung bestehender Lösungen zu investieren. Ich finde es fantastisch, dass Entwickler viel Zeit damit verbringen, Probleme selbst zu lösen - es ist eine der besten Möglichkeiten, neue Dinge zu lernen - aber wenn es sich um ein Experiment handelt, machen Sie das klar, damit andere Entwickler nicht erwarten, dass Sie die Lösung beibehalten Projekt. Diese Art von Dingen trägt nur zum Lärm bei. Bitte berücksichtigen Sie die Unterstützung, wenn Sie Dinge freigeben!.
Einer der großen Mythen ist, dass es JavaScript ersetzt.
Ich war wirklich sehr neugierig, mehr über die Ziele zu erfahren, die Dart hatte, als ich zu Google kam. Einer der großen Mythen ist, dass es JavaScript ersetzt, aber es stellt sich heraus, dass dies nicht ganz stimmt. Dart richtet sich an Entwickler, die mit Java, C ++, C # vertraut sind und hochleistungsfähige Web-Apps erstellen möchten. und so weiter, haben bestimmte Erwartungen in Bezug auf ihre Werkzeuge und Sprache. Ich denke, das ist ein legitimer Grund dafür, dass so etwas wie Dart existiert.
Als Unternehmen sind sowohl JavaScript als auch Dart Technologien, an die wir glauben und in die wir investieren. Wir beteiligen uns an TC39, arbeiten an der Zukunft von JavaScript und arbeiten auch an V8, der schnellen JavaScript-Engine. Die Chrome-Ingenieure arbeiten weiterhin daran, das Web mit neuen Spezifikationen wie Webkomponenten voranzutreiben. Inzwischen baut das Team, das ursprünglich V8 entwickelt hat, die Dart-VM.
Zurück zu Ihrer ursprünglichen Frage - Ich glaube, dass das Forking WebKit viel mehr mit der Divergenz der Multiprozess-Architektur zwischen den beiden Projekten zu tun hatte, als Dart in Chrome einzubetten. Dart ist ein separates Open-Source-Projekt mit eigenen Zielen, und Sie können Dartium auch heute noch erhalten (die Erstellung von Chromium mithilfe der Dart-VM)..
Als ich zum ersten Mal die Nachrichten über Blink hörte, war ich besorgt, dass wir jetzt einen anderen Browser zur Unterstützung hätten.
Die Realität ist jedoch, dass es bereits so viele Unterschiede zwischen den verschiedenen WebKit-Ports gab, dass sich dies nicht negativ auf die Entwicklung und das Testen auswirkt.
Mit Blink können wir den Entwicklern mehr Tools, Funktionen und Kompatibilität geben, die sie benötigen, um das Web als Plattform optimal nutzen zu können. Langfristig werden wir uns mit Funktionen befassen, die die Erstellung der nächsten Generation von Web-Apps erleichtern. Auf dieselbe Weise, wie wir mit V8 JavaScript beschleunigen konnten, denke ich, dass Blink uns Innovationen ermöglichen wird, die von Vorteil sind die ganze Plattform.
Wir sind in der heutigen Zeit ziemlich oft in die Debatte um native vs. web verwickelt, sprechen aber nicht so sehr über die Notwendigkeit, unsere Nutzer an die erste Stelle zu setzen. Sie sind der Fokus. Es gibt viele Fälle, in denen Sie eine überzeugende Erfahrung für das Internet auf Desktop und Mobile bereitstellen können, und es funktioniert fantastisch. Das heißt, es gibt andere, bei denen entweder die Plattform oder die mobilen Browser noch arbeiten müssen. Als Unternehmen müssen Sie häufig anrufen, was für Ihre Benutzer am sinnvollsten ist. Ich denke, dass es derzeit sehr sinnvoll ist, Entwicklern die besten Plattformen zu bieten, die für Anrufe über native vs Web erforderlich sind. Dies tun wir über Android und Chrome für Mobile.
Wiederverwendbare Komponenten.
Wiederverwendbare Komponenten. Traditionell haben viele von uns Anwendungen ganz vertikal entwickelt und ein einziges Konzept (ob Logik oder Benutzeroberfläche) auf einige verschiedene Teile des Projekts verteilt. Dies macht es nicht nur schwieriger, die Idee aufrechtzuerhalten, sondern sie macht es auch schwierig, die Idee in zukünftigen Anwendungen ohne großen Aufwand zu extrahieren und wiederzuverwenden. Dies verringert auch unsere Chancen, die Komponente mit anderen zu teilen.
Ohne auf bestimmte Technologien zu verweisen, arbeiten wir daran, die Definition und Paketierung von Komponenten auf der Plattformplattform zu vereinfachen. Jetzt ist es ein guter Zeitpunkt, um darüber nachzudenken, wie Ihre eigenen Apps geschrieben werden könnten, falls sie in diese eingebrochen wären spezifische Komponenten.
Das Frontend erlebt derzeit eine Revolution in der Werkzeugausstattung. Immer mehr Entwickler nutzen Grunt und erkunden Workflow-Tools wie Yeoman. Die Entwickler achten mehr auf das, was sie automatisieren können, und ich denke, dies wird dazu beitragen, dass mehr Zeit für die Erstellung besserer Apps und weniger Zeit für die manuellen Prozesse dazwischen aufgewendet wird.
Um auf die Idee der Komponenten zurückzukommen, denke ich, dass wir zwischen Webkomponenten und Front-End-Paketmanagement eine große Chance haben, unsere Art und Weise, wie wir sie für das Web entwickeln, wirklich zu verändern. AngularJS (und Angular-Direktiven) haben die Idee wiederverwendbarer Funktionsblöcke wieder neu eingeführt, und auf der Paketverwaltungsseite der Dinge wird über Bower wirklich nachgedacht.
Eine App mit Listen schreiben, die Sie sortierbar machen möchten? Großartig. Ein paar Tastatureingaben an der Befehlszeile und das haben Sie. Möchten Sie, dass die Elemente in dieser Liste bestehen bleiben, wenn Sie offline sind? Kein Problem. Ein paar weitere Tastenanschläge und Sie verwenden ein Paket, das ein anderer Entwickler einmal schreiben musste, um diese Funktion zu erhalten. Möchten Sie Ihre Liste in eine wiederverwendbare Komponente umwandeln, die andere Benutzer verwenden können? Das ist einfach. Das ist die Zukunft, auf die wir hinarbeiten.
Wir haben das Glück, heute eine Fülle hilfreicher Tools im Frontend zur Verfügung zu haben - Tools, die uns Zeit sparen und unser Leben ein wenig einfacher machen. Abstraktionen wie Sass und CoffeeScript, Frameworks wie Twitter Bootstrap, Modulladegeräte wie RequireJS, eine unendliche Liste von MVC- und Komponententestbibliotheken ... manche sagen, wir haben die Qual der Wahl und es ist interessant zu sehen, wie lange es dauert, bis Sie fertig sind ein Projekt hat begonnen.
Aktualisieren Sie Ihren Browser immer noch manuell, wenn Sie Änderungen an Ihrer App vornehmen?
Auch wenn diese Tools ausgesprochen gut für sich alleine arbeiten, kann es ein langwieriger Prozess sein, sie zusammenzubringen, insbesondere wenn Sie einen Workflow- und Build-Prozess zusammenstellen müssen, in dem sie alle kompilieren und präzise optimieren. Selbst wenn es Ihnen gelingt, einen soliden Build-Prozess zu implementieren, müssen Sie oft viel Zeit damit verbringen, den Boilerplate-Code für Ihre Anwendung herauszuschreiben.
Selbst dann müssen Sie sich fragen, wie gut dies zu Ihrem täglichen Arbeitsablauf passt. Es gibt mehrere kleine Schritte, die wir während der Entwicklung immer wieder ausführen, die leichter an Werkzeuge weitergegeben werden können. Aktualisieren Sie Ihren Browser immer noch manuell, wenn Sie eine Änderung an Ihrer App vornehmen, um eine Vorschau des Aussehens der App anzuzeigen? Versuchen Sie immer noch herauszufinden, ob Sie die neuesten Versionen Ihrer Abhängigkeiten verwenden? Ich frage mich, ob es nur etwas gab, das Sie mit dem Programmieren begleiten und viele Grunzarbeiten vergessen lässt?
Wir waren es auch, und deshalb haben wir überlegt, ob wir Entwicklern eine Lösung für viele dieser häufigen Probleme geben können. Wir haben versucht, sie in einem kostenlosen Open-Source-Projekt namens Yeoman zu lösen. Der offizielle Slogan von Yeoman ist, dass wir ein "robuster und meinungsstarker clientseitiger Stack sind, der aus Tools und Frameworks besteht, die Entwicklern helfen können, schnell fesselnde Webanwendungen zu erstellen"?.
In der Praxis sind wir eine Reihe von Tools und Aufgaben, mit denen Sie einige der mühsameren Aufgaben in der Front-End-Entwicklung automatisieren können. Wir setzen sich aus yo (dem Gerüstwerkzeug), Grunzen (dem Bauwerkzeug) und der Laube (für die Paketverwaltung) zusammen..
Wenn Sie der Meinung sind, dass Sie immer noch Boilerplate-Code für Ihre Anwendung schreiben, die Abhängigkeiten für Ihre Apps manuell verwalten oder Ihr eigenes Build-System für die Arbeit mit den von Ihnen bevorzugten Tools zusammenstellen, könnten Sie mit Yeoman eine gute Möglichkeit finden, sich Kopfschmerzen zu ersparen.
Die Windows-Entwicklergemeinschaft könnte uns hier wirklich helfen.
Das Erstellen eines Befehlszeilentools, das plattformübergreifend gut funktioniert, kann ein heikler Tanz sein. Eine der ersten Herausforderungen bei der Windows-Unterstützung bestand darin, dass ein Großteil unseres Teams es gewohnt war, ein * nix-System zu verwenden und Zugriff auf homebrew / apt-get zu haben. Wir waren jedoch mit der Verwendung von PowerShell oder Chocolatey (dem PowerShell-basierten Windows-Äquivalent zu apt-get) nicht so vertraut und brauchten Zeit, um zu verstehen, wie gut diese Lösungen im Vergleich zu den Tools sind, die wir an anderer Stelle verfügbar hatten.
Dann brauchte es Zeit, um alle Pakete zu finden (oder zu erhalten), die wir für Chocolately benötigten, da wir Git, Phantome, Opting und viele andere benötigten. Die Situation dort hat sich seit unserer ersten Veröffentlichung erheblich verbessert. Windows wird nun offiziell von Yeoman anhand der Anweisungen auf unserer Homepage unterstützt.
Die Windows-Entwicklergemeinschaft könnte uns hier wirklich helfen, indem sie sich für eine breitere Akzeptanz von Tools wie Chocolately einsetzt und uns dabei hilft, mit Tools wie apt-get die Gleichheit zu erreichen. Abgesehen davon waren sie fantastisch und wir haben die Unterstützung und Unterstützung, die uns die Windows-Entwicklergemeinde auf unserem Weg zur Kompatibilität angeboten hat, sehr geschätzt.
Ich muss Sindre Sorhus, Mickael Daniels und Paul Irish anrufen, die alle sehr dazu beigetragen haben, unsere Windows-Anstrengungen in den ersten Tagen zu verbessern.
Momentan werden viele (fantastische) Entwicklungstools geschrieben, die nicht nur * nix, sondern Mac-spezifisch sind, da sie für ihre plattformübergreifende Entwicklung ihre eigenen Entwicklungskosten und ihren Overhead haben. Ich würde gerne mehr offene Diskussion und Entwicklung von Tools sehen, die überall funktionieren können, aber dies ist ohne die Hilfe von Benutzern nicht möglich.
Wenn Sie ein Tool für Windows möchten, das Sie gerade auf dem Mac sehen, machen Sie es bitte deutlich. Senden Sie dazu eine Pull-Anfrage!
Versuchen Sie herauszufinden, was es braucht, um Windows (und anderswo) zu veröffentlichen, und wer weiß? Vielleicht würden die gemeinsamen Anstrengungen mehrerer Gemeinschaften ausreichen, um etwas zu erreichen.
Mein erstes Buch veröffentlichen, JavaScript-Entwurfsmuster lernen (mit O'Reilly) war wahrscheinlich die Leistung, die mich am meisten zufriedenstellte. Es war mein größtes Schreibprojekt und ich entschied mich von Anfang an dafür, dass es vollständig Open Source ist - ein Aufruf, den ich nie bereuen werde. Das Bereitstellen von Bildungsmaterial für jedermann, unabhängig davon, ob er es sich leisten kann, birgt das Potenzial für beides.
Es hat auch das Potenzial, die Wirkung Ihres Buches zu steigern. Wenn Sie also Autor sind, sollten Sie dies in Betracht ziehen. Du wirst es nicht bereuen!
Accentsconagua