Qu'estce qu'Astro ? — fracassant

Dans cet épisode, nous parlons d'Astro. Ce constructeur de site statique moderne vous lancera-t-il dans la stratosphère ? Drew McLellan parle au développeur Matthew Phillips pour le savoir.

Afficher les notes

Mise à jour hebdomadaire

Transcription

Drew McLellan : Il est ingénieur chez Skypack et un contributeur majeur à un nouveau projet appelé Astro, qui vise à combiner les meilleures pratiques en matière de performances avec les améliorations de l'expérience des développeurs que nous constatons dans les approches basées sur les composants. Nous savons donc qu'il sait tout sur Astro, mais saviez-vous qu'il peut mettre 18 citrons entiers dans sa bouche ? Mes formidables amis, veuillez souhaiter la bienvenue à Matthew Phillips. Salut, Matthew, comment vas-tu ?

Matthew Phillips : Je défonce.

Drew : C'est bon à entendre. Je voulais vous parler aujourd'hui d'Astro, mais avant cela, pourquoi ne nous parleriez-vous pas un peu de votre parcours et de la façon dont vous en êtes arrivé là où vous en êtes aujourd'hui ?

Matthew : Ouais, eh bien, je travaille sur le développement Web front-end depuis longtemps, probablement six ou sept ans. L'entreprise précédente, j'étais l'un des mainteneurs de canjs, framework front-end. J'ai travaillé sur cet open source à temps plein pendant environ trois ans, je pense. J'ai également fait pas mal de conseil, différentes grandes et petites entreprises en amont. Et donc j'ai beaucoup d'expérience dans le front-end. J'ai eu un grand intérêt pour les composants Web et j'ai écrit diverses bibliothèques entourant les composants Web. L'un s'appelle Haunted, peut-être en a entendu parler, certaines personnes pourraient l'avoir,

Matthew: et Fred, qui est le propriétaire de Skypack, qui a lancé Skypack et a travaillé sur le projet Snowpack, je le connaissais parce qu'il travaillait pour Google sur le projet Polymer, qui est un projet de composant Web. Donc je le connaissais juste à travers l'industrie et je pensais changer d'emploi, chercher à me remettre un peu et ils embauchaient. J'ai donc sauté à bord, très intéressé. Et j'ai aussi une grande connaissance des modules ES et juste du chargement de modules en général et c'est ce sur quoi ils travaillaient à l'époque. C'était donc juste un bon ajustement et j'ai donc décidé de me joindre à bord. Matthieu : Je pense que oui. Je ne suis pas très au courant des données sur toute la terminologie, mais je pense que c'est vrai.

Drew : Cela me semble juste. J'entends donc beaucoup de bruit à propos d'Astro et du fait que c'est une sorte de générateur de site statique, mais je pense que ce terme sous-estime peut-être ce qu'il fait. Qu'est-ce qu'Astro exactement et quel est le problème qu'il résout pour nous ?

Matthew : Exact. Oui. Je veux dire, Astro est un générateur de site statique. C'est un peu difficile d'expliquer comment Astro est né, mais je ne sais pas si ce serait utile d'y aller, mais ce qu'est Astro en général, c'est un générateur de site de pile qui vous permet d'utiliser des composants dans n'importe quel framework qui vous êtes familier, que ce soit View ou React, Svelte, tout ce que vous pouvez vraiment apporter votre propre framework et avoir ce flux de travail que beaucoup de gens apprécient tout en générant du HTML et du CSS purement statiques.

Drew : Ainsi, au lieu d'utiliser quelque chose comme Handlebars ou l'un de ces langages de templates traditionnellement côté serveur, vous pouvez utiliser votre propre framework réactif, essentiellement React ou View ou Svelte ou autre pour agir comme système de template pour votre générateur de site statique. Est-ce-

Matthew: Ouais, c'est un peu, si vous avez entendu parler de 11ty, mais c'est un peu à mi-chemin entre quelque chose comme 11ty ou un générateur de site statique plus traditionnel où vous utilisez un langage de modèle qui est conçu pour essentiellement la concaténation de chaînes dans quelque chose de frontal, plus un générateur de site statique piloté par le front-end comme Gatsby, par exemple, c'est un peu à mi-chemin entre les deux. Nous voulions que l'expérience développeur, l'utilisation des composants, l'utilisation des composants soit très utile. C'est très utile de pouvoir composer des choses en petits morceaux et il n'y a pas un excellent moyen de le faire dans les moteurs de modèles plus traditionnels qui existent. juste parce qu'ils sont si composables et que l'attrait pour cela ne l'est pas nécessairement, ce n'est pas nécessairement : « Hé, je veux que cette chose soit toujours interactive dans le client. » C'est juste : "Je veux composer des choses en petites parties." Et donc oui, nous sommes un peu à mi-chemin entre cela, mais nous voulons toujours générer ce contenu statique idéal. Et je pense qu'il y a beaucoup de gens qui, comme je l'ai dit, gravitent autour de la manière de faire des frameworks, mais ils ne sont pas super contents de ce que ça produit réellement parce que, j'écris un blog ou j'écris un page marketing ou quelque chose comme ça, je n'ai pas besoin de tout ce script Java, mais j'y suis un peu habitué et il se construit bien.

Matthew: Donc, je suppose que c'est un peu le problème que vous re essayer de résoudre est, nous aimons, en tant que personnes avec… Nous avons beaucoup de gens dans notre communauté et dans l'équipe avec une formation en, je suppose que vous diriez le front du front-end, et ils veulent vraiment ce simple HTML et la sortie CSS, c'est donc un moyen d'équilibrer ces deux désirs, je suppose. , et puis il s'agit de leur site marketing et de leur document et de leur blog et de toutes ces choses qu'ils veulent en fait être vraiment bien optimisées pour le référencement et vraiment fa ster charge et très faible surcharge et serait idéal comme pages HTML et CSS statiques, mais ils pourraient toujours utiliser leurs flux de travail normaux et tous les outils auxquels ils sont habitués pour les développer.

Matthew: Ouais. Ces flux de travail, ceux-là sont super importants. Je pense que beaucoup de gens peuvent être un peu critiques de l'extérieur. Du genre : « Oh, pourquoi avez-vous construit cette chose de cette façon ? Pourquoi avez-vous utilisé React ou autre pour créer cette page de destination ? » Mais ce sont des équipes et elles passent beaucoup de temps à créer des sites Web ou à créer des outils internes ou quoi que ce soit qu'elles construisent et cela demande beaucoup d'efforts pour dire : « Oh, nous allons passer à un tout autre contexte et utilisez Jekyll ou autre chose », et vous devez mettre les gens au courant.

Matthew: Je pense donc que ces flux de travail sont vraiment, vraiment importants. Et je lis tout le temps des articles où cette équipe dit : « Oh oui, nous utilisons React. Nous avons donc également construit notre site marketing en React. Et si nous pouvons permettre aux gens de continuer à utiliser ces flux de travail normaux, mais produire un meilleur résultat pour ce que vous essayez réellement de créer, alors je pense que c'est une énorme victoire.

Drew : Il y a une énorme différence, n'est-ce pas. t là, entre quelqu'un qui travaille en solo sur des projets intéressants qui lui plaisent et ils pourraient dire : « Oh, d'accord, la solution technique idéale pour cette chose en particulier est la suivante. Et la solution idéale pour cette autre chose, c'est ça », et il n'y a aucun coût réel pour eux de changer. Mais quand vous parlez d'une équipe, si vous adoptez la solution idéale pour quelque chose qui ne fait pas partie de votre boîte à outils habituelle, alors vous apportez presque une dette technique à l'équipe parce que quelqu'un doit maintenir ses compétences à niveau rendez-vous avec cette autre chose afin de la faire avancer. Donc voilà. C'est vraiment intéressant.

Drew : Bien sûr, l'une des grandes choses qui préoccupent les gens avec ces frameworks JavaScript lourds, React et tous les autres, est le poids du JavaScript. Donc, je veux dire, je suppose que les performances sont un facteur important lorsqu'il s'agit de performances, c'est une grande raison pour laquelle quelqu'un pourrait choisir d'utiliser Astro. Est-ce vrai ?

Matthew : Oh oui, absolument. Astro n'ajoute donc aucun JavaScript par défaut. Vous pouvez évidemment ajouter vos propres balises de script et vous pouvez faire tout ce que vous pouvez faire en HTML, mais par défaut, compte tenu des autres types de frameworks basés sur des composants, nous n'ajoutons aucun JavaScript pour vous, sauf si vous nous le demandez spécifiquement. Et je pense que c'est une chose que nous avons vraiment compris très tôt. Et c'était une sorte d'accident en fait, c'est que nous étions juste en train de construire cette chose et nous n'avons tout simplement pas mis la partie pour que le JavaScript soit chargé. Nous n'avons tout simplement pas écrit cette partie. Nous venons d'écrire la partie qui a généré le code HTML et nous nous sommes dit : " Oh, en fait, nous aimons mieux ça." . Je ne sais pas si cela vous est familier, mais c'est essentiellement un moyen de, vous avez un composant et nous voulons seulement hydrater la partie qui est réellement nécessaire chez le client. Donc, si vous êtes plus familier avec une approche SPA traditionnelle d'application à page unique, vous avez généralement un composant, qui est votre composant d'application et il y a juste un millier de composants imbriqués à l'intérieur. Droit? Et certains de ces composants sont en fait interactifs, n'est-ce pas ? Il pourrait y avoir une liste déroulante ou il pourrait y avoir un certain type de formulaire avec validation, quel qu'il soit. Ce sont les parties qui doivent réellement s'exécuter dans le client, mais juste de la façon dont l'architecture SPA fonctionne, vous devez exécuter tout le code pour que tout fonctionne. l'hydratation est, de manière générale, un moyen de déterminer quelles sont les parties qui comptent réellement, les parties qui doivent réellement s'exécuter dans le client, et de ne voir que ce JavaScript. Ainsi, l'un des membres de notre équipe, Nate Moore, a travaillé sur ce projet appelé Microsite, qui était un projet de rendu de serveur Preact, Preact. Et ce que cela ferait, c'est que vous lui diriez « D'accord, ce composant doit réellement s'exécuter dans le client », et cela ajouterait le JavaScript pour cela. Il avait donc déjà travaillé sur cette idée d'hydratation partielle et nous venons de l'adopter. Il a rejoint notre équipe et nous avons adopté cette approche.

Matthew : Donc, une chose unique qu'Astro fait est de lui dire comment vous voulez qu'il s'hydrate chez le client, et ce que je veux dire par là, c'est qu'il y a différentes façons dont vous pouvez vous hydrater. Astro charge toujours JavaScript paresseusement, ce qui signifie que nous n'ajoutons pas de balise de script pour votre composant dans la tête ou quelque chose comme ça. Nous ne faisons pas ça. Au lieu de cela, nous avons un script en ligne qui charge le JavaScript. Et donc vous pouvez charger, je pense qu'il y a quatre façons différentes maintenant, vous pouvez charger lors du chargement de la page. C'est donc l'événement de chargement qui existe dans les navigateurs, vous pouvez charger au ralenti. Il existe donc une API de navigateur appelée requestIdleCallback, et cela vous permettra de savoir essentiellement quand le processeur est inactif, lorsque le navigateur n'est pas occupé à travailler, afin que vous puissiez charger de cette façon. Et vous pouvez charger sur la visibilité, ce qui signifie que, par exemple, vous avez peut-être un composant qui se trouve loin dans la page, vous attendez que l'utilisateur fasse défiler ce composant dans la vue, puis nous chargeons le JavaScript.

Matthew : Et enfin, il y en a un qui s'appelle media et qui est basé sur les media queries. Donc, le cas d'utilisation est que, disons, vous avez un composant qui ne fonctionne que sur mobile, par exemple, et je suis sûr que vous avez vu les barres latérales sur lesquelles vous pouvez cliquer. Ces types de choses, généralement, n'existent pas sur le bureau, vous pouvez donc définir une requête multimédia et il ne chargera ce composant que lorsqu'il correspond à cette requête multimédia.

Matthew: Donc de toute façon, ces sont les quatre façons de s'hydrater. Donc je pense qu'une chose que nous avons bien fait est que nous vous forçons à choisir laquelle de ces choses faire. Cela oblige donc le développeur à s'arrêter et à se demander quelle est la meilleure façon de charger ce code ? Ai-je vraiment besoin de ce code ? Ce composant doit-il s'exécuter immédiatement ? Oh non, cette chose n'existe qu'en bas de la page. Faisons en sorte que cela soit visible.

Drew : Alors oui, je suppose qu'il y a toutes sortes de compromis entre chaque type. Je suppose que si quelque chose ne se charge que lorsque le navigateur est inactif, alors vous n'avez aucun contrôle sur si cela va se produire à temps pour le type d'interaction que vous souhaitez.

Matthew: Ouais. Vous feriez cela pour des choses peut-être moins prioritaires, je suppose. Je veux dire que c'est généralement assez sûr, en particulier sur les sites Astro. Le ralenti arrive beaucoup plus vite. Vous pensez à quelque chose qui est construit comme un SPA où il se passe beaucoup de choses, qui rend des choses et fait tout cela et peut-être que l'inactivité prend un peu plus de temps, mais oui, il y a certainement des compromis à tout cela. Mais je pense que l'essentiel est que nous n'avons rien fait de vraiment magique. Je veux dire, ce n'est pas comme si nous avions trouvé un moyen fou d'obtenir des performances. Nous vous faisons juste réfléchir, quelles sont les caractéristiques de performance de ce que je construis ? Et comment doit-il se charger ? Et ai-je vraiment besoin que cette chose soit dans le navigateur ? Ou est-ce que cela se produit juste une fois lorsque vous construisez le site ?

Drew : Ouais. Je suppose que beaucoup de développeurs oublient que le site le plus rapide est celui sans JavaScript. Et donc si vous pouviez simplement réduire la quantité de JavaScript qui se charge et passe, alors ce sera plus rapide par défaut. Astro rend donc tout votre JavaScript en HTML et CSS statiques, et vous pouvez apporter votre propre framework, c'est quelque chose qui est en quelque sorte décrit comme, que ce soit React ou View ou ce que vous avez. Cela signifie-t-il qu'Astro doit prendre en charge tous ces frameworks ? Ou est-il construit de telle manière qu'en réalité, le code JavaScript auquel il a affaire n'a pas vraiment d'importance ?

Matthew : Ouais. Il y en a peu, on appelle des plugins pour ces frameworks. Nous en avons donc déjà écrit plusieurs. Si vous venez d'installer Astro par MPM, je pense que vous obtenez React, View, Svelte, Preact. Je pense que ce ne sont que ces quatre-là. Et je sais que nous avons également écrit nos propres plugins pour Solid.JS, qui est un framework plus récent, et Lit, LitElement, nous en avons également un pour cela. Ils sont donc en fait assez faciles à écrire. Chaque framework a une manière différente de rendre HTML. C'est donc ce que font ces plugins, c'est que vous leur donnez un composant, ou Astro leur donne un composant, puis ils rendent simplement cette chose en HTML.

Drew : J'allais demander, oui, parce que tous les les frameworks ont leur propre mécanisme, n'est-ce pas pour le rendu ? Donc, ces plugins permettent essentiellement à Astro de se connecter à ces méthodes de rendu et-

Matthew: Oui, exactement. C'est tout ce qu'ils font, c'est que… Ouais. Ouais.

Drew : C'est excellent. Je suppose donc qu'Astro ne sera pas en mesure de prendre une application d'une seule page existante, disons React, et de la transformer en un site statique. Je suppose que vous devez en fait créer votre site d'une manière particulière en pensant à Astro en premier lieu. Est-ce vrai ?

Matthew : En quelque sorte. Je veux dire qu'il est certainement préférable de commencer à partir d'une position où vous le considérez comme un site statique, mais vous pouvez certainement prendre un React, comme je l'ai dit, un, vous avez votre composant d'application, vous pouvez le mettre dans Astro et vous pouvez dites client load, qui dit de charger cette chose dans le client, puis vous obtenez votre SPA. Donc, vous pouvez réellement construire un SPA au-dessus d'Astro et puis peut-être retirer des choses au fil du temps, vous vous dites : " Oh, attendez, cet en-tête n'a pas besoin d'être exécuté sur le client, laissez-moi le récupérer dans mon SPA et mettez-le dans le fichier Astro. Faites-le de cette façon.

Drew : J'ai donc vu la documentation faire référence à l'approche d'îles plutôt qu'à une grande masse terrestre. Alors peux-tu nous expliquer ça ? Qu'est-ce que ça veut dire?

Matthew: Ouais, ça revient à ce dont je parlais avant avec l'hydratation partielle, c'est qu'au lieu d'avoir, comme je l'ai dit, un grand SPA qui est toute votre application et tout découle de cela, au lieu de cela, vous avez ces petits ce que nous appelons des îlots d'interactivité. Je pense que Jason Miller de Google a proposé cette terminologie. Donc, vous pourriez avoir votre barre de navigation supérieure et c'est une île, puis vous pourriez avoir une île d'onglets avec du contenu, et vous avez ce genre de choses. Ils sont donc comme des mini-applications sur votre page.

Drew : D'accord. Vous pouvez donc avoir essentiellement un composant qui rend votre navigation principale, puis un deuxième composant à côté, qui affiche votre nombre d'articles dans votre panier, par exemple, et vous pouvez choisir différentes approches pour savoir quand ceux-ci sont hydratés. Ainsi, la navigation serait probablement simplement rendue en HTML et pas vraiment interactive, ce ne sont que des liens. Et le composant panier serait en fait plus interactif, s'exécuterait sur le client et se mettrait à jour au fur et à mesure que vous ajoutez des choses à votre panier, ou quel que soit le scénario.

Matthew: Oui, exactement. Et comme vous l'avez dit, c'est un bon point, c'est que vous pouvez choisir différentes façons d'hydrater chacun d'entre eux. Certains de ceux que vous n'avez peut-être pas du tout besoin d'hydrater, certains d'entre eux vous devez vous hydrater immédiatement, certains d'entre eux vous devrez peut-être vous hydrater en visibilité car vous avez ces différentes îles, vous pouvez y penser individuellement et quel est le meilleur façon de les charger réellement. Quelque chose comme un chariot, vous voudrez probablement le faire assez tôt, car vous voulez que l'utilisateur voit ce numéro de chariot apparaître assez rapidement.

Drew : Ainsi, lorsqu'un composant se charge, nous voulons être complètement hydratés. , lorsque ce processus d'hydratation se produit dans le navigateur, que se passe-t-il sous le capot ? Est-ce que tout le code JavaScript initial qui aurait été chargé lorsque la page a été chargée dans l'architecture traditionnelle, est-ce que tout cet ensemble est ensuite téléchargé et instancié à ce stade ? Ou y a-t-il quelque chose de plus intelligent?

Matthew: Non, c'est exactement comme ça que ça marche. Comme je l'ai dit, nous n'avons pas vraiment fait quelque chose de magique, c'est juste très simple. Vous dites que vous voulez que quelque chose se charge au ralenti, nous le chargeons au ralenti. Ce que nous faisons, c'est que nous injectons notre propre petit script spécifiquement pour ce composant, et, par exemple, pour l'inactivité, il existe une API appelée requestIdleCallback, window.requestIdleCallback, lorsque cela est appelé par le navigateur, nous importons votre JavaScript et c'est essentiellement tout. Et puis nous le rendons. Chaque framework a une manière différente de rendre les composants sur le client et nous avons donc ce code qui fait réellement le rendu. Et à partir de là, vous êtes à l'intérieur du composant framework. Tout ce que vous faites, s'il s'agit d'un composant View, tout ce que vous faites avec View, tout se passe à l'intérieur. faire votre regroupement pour vous assurer que vous ne chargez qu'une seule instance de React et toutes ces sortes de choses ?

Matthew : Ouais. Nous utilisons Snowpack. Notre équipe était les créateurs de Snowpack. Fred a créé initialement, mais c'est un outil plus moderne que quelque chose comme Webpack, et cela vous donne essentiellement un serveur de développement qui compile les choses à la demande. Ainsi, au lieu d'obtenir un ensemble géant de l'ensemble de votre "application", chaque fichier est compilé individuellement dans Dev, puis lorsque vous déployez cette production, bien sûr, tout est regroupé de manière optimisée. Ouais.

Drew : L'un des avantages des générateurs de sites statiques est qu'ils sont généralement très simples. Vous prenez des fichiers de démarques ou quoi que ce soit et les restituez au format HTML, et il n'y a pas vraiment trop de mal à se tromper. Y a-t-il plus de risques inhérents à la complexité de ce que fait Astro que vous puissiez apporter une modification à votre code, créer un nouveau composant ou autre, et découvrir soudainement qu'Astro ne se construira pas parce qu'il y a une incompatibilité ? Est-ce un risque ?

Matthew : C'est une très bonne question. Je veux dire, ouais. Je suppose que chaque fois que vous ajoutez une autre couche d'obstruction, il y a une possibilité d'incompatibilités. Le plus important est que vous travaillez avec un framework et que vous devez vous assurer que la version de votre framework correspond au plugin, au plugin React ou à tout ce que vous utilisez, mais nous gardons toutes ces choses à jour. Donc je n'ai pas vu beaucoup de problèmes d'incompatibilités, et ce qui est génial avec Astro en particulier, l'une des choses que j'aime c'est que notre communauté est très passionnée et nous avons du monde, parce que nous avons choisi cette grande tente, apportez la vôtre approche cadre, nous avons des personnes dans notre Discord qui sont des spécialistes Svelte. Ils sont très bons à ça. Ils sont très bons à View. Et si vous avez des questions, quelque chose que vous ne savez pas faire, vous pouvez y aller et poser la question et il y a probablement quelqu'un qui peut vous aider. passé, il y a eu des problèmes où certaines fonctionnalités de View ne fonctionnaient pas correctement, et c'est parce que notre plugin n'a pas implémenté quelque chose correctement, et nous avons des gens qui résolvent ce problème très rapidement.

Drew : Il y a donc assez une communauté active. Vous dites que c'était autour d'un serveur Discord ?

Matthew : Ouais. Oui. Nous avons un Discord et beaucoup de gens là-bas, des gens qui contribuent à la documentation, des gens qui aident avec des questions d'assistance et une communauté très dynamique. Ouais.

Drew : Eh bien, quelle est la maturité d'Astro comme je veux dire, depuis combien de temps les gens l'utilisent-ils en production ?

Matthew : Oui, il y a certainement beaucoup de personnes qui l'utilisent en production. L'idée d'Astro, comme nous en avons parlé, est un moyen de créer des applications à plusieurs pages, en ramenant cette architecture, en reprenant la nouvelle façon moderne dont les gens construisent des choses avec des composants et des frameworks de composants, mais en se débarrassant de la partie SPA. , ce qui, je pense, pose beaucoup de problèmes sur les sites qui n'ont pas besoin d'être des SPA. de sites Web. Notre première approche a donc été de créer un générateur de sites statiques, mais la technologie derrière Astro ne doit pas nécessairement générer uniquement des sites statiques, nous avons juste pensé que c'était la meilleure voie à suivre. Et ce faisant, nous avons ciblé un certain type de site Web. Nous avons ciblé des personnes qui créent des blogs ou des personnes qui créent des pages marketing, ce genre de choses, peut-être même se lancent-elles un peu dans le commerce électronique.

Matthew : Nous nous sommes donc vraiment concentrés sur l'obtention de cette histoire. c'est vrai, donc beaucoup de gens qui ont construit des trucs dans la production, il y a des tonnes de gens qui ont construit des blogs et les ont déployés. Et nous avons aussi des sites de marketing et des trucs comme ça. Je pense donc que ce domaine est définitivement en train de mûrir. Probablement la prochaine chose que nous recherchons, et cela pourrait prendre un peu de temps, mais nous finirons par nous lancer dans le commerce électronique. Plus de choses doivent en fait être rendues dynamiquement sur le serveur. Vous ne pouvez pas le faire actuellement avec Astro, mais nous allons certainement y arriver.

Matthew : Nous nous préparons actuellement à notre version 1.0. Il nous reste quelques trucs à régler. La mise en œuvre initiale d'Astro était difficile à certains égards, et il y a des choses qui n'étaient pas géniales à ce sujet. Donc, certaines personnes de l'équipe ont reconstruit notre compilateur Astro et nous nous préparons à la version 1.0. Je ne peux pas donner de date précise, mais d'ici la fin de l'année, nous espérons sortir cela. Ce serait donc le point où nous l'envisageons, évidemment 1.0 est une étape importante et nous considérons qu'il est prêt pour tout le monde, les personnes qui sont très prudentes quant à l'adoption de nouveaux outils pourraient définitivement y entrer d'ici là.

Drew : Et combien de personnes travaillent sur le noyau d'Astro ? Je veux dire, évidemment, il y a la communauté qui l'entoure, mais j'imagine qu'il y a une équipe plus centrale de personnes qui y travaillent.

Matthew: Ouais. Chez Skypack, nous avons quatre personnes. Eh bien, oui, quatre personnes y travaillent.

Drew : Skypack est-il donc le principal sponsor de ce projet ? Donc Skypack était, ou est, un CDN pour le chargement de JavaScript. Ce que vous pouvez faire, c'est charger tous les packages qui sont publiés MPM, vous pouvez les charger directement dans le navigateur à l'aide de Skypack. Et quand nous avons commencé à travailler sur Astro, ce que nous essayions vraiment de faire, nous essayions de trouver un moyen d'aider les personnes qui utilisaient Skypack à trouver un moyen, les gens voulaient héberger leur contenu, héberger leur propre JavaScript sur Skypack, Et nous cherchons des moyens de le faire. Et nous sommes en quelque sorte tombés dans Astro à cause de cela. Nous nous sommes dit : « Eh bien, nous avons vraiment besoin de savoir comment la personne construit son site Web pour mieux optimiser le chargement de tout. où vous pouvez assembler vos composants et nous connaissons ces composants, nous savons donc exactement de quel JavaScript vous avez besoin. Et nous travaillons sur des optimisations comme ce dont Astro est issu, mais Astro a ensuite décollé dans une plus grande mesure que je pense que nous avions vraiment prévu. Donc, nous voyons en quelque sorte qu'Astro est peut-être l'avenir de l'entreprise, alors nous construisons l'entreprise autour d'Astro maintenant. Toujours à déterminer sur ce que cela signifie exactement, mais c'est un peu la direction dans laquelle nous allons.

Drew : Il semble que l'avenir soit plutôt prometteur pour Astro. Y a-t-il des fonctionnalités auxquelles vous n'avez toujours pas accès ou que vous prévoyez d'ajouter à l'avenir ou que vous espérez ajouter ?

Matthew : Ouais. Donc un gros que nous avons eu au tout début, puis nous l'avons retiré pour des raisons que, plus que je ne peux expliquer, mais des composants de démarque. C'est quelque chose, si vous avez entendu parler de MDX, les gens sont très passionnés par cela. Ils veulent pouvoir utiliser des composants dans leurs fichiers de démarques. MDX n'est pas un fichier MDX, mais c'est quelque chose que nous n'avons pas actuellement. C'est quelque chose dont nous savons que les gens sont vraiment enthousiasmés et nous y travaillons actuellement. Donc, c'est quelque chose que nous devrions avoir très bientôt. Dans Astro, vous pouvez déjà avoir un fichier .md comme page, de cette façon vous écrivez un article de blog, vous le faites dans un fichier markdown au lieu d'un fichier .astro. Mais bientôt, vous pourrez utiliser .MDC, ce qui vous permettra d'écrire des notes, mais vous pourrez également y insérer des composants.

Drew : Cela semble être génial pour des choses comme les sites de documentation, par exemple, où vous pourriez avoir des tonnes de documentation au format Markdown, car il s'agit principalement de texte, mais que vous voudriez ensuite ajouter quelque chose d'interactif pour aider à expliquer un concept ou-

Matthieu : Exemples.

Drew : Exemples. Oui. Donc des choses comme les blogs, des choses comme les sites de marketing, peut-être la documentation, ce genre de choses sont toutes bonnes et très utiles pour Astro en ce moment ?

Matthew : Ouais. Si vous exécutez npm init astro, il exécute notre générateur et le générateur contient essentiellement un tas d'exemples de modèles de démarrage différents. Nous en avons un pour le blog. Nous en avons un pour le blog avec plusieurs auteurs. Donc, si vous avez plusieurs personnes qui travaillent ensemble sur un blog. Nous avons un portefeuille. Astro est très bon pour les sites Web de portefeuille. Et puis nous en avons un aussi pour les docs. Donc, toutes ces choses dont nous avons parlé, il existe déjà des modèles de démarrage pour tout cela. it?

Matthew: Je pense que docs.astro.build est probablement le meilleur endroit. Ou si vous allez simplement sur astro.build, il y a aussi un lien vers celui-ci. Mais cela vous donne nos documents de démarrage, notre documentation. Je pense que nous avons déjà des traductions dans une douzaine de langues. Et oui, alors je pense qu'il y a beaucoup de liens pour sauter sur Discord et commencer à poser des questions. un plugin pour un framework différent que vous n'avez pas couvert ou peut-être même contribuer d'une manière plus lourde ? C'est définitivement un super endroit. Si vous êtes plus à l'aise sur GitHub, nous avons aussi beaucoup de monde là-bas.

Drew : Eh bien, c'est fantastique. Y a-t-il autre chose que nous devrions savoir sur Astro ?

Matthew : C'est le meilleur et tout le monde devrait commencer à l'utiliser.

Drew : Parlez-nous brièvement de Snowpack, car cela semble vraiment intéressant . Du point de vue des personnes qui connaissent peut-être certains de ces outils plus anciens comme Webpack, quelles sont les principales différences avec la façon dont Snowpack aborde le travail ?

Matthew : Ouais. Je veux dire, Snowpack vient d'un point de vue plus large, et Vite est un autre outil très similaire à Snowpack. Ils font tous les deux une chose très similaire. D'où ils l'approchent, vous vouliez vraiment l'approcher à partir de vos modules de chargement dans le navigateur, le navigateur a maintenant un moyen natif de charger des modules, vous pouvez faire un type de script égal à module et il peut charger n'importe quel module qui a l'importation et l'exportation déclarations. Cependant, ce que la plupart des gens écrivent dans leurs modules, c'est qu'ils importent à partir de différents packages sur MPM et le navigateur n'a aucun moyen de charger des éléments à partir de MPM. Il ne connaît pas ce genre de chose. Donc, ce que Snowpack fait essentiellement, c'est qu'il le fait, il le sait, si vous importez React, il va transformer cette importation React en une URL que le navigateur peut comprendre. Donc c'est tout ce qu'il fait, c'est traduire le JavaScript ou taper un script ou quoi que ce soit, le JSX, quoi que vous écriviez, ce qui n'est pas compatible avec le navigateur et le rend compatible. C'est essentiellement ce qu'ils font.

Drew : Désolé. Est-ce là que Skypack entre alors en jeu, car il charge ce module React à partir de Skypack ?

Matthew : Ouais. Eh bien, ça peut. Snowpack ne le fait pas par défaut. Il fait un environnement local plus traditionnel. Vous allez donc toujours faire votre installation MPM et faire tout ce genre de choses. Il existe un moyen d'activer une intégration Skypack. C'est encore quelque chose que nous essayons de trouver de la meilleure façon. Comme je l'ai dit, nous sommes arrivés à cela à partir de l'approche de, nous voulions rendre Skypack meilleur pour les utilisateurs et faciliter l'utilisation de Skypack. Et nous sommes tombés dans Astro à cause de cela. Donc je pense qu'on va probablement, à un moment donné, revenir à l'intégration des choses plus étroitement, mais ce serait l'idéal, non ? Je pense que lorsque vous, je ne sais pas, je pense juste ici, mais lorsque vous déployez votre site Web, peut-être que nous traduisons toutes ces URL React pour qu'elles proviennent plutôt de Skypack, de cette façon ils ' re well cached and all that sort of thing.

Drew: Yeah. So-

Matthew: TBD on that.

Drew: I’ve been learning all about Astro. What have you been learning about lately Matthew?

Matthew: Oh, well, I mean I’m always learning lots of stuff. I think lately, the Astro compiler, it was originally, it’s all JavaScript and they’ve been rewriting it in Go. So Go programming language. I’ve used Go before, but it’s been quite a while so I’ve been relearning that as I play around with the new compiler.

Drew: Yeah. There seems to be a trend in all sorts of parts of the ecosystem of JavaScript tools being replaced by Go versions just for the performance.

Matthew: Yeah. Yeah.

Drew: As our projects get bigger and bigger and our build times get longer and longer, everyone’s looking for the next way to speed it up.

Matthew: Yeah. That’s exactly, that was it. I mean, we knew that we needed to rewrite it anyways and we’re like, “Why not just go for the speed boost as well?”

Drew: Yeah. Oui. If you, dear listener, would like to hear more from Matthew, you can find him on Twitter where he’s @matthewcp or his personal website, which is matthewphillips.info. You can find out how to get started with astro at astro.build. Thanks for joining us today. Matthew. Did you have any parting words?

Matthew: No. Go download Astro and yeah, join Discord and talk to us.

(il)