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.
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.
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.
>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.
>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.
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.