I think svelte is a project that will always remain experimental.
And what makes it experimental in your opinion?
The fact that there's never a v1.0
Introducing Svelte, and Comparing Svelte with React and Vue (2021)
181–190 of 213 posts
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#182Earlier quoted context omitted.
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...
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 mas…
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.
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#183I 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"…
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…
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.
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#184Earlier quoted context omitted.
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 mas…
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 th…
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.
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#185I 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.
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#186Earlier quoted context omitted.
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…
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.
But, but ... resume driven development!
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#187Earlier quoted context omitted.
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...
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…
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".
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#188Earlier quoted context omitted.
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 a…
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.
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...
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#189Earlier quoted context omitted.
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 lik…
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...
Got it. It was both compiled and minified.
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#190Earlier quoted context omitted.
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.
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 othe…
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.