Le Web a évolué assez rapidement au cours des 20 dernières années. De plus en plus de logique est déplacée du côté serveur vers le côté client. Non seulement cela nécessite d'écrire du code JavaScript plus complexe côté client, mais quelque chose d'étrange s'est produit ces dernières années : JavaScript migre vers le serveur et la technologie Web migre vers le bureau. Ce n’est pas nouveau, mais qui aurait pensé à cela il y a 20 ans ?
Le Web a changé, tout comme ma pile technologique. Il semble que ma pile soit revenue aux racines. Il y a 20 ans, j'ai commencé avec HTML et JavaScript, puis je suis passé à l'ASP classique en utilisant VBScript. En 2001, je suis devenu obsédé par ASP.NET et VB.NET et je les ai utilisés dans des produits. J'ai arrêté de le faire jusqu'à fin 2006. Fin 2007, j'ai commencé à écrire ASP.NET en C#. HTML et JavaScript étaient toujours impliqués, mais étaient plus ou moins encapsulés dans des contrôles tiers, et jQuery était à l'époque un alias pour JavaScript. Tout ce qui concerne JavaScript est jQuery. ASP.NET WebForms semble énorme et peu flexible, mais il fonctionne efficacement. Plus tard – en 2010 – je faisais beaucoup de choses avec Silverlight, WinForms et WPF.
ASP.NET MVC est apparu et le Web a recommencé à paraître plus naturel que ASP.NET WebForms. Du point de vue d'un développeur ASP.NET, le Web commence à s'améliorer : plus propre, plus flexible, plus léger et plus naturel.
Mais quelque chose de nouveau est également apparu. Quelque chose en dehors du monde ASP.NET. Bibliothèques JavaScript puissantes comme KnockOut, Backbone, et plus tard Angular et React. Le premier framework d'application d'une seule page (désolé, je ne veux pas mentionner le merdique ASP.NET AJAX...) est apparu et la logique de l'interface utilisateur a été déplacée du serveur vers le client. (D'accord, nous avons eu un SPA sympa en 2005, mais nous n'avons pas trouvé comment créer un cadre avec.)
NodeJS change à nouveau le monde en utilisant JavaScript sur le serveur. Vous n'avez besoin que de deux langages différents (HTML et JavaScript) pour créer des applications Web sympas. Je ne suis pas vraiment intéressé par NodeJS, sauf pour l'utiliser en backend, puisque certains outils sont basés sur NodeJS. C'est peut-être un bug, qui sait ; )
Maintenant que nous disposons d'ASP.NET Core, cela semble beaucoup plus naturel que l'ASP.NET MVC traditionnel. Le soi-disant naturel dans ce cas signifie que cela ressemble presque à l’écriture d’ASP traditionnel. Cela signifie travailler avec le Web sans état plutôt que d’essayer de le réparer. Travailler avec Request and Response est plus simple que ASP.NET MVC traditionnel, et encore plus simple que ASP.NET WebForms. Naturel ne signifie pas que vous devez écrire les mêmes conneries non structurées que l'ASP traditionnel. ; )
Parce que nous avons déjà un framework JavaScript côté client très sympa. Avec un framework côté serveur simplifié et minimaliste, la partie serveur est réduite à simplement servir des fichiers et des données statiques sur un service REST.
C’est à ce moment qu’il est logique d’avoir une compréhension plus approfondie de TypeScript. Mais à ce stade, cela n’a aucun sens pour moi. Je code en JavaScript depuis probablement 20 ans, mais je n'ai jamais écrit autant de code JavaScript dans un seul projet. Puis, au cours des dernières années, j'ai commencé à utiliser AngularJS. Angular2 est l'une des raisons pour lesquelles TypeScript doit être étudié attentivement, car l'Angular2 actuel est entièrement écrit en TypeScript.
Il y a quelques semaines, j'ai lancé mon premier vrai projet NodeJS : une application de bureau qui utilise NodeJS pour fournir aux utilisateurs un environnement d'exécution de script très flexible. NodeJS fournit des fonctionnalités et une interface utilisateur aux utilisateurs, toutes écrites en TypeScript au lieu de JavaScript simple. Pourquoi? Parce que TypeScript présente de nombreux avantages inattendus :
Peut toujours écrire du JavaScript
Aide à écrire de petits modules et du code structuré
Aide à écrire des modules compatibles NodeJS
De manière générale, il n'est pas nécessaire d'écrire tout le code JavaScript pour chaque module
Concentrez-vous simplement sur les fonctionnalités dont vous avez besoin pour écrire
C'est pourquoi TypeScript est d'une grande aide pour moi. Bien sûr, les langages typés sont utiles dans de nombreuses situations, mais - après avoir travaillé avec JS pendant 20 ans - j'aime la flexibilité du langage JavaScript implicitement typé, et je le connais bien. Cela signifie que, de mon point de vue, l'avantage de TypeScript est que je peux toujours écrire du code implicitement tapé dans TypeScript et profiter de la flexibilité de JavaScript. C'est pourquoi j'ai dit "il est toujours possible d'écrire du JavaScript".
La technologie Web a changé, ma pile technologique a changé, tout comme les outils. Toutes ces choses deviennent plus légères, ainsi que les outils. La console est de retour et les IDE reviennent à leurs racines : rien de plus que des éditeurs de texte dotés de fonctionnalités telles que la coloration syntaxique et IntelliSense. Actuellement, je préfère utiliser le couteau suisse de Visual Studio Code ou Adobe Brackets, selon le type de projet sur lequel je travaille. Les deux démarrent très vite et incluent des fonctionnalités intéressantes.
C'est un plaisir d'utiliser un IDE léger. Tout est rapide car les ressources de la machine sont disponibles via l'application que je dois développer, plutôt que via l'IDE que je dois utiliser pour développer l'application. Cela rend le développement beaucoup plus rapide.
Lancer un IDE aujourd'hui signifie lancer cmder (ma console préférée sous Windows), changer le dossier du projet, lancer une commande de console pour afficher le fichier dactylographié, l'enregistrer et le compiler. Je peux lancer une autre console pour utiliser des outils comme NPM, gulp, typings, dotnet CLI, NodeJS, etc. ainsi que lancer mon éditeur léger préféré pour écrire du code ! : )
Texte original : Comment le développement Web a changé pour moi au cours des 20 dernières années
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!