Avantages de Svelte face à React et Vue
Y a-t-il un avantage à utiliser Svelte au lieu de React ou Vue?
Est-ce juste à cause de la performance ?
Il est plus facile d'intégrer des bibliothèques JavaScript "brutes" parce que Svelte agit sur des objets DOM réels, pas sur des objets virtuels.
Pour Vue au moins, une bibliothèque JS vanille est un composable loin de l'intégration. Vue utilise le domaine virtuel pour diffing, mais il met à jour le dom sur la configuration, et les mises à jour ultérieures ne se produisent atomiquement que après les changements d'état.
Je suis d'accord. J'ai couru dans quelques fois où j'avais besoin d'intégrer des bibliothèques de vanille javascript et il fonctionne juste avec svelte. je n'ai pas utilisé vue dans les âges donc je ne sais pas ou ne me souviens pas si elle a des capacités similaires.
La réactivité granulaire ?
Pas besoin d'envoyer un runtime puisque Svelte n'utilise pas de dom virtuel.
Svelte a un temps d'exécution avec svelte 5 pour les runes et les signaux - mais il est petit et permet aux applications d'évoluer beaucoup mieux que précédemment. Donc avant svelte 5 il n'y avait pas de temps d'exécution, mais donc le code a été "duplicé" entre les composants. Maintenant, il est un peu plus grand à commencer, mais c'est pourquoi l'application se développe beaucoup plus lentement qu'avant.
J'ai pensé qu'il utilisait les signaux JavaScript en dessous.
Bien sûr, les signaux sont mis en œuvre dans JavaScript, mais il n'y a pas de norme pour les signaux dans JavaScript.
son juste plus agréable à travailler avec imo. vue est similaire, mais la différence entre réagir est étonnante. réagir vous oblige à apprendre un tas de concepts supplémentaires et de trous et de fusils à éviter.
Malheureusement, j'ai converti de sveltekit à nuxt parce qu'il est juste assez grand pour ne pas s'inquiéter de l'échelle de votre équipe.
Qu'est-ce qui empêche une équipe d'utiliser svelte de l'échelle?
Rien d'autre que d'être relativement vert pour les nouveaux développeurs.
Je dirais que tout développeur assez intelligent pour saisir React peut dépasser leur React-self dans Svelte dans une semaine ou plus. ils auront bien sûr encore un peu de fumbling à travers les traductions "comment faire X dans Svelte", mais même avec les documents ouverts en permanence, ils peuvent généralement dépasser leur React-hook-soup-self.
Il peut servir aux mêmes fins que le projet vue ou réaction. J'ai même commencé mon entreprise à l'aide de svelte, et c'est possible. Svelte peut être plus rapide dans le développement, mais en même temps quand vous rencontrez un problème, il est tellement plus difficile à résoudre. Sans parler de l'acquisition de talents car c'est tellement plus simple pour vue, car il y a juste plus de développeurs pour cela. J'aime svelte et a toujours été un défenseur, ne me trompez pas.
Pourquoi est-il plus difficile de résoudre les problèmes de Svelte? La base de codes est assez bien entretenue par certaines personnes clairement très compétentes, il est donc possible de jeter un coup d'œil à la raison pour laquelle cela ne fonctionne pas. En particulier avec l'aide de l'IA. Et la documentation est assez grande aussi. Pour moi, la chose la plus confuse à propos de sveltekit est à quel point c'est simple. C'est comme si je m'attendais à plus de magie noire qu'il n'y en a. Mais peut-être que je ne l'ai pas utilisé assez longtemps.
C'est tout simplement pas (selon mon expérience). J'ai construit dans Svelte depuis les premiers jours, avec de nombreuses applications en production. Je construis dans React pour le travail normal, et Svelte pour toutes mes propres choses. React crée un paradoxe intéressant où il introduit de nombreux problèmes en raison de la complexité qu'il exige. Cela fait que les développeurs craignent un public plus petit dans Svelte parce qu'ils se demandent "qui répondra à toutes ces questions que j'ai toujours???" Mais la réponse est plus proche de "de nombreuses de ces questions que vous n'auriez même pas dans Svelte". C'est pourquoi je soutiens également que tout développeur assez intelligent pour garder leur propre dans React peut absolument l'écraser (en aucun temps) dans Svelte
Oui, je suis d'accord, c'est exactement ce que je veux dire.La chose la plus effrayante est qu'il n'y a pas beaucoup à s'inquiéter à Svelte, donc il semble que quelque chose manque
Les pires problèmes que j'ai eu à traiter avec l'utilisation de Svelte étaient les différences subtiles dans la façon dont les chaînes de dépendances de magasins dérivés et les déclarations réactives '$:' traitaient les mises à jour, créant des différences de comportement à la logique apparemment équivalente. Mais même cela était prévisible, architecturellement compréhensible, facile à travailler et donc à peine un problème significatif que la plupart des développeurs expérimentés de Svelte ne sont même pas conscients de cela.
Je sens que je suis l'un des rares qui n'aiment pas vraiment les runes ... ils sont formidables dans certains cas, et se sentent comme une régression DX dans d'autres. Tout à fait d'accord avec vous sur certains des défis de réactivité, mais alors chaque cadre réactif semble avoir ce problème d'une manière ou d'une autre (certainement dans React dans mon expérience).
absolument
pour codage agent moins l'expédition de jetons
Ah, lol, je n'ai pas parlé de cette
Vous vous trompez jusqu'à ce que vous le prouviez
Je n'ai pas essayé récemment, mais j'ai senti le contraire il y a quelques mois, alors que les modèles stupides ont juste installé des paquets de réaction, même si je ne l'ai pas dit.
Je l'ai trouvé facile à utiliser lors de la création d'une bibliothèque de générateur d'images avec un itinéraire .png ce n'est tout simplement pas quelque chose que vous pouvez faire en vue. Vous pouvez en réaction car il prend en charge ces fonctions côté serveur. Svelte se sentait plus facile et plus propre quand j'ai testé les deux. (Utilisé pour générer des en-têtes uniques pour des messages sur un blog basé sur une version slug du titre comme la graine)
Moins de stress
Pratiquement tout sauf le marché du travail
Je pourrais être rejeté pour dire cela, mais je pense que le marché de l'emploi est tout aussi difficile aujourd'hui, indépendamment de la bibliothèque ou du cadre, et cela devient une vieille discussion.
Pour ce qui en vaut la peine, l'IA est ce qui m'a fait commencer à "utiliser" Svelte pour la première fois. Je ne pouvais pas le justifier auparavant, en dépit de la recherche et de la conclusion que c'est probablement le meilleur cadre globalement, mais maintenant que je peux fondamentalement réécrire n'importe quoi dans n'importe quoi, je suis allé de ne jamais toucher Svelte à l'utiliser partout. Les agents semblent bien fonctionner avec elle. Je n'ai jamais réellement écrit une ligne de code Svelte moi-même - ou, franchement, n'importe quel code front-end, pré-AI j'ai toujours travaillé avec des behemoths vanilla JS/TS - mais je suis fondamentalement juste battu les AI avec "Ok essayez de diviser
Svelte coûte moins de jetons. Sérieusement! J'ai développé un site Web complexe 3x en utilisant Svelte, React et Vue en utilisant Claude 4.8 Svelte était beaucoup moins cher. Tout comme l'élixir est moins cher que Python Zig est moins cher que la rouille Le développement d'élixir est moins cher que la plupart des langues. Est-il vraiment important de savoir quelle est la langue? Il s'agit de vitesse et de coût de jeton, pas de jours d'homme. C'est: À quelle vitesse vous pouvez obtenir une solution sans erreur en utilisant le nombre minimum de jetons. Les technologies qui sont les moins chères à développer avec LLMs devraient prévaloir à moins que les vendeurs de jetons ne puissent influencer les piles de technologie.
Hahaha oh lord imaginez l'optimisation pour l'embauche pour les emplois de codage à la main en 2026
Bien qu'il ne soit pas manuellement codé, les ouvertures d'emplois nécessitent toujours de l'expérience dans la langue et le cadre spécifiques et l'infrasphère que le projet utilise, pas seulement dans une langue, un cadre et un infrasphère.
Commentaire très clair
Slam dunk comment.
Code plus clair et plus simple, moins d’armes à feu et d’idiosyncrasies de cadre, pas de vDOM (il va au-delà de la performance).
Oui, vous aurez du plaisir à déboguer quand ils envoient une version complètement cassée du cadre Autre que cela, DX est beaucoup, beaucoup pire. L'intégration TS est également beaucoup pire. Svelte est un cadre amusant si vous l'utilisez sur votre type de projet de liste à faire.
Le logiciel a des bugs, ils l'ont déjà résolu.
Vous ne devriez pas installer des paquets qui sont jeunes de toute façon en ce jour et âge courtoisie des attaques de la chaîne d'approvisionnement.
>mehhhhh ils ont publié une version fixe en 24 heures Ils l'ont fait? https://www.npmjs.com/package/svelte?activeTab=versions Je pensais que la version cassée était celle qui était la dernière depuis 3 jours avec 130k téléchargements.
Vous mettez à jour les versions les plus récentes de tous vos paquets, en production? Êtes-vous mendiant d'être piraté? Aucune politique d'âge minimum?
Mieux vaut arrêter de boire
DX. J'ai étudié React pour comme 3 fois, différents cours, des dizaines de projets d'animaux de compagnie. Il m'a fallu environ 4 mois avant qu'il clique. Mais avec Svelte j'étais prêt à créer dans les 3 jours d'étude. BTW il est ridicule que Svelte se sente plus proche de Vanilla JS, que de React. Même si c'est DSL.
J'ai eu quelques années de réaction sous ma ceinture avant de toucher Svelte, et dans un jour ou deux, j'étais déjà plus rapide sur ce dernier. Même juste en passant par les tutoriels, il y avait une réaction d'esprit après l'autre... penser "omg, cela aurait pris beaucoup plus dans React (ou il n'est même pas géré nativement)".
React a aussi un DSL, JSX n'est pas de la vanille
JSX est le sucre synthétique pour React.createElement()
Oui, c'est du sucre syntaxique. Les modèles Vue sont du sucre pour Vue createElement Svelte Les modèles Svelte sont du sucre pour les opérations de dom Ils utilisent chacun des extensions de fichiers non standard, .tsx/jsx, .vue et .svelte. Tous sont des DSL qui ne sont pas compatibles avec vanille JS
Hmm, ça a du sens
santé mentale
syntaxe propre, presque la même que vue, pas trop besoin d'ext deps
Fonctionnalités à distance: https://svelte.dev/docs/kit/remote-functions
Et maintenant ils prennent en charge le streaming en temps réel.
J'ai écrit React professionnellement puisqu'il s'agissait d'une nouvelle bibliothèque de niche de Facebook.
En fait, les outils de bandage sont meilleurs pour React Still.
La même équipe sur les deux comptes! travaille toujours dans React à ce jour (pour le travail), et peut toujours dire en toute sécurité que Svelte est juste plus propre, plus simple, de meilleures performances, et résout tant de problèmes au niveau de l'application que React ne le fait pas.
😂 😂 Ma journée
Il est bon pour le développement web intégré car il utilise moins de stockage
il est difficile d'écrire un mauvais code. le compilateur fait juste le lourd lifting. Un tableau de bord de production était de 2MB sur mon React MVP à 500kb dans mt Svelte Code. Tout se charge rapidement, l'application est snappy, le code n'est pas un enfer d'appel. Moins compromis écosystème de paquets, moins de bibliothèques à apprendre. il fonctionne juste.
1.DX 2.Probe enregistre plus de jetons pour le codage agentique 3.Pas de concepts étranges à apprendre... contrairement à React
Vous déclarez ce que votre HTML/CSS est pour un ensemble donné de variables (état): c'est le templating. 2. Vous écrivez la même logique connectant les actions de l'utilisateur à des changements dans cet état: c'est la programmation. C'est le travail entier. Svelte 5 a pris les deux et les a perfectionnés. Programmation: avec les runes, un état est juste une variable TypeScript. laissez compter = $state(0), puis 'compte++. Vous écrivez la même logique connectant les actions de l'utilisateur à des changements dans cet état: ce n'est rien de spécial, pure TypeScript. Templating: vous faites un fichier .svelte`` et écrivez HTML/CSS avec un grand langage de template, en utilisant ces variables
Angulaires pour les rues, Svelte pour les feuilles
Tu gardes ta sagesse ?
tout
Plus facile sur les agents de codage. Ils peuvent raisonner plus facilement avec svelte car les choses ne sont pas trop abstraites.
Utilisez ce qu’il y a de mieux.
Vous allez l'aimer, c'est le plus grand avantage.
Une bibliothèque pour Frontend et Backend, React peut le faire aussi, mais Reac le complique.
réagir: nous avons des solutions à vos problèmes, puis nous avons des solutions aux problèmes que nos solutions précédentes ont fait... et maintenant vous téléchargez 600kb de réagir sur le chargement de la page svelte: nous avons réactivité... gestion de l'état... et JavaScript, trouver la solution à votre problème par vous-même bro
Le pivot serait Web Components, et l'utilisation intelligente du bundling. Nous n'avons pas besoin de compter entièrement sur un cadre complet. Choisissez tout ce qui fonctionne pour une petite portée, construisez des composants / widgets et emballez le contexte afin que l'IA puisse mieux livrer, et vous pouvez également contrôler la qualité. Mais cela n'a pas d'importance car nous voulons rendre tout propriétaire avec Rust / Go et Web Assembly.
Je dirais que la question est "vs réagir". donc, l'expérience du développeur. Vue a un DX assez identique.
Développeur Experience est juste plus beau, a travaillé pendant 3 ans dans une pile Svelte, SvelteKit, Typescript, GraphQL.
Pourriez-vous écrire un peu plus de nicotine ?
React tutoriel est souvent le sentiment que vous avez besoin d'une liste complète de dépendances seulement pour obtenir les choses de base fonctionnent. Beaucoup de cela peut se sentir hacky, pas très arrondi, et plein de concepts étranges ou pièges cachés qui ne sont pas évidents au début. Au fil du temps, il se sent gonflé, en particulier dans des composants complexes comme une base de codes héritée / paiement ou des choses similaires. J'ai travaillé sur une boutique en ligne pour une marque de mode ici en Allemagne, où nous avons été replatformé sur Svelte assez rapidement. Il était amusant de travailler avec, et parce que je l'ai tant apprécié, j'ai appris beaucoup le long du chemin avec Svelte, SvelteKit, TypeScript, et Graph