4 ms·

There's no ignoring svelte despite a lot of devs pushing back against it due to years in React and "existing resources and community". The performance is super

There's no ignoring svelte despite a lot of devs pushing back against it due to years in React and "existing resources and community". The performance is superior and that will drive adoption. It's a much better development experience. Sort of feels fun again.

Takennickname 3y ago
I think the future is frameworks like Astro that allow you to use any library you want. That'll make the most sense until someone comes up with a new paradigm all together.
- 65 3y ago
  > until someone comes up with a new paradigm all together. Like Bun?
postalrat 3y ago
If react can get server components to work then it will be going in a completely different direction. React as your connection to the server.
- chrisco255 3y ago
  Confused about your comment, they already work.
  - postalrat 3y ago
    Where are they working?
    - jmisavage 3y ago
      Next.js 13 is using them.
Zealotux 3y ago
Performance is never what drives adoption of general solutions like front end frameworks, developer productivity is way above that as a metric and yeah: React having a massive ecosystem is it’s killer feature. Trust me, I wish we could move one from React for something more reasonable like Solid or Svelte, but no amount of benchmark will change the trend. Feels like Twitter is living in a parallel universe.
- baby 3y ago
  Why don’t you move to Vue/Nuxt? I’ve made the move years ago and I’m happy
- SkyMarshal 3y ago
  I’ve just started learning Svelte for a side project, but I think you can make an argument for developer productivity with it too. React doesn’t have a monopoly on that.
  - lolinder 3y ago
    Could you make the argument, then? How does Svelte make up for the massive ecosystem gap?
    - azangru 3y ago
      What if you don't need a massive ecosystem? For example, the project I am currently working on has (checks package.json) react-router, react bindings for redux, and react-spring (the latter could easily be dropped; it is almost not used). Plus Storybook, but that's not even react-specific. That's all.
      - lolinder 3y ago
        The ecosystem is more than the libraries. Do you use the VS Code or WebStorm integrations? Do you use one of the many options we have for bundlers and dev servers? Do you use the browser dev tools? Svelte has to recreate plugins for all of these things and more. I haven't yet tried Svelte (I'm waiting for Svelte 5), but the tooling needs to be at least comparable to Vue's if I'm going to consider adopting it.
robertoandred 3y ago
If you run into performance issues with React it's a code issue.
bastawhiz 3y ago
> The performance is superior and that will drive adoption This has never been true. Nobody adopts React in 2023 because it's the fastest (as in performance) option. Other frameworks have been far faster for the better part of a decade. Why would shaving a handful of milliseconds here and there change the game now? People choose React because you could have gone from 0.15 to 18.0 with maybe a week of effort, often less. It has escape hatches where they're needed. Almost every tool you could need works with React. There's essentially nothing that you can't accomplish with React as the foundation. Nobody has gotten fired for choosing React.
- doodlesdev 3y ago
  > People choose React because you could have gone from 0.15 to 18.0 with maybe a week of effort, often less. That's only if you are not using other libraries, otherwise it will take much more time than that and the upgrade would very likely require you to rewrite your components as functions which will be a massive undertaking, specially for larger codebases which already made extensive use of OOP patterns to keep code modular. It's even worse if you consider that React is unusable for most projects without a lot of associated tooling that also faces breaking changes often (i.e. your build tooling, your CD/CI environment and deploy workflow, etc.). In reality React is anything but stable, it has in 10 years faced multiple paradigm shifts in terms of development experience, had most of its codebase changed or refactored multiple times, etc. > Nobody has gotten fired for choosing React. This is an (unfortunately) very true piece of wisdom which I have to agree with.
- pcthrowaway 3y ago
  I spent a couple of days trying to migrate a react app at v17 bootstrapped with create-react-app to v18 and Vite, but eventually gave up because all the tooling and libraries and deployment processes needed attention along that migration path. I'd be very surprised if 0.15 to 18.0 could be as seamless as you claim, for a real production application with hundreds of components and a few dozen dependencies
- ttfkam 3y ago
  While yes, Svelte is faster out of the box than React, that's not its main draw in my opinion. When you learn React, you learn React's idioms, its methodology, the common component libraries, etc. You learn its API and patterns. Svelte follows the patterns established by HTML and CSS, and builds upon them. If you know how to write static HTML, you will already be familiar with the structure of a Svelte component. If you know CSS, the <style> tag in Svelte is natural to you (except that CSS styles are scoped to component by default, so it's actually easier than plain CSS). For the JS, you don't have to research to find out what the hot client state management tool of the week for React is. You don't have to worry about useState vs useEffect vs useMemo. You don't have to worry about how to integrate with a reactive library like rxjs. You just write what looks like plain JS + things like "$:" and "$store", and you're done. Developer performance is what matters most here. React has an advantage for now due to a decade of inertia, but folks coming up who don't already know React or folks who are feeling burned out by React due to huge transitions like classes-to-functions? They're the target audience who's gonna try Svelte and realize they've been living with Stockholm Syndrome for a while now. Things like useMemo(…) are abstraction leaks. They are mental overhead and boilerplate over and above the actual problems people are trying to solve. Gimme someone with HTML/CSS knowledge and basic JavaScript skills, and I'll deliver a viable Svelte developer in a day or two. That's something React cannot match and will never match. Will React disappear? Of course not. Even COBOL is still in use. No one's dumping React and a large codebase on a whim. But when more folks realize they can use GridJS and ChartJS and other vanilla JS libraries out of the box with Svelte without an elaborate stack of bespoke wrappers to make them work, React's ecosystem will not seem quite so rich in comparison. Folks writing for greenfield are gonna think twice about React.
Rapzid 3y ago
Or people believe yet another language and compiler is the wrong direction. Same with React's skunkworks compiler project. SolidJS has shown what can be done performance-wise without all that nonsense. And Mobx+React/Vue is quite performant. Also, switching costs are incredibly high.
- ttfkam 3y ago
  SolidJS is currently faster at runtime. Not sure it could beat Svelte at developer time. And with the reported speed improvements in Svelte 5 (waiting to see how those bear out in the real world), the difference isn't going to be how fast in runs in your browser; it'll be how fast you can go from a blank IDE text window to a user's browser. let features = 0; let people = 1; $: featuresPerPerson = features / people; function addPerson() { people++; } function addFeature() { features++; } Folks might consider it magic, but it's a lot closer to our mental model of the problem than anything SolidJS can give. As for "magic", we're working with sand we shot with lightning to make it think. If you don't like magic, you're in the wrong vocation. The only question is whether or not the magic is useful, predictable, and reliable. I consider Svelte to be that right kind of magic.

Takennickname 3y ago

I think the future is frameworks like Astro that allow you to use any library you want. That'll make the most sense until someone comes up with a new paradigm all together.

65 3y ago
> until someone comes up with a new paradigm all together. Like Bun?

postalrat 3y ago

If react can get server components to work then it will be going in a completely different direction. React as your connection to the server.

chrisco255 3y ago
Confused about your comment, they already work.
- postalrat 3y ago
  Where are they working?
  - jmisavage 3y ago
    Next.js 13 is using them.

Zealotux 3y ago

Performance is never what drives adoption of general solutions like front end frameworks, developer productivity is way above that as a metric and yeah: React having a massive ecosystem is it’s killer feature. Trust me, I wish we could move one from React for something more reasonable like Solid or Svelte, but no amount of benchmark will change the trend. Feels like Twitter is living in a parallel universe.

baby 3y ago
Why don’t you move to Vue/Nuxt? I’ve made the move years ago and I’m happy
SkyMarshal 3y ago
I’ve just started learning Svelte for a side project, but I think you can make an argument for developer productivity with it too. React doesn’t have a monopoly on that.
- lolinder 3y ago
  Could you make the argument, then? How does Svelte make up for the massive ecosystem gap?
  - azangru 3y ago
    What if you don't need a massive ecosystem? For example, the project I am currently working on has (checks package.json) react-router, react bindings for redux, and react-spring (the latter could easily be dropped; it is almost not used). Plus Storybook, but that's not even react-specific. That's all.
    - lolinder 3y ago
      The ecosystem is more than the libraries. Do you use the VS Code or WebStorm integrations? Do you use one of the many options we have for bundlers and dev servers? Do you use the browser dev tools? Svelte has to recreate plugins for all of these things and more. I haven't yet tried Svelte (I'm waiting for Svelte 5), but the tooling needs to be at least comparable to Vue's if I'm going to consider adopting it.

robertoandred 3y ago

If you run into performance issues with React it's a code issue.

bastawhiz 3y ago

> The performance is superior and that will drive adoption This has never been true. Nobody adopts React in 2023 because it's the fastest (as in performance) option. Other frameworks have been far faster for the better part of a decade. Why would shaving a handful of milliseconds here and there change the game now? People choose React because you could have gone from 0.15 to 18.0 with maybe a week of effort, often less. It has escape hatches where they're needed. Almost every tool you could need works with React. There's essentially nothing that you can't accomplish with React as the foundation. Nobody has gotten fired for choosing React.

doodlesdev 3y ago
> People choose React because you could have gone from 0.15 to 18.0 with maybe a week of effort, often less. That's only if you are not using other libraries, otherwise it will take much more time than that and the upgrade would very likely require you to rewrite your components as functions which will be a massive undertaking, specially for larger codebases which already made extensive use of OOP patterns to keep code modular. It's even worse if you consider that React is unusable for most projects without a lot of associated tooling that also faces breaking changes often (i.e. your build tooling, your CD/CI environment and deploy workflow, etc.). In reality React is anything but stable, it has in 10 years faced multiple paradigm shifts in terms of development experience, had most of its codebase changed or refactored multiple times, etc. > Nobody has gotten fired for choosing React. This is an (unfortunately) very true piece of wisdom which I have to agree with.
pcthrowaway 3y ago
I spent a couple of days trying to migrate a react app at v17 bootstrapped with create-react-app to v18 and Vite, but eventually gave up because all the tooling and libraries and deployment processes needed attention along that migration path. I'd be very surprised if 0.15 to 18.0 could be as seamless as you claim, for a real production application with hundreds of components and a few dozen dependencies
ttfkam 3y ago
While yes, Svelte is faster out of the box than React, that's not its main draw in my opinion. When you learn React, you learn React's idioms, its methodology, the common component libraries, etc. You learn its API and patterns. Svelte follows the patterns established by HTML and CSS, and builds upon them. If you know how to write static HTML, you will already be familiar with the structure of a Svelte component. If you know CSS, the <style> tag in Svelte is natural to you (except that CSS styles are scoped to component by default, so it's actually easier than plain CSS). For the JS, you don't have to research to find out what the hot client state management tool of the week for React is. You don't have to worry about useState vs useEffect vs useMemo. You don't have to worry about how to integrate with a reactive library like rxjs. You just write what looks like plain JS + things like "$:" and "$store", and you're done. Developer performance is what matters most here. React has an advantage for now due to a decade of inertia, but folks coming up who don't already know React or folks who are feeling burned out by React due to huge transitions like classes-to-functions? They're the target audience who's gonna try Svelte and realize they've been living with Stockholm Syndrome for a while now. Things like useMemo(…) are abstraction leaks. They are mental overhead and boilerplate over and above the actual problems people are trying to solve. Gimme someone with HTML/CSS knowledge and basic JavaScript skills, and I'll deliver a viable Svelte developer in a day or two. That's something React cannot match and will never match. Will React disappear? Of course not. Even COBOL is still in use. No one's dumping React and a large codebase on a whim. But when more folks realize they can use GridJS and ChartJS and other vanilla JS libraries out of the box with Svelte without an elaborate stack of bespoke wrappers to make them work, React's ecosystem will not seem quite so rich in comparison. Folks writing for greenfield are gonna think twice about React.

Rapzid 3y ago

Or people believe yet another language and compiler is the wrong direction. Same with React's skunkworks compiler project. SolidJS has shown what can be done performance-wise without all that nonsense. And Mobx+React/Vue is quite performant. Also, switching costs are incredibly high.

ttfkam 3y ago
SolidJS is currently faster at runtime. Not sure it could beat Svelte at developer time. And with the reported speed improvements in Svelte 5 (waiting to see how those bear out in the real world), the difference isn't going to be how fast in runs in your browser; it'll be how fast you can go from a blank IDE text window to a user's browser. let features = 0; let people = 1; $: featuresPerPerson = features / people; function addPerson() { people++; } function addFeature() { features++; } Folks might consider it magic, but it's a lot closer to our mental model of the problem than anything SolidJS can give. As for "magic", we're working with sand we shot with lightning to make it think. If you don't like magic, you're in the wrong vocation. The only question is whether or not the magic is useful, predictable, and reliable. I consider Svelte to be that right kind of magic.