4 ms·

In my anecdotal experience — no. We started with Svelte and quickly migrated to solid (which has it's own handful of headaches but is much more manageable). Sve

In my anecdotal experience — no. We started with Svelte and quickly migrated to solid (which has it's own handful of headaches but is much more manageable). Svelte was originally designed for little pieces of interactive content (in the nytimes), and it scaled like that for us back in 2021

SkyMarshal 3y ago
Interesting, Svelte and Solid seem to be the only two new compiler-based js frameworks. Everything else is virtual-DOM based. Solid is newer than Svelte with less of an ecosystem, so it’s interesting to hear that you found it more manageable. What made it more manageable?
- internetter 3y ago
  So I guess it's worth first discussing ecosystem. Ecosystem is something I understand that people want, but we've generally avoided. Especially in react, there's a large worry about quality. Building something quickly that's taylor made for our business needs is much easier than parsing documentation, reading source code for QA, and then inevitably hitting an edge case. There are a couple instances where we did find ourselves missing an ecosystem (the first example that comes to mind is WYSIWYG editors), but for the most part we build it ourselves, and that's been fine. From what I recall of the Svelte ecosystem, it had a much more monolithic "this is how you do it" with the packages. By contrast, solid has a much larger focus on primitives — composing something you need from a set of modular tools. This also extends to our grievances with Svelte itself. I wish I could recall exact examples, but we transitioned 3 years ago and unfortunately I never recorded the exact issues. I do remember it distilled to a very similar problem. Things go great with the magic, until you hit some sort of problem that the framework authors did not anticipate, and you basically learn "you cannot do this". By contrast, solid gives you tons [0] of primitives. Almost every issue relating to state can be addressed with these primitives, and if not, you can easily compose your own (in fact, very few of the provided primitives are entangled with the core library. They themselves are built upon lower and lower level primitives). Also, with Svelte there were a considerable amount of design decisions I disagreed with. For instance, the context API uses strings instead of imports as identifiers, which breaks intelisense. I guess they want it to feel monolithic and integrated, but it's just frustrating. How do I extend this context system in Svelte? Everything really comes down to this fundamental decision between a "framework" and a "toolbox". Even the file structure reflects this. Solid, in some way, encourages small components — you can have multiple functions in a file, vs svelte where you can only have one. Each component in Svelte has significantly higher size overhead than solid, I suppose because you aren't supposed to have as many. In my opinion, the toolbox philosophy is much better equipped to handle the complexities of a large application. Sorry for such a long ramble without concrete examples. As I said, I really wish I wrote this out 3 years ago when we made the switch. As for Solid vs. React, there's plenty of discussions of this already. Aside from the much better performance, the solid model fixes almost all the footguns relating to state and rendering performance that react introduces, basically because it's closer to vanilla JavaScript (each function only runs "once") [0] https://www.solidjs.com/docs/latest/api https://www.solidjs.com/docs/latest/api e: I've checked back on this thread and I find myself agreeing with other people like gushogg-blake and spuz. Worth checking their comments out as well.
  - SkyMarshal 3y ago
    That is extremely helpful, even without many specific examples, thanks! It’s definitely something to be aware of at the start of a new project. If you anticipate the project will not get too large or complex, then Svelte is probably a good choice for the productivity and performance. But if it could grow over the years into something large and complex, then Solid’s primitives-focus and toolbox approach may be better. I wonder if Svelte5 will retain the framework philosophy or move toward the toolbox approach.
    - internetter 3y ago
      > If you anticipate the project will not get too large or complex, then Svelte is probably a good choice for the productivity and performance. Yup. If I found myself trying to hack together something a weekend I'd be willing to use Svelte again! It's really quite productive at the beginning. Plenty of times when you just want simple reactivity without any other mental overhead.
- earthboundkid 3y ago
  Vue has a compiler and a VDOM.
pier25 3y ago
Could you elaborate on the pros and cons? I've been using Svelte for about 3 years now and haven't found any big scaling headaches.
- DoesntMatter22 3y ago
  Not OP but I'll give my 2 cents. I much prefer Solid because it's explicit as far as which variables will be manipulated. However. I ended up usually using Svelte because it's so much less boilerplate than anything else.

SkyMarshal 3y ago

Interesting, Svelte and Solid seem to be the only two new compiler-based js frameworks. Everything else is virtual-DOM based. Solid is newer than Svelte with less of an ecosystem, so it’s interesting to hear that you found it more manageable. What made it more manageable?

internetter 3y ago
So I guess it's worth first discussing ecosystem. Ecosystem is something I understand that people want, but we've generally avoided. Especially in react, there's a large worry about quality. Building something quickly that's taylor made for our business needs is much easier than parsing documentation, reading source code for QA, and then inevitably hitting an edge case. There are a couple instances where we did find ourselves missing an ecosystem (the first example that comes to mind is WYSIWYG editors), but for the most part we build it ourselves, and that's been fine. From what I recall of the Svelte ecosystem, it had a much more monolithic "this is how you do it" with the packages. By contrast, solid has a much larger focus on primitives — composing something you need from a set of modular tools. This also extends to our grievances with Svelte itself. I wish I could recall exact examples, but we transitioned 3 years ago and unfortunately I never recorded the exact issues. I do remember it distilled to a very similar problem. Things go great with the magic, until you hit some sort of problem that the framework authors did not anticipate, and you basically learn "you cannot do this". By contrast, solid gives you tons [0] of primitives. Almost every issue relating to state can be addressed with these primitives, and if not, you can easily compose your own (in fact, very few of the provided primitives are entangled with the core library. They themselves are built upon lower and lower level primitives). Also, with Svelte there were a considerable amount of design decisions I disagreed with. For instance, the context API uses strings instead of imports as identifiers, which breaks intelisense. I guess they want it to feel monolithic and integrated, but it's just frustrating. How do I extend this context system in Svelte? Everything really comes down to this fundamental decision between a "framework" and a "toolbox". Even the file structure reflects this. Solid, in some way, encourages small components — you can have multiple functions in a file, vs svelte where you can only have one. Each component in Svelte has significantly higher size overhead than solid, I suppose because you aren't supposed to have as many. In my opinion, the toolbox philosophy is much better equipped to handle the complexities of a large application. Sorry for such a long ramble without concrete examples. As I said, I really wish I wrote this out 3 years ago when we made the switch. As for Solid vs. React, there's plenty of discussions of this already. Aside from the much better performance, the solid model fixes almost all the footguns relating to state and rendering performance that react introduces, basically because it's closer to vanilla JavaScript (each function only runs "once") [0] https://www.solidjs.com/docs/latest/api https://www.solidjs.com/docs/latest/api e: I've checked back on this thread and I find myself agreeing with other people like gushogg-blake and spuz. Worth checking their comments out as well.
- SkyMarshal 3y ago
  That is extremely helpful, even without many specific examples, thanks! It’s definitely something to be aware of at the start of a new project. If you anticipate the project will not get too large or complex, then Svelte is probably a good choice for the productivity and performance. But if it could grow over the years into something large and complex, then Solid’s primitives-focus and toolbox approach may be better. I wonder if Svelte5 will retain the framework philosophy or move toward the toolbox approach.
  - internetter 3y ago
    > If you anticipate the project will not get too large or complex, then Svelte is probably a good choice for the productivity and performance. Yup. If I found myself trying to hack together something a weekend I'd be willing to use Svelte again! It's really quite productive at the beginning. Plenty of times when you just want simple reactivity without any other mental overhead.
earthboundkid 3y ago
Vue has a compiler and a VDOM.

pier25 3y ago

Could you elaborate on the pros and cons? I've been using Svelte for about 3 years now and haven't found any big scaling headaches.

DoesntMatter22 3y ago
Not OP but I'll give my 2 cents. I much prefer Solid because it's explicit as far as which variables will be manipulated. However. I ended up usually using Svelte because it's so much less boilerplate than anything else.