4 ms·

I wonder if we are starting to see the initial symptoms of a future exodus. Exodus where though? I don't think Svelte is that place.

pier25 6y ago
React growth has stalled for the past couple of months: https://npm-stat.com/charts.html?package=react&from=2015-09-01&to=2020-09-01 https://npm-stat.com/charts.html?package=react&from=2015-09-... I moved to Svelte and I'm quite happy.
- 52-6F-62 6y ago
  Have you found any successful patterns outside of Sapper for SSR? I was demoing Sapper for a side-project and didn't like how much of the server work and routing was relegated to the folder structure. It might just be a personal preference matter, mind you. That and I did find it a bit sticky to get working with TypeScript and it would break frequently after adding that in. So I nixed that idea for now. Outside of the CLI being pushed so heavily for project structuring, I still find Vue 2 to be one of the simplest to reason around.
  - pier25 6y ago
    You can set up your SSR project very easily. I actually have a demo of SSR + hydration using Fastify here: https://github.com/PierBover/svelte-ssr-example https://github.com/PierBover/svelte-ssr-example No SPA though.
erokar 6y ago
> I don't think Svelte is that place. How come? I'm fine working with either React or Svelte, but I prefer Svelte's simplicity and small bundle size. What would be a good React alternative that is not Svelte?
- azangru 6y ago
  - Svelte seems to have a bit of a problem with large bundle sizes: https://github.com/sveltejs/svelte/issues/2546#issuecomment-678845774 https://github.com/sveltejs/svelte/issues/2546#issuecomment-... - Svelte might feel (it does to me at least; although I haven't really worked much with it) a bit too magical. In React, you are explicit about the fact that you want to change your variables and how exactly you want to change them (Rich Harris seems to think that such explicitness is excessive verbosity); while in Svelte you just change a value inline, then boom magic happens. It may be a leap forward, like JSX once was; but it also has an uncomfortable feel to it.
  - erokar 6y ago
    - The large bundle sizes were recently addressed here. It doesn't seem to be a problem in practice: https://github.com/halfnelson/svelte-it-will-scale https://github.com/halfnelson/svelte-it-will-scale - You could perfectly fine write update functions á la React for your component state if that is what you prefer. Personally I don't feel that's necessary and prefer Svelte's direct way.
    - hajile 6y ago
      You hit the problem at 120k unminified. It only takes a couple feature-rich libraries to hit that number. Even medium-sized business apps can hit that number on their own pretty easily (without including any libraries) > In practice, you're unlikely to hit that inflection point on any given page of your app, as long as you're using code-splitting (which Sapper gives you OOTB) That is straight-up fiction. If you bundle split correctly, you put React and other shared libraries in ONE bundle that is shared by all your component bundles. If you're coding an actual app, they'll wind up needing most of those bundles at which point the problem doesn't go away. Detecting similar functions and combining them is possible (though it will probably add substantially to compile time). I have no doubt that if svelte continues to grow, it will have to handle this problem. I somehow doubt they'll say it's just a minor feature update affecting just a few users when they finally get that work done. Don't forget that reusing code more also allows the JIT to optimize it to get you better performance too.

pier25 6y ago

React growth has stalled for the past couple of months: https://npm-stat.com/charts.html?package=react&from=2015-09-01&to=2020-09-01 https://npm-stat.com/charts.html?package=react&from=2015-09-... I moved to Svelte and I'm quite happy.

52-6F-62 6y ago
Have you found any successful patterns outside of Sapper for SSR? I was demoing Sapper for a side-project and didn't like how much of the server work and routing was relegated to the folder structure. It might just be a personal preference matter, mind you. That and I did find it a bit sticky to get working with TypeScript and it would break frequently after adding that in. So I nixed that idea for now. Outside of the CLI being pushed so heavily for project structuring, I still find Vue 2 to be one of the simplest to reason around.
- pier25 6y ago
  You can set up your SSR project very easily. I actually have a demo of SSR + hydration using Fastify here: https://github.com/PierBover/svelte-ssr-example https://github.com/PierBover/svelte-ssr-example No SPA though.

erokar 6y ago

> I don't think Svelte is that place. How come? I'm fine working with either React or Svelte, but I prefer Svelte's simplicity and small bundle size. What would be a good React alternative that is not Svelte?

azangru 6y ago
- Svelte seems to have a bit of a problem with large bundle sizes: https://github.com/sveltejs/svelte/issues/2546#issuecomment-678845774 https://github.com/sveltejs/svelte/issues/2546#issuecomment-... - Svelte might feel (it does to me at least; although I haven't really worked much with it) a bit too magical. In React, you are explicit about the fact that you want to change your variables and how exactly you want to change them (Rich Harris seems to think that such explicitness is excessive verbosity); while in Svelte you just change a value inline, then boom magic happens. It may be a leap forward, like JSX once was; but it also has an uncomfortable feel to it.
- erokar 6y ago
  - The large bundle sizes were recently addressed here. It doesn't seem to be a problem in practice: https://github.com/halfnelson/svelte-it-will-scale https://github.com/halfnelson/svelte-it-will-scale - You could perfectly fine write update functions á la React for your component state if that is what you prefer. Personally I don't feel that's necessary and prefer Svelte's direct way.
  - hajile 6y ago
    You hit the problem at 120k unminified. It only takes a couple feature-rich libraries to hit that number. Even medium-sized business apps can hit that number on their own pretty easily (without including any libraries) > In practice, you're unlikely to hit that inflection point on any given page of your app, as long as you're using code-splitting (which Sapper gives you OOTB) That is straight-up fiction. If you bundle split correctly, you put React and other shared libraries in ONE bundle that is shared by all your component bundles. If you're coding an actual app, they'll wind up needing most of those bundles at which point the problem doesn't go away. Detecting similar functions and combining them is possible (though it will probably add substantially to compile time). I have no doubt that if svelte continues to grow, it will have to handle this problem. I somehow doubt they'll say it's just a minor feature update affecting just a few users when they finally get that work done. Don't forget that reusing code more also allows the JIT to optimize it to get you better performance too.