Un tas de nouveaux outils de développeur ont atterri au cours de la dernière année et ils mordaient les outils qui ont dominé le développement frontal au cours des dernières années, notamment WebPack, Babel, Rollup, Parcel, Create-React-App.
Ces nouveaux outils ne sont pas conçus pour remplir exactement la même fonction, et chacun a des choses différentes qu'ils essaient d'obtenir et des fonctionnalités pour y arriver. Malgré leurs différences, ces outils partagent un objectif commun: améliorer l'expérience du développeur.
Plus précisément, j'aimerais évaluer chacun, décrivant ce qu'ils font, pourquoi nous en avons besoin et leurs cas d'utilisation. Je me rends compte que les comparaisons ne sont pas toujours justes. Encore une fois, ce n'est pas comme les choses que nous envisageons dans cet article sont des concurrents directs. En fait, Snowpack et Vite utilisent en fait Esbuild sous le capot pour certaines tâches. Notre objectif est davantage d'obtenir une meilleure vue du paysage des outils de développeur qui exécutent des tâches pour faciliter notre travail. De cette façon, nous voyons quelles options existent et comment ils s'accumulent, afin que nous puissions faire les meilleurs choix lorsque nous en avons besoin.
Bien sûr, tout cela sera coloré par mon expérience en utilisant React et Preact. Je suis plus familier avec ces bibliothèques de frameworks , mais nous examinerons également leur support pour d'autres cadres frontaux.
Il y a eu beaucoup de grands articles, flux et podcasts sur ces nouveaux outils de développeur. Il y a quelques épisodes Shoptalk Show que je recommanderais pour plus de contexte: l'épisode 454 discute de Vite et de l'épisode 448 Les créateurs de WMR et Snowpack. Quelque chose qui se démarque de ces épisodes est qu'une énorme quantité de travail a été consacrée à la construction de ces outils pour moderniser nos environnements de développeurs.
En partie, je pense que ces outils arrivent en réaction à la fatigue de l'outillage JavaScript - quelque chose de bien capturé dans cet article sur l'apprentissage de JavaScript en 2016. Ils remplissent également un milieu manquant entre la rédaction d'un seul fichier JavaScript à la vanille, et devoir télécharger 200 mégaoctets de dépendances à l'outillage avant d'avoir écrit une ligne de votre propre code. Ils viennent des batteries incluses sans la liste de dépendances et font partie d'une tendance des couches d'effondrement dans l'écosystème JavaScript.
Snowpack, Vite et WMR ont tous été activés par des modules JavaScript natifs dans le navigateur. En 2018, Firefox 60 a été publié avec les modules ECMAScript 2015 activés par défaut. Depuis lors, tous les principaux moteurs de navigateur ont pris en charge les modules JavaScript natifs. Node.js a également été expédié avec des modules JavaScript natifs en novembre 2019. Nous découvrons toujours quelles possibilités les modules JavaScript natifs déverrouillent aujourd'hui en 2021.
Que nous utilisions WebPack, Rollup ou Parcel pour un serveur de développement, l'outil regroupe notre base de code entière à partir de notre code source et d'un dossier Node_Modules, les exécute via des processus de construction - comme Babel, TypeScript ou PostCSS - pousse ensuite le code groupé vers notre navigateur. Tout cela prend du travail et peut ralentir les serveurs de développement à une rampe dans des bases de code plus grandes, même après tout le travail qui est entré dans la mise en cache et l'optimisation.
Les serveurs de développement neigeux, VITE et WMR ne suivent pas ce modèle. Au lieu de cela, ils attendent que le navigateur trouve une instruction d'importation et fait une demande HTTP pour le module. Ce n'est qu'après cette demande que l'outil s'appliquera les transformations au module demandé et à tous les nœuds de feuilles de l'arborescence d'importation du module, puis les servent au navigateur. Cela accélère beaucoup les choses car il y a moins de travail dans le processus de poussée vers un serveur de développement.
Vous remarquerez Esbuild manquant sur cette image. C'est un bundler avant tout. Il ne sait pas le côté de la façon dont les autres outils le font. Au lieu de cela, Esbuild traite le code extrêmement rapide en évitant les transformations coûteuses, en tirant parti de la parallélisation et en utilisant le langage Go.
J'ai pris l'une des applications d'exemples des documents React et je l'ai reconstruit avec chaque outil couvert dans cet article. Le projet avec lequel je suis allé a été tourné par Yogita Verma. Voici un lien vers le dépôt d'origine et un lien vers mon dépôt avec les quatre versions de Snap Shot, chacune utilisant un outil de construction différent. Nous comparerons la sortie de chaque étape de construction plus tard. La reconstruction de cette application m'a permis de tester l'expérience du développeur visant à tirer des dépendances REATC assez standard dans les outils, y compris le routeur React et Axios.
Avant d'entrer dans les spécificités de chaque outil individuel, ils prennent tous en charge les fonctionnalités suivantes de la boîte (à des degrés divers):
Tous ces outils peuvent compiler TypeScript en JavaScript, mais le feront même s'il existe des erreurs de type . Pour une vérification appropriée, vous devez installer TypeScript et exécuter TSC --NoEMIT sur votre fichier javascript racine, ou alternativement, utilisez des plugins d'éditeur pour surveiller les erreurs de type.
Ok, regardons chaque outil.
Esbuild a été créé par Evan Wallace (CTO de Figma). Sa principale caractéristique est qu'elle fournit une construction étape 10 × -100 × plus rapide que les bundlers basés sur des nœuds (par leurs propres repères). Il ne fournit pas de nombreuses commodités de développeur que vous pourriez trouver dans quelque chose comme Create-REACT-App. Mais il y a de plus en plus de démarreurs d'Esbuild surgissant qui comble ces lacunes, notamment Create-React-App-Esbuild, Estrella et Snowpack, qui utilise Esbuild pour son étape de construction.
Esbuild est très nouveau. Il n'a pas encore atteint une version 1.0 et n'est pas tout à fait prêt pour une utilisation en production - mais ce n'est pas loin. Il vous donne des API JavaScript et ligne de commande intuitive avec des défauts intelligents.
Esbuild change complet dans le monde de Bundler. Il va être plus utile dans les grandes bases de code où la différence de vitesse entre Esbuild et les bundlers de nœuds se multiplie. Quand Esbuild sortira 1.0, il sera très utile dans les grands sites de production et permettront d'économiser des équipes beaucoup de temps en attendant que les constructions se terminent. Malheureusement, les grands sites de production devront attendre que Esbuild devienne stable. En attendant, il sera juste bon d'ajouter de la vitesse à votre regroupement dans des projets secondaires.
La vitesse rapide d'Esbuild sera un bonus pour tout type de travail que vous faites. Moins de temps passé à attendre que les constructions courent seront toujours bonnes pour l'expérience du développeur! Cela a considéré, si vous prototypez des applications rapides, vous voudrez peut-être commencer par quelque chose de plus élevé que Esbuild - sinon, vous devrez passer un peu de temps à tirer des dépendances et à configurer votre environnement avant d'obtenir les commodités que nous attendons dans l'écosystème JavaScript. De plus, si vous souhaitez minimiser la taille de votre bundle autant que possible, vous voudrez peut-être utiliser Rollup et Terser, ce qui produira des tailles de faisceaux légèrement plus petites.
J'ai décidé de démarrer un projet React dans Esbuild d'une manière naïve: NPM installant Esbuild, React et Reactdom. J'ai créé un fichier src / app.jsx et un fichier DIST / index.html. Ensuite, j'ai utilisé la commande suivante pour compiler l'application dans un fichier dist / bundle.js:
./node_modules/.bin/esbuild src / app.jsx --bundle --platform = Browser --outfile = dist / bundle.js
Lorsque j'ai hébergé et ouvert Index.html dans le navigateur, j'ai rencontré l'écran «Écran blanc de la mort» et une erreur de référence «non apprise: le processus n'est pas défini». Les documents et la CLI expliquent exactement ce que vous devez faire pour éviter cela, mais cela pourrait être un peu un «gotcha» pour les débutants, car cela nécessite un argument supplémentaire lorsque le regroupement réagit:
--fine: process.env.node_env = \ "Production \"
Ou, si vous incluez Esbuild dans des scripts NPM écrits comme celui-ci pour échapper aux citations:
--fine: process.env.node_env = \\\ "Production \\\"
Cet argument de définition est nécessaire pour toute bibliothèque regroupée pour le navigateur qui s'attend à des variables d'environnement de nœud. Vue 2.0 s'attend également à celles-ci. Vous n'aurez pas le même problème avec PREACT car il ne s'attend pas à des variables d'environnement et à des navires prêts pour le navigateur par défaut.
Après avoir exécuté la commande avec l'argument Define, mon application «Hello World» React fonctionnait parfaitement. JSX fonctionne hors de la boîte avec des fichiers .jsx. Cela dit, React doit être importé manuellement, puis JSX est converti en react.CreateElement. Cependant, il existe des moyens d'ajouter des importations automatiques dans JSX et / ou de configurer JSX pour Preact.
Esbuild fournit une option --serve pour un serveur de développement. Cela contourne le système de fichiers et sert des modules directement à partir de la mémoire, garantissant que le navigateur ne tire pas des versions plus anciennes des modules. Cependant, il n'inclut pas le rechargement en direct / chaud, vous vous retrouverez donc à rafraîchir le navigateur après avoir sauvé, ce qui n'est pas une expérience idéale.
J'ai décidé d'utiliser la fonction de montre nouvellement publiée. Mais nous avons encore besoin d'un serveur pour voir nos modifications enregistrées. Nous pouvons attirer un package de serveurs de développement, comme le serviteur de Luke Jackson:
NPM Install Servor --Save-Dev
Ensuite, nous pouvons utiliser l'API JavaScript Esbuild pour démarrer en tant que serveur et exécuter le mode de montre d'Esbuild en même temps. Créons un fichier à la racine de notre projet appelé watch.js:
// watch.js
const eSebuild = require ("esbuild");
const Servor = require ("serveur");
esbuild.build ({
// transmet toutes les options à Esbuild ici ...
Entrée: ["src / app.jsx"],
Outdir: "Dist",
définir: {"process.env.node_env": '"production"'},
Regarder: vrai,
});
fonction asynchrone Serve () {
console.log ("Running Server depuis: http: // localhost: 8080 /");
attendre le serviteur ({
// transmet toutes les options au serviteur ici ...
Navigateur: vrai,
Racine: "Dist",
Port: 8080,
});
}
servir();Maintenant, exécutez Node Watch.js dans la ligne de commande. Cela nous donne un joli serveur de développement, mais encore une fois, cela ne nous donne pas un remplacement de module chaud ou un rafraîchissement rapide (c'est-à-dire que votre état côté client ne sera pas conservé). Mais c'était suffisant pour mes besoins de test.
Même si nous rebondissons toute notre application chaque fois que nous enregistrons un fichier, nous aurions besoin d'avoir une application assez massive avant que Esbuild ne ralentit. Après avoir configuré cet outillage, j'obtenais des commentaires instantanés des modifications. Mon ordinateur utilise un Intel i7 de 2012, donc ce n'est certainement pas une machine haut de gamme.
Si vous avez besoin d'une version préconfigurée d'Esbuild avec un rechargement en direct et de quelques défauts de défaut, vous pouvez cloner ce repo.
Esbuild peut importer des CSS en JavaScript si c'est votre style. Il compilera CSS dans un fichier de sortie avec le même nom que votre fichier JavaScript principal. Il peut également regrouper les instructions CSS @Import par défaut. Il n'y a pas de support pour les modules CSS, mais il y a des plans pour cela.
Il existe une communauté croissante de plugins pour Esbuild. Par exemple, il existe des plugins disponibles pour les composants de fichier unique Vue et les composants Svelte.
Esbuild fonctionne avec les fichiers JSON et peut les regrouper en modules JavaScript sans aucune configuration.
Il peut également importer des images en JavaScript avec la possibilité de les convertir en URL de données ou de les copier dans un dossier de sortie. Ce comportement n'est pas activé par défaut, mais vous pouvez ajouter ce qui suit dans votre objet Esbuild Config pour activer l'une ou l'autre des options:
chargeur: {'.png': 'dataUrl'} // se convertit en URL de données dans JS Bundle
Loader: {'.png': 'file'} // copies to sorping dossierLe fractionnement du code semble être un travail en cours, mais il est principalement là dans le format de sortie ESM, et il semble que ce soit une priorité pour le projet. Il convient également de mentionner que la partage d'arbres est intégrée à Esbuild par défaut et ne peut pas être désactivée.
L'utilisation des options «Minify» et «Bundle» dans votre commande Esbuild ne créera pas un pack aussi petit qu'un pipeline Rollup / Terser. En effet Cependant, la différence peut être assez négligeable et en vaut la peine pour l'augmentation de la vitesse de regroupement, selon votre projet. Dans mon clone de l'application Snap Shot, Esbuild a créé un paquet de 177 Ko qui n'est pas beaucoup plus que les 165 Ko produits par Vite, qui utilise Rollup et Terser.
Esbuild est un outil extrêmement puissant. Mais il pourrait être difficile si vous êtes habitué aux configurations zéro config. Si vous en avez besoin de plus, vous voudrez peut-être jeter un œil au prochain outil, neige, qui utilise Esbuild.
Snowpack est un outil de construction des créateurs de Skypack et Pika. Il fournit un serveur de développement impressionnant et a été créé avec une philosophie de «développement non déposé». Pour citer la documentation: "Vous devriez pouvoir utiliser un bundler parce que vous le souhaitez, et non parce que vous en avez besoin."
Par défaut, l'étape de construction de Snowpack ne regroupe pas les fichiers dans un seul package mais fournit des esmodules non déposés qui s'exécutent dans le navigateur. Esbuild y est en fait inclus comme une dépendance, mais l'idée est d'utiliser des modules JavaScript et uniquement du lot avec Esbuild lorsqu'il est nécessaire.
Snowpack a une documentation assez lisse, y compris une liste de guides pour l'utiliser avec des frameworks JavaScript, et un tas de modèles pour eux. Certains guides sont toujours un travail en cours, mais d'autres comme celui de React sont agréables et clairs. Il semble également que Snowpack traite Svelte comme un citoyen de première classe. En fait, j'ai entendu parler pour la première fois de Snowpack de la conversation du «développement Web futuriste» de Rich Harris au Svelte Summit 2020.
Le manteau neigeux est un bon choix si vous voulez doubler le déploiement dégroupé. Vous pouvez écrire du code source avec un petit nombre de modules. Cela signifierait que vous ne créez pas une grande cascade de demande avec une construction dégroupée. Si vous n'avez pas besoin de la complexité supplémentaire et de la dette technique du regroupement, alors Snowpack est un excellent choix. Un bon cas d'utilisation serait si vous adoptez progressivement un cadre frontal dans une application de serveur ou statique. Vous tireriez le moins d'outillage possible à partir de l'écosystème du nœud, mais vous obtiendrez toujours les avantages des cadres de frontend déclaratifs.
Deuxièmement, je dirais que Snowpack est un grand wrapper autour d'Esbuild. Si vous souhaitez essayer Esbuild mais que vous souhaitez également un serveur de développement et des modèles pré-écrits pour les frameworks frontaux, vous ne pouvez pas vous tromper avec Snowpack. Activez Esbuild dans l'étape de construction de votre configuration de neige et vous êtes prêt à y aller.
Comme les choses se tiennent actuellement, je dirais que Snowpack ne serait pas le meilleur remplacement pour un outil de configuration zéro comme Create-React-App, car vous devrez attirer les plugins et les configurer vous-même si vous avez une grande application et avez besoin d'une étape de construction à la production optimisée à superposition.
Commençons un projet avec Snowpack en sautant dans la ligne de commande:
mkdir neige de neige CD SnowpackProject NPM INIT #FILL avec des défauts NPM Installer Snowpack
Maintenant, ajoutons ce qui suit à package.json:
// package.json
"scripts": {
"Start": "Snowpack Dev",
"Build": "Build Snowpack"
},Ensuite, nous allons créer un fichier de configuration:
// mac ou linux Toucher Snowpack.config.js // Windows neige de neige neige.config.js
Je pense que la partie la plus magique du manteau neigeux vient lors de la définition d'une paire de valeurs de clé innocente dans le fichier de configuration. Collez-le dans le fichier de configuration, par exemple:
// neige.config.js
module.exports = {
packageOptions: {
"Source": "Remote",
}
};Source: Remote permet quelque chose appelé les importations de streaming . Les importations en streaming permettent à Snowpack de contourner l'installation de NPM en convertissant les importations nues (par exemple, l'importation de réagir à partir de «réagir»;) en importations CDN à partir de Skypack.
En avance, faisons un fichier index.html:
<adal> <meta charset="utf-8">> <title> Snowpack Streaming Imports </title> head> <div> </div> <script type="module" src="app.js"> </ script> </script></adal>
Et, enfin, nous ajouterons un fichier app.jsx:
// app.jsx
importer réagir à partir de «réagir»
importer la réactdom de «react-dom»
const app = () => {
Retour <h1> Bienvenue aux importations de streaming de neige! </h1>
}
Reactdom.render (<app></app>,Document.getElementByid('ROOT ')); 0Notez que nous n'avons pas installé NPM React ou Reactdom à tout stade. Mais si nous démarrons le serveur de développeur neigeux comme ceci:
./node_modules/.bin/snowpack dev
… Notre application fonctionne toujours!
Au lieu de tirer d'un dossier Node_Modules, Snowpack tire le package NPM de Skypack, un CDN qui héberge le registre NPM, et il est pré-optimisé pour fonctionner dans le navigateur. Snowpack le sert ensuite dans une URL ./_snowpack/pkg.
Il s'agit d'un grand pas loin du flux de travail basé sur Node / NPM. Ce que nous regardons réellement, c'est un nouveau flux de travail basé sur les modules CDN / JavaScript.
Si, cependant, nous exécutons notre application telle qu'elle est et exécutons une construction de production, neige de neige lance une erreur. En effet, il doit savoir quelles versions de React et Reactdom à utiliser lors de la construction. Vous pouvez résoudre ce problème en écrivant à un neige.deps.json qui peut être créé automatiquement en exécutant ce qui suit:
./node_modules/.bin/snowpack Ajouter React ./node_modules/.bin/snowpack Ajouter React-Dom
Cela ne téléchargera pas le package à partir de NPM, mais il enregistrera la version des packages utilisés pour les builds de neige.
Une mise en garde est que nous manquons les messages d'erreur du développeur, car Skypack expédiera la version de production des packages.
Même si nous n'utilisons pas les importations de streaming, le serveur de développement neigeux regorge de chaque dépendance de Node_Modules en un fichier javascript par dépendance, convertit ces fichiers en module JavaScript natif, puis le sert au navigateur. Cela signifie que le navigateur peut mettre en cache ces scripts et les reposer uniquement s'ils ont changé. Le serveur de développement actualise automatiquement la sauvegarde, mais ne préserve pas l'état côté client. Toutes les dépendances du nœud semblaient fonctionner hors de la boîte, qu'elles utilisent des formats de module hérité ou des API de nœud (comme le processus infâme. Nous avons eu des problèmes avec Esbuild).
La préservation de l'état côté client dans React nécessite React-Refresh, qui nécessite quelques packages Babel en tant que dépendances. Ceux-ci ne sont pas inclus par défaut, mais sont disponibles en utilisant le modèle de réaction plus maximal. Le modèle attire la bibliothèque de tests React-Refresh, plus jolie, Chai et React, pour un ensemble total de dépendances aux nœuds pesant à 80 Mo:
NPX Create-Snowpack-App My-React-Project - Template @ Snowpack / App-Template-React
JSX est pris en charge, mais encore une fois, uniquement avec les fichiers .jsx par défaut. Snowpack détecte automatiquement si la réaction ou le préact est utilisé et décide en conséquence de la fonction de rendu à utiliser pour la transformée JSX. Cependant, si nous voulons personnaliser le JSX plus loin que cela, nous aurions besoin de tirer Babel via leur plugin. Il existe également un plugin de neige disponible pour les composants de fichiers uniques Vue et, bien sûr, pour les composants Svelte. De plus, Snowpack Compiles TypeScript, mais pour la vérification de type, nous avons besoin du plugin TypeScript.
Le CSS peut être importé dans JavaScript et est jeté dans le document
Les fichiers JSON importés seront jetés dans un module JavaScript avec un objet comme exportation par défaut. Snowpack prend en charge les images et les copie dans le dossier de production. En suivant sa philosophie non déposée, Snowpack n'inclut pas les images comme URL de données dans le faisceau.
La commande de construction de neige par défaut copie essentiellement la structure de fichier source exacte dans un dossier de sortie. Pour les fichiers qui se compilent vers JavaScript (par exemple TypeScript, JSX, JSON, .Vue, .svelte), il transforme chaque fichier individuel en un module JavaScript convivial pour un navigateur séparé.
Cela fonctionne bien, mais n'est pas idéal pour la production, car cela pourrait provoquer une grande cascade de demandes si le code source est divisé en nombreux fichiers. Dans l'application Snap Shot, je me suis retrouvé avec 184 Ko de fichiers source qui demanderait ensuite 105 ko de dépendances de Skypack, ce qui a fait une cascade assez énorme.
Cependant, Snowpack tire Esbuild en tant que dépendance et nous pouvons permettre à Esbuild de regrouper, minify
// neige.config.js
module.exports = {
Optimiser: {
bundle: vrai,
minify: vrai,
cible: «es2018»,
},
};Cela exécute le code en utilisant les fonctionnalités d'optimisation fournies par Esbuild, donc en ajoutant simplement ces options, nous pourrions obtenir la même construction que nous avions plus tôt avec Esbuild.
Étant donné qu'Esbuild n'a pas encore atteint 1.0, Snowpack recommande d'utiliser le plugin WebPack ou Rollup pour les builds de production, qui doivent tous deux être configurés.
Snowpack offre une expérience de développeur légère avec un serveur de développement complet, une documentation détaillée et des modèles faciles à installer. Vous devez décider si vous souhaitez regrouper votre application et comment vous voulez le faire. Si vous voulez un outil qui fournit à la fois un serveur de développement et une étape de génération plus opiniâtre, vous voudrez peut-être jeter un œil à Vite, le prochain outil de notre liste.
Vite est développé par Vue Creator (et Hadès Speedrunner) Evan You. Lorsque Esbuild se concentre sur l'étape de construction et que Snowpack se concentre sur le serveur de développement, Vite fournit les deux: un serveur de développement complet et une commande de construction optimisée à l'aide de Rollup.
Si vous voulez un concurrent sérieux de création de création ou de Vue CLI, Vite est le plus proche du groupe car il est livré avec des fonctionnalités incluses. Le serveur de développement Lightening-Fast et le build de production optimisé par Zero-Config signifient que vous pouvez passer de zéro à la production sans aucune configuration. Vite est un outil qui pourrait être utilisé à la fois dans un petit projet latéral ou une grande application de production. Un bon cas d'utilisation pour VITE serait toute application de page unique importante.
Pourquoi n'utiliseriez- vous pas Vite? Vite est un outil d'opinion et vous pourriez être en désaccord avec ses opinions. Vous ne voudrez peut-être pas utiliser Rollup pour votre construction (nous avons parlé de la vitesse à laquelle Esbuild est), ou vous voudrez peut-être que votre outillage vous donne toute la puissance de Babel, Eslint et l'écosystème des chargeurs de webpack hors de la boîte.
De plus, si vous voulez des méta-trame de rendu zéro-config, vous feriez mieux de rester avec des frameworks basés sur webpack, comme nuxt.js et next.js jusqu'à ce que l'histoire du rendu côté serveur Vite soit plus complète.
Vite a plus d'opinion par défaut que Esbuild et Snowpack. Sa documentation est claire et détaillée. Nous obtenons un soutien complet à Vue avec Evan étant le créateur et tout, donc Vite est un chemin heureux définitif pour les développeurs Vue. Cela dit, Vite peut être utilisé avec n'importe quel cadre frontal et fournit même une liste de modèles pour vous aider à démarrer.
Le serveur de développement de Vite est assez puissant. Vite pré-rassemble toutes les dépendances d'un projet en un seul module JavaScript natif avec Esbuild, puis le sert avec un en-tête HTTP fortement mis en cache. Cela signifie qu'aucun temps n'est perdu sur la compilation, le service ou la demande de dépendances importées après le chargement de la première page. VITE fournit également une messagerie d'erreur claire, l'impression du bloc exact de code et des numéros de ligne à dépanner. Encore une fois avec Vite, je n'ai eu aucun problème à tirer des dépendances qui utilisaient des API de nœud ou des formats hérités. Ils semblaient tous brillants dans un ésmodule acceptable de navigateur.
Les modèles React et Vue de Vite tirent tous deux des plugins qui permettent le remplacement du module chaud. Le modèle VUE attire un plugin VUE pour les composants de fichiers uniques et un plugin VUE pour JSX. Le modèle de réaction tire le plugin React-Refresh. Quoi qu'il en soit, les deux vous donneront un remplacement de module chaud et une préservation de l'état côté client. Bien sûr, ils ajoutent quelques dépendances supplémentaires, y compris les packages Babel, mais Babel n'est pas réellement nécessaire lors de l'utilisation de JSX en Vite. Par défaut, JSX fonctionne de la même manière que Esbuild - il se convertit en react.CreateElement. Il n'importera pas automatiquement React, mais son comportement peut être configuré.
Et pendant que nous y sommes, Vite ne prend pas en charge les importations en streaming comme Snowpack et WMR. Cela signifie les dépendances d'installation du NPM comme d'habitude.
Une chose intéressante est que VITE inclut la prise en charge expérimentale du rendu côté serveur. Choisissez votre cadre de choix et générez des HTML statiques qui sont expédiés directement au client. Pour le moment, il semble que nous devons construire cette architecture par nous-mêmes, mais cela ressemble à une bonne occasion pour les méta-châssis de construire sur Vite. Evan, vous avez déjà un travail en cours appelé VitePress, un remplacement de Vuepress par les avantages de l'utilisation de Vite. Et Sveltekit a également ajouté Vite à sa liste de dépendances. Il semble que l'inclusion de division du code CSS faisait partie de la raison pour laquelle Sveltekit est passé à Vite.
Pour CSS, VITE offre le plus de fonctionnalités de tous les outils que nous recherchons. Il prend en charge les importations CSS de regroupement ainsi que les modules CSS. Mais nous pouvons également installer les plugins PostCSS NPM et créer un fichier postcs.config.js, et Vite commencera automatiquement à appliquer ces transformations en CSS.
Nous pouvons installer et utiliser les préprocesseurs CSS - simplement NPM installe le préprocesseur et renommer le fichier dans la bonne extension (par exemple .Filename.scss) et VITE commencera à appliquer le préprocesseur correspondant. Et, comme nous l'avons dit dans l'aperçu, VITE prend en charge CSS Code-Spliting.
L'image importe par défaut une URL publique, mais nous pouvons également les charger dans le bundle sous forme de chaînes en utilisant un paramètre brut à la fin de la chaîne d'URL.
Les fichiers JSON peuvent être importés dans la source et convertis en un esmodule exportant un seul objet. Nous pouvons également fournir une importation nommée et Vite sera consacré au champ racine du fichier JSON pour trouver l'importation et Treeshake le reste.
Vite utilise Rollup pour une construction de production préconfigurée avec un tas d'optimisations. Il fournit intentionnellement une version zéro config qui devrait être suffisante pour la plupart des cas d'utilisation.
La construction est livrée avec les fonctionnalités de rouleaux que nous attendons: le regroupement, la minification et les tremblements d'arbres. Mais nous obtenons également des extras, comme les importations dynamiques qui s'attachent au code et quelque chose appelé «chargement de morceaux asynchrones», ce qui est une façon sophistiquée de dire que si nous demandons un module JavaScript qui importe un autre module, la construction sera pré-optimisée pour charger les deux en même temps (de manière asynchrone).
L'exécution de la version par défaut de Vite avec l'application Snap Shot, je me suis retrouvée avec un fichier JavaScript de 5KB et un fichier JavaScript de 160 Ko (pour un grand total de 165 Ko) et tous les CSS du projet ont été automatiquement dirigés vers un minuscule fichier de 2,71 Ko.
La nature d'opinion de Vite en fait un concurrent sérieux avec notre outillage actuel. Beaucoup de travail a été fait pour rendre l'expérience du développeur vraiment transparente et faire des constructions prêtes pour la production à partir de la boîte.
Comme Vite, WMR est un autre outil de construction d'opinion qui fournit à la fois un serveur de développement et une étape de construction. Il a été construit par le créateur de Preact, Jason Miller, donc c'est définitivement un chemin heureux pour les développeurs Preact. Jason Miller a expliqué la pensée derrière WMR lorsqu'il est apparu en tant qu'invité sur le podcast JS Party:
Preact est minuscule et c'est vraiment bien si vous voulez faire un projet léger. Où est notre outillage pour cela? Nous avons un outil basé sur webpack utilisé dans la production par un tas de sites de haut niveau, mais c'est l'outil des poids lourds. Où est l'outil de prototypage? C'était une main. L'autre main est moi et un tas d'autres personnes qui se trouvaient dans l'équipe préalable; Nous avions été en quelque sorte sur la touche de l'écosystème de Bundler depuis un petit moment, poussant les gens, essayant d'obtenir un consensus sur une direction dans laquelle nous pouvons nous déplacer pour faire avancer cette idée d'écrire du code moderne et d'expédier du code moderne.
Cela nous indique que WMR est une question d'écriture et d'expédition de code moderne, permettant des outils plus légers dans un projet.
Vous vous demandez peut-être ce que WMR représente? Rien! Les noms «Runtime des modules Web» et «Remplacement des modules humides» ont été flottés, mais c'est une fausse abréviation, similaire à NPM.
Le RRE est construit avec la même purge de taille de faisceau impitoyable que le préact, il est donc minuscule - pesant seulement 2,6 Mo - et contient exactement des dépendances NPM nulles. Pourtant, il parvient à emballer dans beaucoup de fonctionnalités vraiment impressionnantes, y compris un serveur de développement à module à modules et une version de production optimisée.
J'utiliserais WMR si je cherchais à créer un prototype en utilisant PREACT le plus rapidement possible. Il n'y a pas de configuration et il ne faut que quelques secondes à télécharger. Il a envie d'utiliser un serveur de fichiers statique suralimenté. Avec TypeScript, une étape de construction optimisée et un rendu statique HTML, WMR offre tout ce qui est nécessaire pour expédier des applications de petite taille à la moyenne. Sa petite taille est également idéale pour essayer rapidement une bibliothèque ou faire de la démonstration d'une idée.
WMR peut ne pas être l'outil pour vous si vous n'utilisez pas de préact, de réaction ou de JavaScript de vanille. L'équipe Preact n'a pas encore fourni de modèles pour d'autres cadres. La documentation n'est pas non plus aussi détaillée que les autres outils que nous avons examinés. Cela signifie que plus vous vous éloignez du chemin heureux, plus vous creusez dans la source. Donc, je ne peux pas le recommander si beaucoup de personnalisation est nécessaire.
Si vous utilisez PREACT, il n'y a absolument aucune configuration nécessaire, à l'exception d'une installation NPM rapide. Pour utiliser React avec WMR au lieu de Preact, il y a actuellement deux étapes à prendre. Tout d'abord, alias htm / preact à HTM / React, et réagissez à ES-REAT dans votre package.json:
"alias": {
"htm / preact": "htm / react",
"réagir": "es-réact"
},Ensuite, ajoutez des importations à partir d'ES-REAT dans vos composants:
// Reactdom n'est nécessaire que sur le rendu racine
import {react, reactdom,} de 'es-react';Cela signifie que nous n'utilisons pas réellement le package de réaction normal auquel vous pourriez être habitué, mais que nous tirons plutôt sur React à partir d'ES-REAT. En effet, WMR s'appuie sur les packages compatibles avec les modules JavaScript natifs. React n'utilise pas de modules natifs par défaut, en utilisant plutôt un style de module plus ancien appelé modules UMD. ES-REAT est un package qui tire React mais fournit des exportations compatibles avec la plate-forme Web.
Cela illustre la philosophie de WMR d'utilisation des primitives natives de la plate-forme Web plutôt que d'utiliser des outils pour contourner et l'abstraire.
Une autre option pourrait être d'utiliser les importations de Skypack dans notre application, qui est également pré-optimisée pour fonctionner dans le navigateur:
Importer React à partir de 'https://cdn.skypack.dev/react'; Importez Reactdom depuis 'https://cdn.skypack.dev/rect-dom';
WMR s'attend à ce que vous écrivez du code moderne qui s'exécute dans le navigateur, ce qui peut signifier que vous devrez faire une configuration si vous tirez des dépendances qui utilisent des API de nœud ou des systèmes de modules hérités. Pour faire fonctionner l'application Snap Shot, j'avais besoin de plonger dans des modules de nœud et de convertir une bibliothèque ou deux pour utiliser la syntaxe du module JavaScript natif. Cela pourrait vous ralentir si vous utilisez des bibliothèques plus anciennes. L'écosystème Preact est tout optimisé pour s'exécuter dans le navigateur et ne devrait pas nécessiter de massage. C'est une autre raison de s'en tenir au Preact Happy Path dans WMR.
Il existe des plugins pour WMR. Il expose une API de plugin qui prend en charge les plugins Rollup pour une étape de construction. Il y a de plus en plus d'exemples spécifiques à la WMR sur les documents, y compris un plugin qui divise le HTML, et celui qui dispose d'un routage basé sur le système de fichiers.
WMR prend en charge différents cadres, mais il n'y a pas de modèles prédéfinis pour eux. Et au début, j'ai trouvé assez difficile de configurer la transformée JSX. Cela dit, Jason a confirmé qu'il était prévu de rendre JSX plus configurable et que la RR est destinée à être agnostique. JSX is planned to work out of the box in regular JavaScript files.
To get started you can either run this command in the command line:
npm init wmr your-project-name
Or alternatively, you can run these commands to manually build up your application:
npm init -y npm install wmr mkdir public touch public/index.html touch public/index.js
Then add an script import in the body of your index.html (again make sure to use type="module"):
<script type="module" src="./index.js"></script>
Now you can write a Preact hello world into your index.js file:
import { render } from 'preact';
render(<h1>Hello World!</h1>, document.body);And finally start your development server:
node_modules/.bin/wmr
Now we have a full hot module replacement development server which will immediately respond to any changes to our source-code.
wmr uses a tool called htm when transforming JSX, which provides some awesome benefits. Let's say we're writing a counter using Preact in wmr and make a mistake:
import { render } from 'preact';
import { useState } from 'preact/hooks';
Function App () {
const [count,setCount] = useState(0)
return
<button onclick="{()=">{setCount(cout 5)}}>Click to add 5 to count</button> // HIGHLIGHT
<p>count: {count}</p>
>
}
render(<app></app>, document.body);count is misspelled in the onClick handler function, so running this results in an error. Usually, we would have to rely on our tooling and a source map to gather information about where the bug is located, but wmr takes a different solution. With htm, this gets as close as you can get to native JSX in the browser by using tagged template literals. So, where writing React or Preact code usually looks like this:
<mycomponent>I am JSX. I am not actually valid Javascript</mycomponent>
…htm looks more like this:
html`I am about as close as it gets to JSX as you can get while being able to run in the browser`
Now, if we're debugging our code and open the “Sources” panel in DevTools, we should see a script that's almost identical to what the source code looks like in the editor.
This way, we can properly investigate where bugs are located in the browser without having to use sourcemaps. Sure, this specific example is pretty contrived, but you can see how this could be really useful because it means wmr doesn't need source maps in your developer environment.
wmr supports streaming imports by default, so bare imports will be pulled down from the npm registry. This is done through a complex process which examines all of the source in the npm package, removes all the tests and metadata, and converts it to a single native JavaScript import. Similar to Snowpack, it's possible to build a complex app without using npm to install anything. In fact, wmr is the first tool to support this idea.
As far as the other types of files wmr supports, CSS files can be imported in JavaScript, and CSS modules are supported as well.
There isn't any built-in support for either Vue single file components or Svelte components. However, wmr's build step works with Rollup plugins and the development server can be configured with Polka/Express middleware, so it's possible to use these to convert imports into Vue and Svelte components. In fact, I wrote a small plugin for Vue Single file Components to show how this might be done.
We can't import images into JavaScript as data URLs in wmr without a plugin. Instead, we need to import them using a syntactically correct JavaScript method. So, if we have, say, a picture of a dog in our public folder we might include it in a Preact component like this:
function Dog() {
return <img src="%7Bnew" url import.meta.url alt="dog hanging out">
}And once the build step runs, the image is copied and accessible from the distribution folder. There is hot module replacement for images in the development server, so changes with images are immediately reflected in the browser.
One more note on file support: JSON can be imported, and is converted into a JavaScript object for use. But when actually building an application, we'd need the Rollup JSON plugin.
wmr provides a production build step that includes bundling, minification and tree-shaking without any additional dependencies. Having a look at the source of wmr, it looks like rollup and terser are used under the hood, and minified versions of these are included in the wmr package. The wmr bundle for the Snap Shot app was 164KB so it created a bundle just a tiny bit smaller than total size of the two JavaScript files created by Vite.
There is also a way to configure wmr is such a way that it renders an application to static HTML and hydrates on the browser using preact-iso. This means wmr can be used as a meta-framework for Preact, similar to Next.js.
I love the experience of using wmr to prototype both React and Preact applications. It feels great to get started with a tool that is ridiculously small but provides developer conveniences that get close to matching heavyweight bundlers.
We have just covered a lot of ground! Rather than scroll up and down this article to compare results, I've compiled everything here to see how the tools stack up when they're side-by-side. I've even included additional comparisons for features that we didn't explicitly cover.
I'm super excited about building JavaScript applications with any and all of the tools we just looked at. Whether we're writing a small side project or a big production site, all these tools speed up feedback loops and increase productivity. They've opened up the gates to ask what's necessary for the JavaScript ecosystem and whether we can start losing the cruft brought by legacy modules and browsers. These tools are going to lower the barrier to entry for new developers by providing a leaner, faster developer environment with fewer abstractions between the code that gets written and the code that runs in the browser.
If you're getting sick of waiting for your dependencies to download and your build steps to run, I'd recommend giving this new generation of tooling a try.
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!
Que se passe-t-il lorsque je n'arrive pas à me connecter au réseau ?
solution de réinitialisation de connexion
Comment optimiser une seule page
Comment acheter et vendre du Bitcoin sur Huobi.com
Comment résoudre l'erreur 500 du serveur interne
appuyez sur n'importe quelle touche pour redémarrer
Comment implémenter la fonction de pagination jsp
Introduction aux logiciels de modélisation paramétrique
Comment exécuter un script shell
![[Web front-end] Démarrage rapide de Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
