wirahx
That being said, I tried to sign up, and it broke horribly, and it looks like it was knocked out in 5 minutes, so my desire to give it access to my production codebase is fairly minimal.
Vue suffers less from this issue, as you'll well know, and Svelte doesn't suffer at all.
The same can be said for people being skilled in it. It takes longer to skill up on React, less on Vue, and the least on Svelte.
A lot of people end up using React because of these invented scenarios, when in reality, building something rapidly like a start-up is significantly quicker with Svelte. Trust me, I've done it, and we're post Series A, and now reaching profitability.
Svelte for Apps. Svelte for Sites.
it's not. it's html. incrementCount is a pointer to a javascript function.
> Or what about this… is this JavaScript? > $: doubled = count * 2;
Yes. $: is a javascript label. We use it to indicate that a function should be reactive - if the count variable changes, the right hand will be rerun and double updated.
> <button on:click|once={handleClick}> Click me </button>
html again. the |once is a modifier to click which detaches the handler after a single use. It's a directive in the html markup (still valid html) which the compiler picks up and converts into node.removeEventHandler.
you can on on:click={() => toggle()} in svelte which is more similar, but it isn't parsed and executed, it is a pointer to an anonymous function which is directly executed.
on:click={toggle()} in svelte would run the function immediately (probably not what you want) and return the result as the handler for the on:click
so quite different, really.
SvelteKit is designed to let you build anything at all with Svelte.
ElderJS, JungleJS, Primo etc, are all specialisms.
Your comments are fair, but misguided.
Everything we do is written in Svelte + Sapper, not just our site, but all the backend apps as well that we use for admin + providers.
Not all of us think JSX is a great thing. The "templating" language in Svelte isn't really a templating language at all, it's just Javascript with some (unavoidable) helpers. It takes about 2 minutes to learn since there are really only maybe 5 helpers.
If a fresh user were to spend a few minutes learning React (or Preact), Svelte, Vue, or Angular, they'd almost definitely pick the terse and simple API of Svelte, or Vue, over the others. I've in fact tested this with a number of Junior and Senior developers.
Every language has downsides and upsides, some people find interpreted languages easier to hack around with than compiled ones, but the sheer speed of Svelte's complilation (especially when you try out the new HMR stuff) really excludes Svelte from this anyway.
Your other point is about every component having it's own runtime. This also isn't correct. Have a look at the code outputted from the REPL to see the "runtime" (which is just a set of shared functions in pure javascript) being declared. These are global to your entire Svelte app. It's as close as Svelte gets to a runtime, and it's shared.
As for changing data somewhere and looking how it all renders differently, that's what the Store is for. It's a cross-component store of data, and if you change it, dependends will render differently.
It's not that there's no merit to your article, it's just that a lot of it applies to most development languages, and it would be silly to call them all unappealing. Upsides and downsides, that's all. And my personal feeling about interpreted frameworks like React or Preact is that they offload the downsides to the user, which is unnacceptable.
https://github.com/6eDesign/svelte-calendar
As for the other components, as the ecosystem grows, these things start to appear. The advantage to Svelte is that it's super-easy to integrate any vanilla component into, much more so than other frameworks. You can totally do away with nonsense wrapping projects, and just add the component verbatim.
Also the component model isn't "hacky". It's logical, unopinionated and straight-forward. I don't know how much you know about Rich Harris but he's not one for producing "hacky" public APIs.
I learned to use Svelte (granted, v1), in 45 minutes, and build something using it. I guarantee that a developer won't need 2 weeks to become comfortable in it.
As for 3rd party libraries - it's ludicrously easy to integrate anything you want with Svelte. I've built wrappers for Vue and React before, and I can safely say that it isn't necessary for Svelte. Things just work.
I'm a competent all-round developer, but I (was) more comfortable on the server-side than the client-side. However, Svelte has been the first framework (I've used Angular a lot, Vue a lot, and React somewhat) where I've felt fully comfortable working on the client-side too. It's clean, understandable, fast, and it makes sense. It's easy to maintain, and scale my frontend, whereas I've not felt that when I've built similar sized applications with other frameworks.
Svelte, logically, makes sense to me - the API is consistent and sensible, and I can often take a good guess at how to do something without reading the docs. Having no client-side dependencies makes it an absolute ideal fit for distributable libraries too - people can just "slot" our widgets into their site, in one line.
My criticism, as somebody else voiced, is testability. I'm a huge fan of testing, and I generally look for libraries and frameworks which are test-first/test-centric - for instance I use Hapi on the backend, not Express, for this exact reason. That's not to stay that Svelte isn't testable, it's just not been a focus of the framework, and I'd really like it to be. I've had success using [https://github.com/testing-library/svelte-testing-library](h..., and it works well.
I originally built Beyonk in Nuxt but I switched over to Svelte as I had prior knowledge of it, and felt like Vue wasn't quite as nice to code in. After doing so my code was much terser, cleaner, and easier to understand, so I stuck with it and built out the other applications directly in Svelte.
I don't think I could face using any other framework after using Svelte, it would feel like a backwards step. Single-file components are a massive bonus, and scoped styles... I don't know how I lived without them.
It's worth mentioning that when I first learned Svelte (v1) it took me 45 minutes to get the basics and build what I wanted to build. I think the current v3 API could be learned from scratch by a decent frontend developer within a day. That learning curve is drastically lower than that of any other frontend framework I know, and for that reason I'm not concerned about hiring for Svelte.
I think that's about it really. I really enjoy, and in fact, look forward to writing code in Svelte on a daily basis - and for me, that was historically something I never expected to say!