Earlier quoted context omitted.
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…
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 :-)
Introducing Svelte, and Comparing Svelte with React and Vue (2021)
201–210 of 213 posts
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#202I 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"…
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?
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#203Earlier quoted context omitted.
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 re…
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.
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#204I 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 t…
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.
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#205I 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 t…
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 compi…
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.
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#206Earlier quoted context omitted.
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.
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.
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#207Earlier 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…
However I imagine there isn't alot of community libraries to leverage with such a small ecosystem.
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#208Earlier quoted context omitted.
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 compi…
>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…
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.
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#209Svelte 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.
Larger ecosystems
Re: Introducing Svelte, and Comparing Svelte with React and Vue (2021)
#210Can 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…