> 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.
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.
> it offers nothing for sorta-server-related things like data fetching
The obvious advantage of not including these kinds of things in the library is that it makes less assumptions about the data and communication model. Maybe my data source is a Websocket, a REST API, a GraphQL API, or some Electron IPC messages. Ideally, in my view, the rendering library doesn't care. It shouldn't have to understand all these things to render my view, and it definitely shouldn't assume any single one or two of them.
Yes, I created Mithril. I also co-authored Fusion.js[1], which - in contrast - is about as "big boy" as a framework gets (and mostly works w/ the React ecosystem, if you're curious). We use the latter at over 100 projects at Uber.
Mithril fits in a similar camp as Svelte, and it does offer APIs for HTTP requests and routing out of the box. I've worked on projects before where I literally only had Mithril as a sole dependency (and this was with supporting IE10).
Fusion.js solves a lot of complexity-at-scale problems but it does so at a trade-off of not being nearly as geared towards standards tracking as systems like Svelte and Mithril.
Mithril solves all those issues well except animations, where it's just OK.
Interestingly, even though the Mithril community seems to be a home to people who dislike JSX, Mithril supports it better than React does. You can copy and paste HTML into JSX with Mithril; all the attributes line up. Also Mithril doesn't try to improve elements like <select> and <textarea>; it's all standard.
In personal projects I use Mithril. For medium to large organizations I recommend React. That's because Mithril does everything better than React except for maintaining backward compatibility and attracting large numbers of job candidates.
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)
"Needing" is relative. I could make an app making nothing but raw XMLHttpRequest calls, but that only speaks to the capability of talking to a server. In that sense, sure `fetch` is "enough". But from a perspective of a complex application or a complex org, you may want specific properties to be true: for example, you may want that a request to a certain endpoint follows a predetermined schema, or that one can control the granularity of the response data, or maybe you want to abstract over things like streaming, retries or caching to name a few things.
Something that most frameworks struggle with, IMHO, is that they don't consider how coupled network is to the system and when you need to do something like bundle-specific translations in an SSR context, it's very hard to do it in a generic way without touching half a dozen unrelated parts of an app (meaning librarizing concerns that cross-cut across network boundaries is difficult).
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."
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.
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.
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?
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.
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.
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.
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!
Under the "Why Consider Svelte?" it only mentions bundle size and performance.