Introducing Svelte, and Comparing Svelte with React and Vue (2021)(joshcollinsworth.com)
joshcollinsworth.com
Introducing Svelte, and Comparing Svelte with React and Vue (2021)
https://joshcollinsworth.com/blog/introducing-svelte-comparing-with-react-vue
212 comments
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.)
0 - https://www.quora.com/What-does-the-phrase-Nobody-ever-got-f...
0 - https://www.quora.com/What-does-the-phrase-Nobody-ever-got-f...
Absolutely. I tried to push us to try Svelte at my last job at BigCo for over four years, to replace an internal templating system. We didn't even use React or Node yet, so not only we had to convince the old guard to adopt something new, but also deal with the React-grown crowd protesting.
You can't imagine the amount of flak I've taken for that. Managed to get it on a back-of-the-house system, while we built a massively complex React app for the main product. Everyone who worked on it loved it, but was still considered risky. Now that it has a gazillion GH stars and is mentioned in 1 out of 3 blog posts, of course things are much easier.
You can't imagine the amount of flak I've taken for that. Managed to get it on a back-of-the-house system, while we built a massively complex React app for the main product. Everyone who worked on it loved it, but was still considered risky. Now that it has a gazillion GH stars and is mentioned in 1 out of 3 blog posts, of course things are much easier.
Man, on one hand... evaluating frameworks is just part of the job, right? Same as evaluating a vendor service, or a third-party package, or an architecture or a pattern...
On the other hand, novelty burnout is a real thing. Javascript has mutated so much in a short period of time that it's become impossible to keep up with -- especially once you factor in frameworks and tooling.
Times like this, I wish vanilla JS/ECMAscript was more powerful out of the box. For a language designed to work with the HTML DOM -- the ONLY language that works natively with it -- it is so woefully underpowered. Why do we need a framework at all to do a simple stateful AJAX UI? =/
For many sites and apps, the business logic SHOULD be the focus of dev time, but it's not... it's implementing trivial business logic inside of the ever-growing monster that is the JS ecosystem. There are 1000 ways to do anything in JS, but never just one good way.
On the other hand, novelty burnout is a real thing. Javascript has mutated so much in a short period of time that it's become impossible to keep up with -- especially once you factor in frameworks and tooling.
Times like this, I wish vanilla JS/ECMAscript was more powerful out of the box. For a language designed to work with the HTML DOM -- the ONLY language that works natively with it -- it is so woefully underpowered. Why do we need a framework at all to do a simple stateful AJAX UI? =/
For many sites and apps, the business logic SHOULD be the focus of dev time, but it's not... it's implementing trivial business logic inside of the ever-growing monster that is the JS ecosystem. There are 1000 ways to do anything in JS, but never just one good way.
And if you haven't been hyper-focused on learning every bit of "modern JavaScript" in the last 5 years, employers definitely love to disqualify you just because you were happily working on "legacy tech" instead of catching up on React and every other JavaScript-heavy approach to Web development.
I'm bitter, and I'm not opposed to moving on and learning this stuff, but it's like employers barely understand the value of HTML/CSS relative to how much React is prioritized/used as a single qualifier.
I have "1-2 years experience" with React & friends if that matters, and I consider myself a 10 year Web development vet.
I'm bitter, and I'm not opposed to moving on and learning this stuff, but it's like employers barely understand the value of HTML/CSS relative to how much React is prioritized/used as a single qualifier.
I have "1-2 years experience" with React & friends if that matters, and I consider myself a 10 year Web development vet.
Four years ago? When Svelte was still in it's infancy? You're absolutely right to have received pushback for that.
I would still consider Svelte somewhat risky today.
You're lucky that Svelte has taken off but it could have easily been abandoned and you could be stuck with an outdated framework.
Three years ago, someone at my company made the bad call to use Aurelia. It didn't take off, and we are still stuck with this decision.
I'm not claiming that the success is random - Svelte is clearly a far better framework than Aurelia. But the weaknesses often become apparent only later into development, and so it's safer to bet on established approaches.
You're lucky that Svelte has taken off but it could have easily been abandoned and you could be stuck with an outdated framework.
Three years ago, someone at my company made the bad call to use Aurelia. It didn't take off, and we are still stuck with this decision.
I'm not claiming that the success is random - Svelte is clearly a far better framework than Aurelia. But the weaknesses often become apparent only later into development, and so it's safer to bet on established approaches.
Depends on your perspective. Svelte first came out in 2016, and by that time I'd been following Ractive.js, the author's previous framework at The Guardian, for years already.
Aurelia is maintained though, as opposed to being completely dead at least.
However I imagine there isn't alot of community libraries to leverage with such a small ecosystem.
However I imagine there isn't alot of community libraries to leverage with such a small ecosystem.
Nope, dude at my job totally got "laid off" for choosing to write a feature in an ecommerce system in React. He had used it before at a previous job and was familiar with it. Problem was:
- No one else in the team was familiar with React.
- React did not play nice with the rest of the app and developer work flow.
- It was huge and slow
- He didn't know React as well as he thought he did and we had endless bugs.
- He spent ages working on it.
We rewrote in vanilla JS in 4 days - one dev.
And, yeah, effing JS.
- No one else in the team was familiar with React.
- React did not play nice with the rest of the app and developer work flow.
- It was huge and slow
- He didn't know React as well as he thought he did and we had endless bugs.
- He spent ages working on it.
We rewrote in vanilla JS in 4 days - one dev.
And, yeah, effing JS.
They didn’t literally mean getting fired for choosing a framework choice and it doesn’t sound like your story does either.
The point is about making safe choices compared to alternatives. Migrating a project without full team buy in and without testing the waters in small incremental experiments is a developer/management problem.
The point is about making safe choices compared to alternatives. Migrating a project without full team buy in and without testing the waters in small incremental experiments is a developer/management problem.
Everyone gets miscorrected for using either a heuristic or an analogy.
This should never happen, the developers should not choose whatever technology stack or components they want for their piece of code, that's how Frankenstein started. But getting fired is reasonable in this case.
Agreed, but there must be more to this story that resulted in firing. You can't easily fire people for the issues listed here, at least in most civilized parts of the world.
I wish. West Coast of USA can fire you for a bad haircut.
Yeah, that's a little bit of the story that I left out - he also chose React without the normal team consensus on tech, so there was that, too.
But, but ... resume driven development!
He didn't get fired for choosing React though, he got fired for not being a good developer. If the task was so small you could write it in 4 days it should be easy for any competent developer to write a fast small React version.
I always find React/Vue comparisons with vanilla JS so curious, as if there's feature parity. No one would say "I rewrote this Flask REST API in vanilla Python".
As for the "can't find devs that know it" problem, I'd suggest anyone reading this that Svelte is incredibly easy to pick up. Like I skimmed the docs in literally a few minutes, and was able to build out a reasonably sophisticated application almost immediately.
I lost a non-trivial amount of time converting a vuejs app to svelte before getting blindsided by svelte not having basic error handling: https://github.com/sveltejs/svelte/issues/1096
Many types of errors that the equivalent vuejs/react app will show an error page and allow reporting to sentry for will result in an uncatchable halting (some may describe this as "freezing") and with no way to report this to a service like sentry.
This is unacceptable for a framework claiming to be production ready.
It's unclear to me if this has been fixed in the last year or two.
Many types of errors that the equivalent vuejs/react app will show an error page and allow reporting to sentry for will result in an uncatchable halting (some may describe this as "freezing") and with no way to report this to a service like sentry.
This is unacceptable for a framework claiming to be production ready.
It's unclear to me if this has been fixed in the last year or two.
I hear you. My comment was mostly addressing the ease of learning the basics. I eventually decided to abandon it once I ran into a couple of very-difficult-to-debug problems, but I also didn't try too hard to resolve them. I did not realize they have no error handling, that's interesting.
Without knowing your background or the app is not that useful of an insight.
Fair enough. I do have a little over a decade of experience, so perhaps that gives my opinion some bias. But regardless of the app, the premise behind Svelte feels as close to native as you can possibly manage. If you know html/css/js, it really shouldn't be hard to pick up the basics.
> No one would blame you for choosing React for a major project / new startup
Oh, I know people who would. Especially if that choice was made mechanically, without proper assessment of project requirements and framework strengths/weaknesses.
Oh, I know people who would. Especially if that choice was made mechanically, without proper assessment of project requirements and framework strengths/weaknesses.
"Nobody ever got fired for X" is a rhetorical device which means "in most situations, you generally won't be faulted going with the most main-stream option on the market".
To be fair, as frustrating as it is sometimes for those of us who want to use the best tool, for those who have jobs affected by the risk in their decisions, it's a sound principle to default to.
I think the nuance is that much of the IT world moves much, MUCH slower than the web frontend.
"Nobody ever got fired for choosing IBM/AWS/Google/Microsoft/ESRI" will culturally last a loooooong time (5-10 years? 15?)
"Nobody ever got fired for choosing jQuery? Angular? React? Vue? Svelte? NPM? Yarn? Node? Deno? Next? Gatsby? Netlify? Webpack? Parcel? Babel? Bun? Canvas? WebGL? WASM? Workers? Cloudflare? Fly? Leaflet? OpenLayers? Mapbox?"... that has what, a lifespan of 2-3 years at best?
"Nobody ever got fired for choosing IBM/AWS/Google/Microsoft/ESRI" will culturally last a loooooong time (5-10 years? 15?)
"Nobody ever got fired for choosing jQuery? Angular? React? Vue? Svelte? NPM? Yarn? Node? Deno? Next? Gatsby? Netlify? Webpack? Parcel? Babel? Bun? Canvas? WebGL? WASM? Workers? Cloudflare? Fly? Leaflet? OpenLayers? Mapbox?"... that has what, a lifespan of 2-3 years at best?
Nobody ever got fired for choosing standard browser technologies, I would have thought :-) Which, from your list, would include canvas, webgl, wasm, and workers. As for the rest — they may very well have been :-)
Well, there are a lot of abstractions over those. Canvas by itself in the raw isn't very useful without a framework on top of it. Same for the others, except maybe Workers...
I mean this from the perspective of a newly founded startup.
You're right that this doesn't hold true in a large corporation where they may already have a ton of code and preferred frameworks.
You're right that this doesn't hold true in a large corporation where they may already have a ton of code and preferred frameworks.
I would question the decision maker seriously if he chose a 130.5kb (.min) dom lib instead of sub 10kb alternatives.
The answer is always Ember.js. No doubt. It is just getting better and better and knows everything. The best choice.
Apple Music Web version is made using Svelte
https://beta.music.apple.com/us/browse
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 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.
The guy who created it, Rich Harris, used to work for the New York Times and developed it while he was there. So it's not a big surprise that NYT use it. I'm not sure about many other 'larger news sites' using it, but one place I have seen it out in the wild in a big production app is the Apple Music web app.
How did he managed to push his own framework. I’d love to rewrite the world, that’s so much more fun than converting Json to sql. But it would be a very hard sell to management to write our own framework instead of using something battle tested like spring boot.
Rich Harris did a lot of data viz work (IIRC) during his tenure at the NYT. I don't know if you have experience working with D3 and other template/view libraries but it's always been painful. D3 can also append the dom, so it makes certain parts of the API harder to use. There's also the need to work with large amounts of array values that are uniquely made with D3 (various SVG paths). I can easily see multiple teams adopting it if it makes writing interactive data visualizations that much easier.
Supposedly Svelte is able to do this very well, haven't had the chance to try it with D3 myself.
Supposedly Svelte is able to do this very well, haven't had the chance to try it with D3 myself.
He also started at the Guardian in UK developing Ractive, which I'm sure formed part of his job interview at the NYT.
Well the Jeremy Ashkenas (of Backbone, Underscore, CoffeeScript) and Mike Bostock (of D3) used to work there as well and I'm pretty sure the NYTimes pretty heavily embraced some of those libraries with impressive results, so it's probably part of the culture there.
> It makes sense because you can build and compile a small component without having to bundle the entire react runtime in.
Fixed.
Fixed.
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.
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.
Out of curiosity, what do you find clunky about Vue's variables vs Svelte?
I've been working exclusively with Vue for the last... 6 years. Since the launch of v2. So my mind is already conditioned ;-)
I've been working exclusively with Vue for the last... 6 years. Since the launch of v2. So my mind is already conditioned ;-)
You don’t need to write .value’s everywhere, that’s about all. And Vue is a lot more convenient in other ways.
Do you mean .value when writing a component that's some sort of form field? How do you refer to that value in Svelte components?
edit: oh nvm, we haven't upgraded our codebase to Vue 3 yet, there are a lot more ".value"'s if you click through to the Vue 3 examples in the original post.
edit: oh nvm, we haven't upgraded our codebase to Vue 3 yet, there are a lot more ".value"'s if you click through to the Vue 3 examples in the original post.
Vue has `refs`, which are reactive proxy objects that are used for tracking things like re-rendering.
Since vue does not hide the fact that something is a ref, you need to call `myRef.value` to get to the underlying value of `const myRef = ref(10)`.
In a new and currently experimental syntax, you can use `const myRef = $ref(10)`, at which point you can just use `myRef` directly. This will then be converted by the Vue SFC compiler.
Another option is to use a reactive object as the state: `const state = reactive({ myVal: 10 })`, at which point you can just use `state.myVal`.
Since vue does not hide the fact that something is a ref, you need to call `myRef.value` to get to the underlying value of `const myRef = ref(10)`.
In a new and currently experimental syntax, you can use `const myRef = $ref(10)`, at which point you can just use `myRef` directly. This will then be converted by the Vue SFC compiler.
Another option is to use a reactive object as the state: `const state = reactive({ myVal: 10 })`, at which point you can just use `state.myVal`.
> In a new and currently experimental syntax, you can use `const myRef = $ref(10)`,
Oh sweet didn't know that. I keep forgetting to type `.value` and debugging it wastes a couple of seconds here and there.
https://vuejs.org/guide/extras/reactivity-transform.html#ref...
Oh sweet didn't know that. I keep forgetting to type `.value` and debugging it wastes a couple of seconds here and there.
https://vuejs.org/guide/extras/reactivity-transform.html#ref...
Huh, I forgot reactivity transform is already out! Meant to try it but didn't get the chance. Good thing I happen to be starting a new project today.
What is the `10` here? Is it a reference to the literal value `10`...?
It is just an initial value.
So ref is just a state variable with an initial value of 10? How do you mutate the variable/change the state?
No, $ref(10) will return a reactive object. And 10 will be the initial value of that object.
You use the object the same way you use a js variable.
let st = $ref(10)
st = st + 1 // update it and use it like if it was just "10"
But now, st is reactive.
You use the object the same way you use a js variable.
let st = $ref(10)
st = st + 1 // update it and use it like if it was just "10"
But now, st is reactive.
Thank you for the explanation... I will have to learn a lot of basics, it looks like :)
In vue 2, objects are made reactive with getters/setters, so changing a field on an object can be tracked. That still exists in vue 3, but a separate api was needed for primitives like numbers or strings, without a parent object that they'be set to. Vue3's solution is to wrap it in a wrapper object called a ref, and to read it's value you have to use .value. It's a pretty simple concept.
In svelte, top level variables are automatically reactive.
In svelte, top level variables are automatically reactive.
Yes! This was exactly what I felt was more "natural" in Svelte.
I also like Svelte's "writable store" model rather than React's Redux which forces data to flow a certain way, through the dispatcher.
Svelte Stores make it a little too easy to "shoot yourself in the foot" if you're not too careful though, as you can make data bi-directional, and you can make children set parent data. This makes prototyping super easy and fast, but probably creates massive code readability problems down the line, especially for larger teams.
I also like Svelte's "writable store" model rather than React's Redux which forces data to flow a certain way, through the dispatcher.
Svelte Stores make it a little too easy to "shoot yourself in the foot" if you're not too careful though, as you can make data bi-directional, and you can make children set parent data. This makes prototyping super easy and fast, but probably creates massive code readability problems down the line, especially for larger teams.
These days in reactland, you can easily get app-wide state using useContext (which is much MUCH simpler to work with than Redux). It's just a global store (well, or you can limit it to a certain part of the tree) that any child or sibling can read/write to at will.
But just like you said, it can be a footgun if you're not careful.
But just like you said, it can be a footgun if you're not careful.
FWIW, Redux and Context are different tools that solve different problems, with some overlap.
Context is a Dependency Injection tool for a single value, used to avoid prop drilling.
Redux is a tool for predictable global state management, with the state stored outside React.
Note that Context itself isn't the "store", or "managing" anything - it's just a conduit for whatever state _you_ are managing, or whatever other value you're passing through it (event emitter, etc).
I wrote an extensive article specifically to answer this frequently asked question, including details about what the differences are between Context and Redux, and when to consider using either of them - I'd recommend reading through this:
- https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
Context is a Dependency Injection tool for a single value, used to avoid prop drilling.
Redux is a tool for predictable global state management, with the state stored outside React.
Note that Context itself isn't the "store", or "managing" anything - it's just a conduit for whatever state _you_ are managing, or whatever other value you're passing through it (event emitter, etc).
I wrote an extensive article specifically to answer this frequently asked question, including details about what the differences are between Context and Redux, and when to consider using either of them - I'd recommend reading through this:
- https://blog.isquaredsoftware.com/2021/01/context-redux-diff...
Thanks for sharing. I think you touch on some of the more powerful features of Redux (middleware, selectors, pass by reference instead of value, etc.)
But IMHO a lot of that is overkill when your only goal is global state. Context solves that problem very nicely (in conjunction with state and reducer, yes, but context is the big piece there). Prop drilling was a major hurdle to global state management. But redux introduces its own overhead (Flux architecture, actions and dispatches, etc.) that are unnecessarily complicated for simple state sharing.
I feel like the article spends a lot of time differentiating the specifics of use Context vs state vs reducers, but it kinda misses the bigger point... that using those is often enough and can remove redux, leaving you with more readable and less overengineered code. Redux might be the right choice for really complex states, but it's a pain to work with day to day. Context makes it super simple by comparison.
But IMHO a lot of that is overkill when your only goal is global state. Context solves that problem very nicely (in conjunction with state and reducer, yes, but context is the big piece there). Prop drilling was a major hurdle to global state management. But redux introduces its own overhead (Flux architecture, actions and dispatches, etc.) that are unnecessarily complicated for simple state sharing.
I feel like the article spends a lot of time differentiating the specifics of use Context vs state vs reducers, but it kinda misses the bigger point... that using those is often enough and can remove redux, leaving you with more readable and less overengineered code. Redux might be the right choice for really complex states, but it's a pain to work with day to day. Context makes it super simple by comparison.
I see people ask on a literal daily basis "does Context replace Redux?". So, I was trying to make a few points in that post, mostly clarifying common misconceptions, because the question itself is rooted in some major misunderstandings about what these tools even _do_ in the first place:
- that Context doesn't "manage" anything by itself, and definitely not "state"
- That there are significant technical differences between the combo of `useReducer` + `useContext` and Redux/React-Redux, in terms of render performance, data access, and usage patterns.
- That this means there are also different use cases for those tools as well.
I wouldn't use Redux to maintain state for a form or isolated chunk of the app, I'd use context + `useReducer`. On the flip side, if I do have "global" state, I would pretty quickly switch over to putting it in Redux instead.
- that Context doesn't "manage" anything by itself, and definitely not "state"
- That there are significant technical differences between the combo of `useReducer` + `useContext` and Redux/React-Redux, in terms of render performance, data access, and usage patterns.
- That this means there are also different use cases for those tools as well.
I wouldn't use Redux to maintain state for a form or isolated chunk of the app, I'd use context + `useReducer`. On the flip side, if I do have "global" state, I would pretty quickly switch over to putting it in Redux instead.
Yeah, except... the technicalities make it seem like no, but in reality use context CAN replace redux a lot of times. The power of redux is often unnecessary (or just gets in the way, really), and context is enough.
Your post makes it seem like they are wildly different when in fact they often meet the same need. Use context is helpful precisely because it can replace redux in many situations.
It doesn't really matter how different they are under the hood. Redux is often used only as a global store of state, and context makes that much easier... even globally.
Maybe redux is good for some edge cases, but otherwise it's just overengineered bloat. Context is much more elegant and intuitive. There's no reason to force yourself to use the Flux pattern if you don't have to. I'd certainly never add redux to a project unless I absolutely needed to, it's such a pain...
Your post makes it seem like they are wildly different when in fact they often meet the same need. Use context is helpful precisely because it can replace redux in many situations.
It doesn't really matter how different they are under the hood. Redux is often used only as a global store of state, and context makes that much easier... even globally.
Maybe redux is good for some edge cases, but otherwise it's just overengineered bloat. Context is much more elegant and intuitive. There's no reason to force yourself to use the Flux pattern if you don't have to. I'd certainly never add redux to a project unless I absolutely needed to, it's such a pain...
I'm talking about reactive references in the composition API; the options API is too different from Svelte to make a direct comparison. You can use reactive() to hide some .value's but they are more limited and I personally avoid them. There have been proposals to add more transformations to @vue/compiler-sfc to make refs more "magical" like Svelte.
Check out https://sveltejobs.com/
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.
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.
Seems like you could put any engineer on Svelte.
I’m an engineer who has recently done a large project and a few small ones in Svelte. Where do I apply?
I work at digivault.com in London, UK and we provide custody for digital assets. I've just prepared our job listing and posted it to the Svelte Discord. You'll find all the details about the role there. Hopefully I can also get details on our website soon.
list of real tech companies using svelte:
https://twitter.com/sveltesociety/status/1260209026563858432...
https://twitter.com/sveltesociety/status/1260209026563858432...
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.
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.
If you hate React for some reason I'd consider SolidJS a much more principled framework.
Not a large company, but we did choose Svelte and are actively seeking hiring someone experienced with it.
One of React's competitive advantages is React Native. That's hard to beat.
there is svelte-native based on Nativescript. it is similar fast or faster[1] and provides the ability to directly use every native function in JS without having to rely on new interfaces or build versions (e.g. you can directly access new APIs from JS). beeing able to use Svelte makes it sooo much easier to develop mobile apps.
[1] https://blog.nativescript.org/perf-metrics-universal-javascr...
[1] https://blog.nativescript.org/perf-metrics-universal-javascr...
svelte native is nowhere near react native in maturity.
Discord uses React Native. What larger companies uses Svelte Native?
One (sort of accidental I assume) selling point of Svelte that wasn't mentioned here is that the stack trace is legible.
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.
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.
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?
Does using a debugger help? (like in VScode or IntelliJ). The React stack trace is so useless I find myself just stepping through the code and setting breakpoints when I need to actually locate the source of an issue.
Is there a better way, in React or other languages?
Is there a better way, in React or other languages?
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.
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.
I like NextJS too, except for the API part. The DX is so poor compared to e.g. fastify.
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.
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.
I like NextJS for the frontend and django-ninja for the backend. django-ninja has all those things you mention and way more, and has a very rich backend ecosystem thanks to being in the django world. https://django-ninja.rest-framework.com/
FastAPI is also great but a little more involved. It's good if you don't want to be in the Django world.
FastAPI is also great but a little more involved. It's good if you don't want to be in the Django world.
Yes, there are many solutions to this problem if you don’t mind hosting yet another service, but the best would be if the integrated API routes wouldn’t suck so hard.
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.
what does astro simplify?
Might want to check out Remix too, though I ended up going back to Next due to ergonomics and also just generally more experience Nexting.
What's wrong with Svelte or SolidJS for "big things"? Do they limit scalability in some way?
Mainly that the eco system is smaller. This means fewer third party libraries, fewer people who know it already, and fewer articles online about how to solve specific problems.
Svelte is a solution to a problem that doesn't need to be solved.
almost with many things in software development to be honest.
almost with many things in software development to be honest.
Not having two DOMs running for every website is nice
i agree, but not a critical issue.
In less than a decade, i'm already guessing less than 5 years, WASM will come out with a viable frontend solution that will actually be groundbreaking.
The battles between frontend philosophies in javascript will look like child's play then.
I'm not going to waste anymore time switching FE frameworks (Jquery->Angular->React), as I've found that it's been quite useless (Although I really liked Solid - shame their animation libraries suck and the overall environment isn't mature enough).
I'm happy with React.
Performance isn't an end all be all.
Svelte doesn't have a chance to match the hiring pool of React, nor will Svelte Native ever compete with React Native in maturity.
In 5-7 years, we will be talking about ending the use of Javascript on the Frontend, So i really don't care about reactivity.
In less than a decade, i'm already guessing less than 5 years, WASM will come out with a viable frontend solution that will actually be groundbreaking.
The battles between frontend philosophies in javascript will look like child's play then.
I'm not going to waste anymore time switching FE frameworks (Jquery->Angular->React), as I've found that it's been quite useless (Although I really liked Solid - shame their animation libraries suck and the overall environment isn't mature enough).
I'm happy with React.
Performance isn't an end all be all.
Svelte doesn't have a chance to match the hiring pool of React, nor will Svelte Native ever compete with React Native in maturity.
In 5-7 years, we will be talking about ending the use of Javascript on the Frontend, So i really don't care about reactivity.
> In 5-7 years, we will be talking about ending the use of Javascript on the Frontend
The same prediction has been made for the last 25 years. Having seen the rise and fall of VBScript, Flash, Silverlight, Java applets, and countless others, I would not be so blasé as you about the imminent demise of JavaScript. There is a profoundly strong possibility that you are dead wrong.
The same prediction has been made for the last 25 years. Having seen the rise and fall of VBScript, Flash, Silverlight, Java applets, and countless others, I would not be so blasé as you about the imminent demise of JavaScript. There is a profoundly strong possibility that you are dead wrong.
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.
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.
* fixed from 'no runtime'
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'
> 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.
I don't disagree with this, but people unfairly complain about it anyway, and it's another roadblock in the adoption process that makes it less exciting to fight for.
> and nested components hundred-levels deep, and you start noticing slowness, performance optimization is a gigantic effort.
That right there is the problem. The DOM is optimized for something like 32 levels of depth which is also the standard used for lighthouse scores. It's always possible to go over that, a little bit, but hundreds? At that point, it's not a question of svelte vs react, but really advanced dom (if even that) manipulation.
I don't disagree with this, but people unfairly complain about it anyway, and it's another roadblock in the adoption process that makes it less exciting to fight for.
> and nested components hundred-levels deep, and you start noticing slowness, performance optimization is a gigantic effort.
That right there is the problem. The DOM is optimized for something like 32 levels of depth which is also the standard used for lighthouse scores. It's always possible to go over that, a little bit, but hundreds? At that point, it's not a question of svelte vs react, but really advanced dom (if even that) manipulation.
Svelte absolutely has a runtime, with the two most crucial components being the scheduler and the lifecycle manager. It still comes in a lot lighter than React.
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.
> but have you considered that React and Vue in fact also have custom non-JS syntax?
I 100% agree, and I never fully got this argument. But my God do people love to repeat it. So much of react's initial fervor was around "it's just javascript". I write a lot of vue code and I only use like half a dozen directives and learning all of them should take less than one afternoon. And yet, the number of people that don't like vue because of a very simple DSL has been staggering.
It really doesn't make sense to me, but people seem to really hate learning something that superficially looks different.
I 100% agree, and I never fully got this argument. But my God do people love to repeat it. So much of react's initial fervor was around "it's just javascript". I write a lot of vue code and I only use like half a dozen directives and learning all of them should take less than one afternoon. And yet, the number of people that don't like vue because of a very simple DSL has been staggering.
It really doesn't make sense to me, but people seem to really hate learning something that superficially looks different.
Same here: I write Vue every day and I use `v-if`, `v-else`, `v-for`, `v-model` and sometimes a `v-slot`.
I also use about 30 different `v-` components from Vuetify, which come with so many properties, events and slots that it might as well be a giant DSL.
I also use about 30 different `v-` components from Vuetify, which come with so many properties, events and slots that it might as well be a giant DSL.
Worse than that, Vue has something like three different DSLs under the hood. Some of it JS-like but not fully JS, some of it is custom attributes, some of it is "oh, it's JS, but you have to make very specific objects"
In my opinion parser is not a problem. I'm using tsx so there'll be compiling anyway.
Now if they make tsx native it'll be game changing
Now if they make tsx native it'll be game changing
> 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.
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.
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.
I don't doubt Rich Harris' skills as a developper. But project governance is very different from have strong technical skills. Things like communication, prioritizing features important for the community, dealing with idiots way beyond when it stops becoming fun, gathering money, writing good documentation, etc.
Rollup is cool, but it's a very different beast from a f/e framework. For a lot of projects, migrating from rollup to webpack might be a few hours or a week. Migrating from svelte to react, is months if not many man-years.
Rollup is cool, but it's a very different beast from a f/e framework. For a lot of projects, migrating from rollup to webpack might be a few hours or a week. Migrating from svelte to react, is months if not many man-years.
What's wrong with svelte's documentation or the community interaction that's happening around svelete?
My point is that you've seemingly taken points away from Rich for the same reasons you're giving Evan You validity.
Migrating between react and vue would take probably the same amount of time -- I'm not really sure what your point is here. My point is that you've unfairly discounted Svelte on the same standards you're raising vue.
My point is that you've seemingly taken points away from Rich for the same reasons you're giving Evan You validity.
Migrating between react and vue would take probably the same amount of time -- I'm not really sure what your point is here. My point is that you've unfairly discounted Svelte on the same standards you're raising vue.
> Migrating from svelte to react, is months if not many man-years.
I’m not sure what your argument is here, but I’m pretty sure you have it backwards.
The fact that it might take a while to migrate a svelte project to react is not because of poor documentation or tooling or communication or anything like that. It’s because so many things work out of the box in svelte, and to do the same things in react would take tons of boilerplate or third party libraries. Some things may not even be possible to port, at least not easily.
This doesn’t show that svelte is bad though. It shows that react lacks functionality and is more difficult to use.
I’m not sure what your argument is here, but I’m pretty sure you have it backwards.
The fact that it might take a while to migrate a svelte project to react is not because of poor documentation or tooling or communication or anything like that. It’s because so many things work out of the box in svelte, and to do the same things in react would take tons of boilerplate or third party libraries. Some things may not even be possible to port, at least not easily.
This doesn’t show that svelte is bad though. It shows that react lacks functionality and is more difficult to use.
I've recently started working with Svelte and have been loving it compared to React. A lot of stuff flows through very intuitively.
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
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
You might check out Skeleton (full disclosure, I'm one of the creators)
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!
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!
I'm using Svelte with Daisy UI [0] which is based on Tailwind CSS. It is incredibly simple and beautiful.
[0]: http://daisyui.com
[0]: http://daisyui.com
Daisyui.com seems to disable scrolling with arrow keys, page up, and page down. Is this a general problem when using Daisy UI, or is there something wrong with the page?
Uhm, Carbon supports Svelte too ...
Yes, I think that's the point. Carbon does, but there aren't (many) others.
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.
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
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
The "different way of expressing" is exactly the problem though. We should be encouraging the community to standardize these things and bring it as close to native HTML as possible. This could reduce the learning curve a bit as well when transitioning from one to another.
As for React - the Redux alternatives are pretty nice. Recoil, hooks, mobx, etc. are all more friendly.
As for React - the Redux alternatives are pretty nice. Recoil, hooks, mobx, etc. are all more friendly.
> 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 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.
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.
If you mean Stores, those are Observables (implement that interface similar to rxjs which is used heavily in Angular)
It's a solid pattern that solves a lot of issues in a pragmatic way.
Keep in mind "modern" react is easy less clunky, so the whole state management thing is easier with hooks so it's not as impressive how easy svelte is now at it was when it was introduced 5 years ago.
It's a solid pattern that solves a lot of issues in a pragmatic way.
Keep in mind "modern" react is easy less clunky, so the whole state management thing is easier with hooks so it's not as impressive how easy svelte is now at it was when it was introduced 5 years ago.
I think you've missed something fundamental. Imagine you're using a spreadsheet app. You put data into a column. Then in another column you write a formula referencing the first column. Then you write a sum formula to put it all together.
Oops! One number is wrong in the first column, so you update it, and everything updates automatically. No muss. No fuss.
This is the model that Svelte works in BY DEFAULT. The compiler determines a dependency tree. Variable "b" depends on "a" in a component, you've bound "b" to an element for display, and somewhere, your components logic changes the value to "a". Boom! UI is updated with latest calculation, and all you had to do was use plain ole JavaScript. No useState(). No complete DOM subtree rewrites since the virtual DOM was marked dirty, just the bare minimum of DOM changes automatically.
Reactive variables instead of linking up reactive functions within a reactive framework API.
In React, for performance reasons, you often have to explicitly mark segments of a component (or whole components) that you know won't change so that it doesn't recalculate every time there's a minor property update.
All of that goes away in Svelte. There is no reason to mark segments for no recalculation in Svelte in the first place. It just works, and it just works with what looks to you as the developer as 99% HTML, vanilla JavaScript, and standard CSS.
I imagine most folks who love React syntax have Stockholm Syndrome at this point. Having written for web since 1996 or so, I've seen the progress as well as the fads. I still remember document.write(…) and Netscape's layer tag. I remember the JQuery revolution after the missteps of Prototype. I know full well why React (and Angular and Vue) were created as web sites became larger and more complex.
And I'll tell you truthfully, I haven't been this excited about a return to relative simplicity as evidenced by Svelte in a long time. The strategy behind Svelte is an industry refactor that's been a long time coming. Even if Svelte is not the eventual "winner", I truly hope it's something closer to the Svelte model than the current old guard of Angular, React, and Vue.
You may claim to hate magic, but I have some bad news: there is magic at every level going down to the lightning injected into rock to make it think. The fear of magic is the same argument used by the assembly programmers when C first emerged. "Too much magic. Too easy. Too much loss of control." Never mind that it was an order of magnitude easier to learn, modify, and maintain.
Oops! One number is wrong in the first column, so you update it, and everything updates automatically. No muss. No fuss.
This is the model that Svelte works in BY DEFAULT. The compiler determines a dependency tree. Variable "b" depends on "a" in a component, you've bound "b" to an element for display, and somewhere, your components logic changes the value to "a". Boom! UI is updated with latest calculation, and all you had to do was use plain ole JavaScript. No useState(). No complete DOM subtree rewrites since the virtual DOM was marked dirty, just the bare minimum of DOM changes automatically.
Reactive variables instead of linking up reactive functions within a reactive framework API.
In React, for performance reasons, you often have to explicitly mark segments of a component (or whole components) that you know won't change so that it doesn't recalculate every time there's a minor property update.
All of that goes away in Svelte. There is no reason to mark segments for no recalculation in Svelte in the first place. It just works, and it just works with what looks to you as the developer as 99% HTML, vanilla JavaScript, and standard CSS.
I imagine most folks who love React syntax have Stockholm Syndrome at this point. Having written for web since 1996 or so, I've seen the progress as well as the fads. I still remember document.write(…) and Netscape's layer tag. I remember the JQuery revolution after the missteps of Prototype. I know full well why React (and Angular and Vue) were created as web sites became larger and more complex.
And I'll tell you truthfully, I haven't been this excited about a return to relative simplicity as evidenced by Svelte in a long time. The strategy behind Svelte is an industry refactor that's been a long time coming. Even if Svelte is not the eventual "winner", I truly hope it's something closer to the Svelte model than the current old guard of Angular, React, and Vue.
You may claim to hate magic, but I have some bad news: there is magic at every level going down to the lightning injected into rock to make it think. The fear of magic is the same argument used by the assembly programmers when C first emerged. "Too much magic. Too easy. Too much loss of control." Never mind that it was an order of magnitude easier to learn, modify, and maintain.
>I imagine most folks who love React syntax have Stockholm Syndrome at this point.
And I'd imagine that most folks who are advocating for Svelte never had to build up a startup before.
If everything was done for performance, then python or ruby wouldn't be used as web server languages today, and yet python and ruby web servers comprise of a significant amount of webservers.
And besides, most performance improvements between React and Svelte are almost invisible to the naked eye, we're talking differences of milliseconds here.
So you've built your web client in Svelte, are you ready to traverse into new frontiers and build a production ready app in Svelte Native?
Or are you going to blow extra capital to hire ios and android developers?
Are you ready to deal with the fact that its not using its own implementation and is using Native Script under the hood?
What about the hiring pool?
Svelte is a great choice for personal projects, but extremely impractical for a startup.
Svelte Native will NEVER reach the maturity that React Native has, and that is what makes react such a practical choice for a startup.
If you had to consult a startup to choose a FE framework for both its web client and mobile client, and you suggested Svelte, I would bet that not only would they lose a lot of capital and time, they would run into so much technical debt.
Svelte for the web client is fine, but now you have to manage a different team for the mobile client.
This is what makes react so strong - the web and mobile clients can be handled by the same team.
React is Practical; it doesn't matter if the philosophy in how they render the dom isn't up to par, the community and the environment around it makes it practical.
And honestly, the performance is good enough.
If Discord can use React + RN, it's good enough for the lion's share of applications out there.
And I'd imagine that most folks who are advocating for Svelte never had to build up a startup before.
If everything was done for performance, then python or ruby wouldn't be used as web server languages today, and yet python and ruby web servers comprise of a significant amount of webservers.
And besides, most performance improvements between React and Svelte are almost invisible to the naked eye, we're talking differences of milliseconds here.
So you've built your web client in Svelte, are you ready to traverse into new frontiers and build a production ready app in Svelte Native?
Or are you going to blow extra capital to hire ios and android developers?
Are you ready to deal with the fact that its not using its own implementation and is using Native Script under the hood?
What about the hiring pool?
Svelte is a great choice for personal projects, but extremely impractical for a startup.
Svelte Native will NEVER reach the maturity that React Native has, and that is what makes react such a practical choice for a startup.
If you had to consult a startup to choose a FE framework for both its web client and mobile client, and you suggested Svelte, I would bet that not only would they lose a lot of capital and time, they would run into so much technical debt.
Svelte for the web client is fine, but now you have to manage a different team for the mobile client.
This is what makes react so strong - the web and mobile clients can be handled by the same team.
React is Practical; it doesn't matter if the philosophy in how they render the dom isn't up to par, the community and the environment around it makes it practical.
And honestly, the performance is good enough.
If Discord can use React + RN, it's good enough for the lion's share of applications out there.
> And I'd imagine that most folks who are advocating for Svelte never had to build up a startup before.
>Svelte is a great choice for personal projects, but extremely impractical for a startup.
> What about the hiring pool?
> Svelte for the web client is fine, but now you have to manage a different team for the mobile client.
These are interesting assertions and run contrary to my experience. I work for a successful startup and our front-end team uses Svelte. We've had nothing but success. We run a production-grade mobile app (Cordova) on old low-powered client-provided devices including RF guns (Android 5 to 9) with multiple thousands of concurrent users in stores/logistics warehouses, and a web app running on desktop (Chrome/Firefox/Safari). And, every front-end developer we have (including myself) learned Svelte on-the-job within a few weeks.
>Svelte is a great choice for personal projects, but extremely impractical for a startup.
> What about the hiring pool?
> Svelte for the web client is fine, but now you have to manage a different team for the mobile client.
These are interesting assertions and run contrary to my experience. I work for a successful startup and our front-end team uses Svelte. We've had nothing but success. We run a production-grade mobile app (Cordova) on old low-powered client-provided devices including RF guns (Android 5 to 9) with multiple thousands of concurrent users in stores/logistics warehouses, and a web app running on desktop (Chrome/Firefox/Safari). And, every front-end developer we have (including myself) learned Svelte on-the-job within a few weeks.
Re-read my comment. I was not talking about app performance, though Svelte is indeed lighter and faster for various reasons.
I made the analogy to assembly vs C. It's not about raw speed. Many APIs and (frankly) hacks have been added to React that developers have learned over the course of years. APIs and hacks that simply aren't necessary for Svelte.
I totally agree that the community behind React is absolutely massive. If you want a component for something, chances are someone has made it already. That is a huge advantage. However while the odds are good, the goods are often odd.
When the dev environment is simpler, making the component isn't such a burden. When the code is simpler, maintenance and improvement are easier.
Today, React may be the better choice in many circumstances, and that's fine. However moving forward, expect to see more cases where there's a better option. Because let's face it, Svelte is simply better architecturally. React may be more popular, but you can't argue its foundation is somehow more sound.
I made the analogy to assembly vs C. It's not about raw speed. Many APIs and (frankly) hacks have been added to React that developers have learned over the course of years. APIs and hacks that simply aren't necessary for Svelte.
I totally agree that the community behind React is absolutely massive. If you want a component for something, chances are someone has made it already. That is a huge advantage. However while the odds are good, the goods are often odd.
When the dev environment is simpler, making the component isn't such a burden. When the code is simpler, maintenance and improvement are easier.
Today, React may be the better choice in many circumstances, and that's fine. However moving forward, expect to see more cases where there's a better option. Because let's face it, Svelte is simply better architecturally. React may be more popular, but you can't argue its foundation is somehow more sound.
I agree that Svelte/SolidJS has overall better architecture.
I don't agree that they will match React's community and environment in the near future, if at all.
I don't agree that they will match React's community and environment in the near future, if at all.
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.
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.
Svelte is much closer to regular JavaScript. There really isn't anything you can't do with svelte that you cannot do with vanilla JavaScript. Everything is JavaScript in the end, but react forces you to go through their framework and that's why you need escape hatches. You just don't need that with svelte at all. It's wild when you get that part of it. The reactive part of svelte is just adding stuff during the compile process that at runtime does the DOM manipulation, rather than figuring that entire sequence out in runtime.
Yeah, this matches my experience moving from React (5+ yrs) to Svelte (2 shipped 3 month projects over the last couple of years at this point). Svelte clearly lacks the massive community support of React but I've found it easier to get by on my understanding of JS and the DOM when I get stuck. I've heard lots of gripeing from other React devs about the $ syntax and a few other things around lack of JSX but that feels like really small change when compared to the flexibility Svelte allows around things like transitions (no more hooks!).
I have been using Svelte for a couple of years now on small and large projects and I have yet to hit one of those "5%" problems that I used to hit routinely in larger React projects. Svelte mostly stays out of your way, unlike React where it everything is more ... forced ... in my opinion.
I have a lot of experience with React, Vue, and Angular and I have moved completely over to Svelte if the client will allow. Since it uses normal Javascript, normal HTML, and normal CSS it also doesn't seem to suffer as much regarding the ability to find other people to support it. If they can use normal JS, HTML, and CSS the "Svelte" part of it can be learned in a couple of hours max.
Early on, there was a custom component shortage, but it is so easy to wrap plain vanilla JS components in Svelte components that this is has mostly disappeared as well.
If I where going to point out anything negative about it, I would say that if you are used to developing by just plugging in pre-built components (very common in React development) then it won't be as easy.
I have a lot of experience with React, Vue, and Angular and I have moved completely over to Svelte if the client will allow. Since it uses normal Javascript, normal HTML, and normal CSS it also doesn't seem to suffer as much regarding the ability to find other people to support it. If they can use normal JS, HTML, and CSS the "Svelte" part of it can be learned in a couple of hours max.
Early on, there was a custom component shortage, but it is so easy to wrap plain vanilla JS components in Svelte components that this is has mostly disappeared as well.
If I where going to point out anything negative about it, I would say that if you are used to developing by just plugging in pre-built components (very common in React development) then it won't be as easy.
Using Svelte for a quite large codebase.
Couple years ago, there was lot of hiccups especially with TS support or the vscode plugin. It's much better now.
There are some patterns to know to work around some reactivity issues with component reuse but overall, and still some TS issues with vscode (extra warnings due to lack of understanding of component context) but it's still ok.
The biggest drawback of Svelte is not the tech itself, but the lack of a well developed ecosystem of components, design systems, etc. You'll probably end up implementing many components yourself... whether it's a good thing is left for discussion.
Couple years ago, there was lot of hiccups especially with TS support or the vscode plugin. It's much better now.
There are some patterns to know to work around some reactivity issues with component reuse but overall, and still some TS issues with vscode (extra warnings due to lack of understanding of component context) but it's still ok.
The biggest drawback of Svelte is not the tech itself, but the lack of a well developed ecosystem of components, design systems, etc. You'll probably end up implementing many components yourself... whether it's a good thing is left for discussion.
The one 5% thing I’ve run into is a lack of proper generic component props when using Typescript.
Granted, that’s a rather advanced topic, but I miss having a <Component<MyType>> where all the type checking “just works”.
It’s not a dealbreaker - more like just something I noticed coming from the React world.
Granted, that’s a rather advanced topic, but I miss having a <Component<MyType>> where all the type checking “just works”.
It’s not a dealbreaker - more like just something I noticed coming from the React world.
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.
So I'm staying with Vue.
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.
I did the vue 3 bump a while back and Evan You did a fantastic commit by commit repo to follow along and there's even a migration build of vue 2 which warns you of all the areas where your app will break in vue 3, really fantastic.
I can't claim that that upgrade was painless, it took a few days with an app with > 10 pages, >20 custom components and I had to push ahead with re-writing a 3rd party component or 2 that was only vue 2 at the time (honestly I should never have used them in the first place. reap what you sow). But build times are faster, my bundle size is a lot smaller, I'm really pleased with the new features, and I'm a building faster as a result.
I can't claim that that upgrade was painless, it took a few days with an app with > 10 pages, >20 custom components and I had to push ahead with re-writing a 3rd party component or 2 that was only vue 2 at the time (honestly I should never have used them in the first place. reap what you sow). But build times are faster, my bundle size is a lot smaller, I'm really pleased with the new features, and I'm a building faster as a result.
I upgraded to Vue 3 and Pinia and my project got 2x cleaner.
Vue 3 was designed with large complex projects in mind. Vue 2 is probably easier to grok when starting out or for small projects but the functional modularity, typescript integration, and reduced boilerplate with 3 really starts to show in large projects.
I did it slowly over a year and besides having to wait for some dependencies to catch up it was mostly painless.
Although the biggest pain-reduction was getting to use Vite instead of Webpack (shudder). The build tools not sucking is so critical when doing front end dev.
Vue 3 was designed with large complex projects in mind. Vue 2 is probably easier to grok when starting out or for small projects but the functional modularity, typescript integration, and reduced boilerplate with 3 really starts to show in large projects.
I did it slowly over a year and besides having to wait for some dependencies to catch up it was mostly painless.
Although the biggest pain-reduction was getting to use Vite instead of Webpack (shudder). The build tools not sucking is so critical when doing front end dev.
Haha, I've had this reaction vs other technologies.
But in hindsight your comment (which could have been mine a few years back!), is really funny. Basically, are you staying with Vue because it's the monster you know, or why don't you fear Vue becoming a monster? :)
But in hindsight your comment (which could have been mine a few years back!), is really funny. Basically, are you staying with Vue because it's the monster you know, or why don't you fear Vue becoming a monster? :)
Svelte already did that migration from 2 to 3. I don't think the fundamentals changing is anything to worry about now.
I loved using Svelte for these two open-source projects but haven't yet an opportunity to use it at work:
- 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.
- 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.
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.
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.
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.
>> "Introducing"? Hasn't Svelte existed for a couple of years already?
So has your significant other at the time you introduce them to your family, right?
So has your significant other at the time you introduce them to your family, right?
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.
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.
That can work relatively well for projects where there are a handful of engineers, but I wonder whether it doesn’t be some much harder as your team grows to 20+ engineers working in the same UI code base?
Frameworks does not help in this case any more than proper organization / structuring of code. It is as easy to fuck up your React app setup as it is plain code.
Just make sure that overall architecture and process enforced and are designed by experienced person/s rather than hamsters.
Just make sure that overall architecture and process enforced and are designed by experienced person/s rather than hamsters.
What do you mean by “hamster”?
I agree. The "DSL" and "compiling" aspect of frameworks scares the crap out of me frankly. And on top, it's all happening on my poor users device - well not for Svelte apparently.
Let's have a look at this "compiled" JS. Here's an snippet from the volume slider in his example:
function b() { v = W4(this.value), h(0, v) }
I understand that this is "compiled" - but really it's not - it's EcmaScript. If I wrote code like that, I'd get fired.
Let's have a look at this "compiled" JS. Here's an snippet from the volume slider in his example:
function b() { v = W4(this.value), h(0, v) }
I understand that this is "compiled" - but really it's not - it's EcmaScript. If I wrote code like that, I'd get fired.
You are looking at minified output there; of course nobody writes that.
You can see the compiler output in the "JS output" tab here, it's very easy to follow: https://svelte.dev/repl/12aefec27f0d4ec5ad85ab7e5a123642?ver...
You can see the compiler output in the "JS output" tab here, it's very easy to follow: https://svelte.dev/repl/12aefec27f0d4ec5ad85ab7e5a123642?ver...
Got it. It was both compiled and minified.
Do you get web components somewhere or write most of them from scratch? And how do you organize the layout, using flexbox?
And how do you set states, react to events etc do you write all of the render stuff manually?
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?
It must be the second. Svelte is by far the easiest to understand framework (of the "big" ones) that I have yet encountered.
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.
I'm really looking forward to the stable release of SvelteKit to use as the backend for my next project.
That's the thing... it's always never stable always in development.
I'll habe to check this combination put however. Now the price question, did you use an oidc client? If so which works with both app and web?
I'll habe to check this combination put however. Now the price question, did you use an oidc client? If so which works with both app and web?
Is Svelte blowing up in popularity? I've never heard of it until seeing it multiple places today.
https://github.com/containers/podman-desktop
https://github.com/containers/podman-desktop
According to the survey you linked to:
Phoenix overtakes Svelte’s spot as the most loved web framework.
React.js completes its fifth year as most wanted.
So I’m not sure that’s an unequivocal “yes”.
Phoenix overtakes Svelte’s spot as the most loved web framework.
React.js completes its fifth year as most wanted.
So I’m not sure that’s an unequivocal “yes”.
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.
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.
I mostly work with React, but Svelte is so much better in every way, I hope it becomes more popular soon.
Your comment captures in a nutshell why new frameworks face an uphill climb.
because people like them very much?
I do like working with Svelte, but the most pleasant developer experience I've had in JS has been in Mithril.js with it's small and easily understandable API. I don't understand why there's not a bigger ecosystem and traction around that.
Single file components like .svelte and .vue are nice at first glance. But I want typescript, eslint and prettier understand my code natively and not wrapped in custom syntax and smushed into one file that every tooling now has to support.
Maybe it's finally time for someone to standardize this - even if just pointing at what vue & svelte already do - so every tooling can go ahead and support amalgams of filetypes in a single file for any framework that wants to work like this.
It's a wonder how react managed to force their jsx and angular forced annotations into typescript just to get a good typescript experience out of the box.
Maybe it's finally time for someone to standardize this - even if just pointing at what vue & svelte already do - so every tooling can go ahead and support amalgams of filetypes in a single file for any framework that wants to work like this.
It's a wonder how react managed to force their jsx and angular forced annotations into typescript just to get a good typescript experience out of the box.
Funnily enough, IDEs a decade ago (more, even) solved this for PHP already, as even back then a lot of PHP was still HTML and PHP (and JS) intermixed in one file. It’s a shame we haven’t solved it properly in modern editors without having to rebuild the tooling over and over again for every new framework.
Shouldn't really be a problem - I've had reasonable syntax highlighting of markdown files with support for inline code-blocks in different languages for a while in (neo)vim.
Mixing languages/dsls in a single file shouldn't be a problem.
Should also work for things like in-line sql fragments for orms etc?
Mixing languages/dsls in a single file shouldn't be a problem.
Should also work for things like in-line sql fragments for orms etc?
I'm still very skeptical of the random templating syntax, of the weird reactivity with gotchas and most of all, of two way databinding. Wasn't two way databinding one of the reasons we got react (and one of the reasons i bought into it) back when angular was the go-to? I feel like every time i try to use two-way-databinding it ends up in a jumbled unintelligible mess where I'm chasing mutations around... Personally, if I have to try out a new framework, I'll probably try out solid instead.
svelte’s 2 way data binding is only within a component, and actually is 1 way if you look at the compiled output. very different than say angular, and pretty much equivalent to what you manually write with setState calls.
this is such a common misconception i feel like we should put this in the FAQ somewhere. people are fixating on the wrong thing when they go “oh ho 2 way binding bad”. its local and its compiled away, its fine.
this is such a common misconception i feel like we should put this in the FAQ somewhere. people are fixating on the wrong thing when they go “oh ho 2 way binding bad”. its local and its compiled away, its fine.
Thank you very much for the explanation! I agree with you that this information should be somewhere, especially seeing as I (mistakenly) thought that too, I probably would've had less of a knee-jerk reaction to it if I knew that it's effectively syntax sugar. I'm guessing I'm not the only one who has really bad memories of angular... Sorry for the misunderstanding!
yeah no worries it’s a very common superficial reaction! we just spend a lot of time explaining it:
https://twitter.com/rich_harris/status/1420214295242199041?s...
https://twitter.com/rich_harris/status/1147902393293688834?s...
https://www.swyx.io/svelte-why#two-way-binding
https://twitter.com/rich_harris/status/1420214295242199041?s...
https://twitter.com/rich_harris/status/1147902393293688834?s...
https://www.swyx.io/svelte-why#two-way-binding
React Component is just JS function, which made things simple to learn, debug and understand.
Svelte is a compiler which strip unnessesary JS code in the output.
Wish: Combine both, don't compare.
Svelte is a compiler which strip unnessesary JS code in the output.
Wish: Combine both, don't compare.
Can someone with more experience in the 3 frameworks give some insights into the type safety ergonomics?
I'm extremely biased towards react due to the fact that it effectively brings very strongly typed templates/components to the table, which has saved me easily a hundred hours of debugging/testing over the last 4 years. It also makes components MUCH more accessible due to the declarative nature of props (and their respective types).
I'm extremely biased towards react due to the fact that it effectively brings very strongly typed templates/components to the table, which has saved me easily a hundred hours of debugging/testing over the last 4 years. It also makes components MUCH more accessible due to the declarative nature of props (and their respective types).
30k loc into this project with Svelte and Typescript and everything is 100% fully and correctly typed in strict mode with no implicit any
Never use Svelte but looks very easy to use. I think this post will make it to the top, very interesting comments a lot to learn. Thanks Hackersnews !!!
Have done a couple of projects with sveltekit, including a redesign of my personal website and an internal tool for myself and colleagues for quality of life.
I liked working with it, but I regret not waiting for 1.0 to really dive in. The breaking changes are getting annoying, with the most annoying being recently with changes to its routing. It seems like every time I make a small change and go to rebuild my sites, I'm dealing with a new headache.
Don't get me wrong, the changes are probably warranted to avoid Angular-style major version catastrophes, but for me, the draw to svelte is its ease of use. If I can't go a day without having to go digging for a fix to a breaking change, it's really not that easy to use. I'm mostly a hobbyist dev and don't have the time to keep up with it.
Also, the new folder-based routing is clunky as hell. I'll probably spend some time learning Next.js for future projects. Its ecosystem most likely trumps the syntactic supremacy of svelte currently. That said, I don't doubt svelte will introduce something that reels me back in again in the future.
I liked working with it, but I regret not waiting for 1.0 to really dive in. The breaking changes are getting annoying, with the most annoying being recently with changes to its routing. It seems like every time I make a small change and go to rebuild my sites, I'm dealing with a new headache.
Don't get me wrong, the changes are probably warranted to avoid Angular-style major version catastrophes, but for me, the draw to svelte is its ease of use. If I can't go a day without having to go digging for a fix to a breaking change, it's really not that easy to use. I'm mostly a hobbyist dev and don't have the time to keep up with it.
Also, the new folder-based routing is clunky as hell. I'll probably spend some time learning Next.js for future projects. Its ecosystem most likely trumps the syntactic supremacy of svelte currently. That said, I don't doubt svelte will introduce something that reels me back in again in the future.
I purposely avoided sveltekit in my current project. It's not 1.0 and it clearly states that.
I don't need it. Only seems to bring SSR which many projects simply don't need.
Svelte and vite are working fine for me.
My current project is tied for the most complicated front end project I've built.
It's offline first, pwa, service workers, indexeddb, etc etc. No problems so far. Could use better documentation but what projects can't.
I don't need it. Only seems to bring SSR which many projects simply don't need.
Svelte and vite are working fine for me.
My current project is tied for the most complicated front end project I've built.
It's offline first, pwa, service workers, indexeddb, etc etc. No problems so far. Could use better documentation but what projects can't.
I think "breaking" is really part of Svelte’s life. I used Svelte since v1 five tears ago and basically I had to rewrite those small projects every time I touched them.
One tear for each year?
We use Knockout JS extensively in an old codebase and its two way data bindings and computed values depending on those bindings are a mine field. The uni direcional data flow of React in my opinion has been a breakthrough. How have folks found using two way bindings in Svelte (and other frameworks?)
I'm using Svelte/Sveltekit for a project with about 80 pages (as the designer conceives them -- there are repeated patterns of course... there might be 30-40 sveltekit pages, though some are fairly complex.)
It's been great.
I have no experience with Vue, but I'd rather not work more with react.
It's been great.
I have no experience with Vue, but I'd rather not work more with react.
Vue is just Svelte with extra steps.
If you want something that is a bit lighter weight, check out Surplus. It's been around for ages, is used for real projects, and has a lot of the same design patterns Svelte adopted, without a lot of the extra language semantics.
I was curious about what Svelte "compiler magic" was so this is what I found (I may be wrong): The compiler wires up all the reactive JavaScript ahead of time, while Angular and React do it at run time. Svelte also does DOM manipulation directly and is fast because browsers have improved very much since React was first created. One of Svelte's taglines was "You don't need a virtual DOM". That said, I haven't used Svelte to see what kind of JavaScript it makes and how easy it is to reason about once compiled.
The only thing I don't like about Svelte is the reactive blocks, prefixed with $:. There are a number of gotchas, like updating complex objects, which make things a bit...implicit rather than explicit.
Reactivity is hard in any platform. If you don't like those, I wonder how you'd like the extensive use of rxjs in Angular.
I think svelte has taken the best part of the rxjs observable pattern without the PhD level of insanity in the reactive frameworks.
Beyond debouncing and throttling, the uses for rxjs style reactive patterns (all the variations of Subjects) gets super confusing fast. (Look at a moderate sized Angular app and you see the horror of types and brackets needed to handle http calls and errors correctly, for example).
I think svelte has taken the best part of the rxjs observable pattern without the PhD level of insanity in the reactive frameworks.
Beyond debouncing and throttling, the uses for rxjs style reactive patterns (all the variations of Subjects) gets super confusing fast. (Look at a moderate sized Angular app and you see the horror of types and brackets needed to handle http calls and errors correctly, for example).
Rule of thumb is: it's fired after assignment of a named variable from the root scope which was mentioned in this reactive block.
You can even add a line that just says `myVar;` and the reactive block containing it will be executed on every `myVar = ...`.
You can even add a line that just says `myVar;` and the reactive block containing it will be executed on every `myVar = ...`.
Yeah I understand why people find them confusing. They trip me up too, and I write a lot of Svelte. I think it would have been better if Rich had added something like the computed/useEffect style of this concept, but it would have looked very out of place in the rest of Svelte which is probably why he didn't do it.
Maybe you need vue3 .value
i would like to read a comparison of the major js frameworks from a practical sense of how they can help me meet deadlines faster, as opposed to developer experience
i'm not that bothered about the various technical trade-offs, i mean they sent a rocket to the moon using assembly language
i just want to know how {newThing} can help me get shit done at work faster with less headaches.
i'm not that bothered about the various technical trade-offs, i mean they sent a rocket to the moon using assembly language
i just want to know how {newThing} can help me get shit done at work faster with less headaches.
Is anyone writing svelte in emacs? How's the tooling there? I'd like to know if it's good enough.
web-mode supports .svelte files (provided you add the engine to the alist). I haven't made anything too complicated with it but it seems to do the trick.
Svelte is too married to JS. I hope JS gradually becomes just a compile target for other languages. React is great because you can use it nicely from ClojureScript (via Reagent).
I think svelte is a project that will always remain experimental.
Svelte is used in production by several high profile companies. NYT in primis, since its creator Rich Harris worked there, but also Spotify, Ikea, Reuters, Brave...we can debate if it's not as mature as other frameworks, but definitely is not experimental.
By experimental, I don't mean unsuitable for production. As a development culture, I think that they are in a structure that constantly tries something within themselves. So if I start using it for an application today, the codes I use in a few months may be depreceted. this is my personal observation. I wanted to share.
I understand what you mean.
Something's changed, but the syntax and the svelte way of doing reactive components is the same (but I only used version 3, don't know how they did in the previous versions).
SvelteKit on the other hand is still very much a work in progress. I'm using it for personal projects and it's great, but I'm surely waiting until v1.0 to do anything serious with it.
Something's changed, but the syntax and the svelte way of doing reactive components is the same (but I only used version 3, don't know how they did in the previous versions).
SvelteKit on the other hand is still very much a work in progress. I'm using it for personal projects and it's great, but I'm surely waiting until v1.0 to do anything serious with it.
And what makes it experimental in your opinion?
The fact that there's never a v1.0
https://github.com/sveltejs/svelte/blob/master/CHANGELOG.md
Svelte is currently version 3.5
Svelte is currently version 3.5
I had a good time trying out Svelte a while back. However, at least at the time, TypeScript support for it was nearly non-existent which makes it a non-starter for me.
[deleted]
Hooray! Yet another framework which will do what Angular already does for years.
I love the kitchen-sink and batteries included of Angular. It made our small team very productive on large projects. But I really dislike the separated component files convention. On the other hand, I love React single components but hate having to shop-around and piece together every basic platform feature.
"hate having to shop-around and piece together every basic platform feature."
Can you elaborate on what you mean by this?
Can you elaborate on what you mean by this?
Say, you are making an app, and find yourself needing a router, state management library.
Angular: use inbuilt router and rxjs
Vue: use vue router and pinia
React: shop around third party libraries.
You can shop for alternatives for both angular and vue as well, but they have a first party solution. While react does not and will not have a first party solution for this and many other use cases
Angular: use inbuilt router and rxjs
Vue: use vue router and pinia
React: shop around third party libraries.
You can shop for alternatives for both angular and vue as well, but they have a first party solution. While react does not and will not have a first party solution for this and many other use cases
[deleted]
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?