Steve Sewell est le PDG et co-fondateur de Builder, un outil de conception visuelle et de collaboration de nouvelle génération pour les créateurs et développeurs de contenu Web. Builder inclut un concepteur WYSIWYG pour les spécialistes du marketing, et il a également beaucoup à offrir aux développeurs. Fondamentalement, Builder est un système qui permet de composants entièrement personnalisés être disposé dans l’interface utilisateur, puis connecté aux API et aux magasins de données, le tout sans perdre la possibilité de modifier encore les composants sous-jacents. Dans le même temps, il rationalise les interactions entre l’ingénierie et les parties prenantes commerciales dans le processus de développement.
J’ai récemment parlé avec Sewell de Builder, de la pile technologique qui fait avancer les choses, du niveau fou d’innovation dans l’espace JavaScript en ce moment, et plus encore.
Matthieu Tyson: Heureux d’avoir une chance de parler!
Builder est un concepteur par glisser-déposer, mais aussi bien plus encore. Vous devez passer beaucoup de temps à repousser l’envie des gens de le cataloguer en tant qu’éditeur WYSIWYG ?
Steve Sewell: Une nouvelle catégorie de produits demande beaucoup d’éducation du marché, non ? Les gens voient “glisser-déposer depuis ma pile technologique” et ils peuvent être chargés de confusion juste là.
Comme, comment s’intègrent-ils? Ils pensent que nous devons être un constructeur de site. Mais nous ne le sommes pas.
Nous construisons simplement des pièces connectées à vous. Il est piloté par l’API car notre objectif est de nous assurer que vous pouvez avoir un bon flux de travail de bout en bout. Le marketing de votre équipe peut intervenir, créer une nouvelle page, configurer un test A/B et l’exécuter, puis voir les métriques de conversion sans passer par des déploiements de code et des trucs comme ça.
Et les gens se demandent, comment faites-vous cela ? Cela ressemble à de la sorcellerie. Ensuite, nous devons expliquer tout cela.
Tyson: Quelles sont certaines des idées fausses que vous rencontrez ?
Sewell: Nous devons dissiper beaucoup de mythes que les gens ont immédiatement dans la tête. Les gens pensent généralement : « Oh, faites glisser et déposez. J’ai déjà travaillé avec un outil comme celui-là… il y a 5, 10 ans, et ça va être médiocre. Ça va être buggé. Ça va être limité. »
Et nous disons, non, en fait, c’est une approche extrêmement unique de quelque chose qui peut sembler familier, mais c’est très différent. Il offre de bonnes performances et une flexibilité et une compatibilité incroyables avec l’ensemble de votre pile de code.
Nous sommes un ami de choix. Nous sommes de retour choix. Tous vos services, votre code personnalisé et votre logique, ils se connectent tous parfaitement.
Tyson: Un défi auquel nous sommes tous confrontés est la prolifération des frameworks JavaScript front-end. Je veux dire, c’est un peu fou. Je ne suis pas sûr qu’il y ait jamais eu une telle situation, dans la mesure où il y a tant de prétendants et tant d’entre eux sont prometteurs.
A quoi attribuez-vous cela ?
Sewell: C’est une excellente question. Pourquoi tant de frameworks front-end ? Je pense que cela découle en grande partie de la numérisation du monde, n’est-ce pas ? Tout le monde doit passer au numérique. Tout le monde a besoin de vendre, d’effectuer des transactions, de communiquer, de convertir en ligne.
Mon expérience antérieure était de diriger l’équipe d’ingénierie Web d’une entreprise appelée ShopStyle. Ils exploraient tous les marchands en ligne, offrant une expérience d’achat en un seul endroit.
Nous étions à l’origine sur une pile technologique très héritée et nous sommes passés à une pile plus moderne (AngularJS) qui a permis aux développeurs d’avancer beaucoup plus rapidement. Parce qu’ils n’avaient plus à se soucier, vous savez, des parties du serveur au client. Tout l’État était au même endroit. Toute la logique était au même endroit. Et le DX était assez agréable par rapport à une sorte de pile monolithique Java plus ancienne et à jQuery, qui était difficile à maintenir. C’était une structure plus propre et meilleure.
Mais ensuite, vous trouvez la prochaine série de problèmes, c’est-à-dire que lorsque tout se passe en ligne, le taux de conversion compte beaucoup en ligne. Et lorsque tout passe au mobile, vous constatez que deux choses sont essentielles. La première est que la page initiale doit se charger très, très rapidement pour l’utilisateur final. Cela signifie donc de petites quantités de contenu à télécharger : le moins de JavaScript possible, le moins de HTML possible, des images optimisées. Tout doit être la plus petite chose nécessaire. Et deuxièmement, il doit réagir rapidement au toucher. Il doit rendre les mises à jour rapidement.
Vous avez ces trois besoins très difficiles, et il est difficile de les satisfaire tous les trois. C’est une sorte de choix et de choix pour lequel vous souhaitez optimiser… peut-être deux, mais certainement pas les trois. Entre la flexibilité du développeur, le déplacement rapide, le test de nouvelles fonctionnalités, le nouveau contenu, le temps de chargement initial rapide. C’est donc de minuscules payloads, très optimisés, presque pas de JavaScript, et puis des interactions rapides. La page suivante devrait également se charger presque immédiatement. Nous constatons qu’il y a une pression extrême pour que ces choses soient correctes. Et c’est extrêmement difficile de faire ça, n’est-ce pas ?
Nous, dans la communauté JavaScript, avons donc réagi en trouvant un assez bon équilibre entre le pré-rendu sur le serveur. Cela implique de télécharger beaucoup, d’une manière générale, pour qu’une application du monde réel hydrate cette application. Et puis vous pouvez naviguer assez rapidement. Mais je pense que certaines choses, comme SolidJS, montrent que la navigation pourrait être beaucoup plus rapide. Nous pouvons simplement passer directement à la mutation DOM. Nous pouvons garder ce bon DX. Il pourrait y avoir des victoires là-bas et il y a des gens qui poursuivent cet objectif. Et cela commence à créer une toute nouvelle vague. Les gens demandent, comment pouvons-nous charger l’application avec moins de JavaScript ou pas de JavaScript ?
C’est là que vous avez des gens comme Astro qui essaient de faire des îlots, essayant d’être HTML par défaut, des îlots qui se chargent paresseux en cas de besoin. Il y a des avantages et des inconvénients à cela, en termes de communication et de quantité d’hydratation. Ensuite, vous avez des approches comme React Server Components, qui disent, hé, nous pouvons également produire principalement du HTML pur et supprimer une grande partie du runtime DOM.
Ensuite, vous avez le plus extrême, à notre avis, qui est Qwik, qui dit en gros qu’une page peut s’initialiser sans JavaScript du tout. De manière réaliste, il faut moins de cinq kilo-octets de JavaScript pour avoir un chargeur de démarrage. Quoi qu’il en soit, nous assistons à ces compromis concurrents et à ces circonstances très difficiles, mais à cette pression économique énorme. Pression pour être plus rapide, plus léger, plus simple.
Tyson: Avez-vous une idée de la direction que prennent les choses ? A quoi ressemblera la scène dans quelques années ?
Sewell: La direction que prennent les choses est super intéressante.
Laissez-moi vous dire la partie sur laquelle nous nous concentrons. C’est ce chargement initial de la page. C’est quelque chose que les derniers mouvements Jamstack, à notre avis, prennent vraiment du retard. Il est très difficile de trouver le site Web de commerce électronique ou le site Web en général d’une échelle décente qui a un nombre décent d’ingénieurs qui y contribuent, les ingénieurs dont il a besoin pour exécuter un test A/B et personnaliser et des trucs comme ça. Vous savez, il est difficile d’en trouver un avec un très bon score Google PageSpeed Insights ou Lighthouse. Et je veux dire un score réel comme Google PageSpeed Mobile, où il teste sur une connexion 4G et un appareil émulé à faible puissance, pas sur votre MacBook Pro M1 gigabit-ethernet, n’est-ce pas ?
Ce n’est pas pour cela que nous optimisons. Nous optimisons pour des cas d’utilisation réels. C’est vraiment difficile car tous les frameworks actuels nécessitent de télécharger beaucoup de JavaScript pour devenir interactifs. Vous verrez du HTML, mais il y a beaucoup à télécharger et à exécuter sur l’appareil mobile avant de pouvoir commencer à interagir. C’est là que nous assistons à un grand mouvement vers le HTML pur.
Quelle est la plus infime quantité de JavaScript que nous puissions fournir pour nous réveiller et continuer à être interactif ? C’est le but.
Tyson: C’est un bon one-liner qui met en évidence l’une des principales approches pour aller de l’avant avec JavaScript : quel est le minimum sur le fil pour arriver à un point de départ interactif ?
Sewell: Et c’est là que vous voyez des frameworks comme Marko, qui a ouvert la voie à bien des égards. Vous voyez des frameworks comme Astro essayer de faire cette architecture d’îles, qui a des avantages et des inconvénients.
Et c’est là que vous voyez Qwik pousser cela à l’extrême, qui est capable d’initialiser une page avec moins de cinq kilo-octets de JavaScript, mais ensuite d’être immédiatement interactif. Et c’est une technologie vraiment, vraiment folle inspirée par de très nombreux endroits différents, mais c’est le résultat final en or que les gens recherchent – que votre page soit téléchargée avec juste un tout petit peu de HTML et que vous ne téléchargiez pas beaucoup de JavaScript.
Lorsque vous commencez à interagir, un peu de JavaScript entre en jeu, puis l’interaction se comporte comme prévu. Tout cela, mais en conservant le DX de l’utilisation de composants.
Nous structurons une sorte de vue déclarative de ce à quoi l’application devrait ressembler, puis les mises à jour et la réactivité devraient fonctionner. Le regroupement doit être optimisé automatiquement. Nous ne devrions pas avoir à lutter avec ces choses à la main. Ils devraient juste fonctionner. C’est donc là que nous voyons ce genre de choses se diriger. Comment pouvons-nous livrer la plus petite charge utile aussi rapidement que possible, tout en restant riche et instantanément interactif, ce qui est vraiment assez difficile. Et il y a beaucoup d’approches et c’est là que Qwik est intéressant – dans ce champ de bataille avec les autres.
Nous avons d’assez bonnes performances de rendu DOM, et nous avons des bibliothèques comme SolidJS qui le poussent plus loin et quelques autres, mais nous voyons certainement plus d’attention sur le temps de chargement initial, plus de HTML pur, moins de JavaScript. Je pense qu’il y a ceux qui utilisent des frameworks de service, encore à ce jour, et n’adoptent pas les frameworks frontaux JavaScript lourds comme Reacts parce qu’ils ne se sentent tout simplement pas à l’aise. Ils veulent du HTML pur et un peu de jQuery. Nous innovons enfin sur les moyens de le faire et de satisfaire les besoins de tout le monde de manière intelligente qui était très difficile à comprendre.
Juste pour être clair, Misko [Hevery] du côté de Qwik, c’est celui qui a compris toutes les pièces vraiment essentielles et importantes. Il y a beaucoup d’excellentes recherches menées par d’autres équipes.
Tyson: Je dois dire que lorsque j’ai regardé Qwik (l’exemple de Stackblitz), j’ai pensé, wow, les limites de chargement paresseux à l’état, aux ressources et aux événements. Qu’est-ce qui est possible avec ça ?
Sewell: Entièrement d’accord. Le truc Qwik est incroyable, et nous ne faisons qu’effleurer la surface.
Nous parlons beaucoup de HTML pur au premier chargement, mais vous parlez du fait qu’il a ces limites très granulaires, donc le potentiel de performance que vous obtenez est fou. Et avec Partytown, les choses sont complètement récupérées en arrière-plan. Nous avons fait beaucoup de recherches et avons constaté que même des choses comme la prélecture de liens consomment en fait le fil principal. Mais quand vous êtes dans le Web Worker (comme avec Partytown), c’est une sorte de territoire libre. Il est très isolé et fait son propre truc. Cela n’influence rien.
De plus, avec Partytown, vous pouvez simplement dire “le HTML interne du corps est égal à bla”, ce qui signifie que le code peut rester tel quel, et voilà, il s’exécute dans un thread de travail. Vous cliquez sur une page et les transitions et les changements d’état sont littéralement instantanés, ce qui est fou. Je veux dire comme une milliseconde, c’est juste immédiatement en direct.
Avec Qwik, tout est également automatisé. Je ne sais pas si vous avez vu la démo de l’optimiseur, mais tout est complètement automatisé. Vous n’avez pas besoin de vous disputer pour que cela fonctionne. Beaucoup de gens pensent qu’une application React avec Webpack se regroupe intelligemment et ils ne réalisent à quel point ce n’est pas intelligent avant plus tard. Ils doivent écrire manuellement ces importations asynchrones, et cela devient un gros gâchis.
Tyson: Ouais, je pense que beaucoup d’entre nous peuvent s’identifier à ça.
Sewell: Avec l’optimiseur Qwik, il divisera automatiquement votre code en groupes de la bonne taille et le réécrira essentiellement pour qu’il soit super fin et granulaire. Ainsi, lorsque vous interagissez, par exemple, les composants enfants ne s’hydratent jamais lorsque les parents le font. C’est vraiment fou à quel point il est extrêmement optimisé et mince. Et nous ne faisons qu’effleurer la surface des implications de cela. Et il peut être distribué en tant que HTML simple et il peut simplement se réveiller, puis se lyophiliser à nouveau, changer d’état.
Tyson: C’est la « possibilité de reprise » de Qwik.
Sewell: Oui, et cela pourrait vous donner des choses comme un comportement de va-et-vient vraiment granulaire, comme voyager dans le temps. Les implications et les possibilités sont folles, et c’est une approche tellement nouvelle et unique. Nous explorons chaque jour de nouvelles possibilités et des applications passionnantes, ce qui est incroyable.
Tyson: Avez-vous des conseils pour les personnes qui envisagent de créer une startup, quelqu’un avec une idée brûlante ?
Sewell: J’ai beaucoup d’opinions à ce sujet. Le principal de mes apprentissages est : être obsédé religieusement par les clients. Ainsi, vous pouvez lire La startup Lean. Vous pouvez suivre n’importe quel programme YC ou lire n’importe quelle littérature YC et cela renforcera la même idée. Mais je pense que c’est une idée tellement puissante que les gens doivent non seulement la comprendre, ils doivent être obsédés par elle.