5 ms·

> Svelte has not yet received the attention it deserves. When it is mentioned, the focus is typically on its ability to produce bundled code that is significant

> Svelte has not yet received the attention it deserves. When it is mentioned, the focus is typically on its ability to produce bundled code that is significantly smaller than the alternatives. However, Svelte makes many tasks easier, including defining components, managing component state, managing application state, and adding animation. Under the "Why Consider Svelte?" it only mentions bundle size and performance.

mister_hn 7y ago
Which is perfectly fine
- rat9988 7y ago
  It is not, I can already do that directly with the DOM. It's a huge asset, but not enough. Ease of use, development velocity or something along these lines should be mentioned.
- felideon 7y ago
  For me, that's icing on the cake. Why I truly like and recommend Svelte is its ergonomics. Paired with Sapper, building a fast website is a breeze and feels like you're just writing plain HTML and (supercharged) JS.
  - choward 7y ago
    Cool, but how does it help me reason about my code and maintain large projects? It doesn't even support typescript. Sure, the components look okay in isolation, but what about the big picture?
    - s_y_n_t_a_x 7y ago
      It doesn't and it won't. Advocates for Svelte seem to prefer it over the complicated (I do not agree) React patterns. Those patterns are there for a reason and help the code stay maintainable and predictable. Not supporting TypeScript is also a big blow. Small projects / websites = use the DOM SPAs = use React Why would you use Svelte for small websites when it requires JS? All of my "websites" are made w/ pure HTML/CSS/JS and the JS is optional. All of my "apps" are made w/ React (Web, Electron) & React Native (Windows, iOS, Android) I'm working on a stack that sets all this up for you so you can get started on deploying for every platform. I already use it in production. Don't cheat yourself, use React and take advantage of the progress and ecosystem. If you don't need that, then use vanilla.
      - felideon 7y ago
        What patterns are you talking about? Nothing specific to React, as far as I know, helps with maintaining a large codebase. Though, perhaps you mean the larger React ecosystem. But still, what patterns are you talking about? TEA/Redux? There's no reason why you can't use the same patterns with Svelte.
      - emerongi 7y ago
        React doesn't have some intricate patterns. It mostly advocates for a functional-style UI, where you do computation in the render cycle and keep state localized to a component. Svelte gives you the exact same tools. I've been building React-based applications for years now and have been using Svelte for some projects on the side and in my opinion both are decent tools. Some of the Svelte "sugar" is easily replicated in React, it's just that React doesn't provide those out of the box; on the other hand, Svelte has some "gotchas" that don't appear in React.
    - lhorie 7y ago
      > typescript I hear that this is something they are looking into adding support for
    - mvolkmann 7y ago
      Here is the issue that describes what the Svelte team is doing to add support for TypeScript: https://github.com/sveltejs/svelte/issues/1639 https://github.com/sveltejs/svelte/issues/1639
- paulddraper 7y ago
  It's perfectly fine if your most pressing issue with large bundle sizes/slow performance. If your most pressing issue is removing bugs from managing state, you will pass it by.
  - ummonk 7y ago
    Right, and if your pressing issue is large bundle sizes/slow performance, you'd probably be using Preact.
  - mvolkmann 7y ago
    If your most pressing issue is making managing state easier, you should run to Svelte! Take a look at how Svelte supports "stores", "context", and state within a component. Those are so good that I predict nobody will ever feel the need to write a state management library for Svelte. It's already very easy!
mvolkmann 7y ago
Not true. That section mentions several other "Whys" including this: "Svelte dramatically simplifies component and application state management. Contributing features include context, stores, and module context, each of which is covered in detail later."
lhorie 7y ago
The way I see Svelte is as a one-stop-shop type of framework (similar to Angular and Ember in philosophy), but exclusively for client-side concerns, and aggressively geared towards leveraging standard web idioms (HTML that looks like HTML, CSS that looks like CSS, JS that looks like JS), whereas most competing frameworks extend grammars in various non-standard ways (Angular's "HTML" isn't parseable via a standard HTML parser, and React's "JS" requires a parser that supports JSX - and then there's the whole CSS-in-JS thing where people get tripped up by double quoting and camel casing rules). Said frameworks typically also have steeper learning curves due to framework-specific APIs. Where I think Svelte falls a bit short (given its flavor of comprehensiveness) is that while it concerns itself with strictly client-side things like in-memory state and animations, it offers nothing for sorta-server-related things like data fetching or routing, and you're left to find libraries to fill the gaps (similar to how you would in React). I feel like the bigger frameworks are up to something DX-wise, with providing more integrated/idiomatic ways of interfacing between subsystems (e.g. getting a data fetching API to talk to a state store, or making routing aware of them). Gluing subsystems from different libraries adds weight to application space code (see e.g. react-redux vs Vue) and at some point this starts mattering (usually during maintenance phase). Maybe Svelte's middle ground is your cup of tea, but obviously YMMV a lot.
- jeremyjh 7y ago
  Have you looked at the Sapper project? I think it adds a lot of what you are looking for. It’s basically a next.js equivalent.
  - lhorie 7y ago
    Superficially. It does feel very much like Next.js, but I feel that direction sort of misses the mark, especially coming from a try-to-be-as-transparent-as-possible angle. There's still no opinionated way of doing data fetching (meaning one is free to shoot themselves in the foot trying to chase trends) and for doing non-trivial server-side things, you're basically dealing w/ raw req/res, which tends to devolve into an unstructured mess if the framework doesn't provide guidance (which neither Next nor Sapper do IMO). For me personally, it has one other showstopper (its file naming convention is not compatible w/ Bazel)

mister_hn 7y ago

Which is perfectly fine

rat9988 7y ago
It is not, I can already do that directly with the DOM. It's a huge asset, but not enough. Ease of use, development velocity or something along these lines should be mentioned.
felideon 7y ago
For me, that's icing on the cake. Why I truly like and recommend Svelte is its ergonomics. Paired with Sapper, building a fast website is a breeze and feels like you're just writing plain HTML and (supercharged) JS.
- choward 7y ago
  Cool, but how does it help me reason about my code and maintain large projects? It doesn't even support typescript. Sure, the components look okay in isolation, but what about the big picture?
  - s_y_n_t_a_x 7y ago
    It doesn't and it won't. Advocates for Svelte seem to prefer it over the complicated (I do not agree) React patterns. Those patterns are there for a reason and help the code stay maintainable and predictable. Not supporting TypeScript is also a big blow. Small projects / websites = use the DOM SPAs = use React Why would you use Svelte for small websites when it requires JS? All of my "websites" are made w/ pure HTML/CSS/JS and the JS is optional. All of my "apps" are made w/ React (Web, Electron) & React Native (Windows, iOS, Android) I'm working on a stack that sets all this up for you so you can get started on deploying for every platform. I already use it in production. Don't cheat yourself, use React and take advantage of the progress and ecosystem. If you don't need that, then use vanilla.
    - felideon 7y ago
      What patterns are you talking about? Nothing specific to React, as far as I know, helps with maintaining a large codebase. Though, perhaps you mean the larger React ecosystem. But still, what patterns are you talking about? TEA/Redux? There's no reason why you can't use the same patterns with Svelte.
    - emerongi 7y ago
      React doesn't have some intricate patterns. It mostly advocates for a functional-style UI, where you do computation in the render cycle and keep state localized to a component. Svelte gives you the exact same tools. I've been building React-based applications for years now and have been using Svelte for some projects on the side and in my opinion both are decent tools. Some of the Svelte "sugar" is easily replicated in React, it's just that React doesn't provide those out of the box; on the other hand, Svelte has some "gotchas" that don't appear in React.
  - lhorie 7y ago
    > typescript I hear that this is something they are looking into adding support for
  - mvolkmann 7y ago
    Here is the issue that describes what the Svelte team is doing to add support for TypeScript: https://github.com/sveltejs/svelte/issues/1639 https://github.com/sveltejs/svelte/issues/1639
paulddraper 7y ago
It's perfectly fine if your most pressing issue with large bundle sizes/slow performance. If your most pressing issue is removing bugs from managing state, you will pass it by.
- ummonk 7y ago
  Right, and if your pressing issue is large bundle sizes/slow performance, you'd probably be using Preact.
- mvolkmann 7y ago
  If your most pressing issue is making managing state easier, you should run to Svelte! Take a look at how Svelte supports "stores", "context", and state within a component. Those are so good that I predict nobody will ever feel the need to write a state management library for Svelte. It's already very easy!

mvolkmann 7y ago

Not true. That section mentions several other "Whys" including this: "Svelte dramatically simplifies component and application state management. Contributing features include context, stores, and module context, each of which is covered in detail later."

lhorie 7y ago

The way I see Svelte is as a one-stop-shop type of framework (similar to Angular and Ember in philosophy), but exclusively for client-side concerns, and aggressively geared towards leveraging standard web idioms (HTML that looks like HTML, CSS that looks like CSS, JS that looks like JS), whereas most competing frameworks extend grammars in various non-standard ways (Angular's "HTML" isn't parseable via a standard HTML parser, and React's "JS" requires a parser that supports JSX - and then there's the whole CSS-in-JS thing where people get tripped up by double quoting and camel casing rules). Said frameworks typically also have steeper learning curves due to framework-specific APIs. Where I think Svelte falls a bit short (given its flavor of comprehensiveness) is that while it concerns itself with strictly client-side things like in-memory state and animations, it offers nothing for sorta-server-related things like data fetching or routing, and you're left to find libraries to fill the gaps (similar to how you would in React). I feel like the bigger frameworks are up to something DX-wise, with providing more integrated/idiomatic ways of interfacing between subsystems (e.g. getting a data fetching API to talk to a state store, or making routing aware of them). Gluing subsystems from different libraries adds weight to application space code (see e.g. react-redux vs Vue) and at some point this starts mattering (usually during maintenance phase). Maybe Svelte's middle ground is your cup of tea, but obviously YMMV a lot.

jeremyjh 7y ago
Have you looked at the Sapper project? I think it adds a lot of what you are looking for. It’s basically a next.js equivalent.
- lhorie 7y ago
  Superficially. It does feel very much like Next.js, but I feel that direction sort of misses the mark, especially coming from a try-to-be-as-transparent-as-possible angle. There's still no opinionated way of doing data fetching (meaning one is free to shoot themselves in the foot trying to chase trends) and for doing non-trivial server-side things, you're basically dealing w/ raw req/res, which tends to devolve into an unstructured mess if the framework doesn't provide guidance (which neither Next nor Sapper do IMO). For me personally, it has one other showstopper (its file naming convention is not compatible w/ Bazel)