(La seule alternative actuelle : Vanilla JavaScript

J'ai vu des développeurs qui travaillent avec C depuis longtemps, développant toujours avec MFC (Microsoft Foundation Classes). La raison est simple : il n’existe pas de véritable alternative pour créer des interfaces utilisateur en C . Bien que Qt existe, il nécessite une licence commerciale pour un usage professionnel, ce qui fait de MFC la seule option.

MFC fournit des composants d'interface utilisateur de base, mais il est toujours capable de créer des programmes de niveau production tels que des logiciels de CAO ou des applications pour les hôpitaux.

L'état actuel de l'écosystème JavaScript est assez similaire.

Aucun cadre n'a été construit spécifiquement pour répondre aux objectifs de HPSE. Bien qu'il existe des moteurs de jeu comme Babylon.js, ceux-ci n'offrent que des fonctionnalités pour les graphiques 3D et ne fournissent pas de structure globale comme le fait React.

Donc, en fin de compte, tout revient à Vanilla JavaScript et TypeScript. Ce n’est pas que les développeurs utilisent Vanilla JavaScript parce qu’ils l’adorent ; ils l'utilisent parce qu'il n'y a pas d'autre choix. Tout comme au début, lorsque les développeurs devaient tout construire à partir de zéro en C en raison du manque de frameworks commerciaux, nous sommes désormais confrontés à la même situation en JavaScript. Il n'existe aucun framework existant qui réponde pleinement aux exigences de HPSE, nous devons donc développer manuellement avec Vanilla JavaScript.

Et franchement, ce n’est pas exclusif à JavaScript. C'est également vrai pour la plupart des autres langues.

Il y a un dicton qui dit : "Un déjeuner gratuit n'existe pas."

De nombreux programmes qui ont démarré avec de grandes ambitions de briser de nouvelles frontières ont fini par s'appuyer fortement sur des fonctionnalités personnalisées intégrées directement dans le langage de programmation. HPSE a également commencé avec la vision d'exécuter un jour des programmes natifs dans le navigateur, et pour l'instant, il doit être écrit morceau par morceau en JavaScript Vanilla.

Certains pourraient dire : « Pourquoi ne pas simplement abandonner JavaScript et utiliser C ou Rust pour créer un module WebAssembly (WASM) et l'exécuter dans le navigateur à la place ? »

Il existe une bonne histoire qui répond à cette question.

On a un jour demandé dans un commentaire aux dirigeants de Babylon.js et Three.js si la technologie WASM serait l'avenir de leurs moteurs. Leur réponse a été "Non."

La raison est simple : le code C/Rust ne s’exécute pas directement dans l’environnement web, ce qui rend le débogage plus difficile. Et grâce aux avancées du moteur V8, JavaScript peut désormais atteindre des performances élevées. JavaScript est un langage de script qui s'exécute directement dans le navigateur et offre une productivité élevée : il n'est pas nécessaire d'abandonner ces atouts.

Dans le passé, les programmeurs rivalisaient en développant leurs propres systèmes d'exploitation. Mais après que Windows, Mac et Linux soient devenus des standards, l’attention s’est portée sur la façon de créer des programmes qui s’exécutent sur ces systèmes. De même, les navigateurs d’aujourd’hui ont évolué à un point tel qu’il est raisonnable de réfléchir à la manière de créer des programmes qui s’exécutent à l’intérieur de ceux-ci.

S'il y avait des lignes claires sur ce pour quoi JavaScript devrait et ne devrait pas être utilisé, et si les tâches haut de gamme étaient vraiment inadaptées à JavaScript, alors Microsoft n'aurait jamais lancé le projet Babylon.js, et Three.js ne l'aurait jamais fait. ont été créés. Il en va de même pour WebGPU, qui s'impose comme un nouveau standard Web.

Récemment, j'ai réfléchi à mon identité de développeur, me demandant ce que signifie exactement « frontend » et si ce terme peut vraiment englober la portée du développement de clients Web.

Je suis sûr qu'il y a beaucoup de désinformation dans mes pensées, mais je publierai ceci comme première entrée de blog pour consolider ce que j'ai pensé.

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!