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).
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.