The rise of JS
•Télécharger en tant que PPTX, PDF•
0 j'aime•136 vues
Il y a 20 ans, personne de sobre n’aurait utilisé Javascript pour autre chose que des étoiles filantes qui sortent de ta souris. Pourtant aujourd’hui, javascript est l’un des langages les plus utilisés au monde, tellement qu’on fait même du backend avec. Comment en est-on arrivé là? C’est ça inspecteur. C’est ça la bonne question.
Recommandé
Recommandé
Contenu connexe
Similaire à The rise of JS
Similaire à The rise of JS (20)
Plus de Loic Ortola
Plus de Loic Ortola (7)
The rise of JS
- 1. The Rise of JS Loïc Ortola
- 6. • Programmer dans le navigateur • Event-driven • Pour les noobs…
- 9. Brendan Eich Java Scheme Self Mocha
- 10. Brendan Eich Java Scheme Self Mocha LiveScript
- 12. Brendan Eich Java Scheme Self Mocha LiveScript JavaScript
- 13. JavaScript Netscape : Mocha, SpiderMonkey Microsoft : Jscript …. MMMmhhh… Standards
- 14. Making JavaScript a Standard
- 15. Making JavaScript a Standard Standard Comité ECMA-262 TC39
- 16. ES EcmaScript ES1 : Juin 1997 ES2 : Aout 1998 ES3 : Décembre 1999 … ES5 : Décembre 2009 ES6 : Juin 2015 ES2015 … ES2016 … ES2017 …
- 22. jQuery
- 38. On veut quoi? Faire des APIs Du responsive Développer des applis entièrement dans le browser
- 40. 0) Des standards rafraichis Lars Bak
- 41. Responsive design HTML 5, CSS 3 Media Queries, Flexbox, Video Canvas, WebGL, History API, Local Storage Pre-processors (LESS, SASS) Helper-Librairies (Twitter Bootstrap)
- 42. 1) Un interpréteur rapide Lars Bak
- 43. Javascript Engine vs Rendering / Layout Engine Browser JS Engine Rendering Engine Chrome V8 Blink (fork of WebKit) Firefox TraceMonkey (ex SpiderMonkey) Gecko Safari Nitro (ex: SquirrelFish) WebKit (fork of KHTML & KJS) IE Chakra Trident Edge Chakra (ChakraCore) EdgeHTML Opera V8 Blink
- 44. 2) De nouveaux Frameworks
- 45. Node.js 1 user = 1 thread ? Non-Blocking, Event-loop based (Reactive?) Jordan Walke – Pete Hunt
- 46. Angular(.js)? Misko Hevery – Adam Abrons
- 47. React.js “Templates separate technologies, not concerns” Pete Hunt Jordan Walke – Pete Hunt
- 48. 3) Testing
- 49. 4) Build / Dependency mgmt
- 50. What’s up with JS? CoffeeScript en 2009 TypeScript en 2012 Kotlin en 2016 WebAssembly en 2017
- 52. Et maintenant?
- 53. Loïc Ortola Tech Advocate @ Takima Loïc Ortola @LoicOrtola loic@takima.fr DevOps – Archi Java – Node.js –React – Android – IoT
Notes de l'éditeur
- 65M users in 1 year and a half. Jamais eu 65M of users de quoi que ce soit. https://www.youtube.com/watch?v=_L3Y2_YiT-A Le navigateur peut être une plateforme alternative en 1994… Microsoft comprend. Le 26 May 1995 http://www.lettersofnote.com/2011/07/internet-tidal-wave.html Bill Gates envoit un mail un soir à toutes ses équipes qui s’appelle “The Internet Tidal Wave” Il déclare que le web est la plus grande invention après le PC. Il identifie Netscape comme LE compétiteur à descendre. Netscape de son côté fait une IPO alors qu’ils n’ont quasi pas de revenu et explosent à l’ouverture des marchés. Ils sont identifiés comme LA boite. Ils deviennent des superstars… un peu arrogants aussi... On va sur Netscape, pas sur Internet ou pas sur le World Wide Web Ils trouvent leur marché: vendre leur suite logicielle. De 2 manières: en vendant des licences au niveau des constructeurs en vendant en physique (disquettes ou CD-ROM)
- Pendant que l’équipe bosse d’arrache pied sur le support de l’Applet dans Netscape, On demande à Brendan Eich de créer un langage de scripting serveur LiveScript pour renforcer l’offre commerciale de serveurs web chez Netscape. Le 4 décembre 1995, conférence de Presse avec Netscape et Sun qui annoncent ensemble l’arrivée de Javascript comme complément de Java. C’est un pur coup marketing de la part de Netscape. Implémentation se fait en mars 1996 avec la sortie de Netscape 2.0 Il travaille ensuite sur une version Client, qui sort en 1996 sous le nom de javascript. Microsoft fait un reverse engineering rapidement appelé Jscript, qui sortira avec IE3 en Aout 1996. et Netscape soumet alors la spec pour standardisation à l’ECMA qui finira en juin 1997 http://tech-insider.org/java/research/1995/1204.html
- Développeur Kernel à Silicon Graphics Il dit qu’il peut faire un interpreteur Scheme pour le navigateur. Scheme dialecte de Lisp développé au MIT qui etait fonctionnel, dynamique…
- Développeur Kernel à Silicon Graphics Il dit qu’il peut faire un interpreteur Scheme pour le navigateur. Scheme dialecte de Lisp développé au MIT qui etait fonctionnel, dynamique…
- Fais un truc populaire, comme Java, pour les enfants quoi… En 10 jours, il a implémenté un nouveau langage de programmation. La syntaxe il a pris de Java De scheme il a pris le coté fonctionnel Et il y avait aussi un autre langage Self (dialecte de Smalltalk) développé par Xerox Park et plus tard à Sun Labs. Self changeait des choses par rapport à SmallTalk (un des premiers vrais langages orientés objets) en enlevant notamment les classes. Et en May 1995 ils annoncent Mocha, le premier langage de scripting pour le navigateur
- Bon Mocha c’était un peu “fléché Java”, ils l’ont très vite renommé LiveScript.
- Quand Sun sort java, le deal c’est Java est le langage du navigateur, si vous développez sur la JVM, vous serez libéré de Microsoft. Netscape pitch la même chose: si vous utilisez les langages du web, l’OS ne compte plus, tout sera pareil de partout. Le Sun / Netscape Deal: Netscape ajoute java dans le navigateur Sun arrête le développement de HotJava / WebRunner LiveScript doit être tué… Netscape refuse
- Bon Mocha c’était un peu “fléché Java”, ils l’ont très vite renommé LiveScript.
- European Computer Manufacturers Association. Netscape lance le truc Microsoft rejoint le comité, et le domine d’ailleurs. Ils insistent pour que tous les “bugs” restent dans le standard Ils ne peuvent pas l’appeler JavaScript… WebScript, NetScript… ECMAScript ECMA 262
- C’est cool sauf que du coup, on transforme un peu nos Webapps. D’un côté on code des pages PHP, JSP, ASP pour le serveur d’application, de l’autre côté on expose des APIs XML (ou JSON) et on développe des libs JS qui commencent à prendre de la place. C’est difficile à maintenir, et c’est un peu le grand écart pour les devs…
- Sauf qu’au fur et à mesure que le web devient grand public, on voit apparaitre de nouveaux usages, de nouveaux besoins. Jusqu’en 2001, aucun moyen de communiquer avec une API depuis JS. 2002 AJAX
- ECMA-357 E4X (ECMASCRIPT 4 XML)
- Jquery a permis 3 trucs - Faciliter l’accès et les manipulations du DOM - One API for all browsers - Faciliter la communication avec des APIs externes
- C’est cool sauf que du coup, on transforme un peu nos Webapps. D’un côté on code des pages PHP, JSP, ASP pour le serveur d’application, de l’autre côté on expose des APIs XML (ou JSON) et on développe des libs JS qui commencent à prendre de la place. C’est difficile à maintenir, et c’est un peu le grand écart pour les devs…
- C’est cool sauf que du coup, on transforme un peu nos Webapps. D’un côté on code des pages PHP, JSP, ASP pour le serveur d’application, de l’autre côté on expose des APIs XML (ou JSON) et on développe des libs JS qui commencent à prendre de la place. C’est difficile à maintenir, et c’est un peu le grand écart pour les devs…
- C’est cool sauf que du coup, on transforme un peu nos Webapps. D’un côté on code des pages PHP, JSP, ASP pour le serveur d’application, de l’autre côté on expose des APIs XML (ou JSON) et on développe des libs JS qui commencent à prendre de la place. C’est difficile à maintenir, et c’est un peu le grand écart pour les devs…
- C’est cool sauf que du coup, on transforme un peu nos Webapps. D’un côté on code des pages PHP, JSP, ASP pour le serveur d’application, de l’autre côté on expose des APIs XML (ou JSON) et on développe des libs JS qui commencent à prendre de la place. C’est difficile à maintenir, et c’est un peu le grand écart pour les devs…
- C’est cool sauf que du coup, on transforme un peu nos Webapps. D’un côté on code des pages PHP, JSP, ASP pour le serveur d’application, de l’autre côté on expose des APIs XML (ou JSON) et on développe des libs JS qui commencent à prendre de la place. C’est difficile à maintenir, et c’est un peu le grand écart pour les devs…
- Un site-web n’est plus suffisant. Différents terminaux, résolutions, paradigmes. Le XML n’est plus un format de transport adapté Avènement du web social
- Un site-web n’est plus suffisant. Différents terminaux, résolutions, paradigmes. Le XML n’est plus un format de transport adapté Avènement du web social
- Un site-web n’est plus suffisant. Différents terminaux, résolutions, paradigmes. Le XML n’est plus un format de transport adapté Avènement du web social
- Un site-web n’est plus suffisant. Différents terminaux, résolutions, paradigmes. Le XML n’est plus un format de transport adapté Avènement du web social
- Un site-web n’est plus suffisant. Différents terminaux, résolutions, paradigmes. Le XML n’est plus un format de transport adapté Avènement du web social
- Un site-web n’est plus suffisant. Différents terminaux, résolutions, paradigmes. Le XML n’est plus un format de transport adapté Avènement du web social
- C’est cool sauf que du coup, on transforme un peu nos Webapps. D’un côté on code des pages PHP, JSP, ASP pour le serveur d’application, de l’autre côté on expose des APIs XML (ou JSON) et on développe des libs JS qui commencent à prendre de la place. C’est difficile à maintenir, et c’est un peu le grand écart pour les devs…
- C’est cool sauf que du coup, on transforme un peu nos Webapps. D’un côté on code des pages PHP, JSP, ASP pour le serveur d’application, de l’autre côté on expose des APIs XML (ou JSON) et on développe des libs JS qui commencent à prendre de la place. C’est difficile à maintenir, et c’est un peu le grand écart pour les devs…
- C’est cool sauf que du coup, on transforme un peu nos Webapps. D’un côté on code des pages PHP, JSP, ASP pour le serveur d’application, de l’autre côté on expose des APIs XML (ou JSON) et on développe des libs JS qui commencent à prendre de la place. C’est difficile à maintenir, et c’est un peu le grand écart pour les devs…
- Donc en gros: - J’ai besoin de faire des APIs - Faut que je développe tout mon code web au même endroit (vu que je dois faire des APIs, autant tout consommer depuis les APIs non?) - J’ai besoin de faire évoluer les langages du web pour le responsive
- HTML, JS, CSS… Ahh oui mais attendez. Comment je fais des imports? Des composants? Des modules? Des injections de dépendances? Impossible.
- SASS 2006-2007 (mais vraiment bien utilisé à partir de 2012 depuis le rewrite en C de libSass) LESS c’est en 2009
- Import Injection de dépendances Client HTTP Liaison entre le monde JS et le monde HTML, gestion et manipulation du DOM?
- Ryan Dahl, un mec tout seul https://www.youtube.com/watch?v=ztspvPYybIY 8000 Lignes de C en 2009 Utilise commonjs
- Import Injection de dépendances Client HTTP Liaison entre le monde JS et le monde HTML, gestion et manipulation du DOM? Misko Hevery DOM à manipuler Donnée à récupérer Qui vient d’une DB, Sécurisée, à travers une API, etc… C’est toujours pareil. Je veux simplifier ça pour les gens qui ne sont pas développeurs, mais plutôt pour les web-designers <angular/> ==> Managed database in the cloud ==> Des APIs (ng-init, ng-repeat, ng-entity) pour pouvoir mettre à jour le DOM simplement L’idée était vraiment d’être HTML-driven. Dans l’idéal, on ne ferait que d’utiliser les balises classiques <>. ==> Son pote Adam Abrons qui travaillait aussi sur le projet l’a appelé Angular parce que les balises HTML sont angulaires… Ils ont lancé leur plateforme sur getangular.com, ça n’a pas marché. En parallèle, Misko travaillait à Google sur un projet interne, Google Feedback depuis 6 mois, qui utilisait GWT (Un framework Java qui permettait de faire des applis web dynamiques avec AJAX), qui était malheureusement ultra stateful, complexe car nécessitant de transpiler les classes à chaque modif, Il a été ballsy et a réécrit l’ensemble en 3 semaines avec Angular. Comme le senior VP of engineering n’avait pas partagé leur vision, ils décident de l’OpenSourcer en octobre 2010, où ils drop tout ce qui est database management. Objectif: Un framework javascript pour gérer sa one-page app. Il y avait déjà beaucoup de choses: modules, DI, two-way databinding, Forms, Promises, Hashbang URLs… The rest is history. Angular.js, c’est le premier framework javascript qui permet de presque s’affranchir des manipulations du DOM. Il séduit par son architecture MVC proche de ce qu’on peut retrouver dans un backend classique. Parce qu’avant, pas d’imports. Pas d’injection de dépendances dans vos objets métier.
- 2011 Jordan Walke crée FaxJS, un Framework pour faire du UI rendering en Javascript avec mise à jour automatique et une structure orientée composants. Un composant c’est du code, une vue, un style En 2012 Facebook Ads était trop gros, il fallait vraiment un framework pour gérer le view rendering efficacement, il a créé React. Après le rachat d’IG, ils ont du se bouger pour sortir la librairie et la rendre générique et éventuellement Opensourcable. C’est Pete Hunt qui a bien bossé dessus. Ce qui est fou avec React, c’est qu’il viole des bonnes pratiques qui étaient établies depuis longtemps et les remet en question. Typiquement, séparer la présentation de la logique. React n’a pas de templates quand il sort. Il cible les directives angular par exemple Couplage et Cohésion Le markup et la logique d’affichage sont couplés par nature. Ils font la même chose. Les templates séparent les TECHNOLOGIES, non les responsabilités. Quand on a un langage de markup, il faut être super créatif pour retrouver toute la panoplie des paradigmes dont on aura besoin et qu’on a déjà nativement dans JS par exemple. Paradoxalement, spécifier tout le markup dans du langage comme JS est une hérésie, car c’est fait pour déclarer de la logique.
- Unit Integration UI / Functional
- Import Injection de dépendances Client HTTP Liaison entre le monde JS et le monde HTML, gestion et manipulation du DOM?
- Chaque jour, un nouveau FW Avant: concentration Maintenant: micro-service, micro-choix Web, DBs, Backend / Cloud Pendant 8 ans, il était rare qu’un jour passe sans qu’un nouveau framework ou version web arrive. Avant on était plutôt dans une ère de concentration des technologies. JEE, .Net, PHP. Aujourd’hui, à l’ère du micro-service, on est passés dans une époque de micro-choix. Il va falloir tout choisir. La couleur de la peinture, le gravier pour les moellons, etc… Et là je ne parle pas que du web. C’est aussi vrai pour les DBs, c’est aussi vrai pour les technologies backend.
- Stabilisé Maturé Encore des choses pas matures: SSR, Metadata / i18n Aujourd’hui, on commence à voir que cela se stabilise. Le marché a fait ses choix, et les technos commencent à se concentrer et maturer, chacun dans son style. Mais certains besoins ne sont pas encore tout à fait matures: Server-side rendering Metadata & SEO On revoit émerger le besoin de disposer d’une génération de la page en avance. Deux utilités: Le temps avant le premier affichage et la réduction de la WAN-latency des différents services.