4 ms·

Not a frontend person, and unlikely to become one anytime soon, but maybe someone can shed some light into the downsides of Svelte? The article fails to mention

Not a frontend person, and unlikely to become one anytime soon, but maybe someone can shed some light into the downsides of Svelte? The article fails to mention any (it's apparently "win-win"). Presumably if Svelte were the be-all-end-all of front-end frameworks, it would dominate soon enough?

pmarreck 3y ago
The problem is, there is no panacea in technology, only tradeoffs. Svelte does look pretty sweet though.
Aerbil313 3y ago
Well it is very new. React has a massive inertia, so it dominates for now. I do FE work and see Svelte is gaining popularity.
- bobolino123 3y ago
  2016 is not very new
  - deleted 3y ago
    [deleted]
  - karaterobot 3y ago
    Probably as much as the 3 year difference is the fact that Facebook made and evangelized React. I know I didn't hear about Svelte until 2018-2019, but I knew about React within a few days of its release.
  - boringuser2 3y ago
    Actually, that's very old in frontend years.
tl 3y ago
React: - had a 3 year head start on Svetle (2013 vs. 2016) - has major engineering orgs behind it. Facebook started it. Microsoft makes it work with Typescript. - is easier to get started with. While JS-compilation is common, it's required for Svetle. Svelte isn't free of pain points. Like any form of magic, it has edge cases. It's better but not "better enough" to de-throne React.
simlevesque 3y ago
> maybe someone can shed some light into the downsides of Svelte The automatic handling of dependencies and recomputing means you have less control over how updates work. Also I think it is important to understand the mutations going on in your ui. Having them explicit like in Vue makes it easier to understand what is gonna happen by looking at the code versus the implicit way that Svelte uses.
grayrest 3y ago
> maybe someone can shed some light into the downsides of Svelte Svelte trades off runtime size for component size. It was created in the context of infographics for the New York Times online and for projects that roughly line up with that it's pretty much the technically best option. I like the Svelte authoring experience and introduced it for a few components in a React based low-code platform. The reason I phased it out was a chat component that was ~600 LoC and 50-something reactive variables in a moderately complex chain blew up into ~5k LoC of output. I also ran into what seemed to be some transient invalidation issues. I was short on time to debug this and engage with the Svelte community so I rewrote it in React to match the rest of the system. It's possible I was doing something wrong but I don't have enough confidence to bet on 3.x again. I'll take another look when 4.x comes around. > Presumably if Svelte were the be-all-end-all of front-end frameworks, it would dominate soon enough? There's significant network effects around the established frameworks. Nobody gets fired for picking React. I personally think Solid is the best overall technically but the ecosystem and mindshare is smaller and that matters to a company making a business and not necessarily technical decision.
- boringuser2 3y ago
  Why do you care about compilation output? Also, your component sounds cumbersome.
  - i-use-nixos-btw 3y ago
    I’m mainly a C++ developer, not a frontend developer (though I dabble), and when I have a choice of multiple approaches the first thing I do is go to godbolt.org, implement MWEs and compare the assembly. I also do a lot of code generation, and my absolute goal is to have it write code that I’d write if I were doing it by hand. That’s pretty key for me. If the output is better, then good. If the output is doing a bunch of stuff it doesn’t need to be doing because it’s taking my specific use case and making it conform with its own model for doing generic things, I don’t like it. I was a web developer back when tables for layout, HTML attribute soup for styling, and applets for interactivity were going out of fashion. Semantic HTML and CSS for layout and styling and JS for interactivity were coming into fashion. Divs for layout, class soup for styling, and JS frameworks for interactivity hadn’t yet become mainstream when I stopped. So my default is lean HTML, lean CSS, raw JS. Maybe JQuery if needs be. It’s an outdated default, but it’s mine. The thing is, I get great load times and performance for what I need. What I need is normal dashboard stuff - though because of the nature of the field I work in, it condenses a lot of information onto a page and that information is updating many times per second. I don’t seem to get enough performance from the frontend frameworks I’ve tried. I don’t know if it comes from code bloat, or deep call stacks through god knows how many levels of indirection, the way DOM updates are issued, or something else - but it has just never seemed worth the learning curve to end up with something I can’t do myself with admittedly a lot of work. As such, I find this review helpful. Svelte has caught my attention and I want to give it a go, but if the output is bloaty then that’s a red flag for me. If it’s bloaty because it isn’t doing backflips through the call stack, but is inlining code - that’s familiar territory and certainly something I can deal with.
satvikpendem 3y ago
You need to learn a custom DSL for logic instead of using just Javascript. This makes it worse for TypeScript as well as other tools like for linting, etc. Personally I'll never learn another DSL after JSX. Implicit 2 way data binding which makes logic hard to follow in larger projects, same with their reactivity model.
- aryanmann 3y ago
  It really isn't that bad. You can frontload your logic outside inside the script section (or use @const's). The DSL is just a couple of {#if} and {#each}'s. Is the 2 way data binding implicit? As I understood, you need the "bind:" keyword for 2 way data binding.
boringuser2 3y ago
My experience: JSX is the best templating language. Svelte hides complexity and this can bite you in tracking down issues. React just feels better to me for a professional project, though I like Svelte.
nine_k 3y ago
Two-way data binding. 'Nuff said. Instead of easy-to-trace functional logic and pure functions you have a thing more like an electrical circuit, or like a highly advanced jQuery contraption. It's fine and even great for smaller bits of interactivity. It becomes increasingly unwieldy as the scope grows. (And for tiny bits of interactivity there is HTMX, wonderful in its own way.)
SebastianKra 3y ago
I'm disappointed that this isn't talked about, even when someone explicitly asks: You can't use JS to iterate over, store or otherwise work with the output of the templating language. For example: const cells: Record<string, ReactNode> = { a: "hello world", b: <>hello <b>world</b></>, c: <Icon src="world.png" />} The closest you could get in Svelte, is creating three new components (3 entire files), which are then rendered using `<svelte.component this={HelloWorldComponent} />`. This becomes a problem, when you build composed components that decide their layout based on logic thats too complex to express in CSS or Sveltes templating system. For example: - A component for tabbed navigation that automatically becomes a sidebar on desktop. - React Router defining its entire navigation tree [1] - Ant.Design defining the columns of the table, where you can trivially supply a short callback to render a cell [2] [1]: https://reactrouter.com/en/main/routers/create-browser-router https://reactrouter.com/en/main/routers/create-browser-route... [2]: https://ant.design/components/table https://ant.design/components/table
JuanPosadas 3y ago
Just note that I last used svelte/sapper 2 years ago. I have no idea if core updates or sveltekit or (hopefully) improved typescript support changes anything. Some types of errors cause your application to halt (which might feel like a UI freeze). There's no way to catch these errors and show an error page, show an error message, or report the error to an error tracking service like Sentry. I'm subbed to the github issue for this and never saw a fix. Poor composability of components. Components in svelte are awesome in the general sense, they're just missing this higher-level code organization possibility that react, solidjs, and vuejs users have cozy versions of. The docs claimed a specific function worked like nuxt's asyncData function. Whoever wrote that has no idea what nuxt's asyncData function does, because that function worked very very very differently.

pmarreck 3y ago

The problem is, there is no panacea in technology, only tradeoffs. Svelte does look pretty sweet though.

Aerbil313 3y ago

Well it is very new. React has a massive inertia, so it dominates for now. I do FE work and see Svelte is gaining popularity.

bobolino123 3y ago
2016 is not very new
- deleted 3y ago
  [deleted]
- karaterobot 3y ago
  Probably as much as the 3 year difference is the fact that Facebook made and evangelized React. I know I didn't hear about Svelte until 2018-2019, but I knew about React within a few days of its release.
- boringuser2 3y ago
  Actually, that's very old in frontend years.

tl 3y ago

React: - had a 3 year head start on Svetle (2013 vs. 2016) - has major engineering orgs behind it. Facebook started it. Microsoft makes it work with Typescript. - is easier to get started with. While JS-compilation is common, it's required for Svetle. Svelte isn't free of pain points. Like any form of magic, it has edge cases. It's better but not "better enough" to de-throne React.

simlevesque 3y ago

> maybe someone can shed some light into the downsides of Svelte The automatic handling of dependencies and recomputing means you have less control over how updates work. Also I think it is important to understand the mutations going on in your ui. Having them explicit like in Vue makes it easier to understand what is gonna happen by looking at the code versus the implicit way that Svelte uses.

grayrest 3y ago

> maybe someone can shed some light into the downsides of Svelte Svelte trades off runtime size for component size. It was created in the context of infographics for the New York Times online and for projects that roughly line up with that it's pretty much the technically best option. I like the Svelte authoring experience and introduced it for a few components in a React based low-code platform. The reason I phased it out was a chat component that was ~600 LoC and 50-something reactive variables in a moderately complex chain blew up into ~5k LoC of output. I also ran into what seemed to be some transient invalidation issues. I was short on time to debug this and engage with the Svelte community so I rewrote it in React to match the rest of the system. It's possible I was doing something wrong but I don't have enough confidence to bet on 3.x again. I'll take another look when 4.x comes around. > Presumably if Svelte were the be-all-end-all of front-end frameworks, it would dominate soon enough? There's significant network effects around the established frameworks. Nobody gets fired for picking React. I personally think Solid is the best overall technically but the ecosystem and mindshare is smaller and that matters to a company making a business and not necessarily technical decision.

boringuser2 3y ago
Why do you care about compilation output? Also, your component sounds cumbersome.
- i-use-nixos-btw 3y ago
  I’m mainly a C++ developer, not a frontend developer (though I dabble), and when I have a choice of multiple approaches the first thing I do is go to godbolt.org, implement MWEs and compare the assembly. I also do a lot of code generation, and my absolute goal is to have it write code that I’d write if I were doing it by hand. That’s pretty key for me. If the output is better, then good. If the output is doing a bunch of stuff it doesn’t need to be doing because it’s taking my specific use case and making it conform with its own model for doing generic things, I don’t like it. I was a web developer back when tables for layout, HTML attribute soup for styling, and applets for interactivity were going out of fashion. Semantic HTML and CSS for layout and styling and JS for interactivity were coming into fashion. Divs for layout, class soup for styling, and JS frameworks for interactivity hadn’t yet become mainstream when I stopped. So my default is lean HTML, lean CSS, raw JS. Maybe JQuery if needs be. It’s an outdated default, but it’s mine. The thing is, I get great load times and performance for what I need. What I need is normal dashboard stuff - though because of the nature of the field I work in, it condenses a lot of information onto a page and that information is updating many times per second. I don’t seem to get enough performance from the frontend frameworks I’ve tried. I don’t know if it comes from code bloat, or deep call stacks through god knows how many levels of indirection, the way DOM updates are issued, or something else - but it has just never seemed worth the learning curve to end up with something I can’t do myself with admittedly a lot of work. As such, I find this review helpful. Svelte has caught my attention and I want to give it a go, but if the output is bloaty then that’s a red flag for me. If it’s bloaty because it isn’t doing backflips through the call stack, but is inlining code - that’s familiar territory and certainly something I can deal with.

satvikpendem 3y ago

You need to learn a custom DSL for logic instead of using just Javascript. This makes it worse for TypeScript as well as other tools like for linting, etc. Personally I'll never learn another DSL after JSX. Implicit 2 way data binding which makes logic hard to follow in larger projects, same with their reactivity model.

aryanmann 3y ago
It really isn't that bad. You can frontload your logic outside inside the script section (or use @const's). The DSL is just a couple of {#if} and {#each}'s. Is the 2 way data binding implicit? As I understood, you need the "bind:" keyword for 2 way data binding.

boringuser2 3y ago

My experience: JSX is the best templating language. Svelte hides complexity and this can bite you in tracking down issues. React just feels better to me for a professional project, though I like Svelte.

nine_k 3y ago

Two-way data binding. 'Nuff said. Instead of easy-to-trace functional logic and pure functions you have a thing more like an electrical circuit, or like a highly advanced jQuery contraption. It's fine and even great for smaller bits of interactivity. It becomes increasingly unwieldy as the scope grows. (And for tiny bits of interactivity there is HTMX, wonderful in its own way.)

SebastianKra 3y ago

I'm disappointed that this isn't talked about, even when someone explicitly asks: You can't use JS to iterate over, store or otherwise work with the output of the templating language. For example: const cells: Record<string, ReactNode> = { a: "hello world", b: <>hello <b>world</b></>, c: <Icon src="world.png" />} The closest you could get in Svelte, is creating three new components (3 entire files), which are then rendered using `<svelte.component this={HelloWorldComponent} />`. This becomes a problem, when you build composed components that decide their layout based on logic thats too complex to express in CSS or Sveltes templating system. For example: - A component for tabbed navigation that automatically becomes a sidebar on desktop. - React Router defining its entire navigation tree [1] - Ant.Design defining the columns of the table, where you can trivially supply a short callback to render a cell [2] [1]: https://reactrouter.com/en/main/routers/create-browser-router https://reactrouter.com/en/main/routers/create-browser-route... [2]: https://ant.design/components/table https://ant.design/components/table

JuanPosadas 3y ago

Just note that I last used svelte/sapper 2 years ago. I have no idea if core updates or sveltekit or (hopefully) improved typescript support changes anything. Some types of errors cause your application to halt (which might feel like a UI freeze). There's no way to catch these errors and show an error page, show an error message, or report the error to an error tracking service like Sentry. I'm subbed to the github issue for this and never saw a fix. Poor composability of components. Components in svelte are awesome in the general sense, they're just missing this higher-level code organization possibility that react, solidjs, and vuejs users have cozy versions of. The docs claimed a specific function worked like nuxt's asyncData function. Whoever wrote that has no idea what nuxt's asyncData function does, because that function worked very very very differently.