Share
Étoile brillante de la communauté JavaScript, Addy Osmani est devenue une vedette, non seulement pour ses articles JavaScript fabuleux et ses contributions open source, mais également pour être l'un des développeurs les plus sympathiques et les plus abordables qui soient..
Son blog est une véritable mine de connaissances initiales et vaut bien la visite. Dans cet article, nous discuterons avec Addy de la manière dont il s’est familiarisé avec JS et abordons des sujets difficiles relatifs à son travail dans les relations avec les développeurs chez Google..
JavaScript allait jouer un grand rôle pour rendre cela possible.
J'ai écrit certains de mes premiers JavaScript à l'époque où Netscape Navigator était le navigateur dominant. Le développement dynamique front-end commençait lentement à devenir plus populaire à l'époque, mais l'idée de pouvoir écrire quelque chose uniquement avec HTML / CSS / JS et le faire fonctionner partout était puissante. Je suis devenu accro à cette idée et ce depuis toujours. Certaines de mes premières créations étaient de petites choses dont on pouvait rire aujourd'hui: calculatrices, générateurs de mots de passe, rien d’extraordinaire.
En tant que passionné de langues, j'ai aimé le fait que JavaScript était basé sur un prototype et faiblement typé. J'ai donc décidé de continuer à l'apprendre aux côtés d'autres langages comme le C ++. Au début des années 2000, j’ai essayé de rapprocher les langues en écrivant un petit interpréteur au-dessus de SpiderMonkey (le moteur JavaScript de Mozilla), qui me permettait d’écrire la logique de mes applications de bureau dans JS et de définir les composants de l’interface utilisateur à l’aide de C ++. C'était une idée idiote, mais j'ai beaucoup appris sur les composants internes du moteur JavaScript..
J'ai passé beaucoup de temps à créer de petits sites de loisirs, mais lorsque j'étais dans ma dernière année au lycée, j'ai décidé de vraiment me perdre dans le monde des navigateurs. J'ai écrit un moteur de rendu léger, des analyseurs syntaxiques HTML 4.01 / CSS 2.1 de base et intégré toutes ces parties dans mon propre petit navigateur. Le projet était un cauchemar pour travailler de manière fiable, en partie à cause de la façon dont les développeurs Web laxistes respectaient les normes dans leurs pages - il est amusant de se retrouver de l’autre côté de la barrière! Les plus grands défis étaient la conformité aux spécifications, le rendu de grandes tables et le maintien des performances, tout en chargeant des plugins vidéo (vous souvenez-vous du bon vieil ActiveX?).
J'ai continué à apprendre et à utiliser JavaScript en tant que développeur Web indépendant alors que j'étais à l'université, écrivant lentement des sites plus complexes et jouant avec Dojo. Ce n’est cependant que lorsque j’ai reçu une invitation à GMail en 2006 que je me suis dit que le navigateur allait devenir la prochaine plate-forme permettant de créer des applications riches. JavaScript allait jouer un grand rôle pour rendre cela possible et j'ai décidé de m'éloigner définitivement du développement d'applications de bureau..
Depuis lors, j'essaie de continuer à apprendre et, dans la mesure du possible, à faire avancer la communauté frontale grâce à mes écrits et à mes contributions à l'open source. JavaScript est pratiquement partout aujourd'hui et c'est l'une des raisons pour lesquelles j'aime cette langue. Si je veux enseigner à un de mes enfants comment créer du JavaScript, je peux simplement ouvrir mon navigateur DevTools et le leur montrer. Aucune étape de compilation supplémentaire n'est nécessaire - cela a quelque chose de vraiment spécial.
Si vous vous lancez dans un sujet non trivial avec cet état d'esprit, il est nécessaire de le décomposer en étapes simples et plus faciles à digérer.
Le secret est que je me considère un peu stupide. Vraiment. Si vous vous lancez dans un sujet non trivial avec cet état d'esprit, il est nécessaire de le décomposer en étapes simples et plus faciles à digérer, de manière à lui donner un semblant de sens..
Je pense que c'est cette perspective qui rend mon écriture accessible. J'essaie de donner un sens à ces concepts ou outils qui peuvent au début sembler assez décourageants pour le développeur moyen. Il est important de pouvoir appliquer cela aux articles et en particulier à la documentation. Alors, restez simple. Cela aide à rendre les articles plus ciblés. Comment générer autant de contenu tout en comprenant le contenu? Eh bien, je fais de la compréhension un préalable.
D'abord faites-le, ensuite faites-le bien, puis mieux le faire.
Einstein a cette excellente citation: "Si vous ne pouvez pas l'expliquer simplement, vous ne le comprenez pas assez bien" et c'est vrai. Vous ne pouvez pas enseigner ou revendiquer un cadre, un outil ou une pratique exemplaire, à moins que vous ayez réellement pris le temps de l’utiliser vous-même. Il est plus facile de trouver ce temps dans mon rôle actuel, mais à l'époque où j'étais ingénieur 9-5, je passais mon temps à déjeuner et à déjeuner activement en utilisant ce que j'écrirais plus tard le week-end..
Trouver le temps de tout faire est toujours un défi. Depuis quelques années, j'ai ce mantra que j'essaie d'appliquer à chaque tâche - "
Vous pouvez ensuite partager cette première itération avec vos pairs et avoir une idée de si vous allez dans la bonne direction ou si l'idée vaut la peine d'être poursuivie. Pour moi, cela a beaucoup plus de sens que de passer des semaines sur un brouillon ou un prototype avant de demander une contribution..
Faire partie d'une entreprise ayant des normes aussi élevées.
AOL et Google sont tous deux des entreprises avec des équipes d'ingénieurs formidables, et aucune de mes réflexions sur la culture ne concerne un groupe spécifique, mais plutôt une observation générale..
La culture d'ingénierie chez Google est telle que nous accordons une grande importance au polissage et à l'expédition de choses lorsque nous estimons que tout est parfait. Faire partie d'une entreprise ayant des normes aussi élevées.
Chez AOL, j'étais fier de l'un ou l'autre des produits ou applications que nous avions développés, mais en raison de la rapidité des affaires et de la concurrence, il n'était pas toujours possible de retarder les lancements ou les sorties pour le vernis. Je pense que c'est une réalité pour de nombreuses entreprises, malgré leur volonté de changer cette culture..
Quand il est possible de retarder la sortie des versions, comme dit Google, il faut que cela soit "correct", je pense que cela peut faire toute la différence pour vos premières impressions d'utilisateurs sur votre produit..
Je suis satisfait de la direction prise par TC39 au cours des dernières années.
Je suis ravi de la direction prise par TC39 au cours des dernières années, grâce notamment à la participation de Rick Waldron et de Yehuda Katz du projet jQuery. Ils ont porté une attention particulière aux modèles et aux bibliothèques sur lesquels les développeurs se sont beaucoup appuyés, et ont cherché à savoir comment les résoudre plus efficacement à l'aide de primitives de plate-forme. Je ne ferai pas de commentaire sur ES6 en particulier, mais je suis impatient de voir les modules, les classes, les 'laisser' et Object.observe () disponible plus largement.
Sur la communauté JavaScript: nous sommes bien placés, mais je voudrais, collectivement, passer moins de temps à créer de nouveaux cadres et plus de temps à investir dans les efforts d’amélioration des solutions existantes. Je trouve fantastique que les développeurs passent du temps à apprendre à résoudre eux-mêmes leurs problèmes - c’est l’un des meilleurs moyens d’apprendre de nouvelles choses - mais si c’est une expérience, précisez-le afin que les autres développeurs ne s’attendent pas à ce que vous mainteniez la projet. Ce genre de choses n’ajoute que du bruit, alors n’oubliez pas votre soutien lorsque vous publiez des choses.!.
L'un des grands mythes existants est qu'il existe pour remplacer JavaScript..
J'étais en fait très curieux d'en savoir plus sur les objectifs que Dart avait quand j'ai rejoint Google pour la première fois. L'un des grands mythes existants est qu'il existe pour remplacer JavaScript, mais il s'avère que ce n'est pas tout à fait vrai. Dart est destiné aux développeurs plus familiarisés avec Java, C ++ et C #, qui tentent de créer des applications Web hautes performances. et ainsi de suite, ont certaines attentes concernant leurs outils et leur langage. Je pense que c'est une raison légitime pour que quelque chose comme Dart existe.
En tant que société, JavaScript et Dart sont des technologies dans lesquelles nous croyons et dans lesquels nous investissons. Nous participons à TC39, nous travaillons sur l'avenir de JavaScript et continuons également à travailler sur V8, le moteur JavaScript rapide. Les ingénieurs de Chrome continuent de travailler pour faire avancer le Web avec de nouvelles spécifications telles que Composants Web. Pendant ce temps, l’équipe qui a initialement construit le V8 est en train de construire le Dart VM.
Revenons à votre question initiale. Je pense que la création de WebKit était beaucoup plus liée à la divergence de l'architecture multiprocessus entre les deux projets que d'essayer d'intégrer Dart dans Chrome. Dart est un projet open source distinct avec ses propres objectifs et vous pouvez toujours obtenir Dartium aujourd'hui (la version de Chromium utilisant Dart VM).
Lorsque j’ai entendu parler de Blink pour la première fois, je craignais que nous ayons maintenant un autre navigateur à prendre en charge..
Cependant, la réalité est qu’il ya déjà tellement de différences entre les différents ports WebKit que cela ne va pas avoir un impact négatif sur la façon dont vous développez et testez..
En fait, Blink nous permet de donner aux développeurs davantage d'outils, de fonctionnalités et de compatibilité dont ils ont besoin pour tirer le meilleur parti du Web en tant que plateforme. À long terme, cela nous permettra de hiérarchiser les fonctionnalités qui faciliteront la construction de la prochaine génération d'applications Web et de la même manière que la V8 nous a permis d'accélérer le développement de JavaScript. Je pense que Blink va nous permettre d'innover de manière à en tirer profit l'ensemble de la plate-forme.
Nous sommes souvent pris au piège dans le débat sur le Web par rapport au Web, mais ne parlez pas autant de la nécessité de donner la priorité à nos utilisateurs. Ils sont la mise au point. Il existe de nombreux cas où vous pouvez offrir une expérience convaincante pour le Web sur ordinateur et mobile et cela fonctionnera à merveille. Cela dit, il en existe d’autres où la plate-forme ou les navigateurs mobiles ont encore besoin de fonctionner. En tant qu’entreprise, vous devez souvent appeler pour déterminer ce qui convient le mieux à vos utilisateurs. Je pense qu’à présent, il est tout à fait judicieux d’offrir aux développeurs les meilleures plates-formes possibles pour passer un appel natif à Web, et c’est ce que nous faisons via Android et Chrome for Mobile..
Composants réutilisables.
Composants réutilisables. Traditionnellement, beaucoup d’entre nous ont développé des applications assez verticalement, en diffusant un seul concept (qu’il s’agisse de la logique ou de l’interface utilisateur) dans plusieurs parties différentes du projet. Cela rend non seulement plus difficile le maintien de l'idée, mais également l'extraction et la réutilisation de l'idée dans de futures applications sans beaucoup d'effort. Cela réduit également nos chances de pouvoir partager le composant avec d'autres.
Sans faire référence à des technologies spécifiques, nous travaillons à faciliter la définition et le regroupement des composants côté plate-forme Web. C’est maintenant qu’il est temps de réfléchir à la manière dont vos propres applications pourraient être écrites, si elles étaient décomposées. composants spécifiques.
Le front-end voit actuellement une révolution dans l’outillage avec un nombre croissant de développeurs qui commencent à utiliser Grunt et à explorer des outils de flux de travail autour de lui, comme Yeoman. Les développeurs accordent plus d’attention à ce qu’ils peuvent automatiser et je pense que cela facilitera la tâche de passer plus de temps à créer de meilleures applications et moins de temps à ces processus manuels entre.
Pour en revenir à l'idée des composants, je pense qu'entre les composants Web et la gestion des packages front-end, nous avons une énorme opportunité de vraiment changer notre façon de développer pour le Web. AngularJS (et les directives angulaires) ont réussi à réintroduire l’idée de blocs de fonctionnalités réutilisables. La gestion des paquetages a vraiment un aspect positif, par l’intermédiaire de Bower..
Écrire une application avec des listes que vous voulez rendre triables? Génial. Quelques frappes au clavier sur la ligne de commande et vous l'avez. Vous voulez que les éléments de cette liste persistent lorsque vous êtes hors ligne? Aucun problème. Quelques touches supplémentaires et vous utilisez un package qu'un autre développeur a déjà dû écrire pour obtenir cette capacité. Vous souhaitez transformer votre liste en un composant réutilisable que tout le monde peut utiliser? C'est facile. C'est l'avenir que nous travaillons.
Nous sommes chanceux de pouvoir disposer d'une multitude d'outils utiles dès le départ, des outils qui nous permettent de gagner du temps et de simplifier un peu la vie. Des abstractions telles que Sass et CoffeeScript, des frameworks tels que Twitter Bootstrap, des chargeurs de modules tels que RequireJS, une liste interminable de bibliothèques de tests MVC et unitaires. Certains diraient que nous avons l'embarras du choix et qu'il est intéressant de voir combien de temps cela prend un projet démarré.
Actualisez-vous toujours manuellement votre navigateur chaque fois que vous modifiez votre application??
Bien que ces outils fonctionnent exceptionnellement bien seuls, il peut s'avérer fastidieux de les faire travailler ensemble, en particulier si vous devez mettre en place un processus et un processus de construction où ils sont tous compilés et optimisés de manière succincte. Même si vous parvenez à mettre en place un processus de construction solide, il vous reste souvent beaucoup de temps à écrire le code standard pour votre application..
Même dans ce cas, vous devez vous demander si cela s’intègre parfaitement dans votre flux de travail quotidien. Nous développons de manière répétitive plusieurs petites étapes que nous pouvons plus facilement confier à l’outillage. Rafraîchissez-vous toujours manuellement votre navigateur chaque fois que vous modifiez votre application pour avoir un aperçu de son apparence? Vous essayez toujours de savoir si vous utilisez les dernières versions de toutes vos dépendances? Vous vous demandez s'il y a simplement quelque chose qui vous permet de continuer à coder et d'oublier beaucoup de travail acharné?
Nous aussi, c'est pourquoi nous avons commencé à nous demander si nous pouvions donner aux développeurs une solution à nombre de ces problèmes courants. Nous avons essayé de les résoudre dans le cadre d'un projet gratuit et open-source récemment publié, intitulé Yeoman. Le slogan officiel de Yeoman est le suivant: nous sommes une pile client robuste et avisée, composée d'outils et de cadres permettant aux développeurs de créer rapidement des applications Web attrayantes..
En pratique, nous sommes une série d’outils et de tâches qui vous aident à automatiser certaines des tâches les plus fastidieuses du développement front-end. Nous sommes composés de yo (l'outil d'échafaudage), de Grunt (l'outil de construction) et de bower (pour la gestion des paquets)..
Si vous constatez que vous écrivez toujours du code standard pour votre application, que vous gérez manuellement les dépendances de vos applications ou que vous créez votre propre système de construction pour utiliser les outils que vous aimez, vous trouverez peut-être un bon moyen de vous épargner des maux de tête..
La communauté des développeurs Windows pourrait vraiment nous aider ici.
Créer un outil en ligne de commande qui fonctionne bien sur plusieurs plates-formes peut être une danse délicate. L'un des défis initiaux du support Windows était qu'une grande partie de notre équipe était habituée à utiliser un système * nix et avait accès à homebrew / apt-get. Cependant, nous ne savions pas utiliser PowerShell ou Chocolatey (l'équivalent Windows d'apt-get pour Windows basé sur PowerShell) et nous avions besoin de temps pour comprendre à quel point ces solutions étaient comparables aux outils disponibles ailleurs..
Il a ensuite fallu du temps pour trouver (ou obtenir) tous les paquets dont nous avions besoin pour Chocolately car nous avions besoin de git, de fantômes, d’opting et bien d’autres. La situation s’est considérablement améliorée depuis notre première version et Windows est maintenant officiellement pris en charge avec Yeoman en suivant les instructions de notre page d’accueil..
La communauté des développeurs Windows pourrait vraiment nous aider ici en préconisant une adoption plus large d'outils tels que Chocolately et en nous aidant à atteindre la parité avec des outils tels qu'apt-get. En dehors de cela, ils ont été fantastiques et nous avons vraiment apprécié l'aide et le soutien que la communauté des développeurs Windows nous a proposés tout au long de notre route vers la compatibilité..
Je dois donner un coup de téléphone à Sindre Sorhus, Mickael Daniels et Paul Irish, qui ont tous grandement contribué à l'amélioration de nos efforts Windows au tout début..
À l'heure actuelle, de nombreux outils de développement (fantastiques) sont en cours d'écriture, qui ne sont pas simplement * nix, mais spécifiques à Mac, car leur utilisation sur plusieurs plates-formes a ses propres coûts de développement et ses frais généraux. J'adorerais voir plus de discussions ouvertes et de développement d'outils pouvant fonctionner partout, mais cela ne peut être fait sans l'aide des utilisateurs..
S'il existe un outil Windows que vous ne voyez que sur Mac, n'hésitez pas à en parler - mieux encore, envoyez une demande d'extraction.!
Essayez de savoir ce qu'il faudrait pour le transférer sous Windows (et ailleurs) et qui sait? Peut-être que les efforts combinés de plusieurs communautés suffiraient pour faire avancer les choses.
Libérer mon premier livre, Apprentissage de modèles de conception JavaScript (avec O'Reilly) était probablement la réalisation qui m'a donné le plus de satisfaction. C'était mon projet d'écriture le plus important et j'ai pris la décision de le rendre totalement open-source dès le début - un appel que je ne regretterai jamais. Rendre le matériel éducatif accessible à tous, où qu’ils soient en mesure de le payer, offre un potentiel considérable.
Il a également le potentiel d’augmenter l’impact de votre livre. Si vous êtes auteur, envisagez de le faire. Vous ne le regretterez pas!
Accentsconagua