> Svelte code looks like JavaScript, CSS, and HTML, but its compilation stage takes that and munges it totally out of recognition into a tangle of reactive JS code.
Isn’t that fairly similar to React? I tried to understand some React on a page, and there is no way the JavaScript events or HTML updeates have any obvious connection to the code causing it.
But it's still the code you wrote, it just executes using the React runtime. Svelte actually rewrites your code to inject the Svelte boilerplate to get it working.
You typically write in one language and the compiler produces something lower-level out of it. In this case, you write vanilla JS and get (different) vanilla JS.
I argue that transpilation done by tools like Svelte or Babel is just compilation in a broader sense. I don’t see the seemingly relevant difference here.
You can write and run React/Preact based applications "as is" without using a transpiler like Babel (you just typically do to minify code and use more fancy javascript features). You can't run a Svelte based application without precompiling it using the Svelte compiler.
The essential feature of it is that it’s a compiler. Things in general get easier to debug over time as they get improved, the basic concept is actually a very powerful. I’m a fan of svelte for the small things I’ve tried it on; there’s always growing pains with learning curves.
Yeah, I do agree. That was not a critic of Svelte, just a comment about that there is a difference between compilation (Svelte) and transpilation (Babel).
I do use Svelte in every day job myself and prefer it to React (which is also great) just because writing Svelte "feels" like what Javascript has intended to be.
in comparison to what comes out of some webpack things I've looked at, yes it looks more readable. Offhand I don't agree with all their undefined lets there, but not a big issue either.
All those undefined lets are part of how Svelte components are constructed, and it can’t be done in any other way across the board. It may not be how you’d write such things manually, but for compiler output it’s sane. For simple cases like that one, the create (c) lifecycle method could essentially be shifted up into the let statements, but for some more complex cases that couldn’t be done, and if hydration is enabled it definitely can’t be done, because those variables can then be filled in one of two ways, creating (c) new nodes or claiming (l) existing nodes.
Are you kidding? It's at some point understandable when looking a minute at it, but this only a small hello world app. How will you be able to understand the generated code with a few dozen components and much more logic?
Great demo, even though I don't agree that it is easy to understand.
I have to try a larger program and see what it emits but I don't think junior developers will think it is easy. And trying to find your bugs if you connect things to the wrong component/part might be very hard to spot. I still think React dev tools are way nicer.
Sure, but are people looking at the artifacts that other frameworks generate? I think generated code is mostly interesting to the framework devs themselves and not to most others.
as I said, seldomly, but I did have to spend several days recently looking over webpack output to figure out what was wrong.
Also I remember one time in a previous consulting job a developer who was not very good had used an instruction to not show something if env was prod, but forgotten to end if, which caused module compilations using the horrendous babel/gulp setup to break in the middle of one module but finally start working again in another one, meaning that there were parts of the applications that were trying to refer to a module # 31 or something like that which was no longer present in the big object that was put out of compiled modules. (this is like 3-4 years ago now)
Since it was not showing something if env was prod, if env was dev no problem.
That meant I had to take the output of the prod build and walk through comparing with dev build to figure out what modules were not compiled in, and then figure out from that were the likely error was and then looking in those places with git blame to say what was done wrong.
In React, they're basically all JavaScript. Even for JSX people can imagine themselves as compilers, and can easily write down the JavaScript output by hand - it's totally predictable. It's really a super thin layer of DSL with nothing interesting at all.
In Svelte, people cannot do that for a fairly small application with only hundreds lines of code.
I would say I could theoretically write down the JS output by hand, but not easily - for any application likely to need debugging. Also in most cases you've got WebPack there, and I'm not sure if I can really write down that output by hand.
> In React, they're basically all JavaScript. Even for JSX people can imagine themselves as compilers, and can easily write down the JavaScript output by hand - it's totally predictable. It's really a super thin layer of DSL with nothing interesting at all.
No it isn't.
Jsx gets transformed into js that calls react code. No one is writing out that react code, which is pretty much what svelte does.
For react there are very good dev tools that shows you the component tree and the current state.
Barring that it is generally just a lot of components that "writes a view" from the current state. You can also easily break inside the render function and see what properties were sent to the component if you don't want to use the dev tools.
I stumbled on Svelte after using both react and vue. I have to say Svelte is a breath of fresh air and a pleasure to use, especially with a rails 6 app using webpacker.
I’d recommend you check Svelte out as it will only take 20 minutes for you to get your head around it. This is a far cry from react.
This was the same thought I had about Vue when I first used it.
I knew vanilla javascript - Vue is vanilla javascript.
I knew HTML and CSS - Vue's component-based approach looks exactly like HTML.
It didn't take more than 20 minutes to get some code running using Vue and it made me significantly faster.
Then I stumbled upon Svelte and after using it for a day, I asserted it won't make me much faster and I'd have to learn yet another tool.
That's why I stuck with Vue, and then I discovered Vuetify and Nuxt, awesome tools that made my life even easier. I really can't draw a parallel between Svelte and Vue in terms of "better", so I started using my subjective feeling to justify my decision of going with a tool.
Subjectively speaking, I don't like Svelte. I don't have a solid, objective reason except this one: I really don't want to abandon 3 years of work I've put into projects that are based on Vue and TypeScript and go with Svelte without obvious gains.
There's nothing so different that it'd justify yet another downtime in order to swap the toolset so I can satisfy my peers online who approve or disapprove my choice of tooling.
Every new paradigm you look will feel like a breath of fresh air. However, I would strongly recommend striking a balance between shiny new syndrome and shipping things, the former can spiral into endless level of choices.
This was actually one thing that drew me into React from the beginning, the api was so small and it was very easy to understand. I could start and be up and running very quickly and also learn most of the api fast. Some solutions are very easy to start with but then you have to learn more and more and it takes a lot of time.
I think Vue was like this in the beginning. You could just start with simple data binding but for a real application you should switch to VueEx and you could start with without a compile/transpile step but if you had a serious application you probably needed that anyway.
I understand the author's claims to be "Svelte makes it hard to debug the compiled code, compared to plain-old uncompiled JavaScript" and "the Svelte runtime architecture makes it harder to observe the system as a whole, so debugging is harder".
I think the article would benefit from specific examples of where this caused a problem, and if e.g. whether the claim about "compiled code hard to debug" applies to Svelte in a way that it doesn't apply to TypeScript, Babel, etc.
The likes of TypeScript, Babel and JSX are providing a simple source-to-source transformation that leaves the structure untouched, broadly just changing the exact syntax employed. (I exclude any transformation of async code to not use async/await syntax; that one is a more involved transformation.)
Svelte is not like that. It’s unequivocally a compiler, doing much more involved transformations. If reactivity becomes involved in your debugging efforts, it can indeed be harder to pin down than in plain old JavaScript—depending on how that JavaScript was written, of course.
Compared with the likes of React? I have no real idea, I’ve never used React seriously. If the issue gets involved with the depths of React or Svelte, remember that there’s a lot less of Svelte, which may make it easier to debug. But for some of the sorts of problems that could occur, I would expect React to be easier to debug, because the bit that’s your code is essentially just plain JavaScript.
Agree with parent comment. I don’t get the sense from reading the article that the author even used Svelte much — it sounds more like they just read the marketing.
Would be great to see some code examples which exemplify the problems that the author is talking about, and compares it to alternative frameworks. Currently it's only about half a blog post.
Not sure why the author points out that Svelte isn't JS/HTML/CSS then goes on to recommend Preact over React. Preact isn't React either. If using Preact were caveat-free, React would be redundant.
I don't think there is anything bad or wrong about using preact. I gave it a shot and for the most part it worked really well. I think the only bad thing I noticed was that not everyone supports it (or at least some parts of it).
I ended up switching back to react due to the fact the react router coupled with typescript didn't work with preact. It's a known issue, and one that's kind of hard to get around if you want to use react router (which my code was already written with). That being said, there are routers that work with preact and typescript, just not react router.
Preact is great by itself, and works very well. All the advantages are true, it's fast and about 10x smaller than React [1]. It's GREAT for super-small interactive apps that need to be fast.
But if you try to use it as a drop-in replacement for React [2] and use a lot of third-party React components, Redux, React Router, then you might run into incompatibilities. React is very large and some components rely on obscure behavior, sometimes bugs. You'll have to do some deep diving and opening PRs in third-party repos, and a lot of those people will even deny those PRs.
But honestly: if you're gonna use third-party stuff, Redux, React Router, all that... is the ~38kb it saves really all that much?
If you're doing startup-style development where number of dependencies don't matter, go with React. If you're aiming for an app with only 30kb or 50kb of gzipped Javascript, maybe try Preact.
I'd it's actually more of a competitor to Svelte or to VanillaJS, not to React.
--
[1] 3750 vs 42623 gzipped for the UMD, last I checked. Used the UMD production dist of both of them. Used React+React-DOM concatenated for measuring React.
[2] Sure, maybe they should drop the compatibility line from their "sales" pitch. It mostly works fine, but it's a hard position for them to be in.
I'm not the writer of the post, but what I understand is that Svelte is a super-leaky abstraction mostly because the compiler's output is unpredictable.
JSX (that most React-esque libraries use) is basically a syntactic sugar for function calls with objects - so the output is fully predictable.
One of Svelte's selling points was that it abstracts complex state management by compiling JS down into DOM API calls - but that abstraction is leaky and it's hard to debug why something's not working when it's expected to be.
Well, React diffs the VDOM and decides what elements to update on runtime; Svelte decides the elements to update on compile time. That's the difference (and the meaning of 'compiling JS down into DOM API calls').
That's not true. I've been fighting with React rerendering every element of a long list when I change one element and update the context state. For some reason React rerenders everything, even when the keys are set and the references are the same.
The only recommendation I got is to use React.memo, which still rerenders every element, but from some internal cache.
I don't use context so I don't know if this is true or not. It might think it has to re-render since the context could affect anything below a component. It should however use the virtual DOM to diff first and not update the actual DOM more than needed.
For class components in react you also have a special method shouldComponentUpdate that you can write to optimize things. But I feel we are into performance details now, it doesn't make the code hard to understand. You updated a value in the context and some component re-renderd, hopefully with the correct output.
I'm a C++ developer, not a frontend developer. I can debug C++ executables, because of debug symbols and gdb. I generally don't need to know any assembly for debugging.
If Svelte is compiles down to JS where the connection between the compiled down code and the source code is unclear then maybe they need similar tooling to address this.
I've been testing Svelte for a project, and it seems to generate good source maps. In the Firefox Dev Tools, you can just breakpoint on .Svelte files with no issues.
Debugging the svelte compiled code is easy though, it has an order of magnitude less indirection and layers than equivalent React code. Ever got a stack trace in a react event handler? 30 stack frames. Svelte handler? 3.
This is one of the reasons Svelte is much faster than React.
This is one of the reasons Svelte is much faster than React.
Possibly an unpopular opinion here on HN, but if the framework is actually making a difference to the speed of your app then you've probably made some horrible mistakes in your part of the code. React apps aren't slow because of React. Vue apps aren't slow because of Vue. Svelte apps aren't slow because of Svelte. And so on. Framework developers work hard not to get in the way, and they do a damn good job. If your app is slow then it's very likely to be your own fault. There are React apps out there that handle tens of thousands of DOM elements at once at a solid 60fps. React doesn't automatically mean slow at scale. Likewise I could write a Svelte app that's struggles along at 5fps. Svelte doesn't automatically mean fast.
There are edge cases where an app is really pushing what the browser can do, and that's where the choice of framework really makes a difference. In those cases which framework is the right choice depends on the app - it's not simply a case that X is always better than Y. If you're updating tons of DOM elements then Svelte is a good choice. If you have lots of DOM elements but you're only updating a few then React (or any virtual DOM based framework) probably works better. But if your app is a glorified To Do list as so many really are, there's no excuse for it to be slow in any framework.
Broadly I agree with you, though my personal opinion is that Svelte is also more pleasant to use, so it really only loses out to React in ecosystem. I've also used React for years and have used it much more than Svelte, so I may be biased from seeing all the warts of React.
Billions of people around the world are coming online in recent years, and they're using budget $100, underpowered android phones. Every little difference in performance is magnified for them.
I sort of agree - for now, at least. The tooling around React for debugging is pretty great. React Dev Tools lets you easily debug your component tree. And the underlying source is pretty much what you wrote (JSX doesn't really get in the way here).
I've been working with some older Angular (1.5) code recently and it's been an absolute nightmare because the debugging experience is just awful. Error messages are unusable at times. Failures simply get swallowed. It's difficult to debug bindings. But with React, I don't have to deal with any of this (though much is because of the simpler API).
You see a similar thing with Redux. It's very straight-forward to debug, and there are similar dev tools. Even Apollo has dev tools for their GraphQL library. And I think this is what sets these things apart and makes them so much more popular than similar libraries - the debugging experience. And while I haven't used Svelte for a project, I'm getting the sense that the debugging experience is going to be painful. It may be great _most of the time_. But I don't think that's going to be enough in the long run. Just my opinion.
This reminds me that I've got to draft an email on why we should change our three quarters complete project from using Vue to using Svelte (even if it is not Typescript friendly yet).
Not that I'm actually intending to do that. I'm just going to send it to our front-end developer on April 1st and watch him freak out.
The author seems to start from the premise that the purpose of the Svelte compiler is to generate code for him to look at and fiddle with. Surely that is where he's going wrong? If it's merely a question of debugging, source maps are the answer, no?
What I get is "Svelte is Unappealing" because the compiled code doesn't look like my code. If you minimize JS in general, it doesn't look like your code. SourceMaps are provided for this purpose.
Unappealing because of the approach taken for compilation is not a good reason for me not to recommend Svelte. I will recommend Svelte or any library that helps cut down on the cognitive overload on trying to get your application up and running and provides a multitude a ways to debug state.
The API surface of Svelte is very tiny allowing you to do what you need to do without running into limitation. I've never had to complain about Svelte not exposing something, but sure have for React. API on React has changed multiple times causing modest rewrites of components. I have found the debugger with Svelte's @debug marker very helpful during development.
I'm glad I can use components compiled with Svelte in any application without bringing in a whole runtime and vice versa. It makes sharing natural and much easier than React, Angular, etc.. I dislike any frameworks (front and backend) that shut the door on previous work and make you conform to that world. Countless times I have questioned why do I need to build a component that implements pre-react work in React in order to use it in a React application. I should be able to bring in any library that works on the web today and use it without having it conform to "The Framework". I haven't had this trouble with Svelte.
I can agree that Svelte is early and there will be offspring that will likely leap frog and build on the ideas of Svelte.
You can use useRef in React to get a DOM node and pass it to other parts if needed.
Saying that every framework should be possible to combine with every other sounds very nice but probably impossible. Unless you restrict what you can do in a framework a lot. Most frameworks has components that has an api and a life cycle. Since frameworks have different api's and life cycles they are hard to combine in one application. Not impossible but hard.
I have a feeling this is somewhat true for Svelte also. How would I how to update a state inside a Svelte component from the outside?
There is a standard for components, Web Components, but it did not exist when Angular and React was created. It also works in a different way and don't solve the exact same use cases.
So your overarching point is that compiled languages are unappealing. Obviously, this isn't correct.
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.
Sorry tangent, but been working w/ Svelte a long time. Can you tell me about this:
> especially when you try out the new HMR stuff
I tried setting up HMR w/ Sapper but couldn't figure it out. Using Rollup. Are you referring to WebPack? Happy to take offline. Ping me on Discord if you want: @arxpoetica
66 comments
[ 3.2 ms ] story [ 139 ms ] threadIsn’t that fairly similar to React? I tried to understand some React on a page, and there is no way the JavaScript events or HTML updeates have any obvious connection to the code causing it.
https://svelte.dev/repl/f104bac93c9c48f5bd18322e3b9b9425?ver...
I have to try a larger program and see what it emits but I don't think junior developers will think it is easy. And trying to find your bugs if you connect things to the wrong component/part might be very hard to spot. I still think React dev tools are way nicer.
Also I remember one time in a previous consulting job a developer who was not very good had used an instruction to not show something if env was prod, but forgotten to end if, which caused module compilations using the horrendous babel/gulp setup to break in the middle of one module but finally start working again in another one, meaning that there were parts of the applications that were trying to refer to a module # 31 or something like that which was no longer present in the big object that was put out of compiled modules. (this is like 3-4 years ago now)
Since it was not showing something if env was prod, if env was dev no problem.
That meant I had to take the output of the prod build and walk through comparing with dev build to figure out what modules were not compiled in, and then figure out from that were the likely error was and then looking in those places with git blame to say what was done wrong.
In Svelte, people cannot do that for a fairly small application with only hundreds lines of code.
No it isn't.
Jsx gets transformed into js that calls react code. No one is writing out that react code, which is pretty much what svelte does.
Barring that it is generally just a lot of components that "writes a view" from the current state. You can also easily break inside the render function and see what properties were sent to the component if you don't want to use the dev tools.
I guess Svelte lacks extra tools.
I’d recommend you check Svelte out as it will only take 20 minutes for you to get your head around it. This is a far cry from react.
(honest question)
I knew vanilla javascript - Vue is vanilla javascript. I knew HTML and CSS - Vue's component-based approach looks exactly like HTML.
It didn't take more than 20 minutes to get some code running using Vue and it made me significantly faster.
Then I stumbled upon Svelte and after using it for a day, I asserted it won't make me much faster and I'd have to learn yet another tool.
That's why I stuck with Vue, and then I discovered Vuetify and Nuxt, awesome tools that made my life even easier. I really can't draw a parallel between Svelte and Vue in terms of "better", so I started using my subjective feeling to justify my decision of going with a tool.
Subjectively speaking, I don't like Svelte. I don't have a solid, objective reason except this one: I really don't want to abandon 3 years of work I've put into projects that are based on Vue and TypeScript and go with Svelte without obvious gains.
There's nothing so different that it'd justify yet another downtime in order to swap the toolset so I can satisfy my peers online who approve or disapprove my choice of tooling.
When I am writing React I am writing Javascript (usually a bit obscured with JSX).
With Vue a large part of functionality is in v-directives.
That doesn't change the fact that Vue is easier to learn for those new to webdev than React.
Students who just started learning Javascript can usually pick up Vue but I am yet to see someone with little JS experience pick up React in a hurry.
I think Vue was like this in the beginning. You could just start with simple data binding but for a real application you should switch to VueEx and you could start with without a compile/transpile step but if you had a serious application you probably needed that anyway.
I think the article would benefit from specific examples of where this caused a problem, and if e.g. whether the claim about "compiled code hard to debug" applies to Svelte in a way that it doesn't apply to TypeScript, Babel, etc.
Svelte is not like that. It’s unequivocally a compiler, doing much more involved transformations. If reactivity becomes involved in your debugging efforts, it can indeed be harder to pin down than in plain old JavaScript—depending on how that JavaScript was written, of course.
Compared with the likes of React? I have no real idea, I’ve never used React seriously. If the issue gets involved with the depths of React or Svelte, remember that there’s a lot less of Svelte, which may make it easier to debug. But for some of the sorts of problems that could occur, I would expect React to be easier to debug, because the bit that’s your code is essentially just plain JavaScript.
For myself, I choose to use Svelte.
The author isn't recommending Preact over React. He's recommending Preact over Svelte.
If one is already looking at Svelte because it's small (and a lot of people are), then Preact makes a lot of sense.
React is fine if size is not a constraint, of course.
I ended up switching back to react due to the fact the react router coupled with typescript didn't work with preact. It's a known issue, and one that's kind of hard to get around if you want to use react router (which my code was already written with). That being said, there are routers that work with preact and typescript, just not react router.
I say give it a try and see if you like it.
Also you can take a look at this for a more in depth comparison https://preactjs.com/guide/v8/differences-to-react/ (at least between preact and react.)
But if you try to use it as a drop-in replacement for React [2] and use a lot of third-party React components, Redux, React Router, then you might run into incompatibilities. React is very large and some components rely on obscure behavior, sometimes bugs. You'll have to do some deep diving and opening PRs in third-party repos, and a lot of those people will even deny those PRs.
But honestly: if you're gonna use third-party stuff, Redux, React Router, all that... is the ~38kb it saves really all that much?
If you're doing startup-style development where number of dependencies don't matter, go with React. If you're aiming for an app with only 30kb or 50kb of gzipped Javascript, maybe try Preact.
I'd it's actually more of a competitor to Svelte or to VanillaJS, not to React.
--
[1] 3750 vs 42623 gzipped for the UMD, last I checked. Used the UMD production dist of both of them. Used React+React-DOM concatenated for measuring React.
[2] Sure, maybe they should drop the compatibility line from their "sales" pitch. It mostly works fine, but it's a hard position for them to be in.
JSX (that most React-esque libraries use) is basically a syntactic sugar for function calls with objects - so the output is fully predictable.
One of Svelte's selling points was that it abstracts complex state management by compiling JS down into DOM API calls - but that abstraction is leaky and it's hard to debug why something's not working when it's expected to be.
The only recommendation I got is to use React.memo, which still rerenders every element, but from some internal cache.
For class components in react you also have a special method shouldComponentUpdate that you can write to optimize things. But I feel we are into performance details now, it doesn't make the code hard to understand. You updated a value in the context and some component re-renderd, hopefully with the correct output.
The more convoluted and lossy the transformation between that code and the final code that runs, the harder things are to debug.
If Svelte is compiles down to JS where the connection between the compiled down code and the source code is unclear then maybe they need similar tooling to address this.
This is one of the reasons Svelte is much faster than React.
Possibly an unpopular opinion here on HN, but if the framework is actually making a difference to the speed of your app then you've probably made some horrible mistakes in your part of the code. React apps aren't slow because of React. Vue apps aren't slow because of Vue. Svelte apps aren't slow because of Svelte. And so on. Framework developers work hard not to get in the way, and they do a damn good job. If your app is slow then it's very likely to be your own fault. There are React apps out there that handle tens of thousands of DOM elements at once at a solid 60fps. React doesn't automatically mean slow at scale. Likewise I could write a Svelte app that's struggles along at 5fps. Svelte doesn't automatically mean fast.
There are edge cases where an app is really pushing what the browser can do, and that's where the choice of framework really makes a difference. In those cases which framework is the right choice depends on the app - it's not simply a case that X is always better than Y. If you're updating tons of DOM elements then Svelte is a good choice. If you have lots of DOM elements but you're only updating a few then React (or any virtual DOM based framework) probably works better. But if your app is a glorified To Do list as so many really are, there's no excuse for it to be slow in any framework.
Being small & fast enables real business use-cases that just weren't possible before, eg https://artemdemo.com/static/2f8acbe19c0ba4ec4d98e06e6b8fd85....
Billions of people around the world are coming online in recent years, and they're using budget $100, underpowered android phones. Every little difference in performance is magnified for them.
I've been working with some older Angular (1.5) code recently and it's been an absolute nightmare because the debugging experience is just awful. Error messages are unusable at times. Failures simply get swallowed. It's difficult to debug bindings. But with React, I don't have to deal with any of this (though much is because of the simpler API).
You see a similar thing with Redux. It's very straight-forward to debug, and there are similar dev tools. Even Apollo has dev tools for their GraphQL library. And I think this is what sets these things apart and makes them so much more popular than similar libraries - the debugging experience. And while I haven't used Svelte for a project, I'm getting the sense that the debugging experience is going to be painful. It may be great _most of the time_. But I don't think that's going to be enough in the long run. Just my opinion.
Has any other language needed this kind stack to support it?
Not that I'm actually intending to do that. I'm just going to send it to our front-end developer on April 1st and watch him freak out.
Unappealing because of the approach taken for compilation is not a good reason for me not to recommend Svelte. I will recommend Svelte or any library that helps cut down on the cognitive overload on trying to get your application up and running and provides a multitude a ways to debug state.
The API surface of Svelte is very tiny allowing you to do what you need to do without running into limitation. I've never had to complain about Svelte not exposing something, but sure have for React. API on React has changed multiple times causing modest rewrites of components. I have found the debugger with Svelte's @debug marker very helpful during development.
I'm glad I can use components compiled with Svelte in any application without bringing in a whole runtime and vice versa. It makes sharing natural and much easier than React, Angular, etc.. I dislike any frameworks (front and backend) that shut the door on previous work and make you conform to that world. Countless times I have questioned why do I need to build a component that implements pre-react work in React in order to use it in a React application. I should be able to bring in any library that works on the web today and use it without having it conform to "The Framework". I haven't had this trouble with Svelte.
I can agree that Svelte is early and there will be offspring that will likely leap frog and build on the ideas of Svelte.
Saying that every framework should be possible to combine with every other sounds very nice but probably impossible. Unless you restrict what you can do in a framework a lot. Most frameworks has components that has an api and a life cycle. Since frameworks have different api's and life cycles they are hard to combine in one application. Not impossible but hard.
I have a feeling this is somewhat true for Svelte also. How would I how to update a state inside a Svelte component from the outside?
There is a standard for components, Web Components, but it did not exist when Angular and React was created. It also works in a different way and don't solve the exact same use cases.
> Saying that every framework should be possible to combine with every other sounds very nice but probably impossible.
I said specifically that I disliked frameworks that want me to conform. I did not say that all frameworks should conform to me.
> How would I how to update a state inside a Svelte component from the outside?
How would you update a Web Component is the same way this works. https://dev.to/silvio/how-to-create-a-web-components-in-svel...
Rich Harris is an excellent speaker and it's worth seeing how Svelte approaches some things
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.
> especially when you try out the new HMR stuff
I tried setting up HMR w/ Sapper but couldn't figure it out. Using Rollup. Are you referring to WebPack? Happy to take offline. Ping me on Discord if you want: @arxpoetica