I've worked with all three frameworks, but as a mostly single dev/engineer I very very much prefer Svelte because it lacks a lot of boilerplate that React has, and it's easier to think about than Vue's clunky way to write variables and functions.
But I'm a "hacker type" and don't work in a large tech company. I haven't seen Svelte in any sort of "real tech companies", haven't seen it on job boards, and it doesn't seem a very desirable skill.
Does this mean that Svelte "doesn't work" for large teams, because it lacks the boilerplate of React?
It's a case of "Nobody ever got fired for choosing X"[0]. No one would blame you for choosing React for a major project / new startup, but someone could definitely poke holes in choosing Svelte ("theres no package for X", "it doesn't scale", "we can't find devs that know it", etc.)
I know svelte is a very common choice for larger news sites to build interactive stories. Ive specifically heart of NYT using it as well as pudding.cool.
It makes sense for this small website extension because you can build and compile a small component without having to bundle the entire react runtime in.
It's a mixed bag of marketing, hiring pool, late mover, and cult problems. The latest one doesn't contribute much but to deaccelerate.
The critical point of adoption is libraries, there must be variety of them to serve broad kind of application. That's "late mover" problem, people are tired of re-implementing stuff again. I wish popular frameworks would pass down some funding to vanilla js libs individuals.
Marketing, it's about image of "facebook's engineering team" vs "these individuals guys". (often time, big corp's team is not that smart, really)
Hiring pool. Small companies couldn't afford shinny things (risks management), so the larger pools of dev, the less risk.
Cult, ahaa.. It seems to LOTs of devs agree that Re*ct sucks. Leaving a cult is not easy, it's leaving community. Most people don't want to leave at all, and in a sense they hate that people are leaving too! They become angry and defensive. So we don't make progress more quickly here.
This is my experience as well (in a similar situation to you). I also found Svelte far easier to grok, as someone who is generally not a web developer, than alternatives. Not having to bundle a huge runtime and deal with all the virtual DOM cruft is a nice bonus for performance, but the reality is that it's probably not a measurable difference for anything I'm doing on the front end.
We use it at Stylitics for our main user-facing product, a highly configurable 3rd party js widget, with many millions of engagements daily. It’s a small team that works on it directly, but we’re “real” and have to meet fairly stringent/“real” requirements from our big brand/retailer clients (and we’re hiring, email & link in profile)
Svelte is indeed more svelte and might appeal more to some, but React doesn’t have a lot of boilerplate to begin with. Sure, calling useState is more work than simply declaring a value and useEffect is badly designed. That’s about it.
Nowhere near enough “to work for large teams”, as is the argument for Angular and the Java world it gets its bad ideas from.
Depends on your needs. Personally I hate Svelte's data model and how it changes the semantics of your code by injecting state handling (it's a mental burden). If you are basically writing blogs or very simple content this is probably not a problem. Writing complex apps though I much prefer deterministic top-down data flow and not arbitrary reactivity.
If you hate React for some reason I'd consider SolidJS a much more principled framework.
This should really be an explicit goal of a frontend framework and a pain point I have encountered often in React and Angular. How are you supposed to debug stuff if the stack trace isn't even legible?
I work with React (Next.js) on my main project and while I don't appreciate some things generally I haven't had any issues and Next.js in particular has been great. I also find JSX stellar.
I used Vue from 0.12 until around ~2.5, I really liked it at the beginning (coming from a jQuery only world) but I was forced into learning React for React Native and then I kind of standardized on it for a while and Vue fell off.
I used Svelte for a side project recently and it was quite enjoyable but I do really miss JSX and I don't like the $: syntax. I plan to give SolidJS a try on my next side project and then I'll standardize on either Svelte or SolidJS for side projects and React for big things.
Since Svelte and SolidJS are such great options for smaller things I kind of don't have a use case for Vue anymore, but I do remember it fondly.
Next.js saved me from the mess that was Gatsby and have used it for many projects but these days I find Astro simplifies things even more and has become my go to tool.
My 2c: I think svelte is overhyped and a poor solution to the problem it's trying to solve.
First of all, I am tired of ridiculous metrics like how small svelte is when it's a really small example, and it's one or two lines of initial boilerplate.
The thing that really set svelte apart was it's better syntax and experience when it first came out. I think that was when react class components, and vue 2 was still prominent. Look at the react and vue 3 examples now. They're really close. Vue 3 in particular looks a lot like svelte with vue's sfc.
I don't even think the dissapearing part about svelte is that important. That kind of performance is rarely going to matter before other bottlenecks. And if it really is that crucial, there's nothing stopping either react or vue 3 from doing something very similar. Vue 3 already has sfc that go through a "compile" process, and it uses getter/setters to make targetted changes.
There's also some considerable challenges to svelte: it's brining in custom syntax to really tackle the problems with reactivity. That's honestly really good if we could get one unifying system. It would be wonderful. But that's a tall order. Given how much traction these other tools already have, I don't see svelte ever fully dominating. Which makes it's extra magic and custom language features even more of a burden. People already complain about vue's few dsl's in the template or react's hooks.
Finally the eco-system for the other tools have come so far. Given how much the gap has closed, and how much farther the other tools are, the better ecosystems make them much better choices. Also as much as I respect Rich Harris, it's a tough sell against people the momentum of something like Facebook or even Evan You with vue and related tools like vite. I know he's working full-time on svelte now at vercel, but the corporate side of this as well as maintaining a community around this is another hurdle. Say wha t you will about react, nobody got fired for choosing it. On the other hand, it's a punch in the gut to jump on something like sapper and then have it be oddly deprecated/rolled into sveltekit.
> I am tired of ridiculous metrics like how small svelte is when it's a really small example, and it's one or two lines of initial boilerplate.
There is nothing ridiculous about it. Svelte has a tiny* runtime library by design, so naturally the code output will be much smaller. Also as a result of its design, you do end up writing less lines of code.
> That kind of performance is rarely going to matter before other bottlenecks
It matters a lot for complex apps. React is unoptimized by default, and the standard advice is to only "optimize when you need it", which more often than not is too late. By the time you have an app with 15 context providers and nested components hundred-levels deep, and you start noticing slowness, performance optimization is a gigantic effort.
> it's brining in custom syntax to really tackle the problems with reactivity
While Svelte uses a (tiny) bit of custom syntax, React makes you bring in a ton of DSLs. Hooks, the component lifecycle, and all the third party libraries you will need to build a functional app require a lot more effort. People forget just how much stuff they had to learn.
Just throwing this out there, but have you considered that React and Vue in fact also have custom non-JS syntax? JSX is not valid JS, parsers had to be written to work with it. And Vue uses templating syntax in HTML, just like Svelte. Svelte doesn't have any non-native syntax in the JS parts, just the templating.
> I don't even think the dissapearing part about svelte is that important. That kind of performance is rarely going to matter before other bottlenecks. And if it really is that crucial, there's nothing stopping either react or vue 3 from doing something very similar. Vue 3 already has sfc that go through a "compile" process, and it uses getter/setters to make targetted changes.
It matters a lot, especially on mobile phones with less processing power and spotty internet connection.
It's a huge factor, actually. Downloading and parsing React+React-DOM on mobile phones, especially if they are not high end, is miserably slow.
Also, it's not only a user experience problem, your "Google Rank" is influenced by your lighthouse scores.
So I'd argue "that kind of performance" is business critical on several levels. At least in my experience.
Re: Sapper -> Sveltekit, you might say the same thing for React Router users who adopted Reach-router, back to react-router and are now on remix-router or next.js router.
Also I found it weird that you mention Evan You WRT vite as a counter to why Rich might be up against stronger devs, but Rich made rollup, which was foundational to Vite's bundling.
When my partner and I were getting started with Svelte we noticed there was plenty of wrapper libraries, but very few that lean into the benefits of Svelte specifically. We wanted something like Mantine from the React world.
We're still early days (open source and public for about a month) but the feedback has been really positive. The one thing to note is we pair heavily with Tailwind, so if that's not your jam the library may not be for you. However for any sizable app where you're building with a design system, something like this can fit right in.
Hopefully you can give it a try and it helps out! My username is the same on our Discord if you need any help!
I still think Vue (especially Vue 2) is the greatest of them all. I've worked professionally with Angular, React, and Vue. Each for several years. Vue is easily the winner for me with the syntax that closely matches native HTML and JS/TS and how it encourages clean separation of concerns and clean code. JSX/TSX is absolutely the worst for the latter, it's like the wild west. "But you don't have to write it that way" - yeah ok, but when you work in a large organization it's going to get written that way by your peers; good luck trying to stop it. Angular is just a clusterfuck of pipes and observables that require higher cognitive load to unravel when trying to understand a semi-complex block of code. Contrast with Vue where I can near instantly understand what it's trying to accomplish.
This shit right here - {#if <condition>} {:else} {/if} - is why Svelte is deterring me. For the love of god, can we stop coming up with weird custom syntax for templating code? This is one area where Angular also pisses me off: *ngIf for example is just as hideous. With Vue: v-if, v-else. You add it as an attribute to native html, it's dead simple. No weird symbols, no braces or other oddball shit I have to look up when I step away from it for a few months and come back. It just makes sense right away.
Amen brother preach however I don't agree with the last paragraph.
It's just a different way of expressing it and in React that's actually straightforward, all your interpreted logic is in {}.
Each of them has their upsides but personally I use Vue because it just worksTM. And it has vuex-orm, which albeit not perfect is the only no bs client state orm that you can query any way you like and supports relationships.
I was in an Angular discord and dared speak against the pipes/streams. They has their place but ultimately they're too complicated for every day use. No it's not an issue of me not being able to deal with them. It's a too complicated way.
Sometimes all you need is 1 variable, to which the moderators there said I'm doing it wrong, no it's in the data store and I want that 1 var's value, I have to break my fingers just to get it, a block of code to get 1 value, since I can't write if a == 10...
Well they kept suggesting I'm too dumb to handle it and in the end banned me for criticizing their holy framework.
I said that I've recently worked with Vue, you have to try other things too, after 3 years of Angular and that Vue was a productivity increase and that I finished 2 projects with vue in the same time I did half a project in Angular.
In the end Vue won it for me, I tried React also NextJS and React has some nice things, it's more JS , more straightforward than Vue but its ecosystem is a hell of commercial offerings.
Want to use MUI? Well pay up. Redux-orm complicated because Redux is complicated.
Svelte, I'd love to use it but it's always in development it seems and no "proper" or well maintained packages seem to exist.
I did 2 experimental projects with Svelte, it's nice and it's fast but it's never there... always in development
> This shit right here - {#if <condition>} {:else} {/if} - is why Svelte is deterring me. For the love of god, can we stop coming up with weird custom syntax for templating code?
I noticed that, too. Also, the {#each posts as post} struck me as being different as a fashion statement t. What was wrong with the good ol’ “for item in items” syntax?
I don't see how Svelte is "React without all of the bullshit", Svelte really seems like the complete opposite of React. To me it's more like a modern Angular 1 where it's a magic HTML DSL (just now with a compile step to make it more optimized). For instance, Angular 1 had the ng-if attribute in templates for optionally including parts of the template based on JS values and Svelte has {#if ... } blocks in templates that do similar. Whereas React is just JavaScript, you just write a function and ifs like anywhere else.
Seeing Svelte take the global variables (are they now not global because of Svelte's compiler? probably) in a <script> tag and binding them to HTML elements seems too magic for me. Whereas at least with React, I can sort of understand how it works under the hood and could probably write a poorly optimized version of it without thinking much about it.
React isn't perfect by a long shot so I think something will eventually overtake it, but I hope it's not magic HTML templates, that seems like a step back.
Just one note. The article spends a lot of time talking about how all react returns must be wrapped.....
Dude, just use fragments it's just an empty tag in the jsx compiler and adds like zero effort.
Other than that, seems interesting. Didn't actually function in the embedded browser used in my hn client so that's bad... But overall seems like it's worth a try.
I'd really like to hear more from Svelte devs about what non-happy paths look like. I specialise in React.js and there are any number of escape hatches to make sure you can get something working just the way you want. What I fear about Svelte is getting to 95% complete and finding the one obscure thing a stakeholder will not budge on is not possible.
I'm afraid of switching to Svelte because of what happened to Angular. I switched to Vue because of Angular's 1.x to 2+ upgrade. Then I was faced with the Vue 2 to Vue 3 upgrade, which now has a lot of my code in a state of mess.
Svelte has always looked so promising, just what I wanted. But my fear is that if I ditch Vue and jump to Svelte, it will do the same thing as any other framework did: become a monster and cause problems with all my dependencies.
Svelte is what Ember could have been and where I suspect Vue is ultimately going (in their own flavor of course). If you really like templates and the constraints they bring over being closer to plain JavaScript, Svelte takes that to the most logical "extreme".
On the other hand, if you like leveraging most JavaScript features then React, Preact, Inferno, SolidJS and especially Lit are much closer to allowing developers to use any part of the language that is useful, with some exceptions for reactivity.
Lit in particular is 100% JavaScript primitives and very little sugar on top.
My endgame is lib like uhtml/lit-html(alone), custom element, event delegation technique and global store. You can write any fancy widget with this. Writing your own (event -> update -> render) is not rocket science, just utilizing the platform! (seriously, don't make fun of platform, it's legit)
"Introducing"? Hasn't Svelte existed for a couple of years already? I remember a speaker talking about it on a conference some time before Covid hit.
Still, it's a great article that does a good job of showing how easy Svelte is. I think it looks most like Vue, but simpler, with even less boilerplate.
Of course keeping everything so simple does make me wonder how it would deal with more complex situations where you really do need a lot more structure.
Personally to me the best framework is no framework at all. Instead I use libraries of code and Web Components. The libraries are either my own or some existing ones. Overall writing web front end this way for me is the most natural way.
In my personal experience I spend less time creating the web front ends this way comparatively to when using "frameworks". No "compiling" is needed either, other then optional minimization.
At windmill (https://github.com/windmill-labs/windmill), our whole frontend is in svelte, we love it, the performance are second to none and the dev experience is great. But finding svelte dev is proving itself harder than I thought. So there is that issue as well.
Surely any reasonably smart React dev will become productive within a very short period of time? Or is it that people simply don't apply when they see Svelte on the tech list?
Just published an app on both app stores using Svelte and Ionic. Svelte was a pleasure to use - everything seems like just enough of what you need, without adding any additional mental overhead or complexity.
I'm really looking forward to the stable release of SvelteKit to use as the backend for my next project.
Svelte/Solid JS and reactivity are great; Reactivity definitely is a better philosophy than Virtual DOM diffing.
However, I'd like to add one more reason to the "arguments adopting svelte" and that is native development.
Svelte Native doesn't even come close to touching React Native in maturity, and I'm willing to bet it never will.
For a startup to consider a frontend technology, React is easily the better choice in terms of capital because there is no way you're going to build a production ready native app in Svelte Native.
If you were to build your web client in Svelte, then you would have to spend capital on another team to build Native (God forbid in React Native), in which you would split teams on ios and android.
Or you could you use just one team for React + RN altogether and save you possibly millions in capital.
Also I'd like to mention that the NYT article that was linked to showcase Svelete actually showcases more of D3 instead.
Mike Bostock also used to work for NYT and NYT absolutely loves using D3.
Svelte is brilliant. The new things you have to learn are minimum. New devs can be productive since day one. I don't know why I would ever want to use vue or react.
[+] [-] yawnxyz|3 years ago|reply
But I'm a "hacker type" and don't work in a large tech company. I haven't seen Svelte in any sort of "real tech companies", haven't seen it on job boards, and it doesn't seem a very desirable skill.
Does this mean that Svelte "doesn't work" for large teams, because it lacks the boilerplate of React?
[+] [-] mritchie712|3 years ago|reply
0 - https://www.quora.com/What-does-the-phrase-Nobody-ever-got-f...
[+] [-] illegalmemory|3 years ago|reply
[+] [-] msdrigg|3 years ago|reply
It makes sense for this small website extension because you can build and compile a small component without having to bundle the entire react runtime in.
[+] [-] Existenceblinks|3 years ago|reply
The critical point of adoption is libraries, there must be variety of them to serve broad kind of application. That's "late mover" problem, people are tired of re-implementing stuff again. I wish popular frameworks would pass down some funding to vanilla js libs individuals.
Marketing, it's about image of "facebook's engineering team" vs "these individuals guys". (often time, big corp's team is not that smart, really)
Hiring pool. Small companies couldn't afford shinny things (risks management), so the larger pools of dev, the less risk.
Cult, ahaa.. It seems to LOTs of devs agree that Re*ct sucks. Leaving a cult is not easy, it's leaving community. Most people don't want to leave at all, and in a sense they hate that people are leaving too! They become angry and defensive. So we don't make progress more quickly here.
[+] [-] dstick|3 years ago|reply
I've been working exclusively with Vue for the last... 6 years. Since the launch of v2. So my mind is already conditioned ;-)
[+] [-] spuz|3 years ago|reply
And also the #jobs channel on the Svelte Discord https://svelte.dev/chat
There are jobs being posted every day. And btw, we're one of those looking for Svelte engineers.
[+] [-] swyx|3 years ago|reply
https://twitter.com/sveltesociety/status/1260209026563858432...
[+] [-] mcronce|3 years ago|reply
[+] [-] jraines|3 years ago|reply
[+] [-] gherkinnn|3 years ago|reply
Nowhere near enough “to work for large teams”, as is the argument for Angular and the Java world it gets its bad ideas from.
[+] [-] nightski|3 years ago|reply
If you hate React for some reason I'd consider SolidJS a much more principled framework.
[+] [-] danra|3 years ago|reply
[+] [-] cutler|3 years ago|reply
[+] [-] Tade0|3 years ago|reply
Working with this framework I found that it was very easy for me to trace back to where the change that caused the error happened.
You don't get this in most frameworks, which hide everything under layers of event handlers, schedulers and whatnot.
[+] [-] Sammi|3 years ago|reply
[+] [-] pixard|3 years ago|reply
I used Vue from 0.12 until around ~2.5, I really liked it at the beginning (coming from a jQuery only world) but I was forced into learning React for React Native and then I kind of standardized on it for a while and Vue fell off.
I used Svelte for a side project recently and it was quite enjoyable but I do really miss JSX and I don't like the $: syntax. I plan to give SolidJS a try on my next side project and then I'll standardize on either Svelte or SolidJS for side projects and React for big things.
Since Svelte and SolidJS are such great options for smaller things I kind of don't have a use case for Vue anymore, but I do remember it fondly.
[+] [-] mccorrinall|3 years ago|reply
Want to only allow a specific http method for this route? Have fun adding boilerplate.
Want to throw a specific http error like 403? Have fun writing this by hand.
It also lacks schema validation (I’d love to see ajv here) and openapi gen. You have to write everything. by. yourself.
[+] [-] jjdeveloper|3 years ago|reply
[+] [-] halfmatthalfcat|3 years ago|reply
[+] [-] zozbot234|3 years ago|reply
[+] [-] shroompasta|3 years ago|reply
almost with many things in software development to be honest.
[+] [-] preommr|3 years ago|reply
First of all, I am tired of ridiculous metrics like how small svelte is when it's a really small example, and it's one or two lines of initial boilerplate.
The thing that really set svelte apart was it's better syntax and experience when it first came out. I think that was when react class components, and vue 2 was still prominent. Look at the react and vue 3 examples now. They're really close. Vue 3 in particular looks a lot like svelte with vue's sfc.
I don't even think the dissapearing part about svelte is that important. That kind of performance is rarely going to matter before other bottlenecks. And if it really is that crucial, there's nothing stopping either react or vue 3 from doing something very similar. Vue 3 already has sfc that go through a "compile" process, and it uses getter/setters to make targetted changes.
There's also some considerable challenges to svelte: it's brining in custom syntax to really tackle the problems with reactivity. That's honestly really good if we could get one unifying system. It would be wonderful. But that's a tall order. Given how much traction these other tools already have, I don't see svelte ever fully dominating. Which makes it's extra magic and custom language features even more of a burden. People already complain about vue's few dsl's in the template or react's hooks.
Finally the eco-system for the other tools have come so far. Given how much the gap has closed, and how much farther the other tools are, the better ecosystems make them much better choices. Also as much as I respect Rich Harris, it's a tough sell against people the momentum of something like Facebook or even Evan You with vue and related tools like vite. I know he's working full-time on svelte now at vercel, but the corporate side of this as well as maintaining a community around this is another hurdle. Say wha t you will about react, nobody got fired for choosing it. On the other hand, it's a punch in the gut to jump on something like sapper and then have it be oddly deprecated/rolled into sveltekit.
[+] [-] ricardobeat|3 years ago|reply
There is nothing ridiculous about it. Svelte has a tiny* runtime library by design, so naturally the code output will be much smaller. Also as a result of its design, you do end up writing less lines of code.
> That kind of performance is rarely going to matter before other bottlenecks
It matters a lot for complex apps. React is unoptimized by default, and the standard advice is to only "optimize when you need it", which more often than not is too late. By the time you have an app with 15 context providers and nested components hundred-levels deep, and you start noticing slowness, performance optimization is a gigantic effort.
> it's brining in custom syntax to really tackle the problems with reactivity
While Svelte uses a (tiny) bit of custom syntax, React makes you bring in a ton of DSLs. Hooks, the component lifecycle, and all the third party libraries you will need to build a functional app require a lot more effort. People forget just how much stuff they had to learn.
* fixed from 'no runtime'
[+] [-] 7sidedmarble|3 years ago|reply
[+] [-] kolme|3 years ago|reply
It matters a lot, especially on mobile phones with less processing power and spotty internet connection.
It's a huge factor, actually. Downloading and parsing React+React-DOM on mobile phones, especially if they are not high end, is miserably slow.
Also, it's not only a user experience problem, your "Google Rank" is influenced by your lighthouse scores.
So I'd argue "that kind of performance" is business critical on several levels. At least in my experience.
[+] [-] davidjfelix|3 years ago|reply
Also I found it weird that you mention Evan You WRT vite as a counter to why Rich might be up against stronger devs, but Rich made rollup, which was foundational to Vite's bundling.
[+] [-] thunderbong|3 years ago|reply
However, for any front-end framework, the UI is paramount, and the most full-fledged component framework I found was Carbon Components[0].
I've heard rave reviews about Quasar[1] for Vue 3. Are there any equivalent UI component frameworks for Svelte?
[0]: https://carbondesignsystem.com/developing/frameworks/svelte/
[1]: https://quasar.dev/layout/grid/row
[+] [-] engido9740|3 years ago|reply
https://skeleton.brainandbonesllc.com/
https://github.com/Brain-Bones/skeleton
When my partner and I were getting started with Svelte we noticed there was plenty of wrapper libraries, but very few that lean into the benefits of Svelte specifically. We wanted something like Mantine from the React world.
We're still early days (open source and public for about a month) but the feedback has been really positive. The one thing to note is we pair heavily with Tailwind, so if that's not your jam the library may not be for you. However for any sizable app where you're building with a design system, something like this can fit right in.
Hopefully you can give it a try and it helps out! My username is the same on our Discord if you need any help!
[+] [-] ibz|3 years ago|reply
[0]: http://daisyui.com
[+] [-] jdthedisciple|3 years ago|reply
[+] [-] y-c-o-m-b|3 years ago|reply
This shit right here - {#if <condition>} {:else} {/if} - is why Svelte is deterring me. For the love of god, can we stop coming up with weird custom syntax for templating code? This is one area where Angular also pisses me off: *ngIf for example is just as hideous. With Vue: v-if, v-else. You add it as an attribute to native html, it's dead simple. No weird symbols, no braces or other oddball shit I have to look up when I step away from it for a few months and come back. It just makes sense right away.
[+] [-] lakomen|3 years ago|reply
Each of them has their upsides but personally I use Vue because it just worksTM. And it has vuex-orm, which albeit not perfect is the only no bs client state orm that you can query any way you like and supports relationships.
I was in an Angular discord and dared speak against the pipes/streams. They has their place but ultimately they're too complicated for every day use. No it's not an issue of me not being able to deal with them. It's a too complicated way. Sometimes all you need is 1 variable, to which the moderators there said I'm doing it wrong, no it's in the data store and I want that 1 var's value, I have to break my fingers just to get it, a block of code to get 1 value, since I can't write if a == 10...
Well they kept suggesting I'm too dumb to handle it and in the end banned me for criticizing their holy framework. I said that I've recently worked with Vue, you have to try other things too, after 3 years of Angular and that Vue was a productivity increase and that I finished 2 projects with vue in the same time I did half a project in Angular.
In the end Vue won it for me, I tried React also NextJS and React has some nice things, it's more JS , more straightforward than Vue but its ecosystem is a hell of commercial offerings. Want to use MUI? Well pay up. Redux-orm complicated because Redux is complicated.
Svelte, I'd love to use it but it's always in development it seems and no "proper" or well maintained packages seem to exist. I did 2 experimental projects with Svelte, it's nice and it's fast but it's never there... always in development
[+] [-] throwaway1851|3 years ago|reply
I noticed that, too. Also, the {#each posts as post} struck me as being different as a fashion statement t. What was wrong with the good ol’ “for item in items” syntax?
[+] [-] s-lambert|3 years ago|reply
Seeing Svelte take the global variables (are they now not global because of Svelte's compiler? probably) in a <script> tag and binding them to HTML elements seems too magic for me. Whereas at least with React, I can sort of understand how it works under the hood and could probably write a poorly optimized version of it without thinking much about it.
React isn't perfect by a long shot so I think something will eventually overtake it, but I hope it's not magic HTML templates, that seems like a step back.
[+] [-] Justsignedup|3 years ago|reply
Dude, just use fragments it's just an empty tag in the jsx compiler and adds like zero effort.
Other than that, seems interesting. Didn't actually function in the embedded browser used in my hn client so that's bad... But overall seems like it's worth a try.
[+] [-] Vanit|3 years ago|reply
[+] [-] qwertox|3 years ago|reply
Svelte has always looked so promising, just what I wanted. But my fear is that if I ditch Vue and jump to Svelte, it will do the same thing as any other framework did: become a monster and cause problems with all my dependencies.
So I'm staying with Vue.
[+] [-] nileshtrivedi|3 years ago|reply
- An SVG-based graph dataset editor: https://codeberg.org/nilesh/grapher
- A curated collection of educational resources: https://github.com/learn-awesome/learndb
Compared to React, developing with Svelte felt like a breath of fresh air.
[+] [-] no_wizard|3 years ago|reply
On the other hand, if you like leveraging most JavaScript features then React, Preact, Inferno, SolidJS and especially Lit are much closer to allowing developers to use any part of the language that is useful, with some exceptions for reactivity.
Lit in particular is 100% JavaScript primitives and very little sugar on top.
[+] [-] Existenceblinks|3 years ago|reply
[+] [-] mcv|3 years ago|reply
Still, it's a great article that does a good job of showing how easy Svelte is. I think it looks most like Vue, but simpler, with even less boilerplate.
Of course keeping everything so simple does make me wonder how it would deal with more complex situations where you really do need a lot more structure.
[+] [-] FpUser|3 years ago|reply
In my personal experience I spend less time creating the web front ends this way comparatively to when using "frameworks". No "compiling" is needed either, other then optional minimization.
[+] [-] rubenfiszel|3 years ago|reply
[+] [-] widdershins|3 years ago|reply
[+] [-] pugio|3 years ago|reply
I'm really looking forward to the stable release of SvelteKit to use as the backend for my next project.
[+] [-] 2OEH8eoCRo0|3 years ago|reply
https://github.com/containers/podman-desktop
[+] [-] shroompasta|3 years ago|reply
However, I'd like to add one more reason to the "arguments adopting svelte" and that is native development.
Svelte Native doesn't even come close to touching React Native in maturity, and I'm willing to bet it never will.
For a startup to consider a frontend technology, React is easily the better choice in terms of capital because there is no way you're going to build a production ready native app in Svelte Native.
If you were to build your web client in Svelte, then you would have to spend capital on another team to build Native (God forbid in React Native), in which you would split teams on ios and android.
Or you could you use just one team for React + RN altogether and save you possibly millions in capital.
Also I'd like to mention that the NYT article that was linked to showcase Svelete actually showcases more of D3 instead.
Mike Bostock also used to work for NYT and NYT absolutely loves using D3.
[+] [-] lexx|3 years ago|reply
[+] [-] nathias|3 years ago|reply