I am a big fan of Svelte - as a backend dev who is also responsible for writing frontend code, I saw a massive productivity jump when we moved our website from React to Svelte. But the premise of the article is just not true - you do need to fundamentally understand how Svelte manages the state of your pages. You need to understand how and when an update to the state in one location gets reflected elsewhere. Most of my time is spent trying to work out why state is or is not updating as I expect.
Not helping this, it's not particularly well documented. For example, recently I had to learn about the onDestroy function which accepts as an argument a lambda. The docs [1] state that the lambda is run when the component is "unmounted", but offers no further information about exactly how or when this occurs. There is no official documentation on all the various lifecycle stages of a component and how or when each transition occurs. I find myself simply relying on a lot of trial and error or asking in the Discord forum.
>But the premise of the article is just not true - you do need to fundamentally understand how Svelte manages the state of your pages.
I agree with this. Like the example in the linked article about reactive blocks: "Svelte automatically tracks dependencies, and you only need to label a code block as reactive ($:). It'll run the code any time those dependencies change."
There's a huge caveat to that, it only does that with primitives. Which might seem obvious if you've been a developer for a while, but not at all obvious if you are a new developer. React has always taken the approach of asking you to explicitly declare state and use special methods to update it (either with setState or useState when hooks became popular) for exactly this reason, whereas in Svelte sometimes you need to actually reassign a mutated piece of state to itself so it gets picked up by this system like `foo = foo`
I think it's a reasonable tradeoff, because most state can be stored in simple primitives like strings and booleans.
Regarding lifecycle methods and Svelte, it's literally based on the DOM. Is the component leaving the DOM for whatever reason? Then onDestroy will fire. The same as you can treat onMount as a callback that fires as soon as the component is added to the DOM.
I think part of where things get tricky is that Svelte and SvelteKit are so melded together, unless you're 1. only using Svelte and not SvelteKit or 2. Are doing something really advanced and complex, you probably don't need lifecycle methods. And even then, you probably only need onMount.
A custom onDestroy can be used to manually remove something from memory, but it's mostly not needed. I agree though the docs should be better.
I'm curious now, what disadvantages of React could outweight the entanglement of reactive state management and undocumented lifecycle. I could understand that you could have the same issues with state management if you were using MobX with React, but undocumented component lifecycle sounds crazy.
Out of the box, React provides much less than Svelte. Also the mental model of Svelte is one tenth of React. I was able to start building stuff after like 3 hours of reading Svelte tutorial. I have done the same with React several time and every time I left with “I kind of see how to do things but I’m unsure how to build larger things with this”.
but there are literally libraries on top of libraries to immediately provide in react what svelte might provide "out of the box". the best thing too is that these hooks are all open source - so you can either install a package directly, or pick and choose and install whatever hook you need.
idk, i'm dying on the hill that react is unopinionated for a reason, i think it can be morphed and molded to so many use cases
I agree, but what that freedom in reality often means, at least from what I've seen, is a patchwork of dozen libraries and dependencies that make large scale projects more complex than they need to be.
That's not the fault of React, but it is a consequence of it.
If you want something that's not "libraries on libraries," use Angular. And if you don't like Angular, you have proved my point, that the "integrated approach" is simply not good, because you cannot make your own decisions to improve parts you don't like. Hence why I said I use React and not Angular.
I said there was a reactive state model that you have to get your head around in Svelte, but this is still much easier and simpler to do than it is in React in my experience. I'm not trying to pursuade anyone either way but I do want to dispell the notion that the mental model of Svelte is so straightforward that there is nothing to "learn" as the article claims because that will eventually lead to disappointment. Like I said, I think Svelte as a technology is great, so I'd rather people had the right expectations if they are going to give it a go.
You should check out Imba. It is the sanest of the lot. The only issue is they have very few updates and the development is not transparent so it didn't spark much of a community.
I kinda find this a weird comment... you say productivity is way better than React but then go on to say you still sometimes need to resort to the Discord forum to figure out what is going on (!)
To be fair, React used to have a documentation problem as well, but at this point I think anything and everything under the sun is documented excruciatingly well.
Of course people will comment I'm shilling React, but, reading the top comment, its kind of like trying to shill Svelte but immediately coming up short.
My comment is mainly to criticise the article and specifically the original title (You Don't Need to "Learn" Svelte), not to advocate for either Svelte or React. Yes there is a state model that you need to get your head around to work in Svelte just as there is in React and unfortunately, that task isn't made easy by the official documentation. But like I said, I still much prefer Svelte and would choose it over react 99 times out of 100.
Having used Svelte on a large project, I found that it did scale reasonably well but that the usual problems did require effort and trade-offs. The two big ones for me were:
- Managing file size and complexity in the component-per-file paradigm. Having all logic for a complex component in one file makes it big, e.g. 1,000 lines, but splitting into multiple files introduces a component boundary and consequent state passing/event handling boilerplate.
- With tight coupling between a complex UI and complex domain objects/data structures, it becomes difficult to reason about data flow. There are multiple ways of binding the data to the UI -- props, stores, standard JS variables, and reactive statements -- but all come with trade-offs and none let you develop domain objects that are completely framework-agnostic without introducing repetitive boilerplate.
For certain types of app I actually really like the DX of writing a UI-agnostic app and then layering Svelte on top of it with event handlers. It's repetitive -- you have to manually listen to events from the domain objects and update local variables with assignments -- but it's easy to reason about and seems to scale well. A good middle-ground might be making the app aware of the Svelte store contract, which is also very simple, but I haven't tried this and the store syntax comes with its own idiosyncrasies (you can't do $obj.store, for example, because only the $obj bit is interpreted as a reference to a store).
I really like the look of the composition API in Vue 3 though I have not used it yet, it gives me hope for addressing some of the issues you mention. I wonder does Svelte have anything comparable?
> - Dependency injection - not sure what it is exactly as I'm not familiar with Vue, but I don't think Svelte has a concept like this
It's poorly named (holdover from earlier version of vue when svelte didnt exist and react didn't have contexts), but it's basically React/Svelte context API for passing data to children further down the tree instead of passing them through props or through a separate state management solution (e.g. vuex/redux).
Perhaps this falls into the repetitive boilerplate category you referred to, but if you want framework-agnostic domain objects that still work well with Svelte, create your own using the observer pattern.
Create an object with a subscribe method and whatever other methods make sense for updating its state. Svelte will treat it like one of its stores, and it will work with the $ syntax. It can be used with React via its `useSyncExternalStore` hook. It can be used with SolidJS via its `from` utility.
If you don't want to handle the set-up boilerplate, you could use another library like Effector or RxJS, but of course, that means another dependency. There is a gradual move to make something like this a part of the platform[1], but who knows when or if it will land.
As a hobbyist web dev using Rails, I am watching the JavaScript ecosystem from some distance - the mere JS experience I have is very vanilla or through StimulusJS/Hotwire.
For the 3 years I have played with the web, I have been seduced to dive into a framework that is "fullstack" JavaScript to learn the language that is seemingly everywhere and "here to stay".
I have seen dozens of articles like this one for all the major frameworks around - some not really maintained over time. I cannot find, in the JS ecosystem, the stability I know in the Rails ecosystem. I fall in a state where I search for objective arguments, hesitate, and end up not taking any decision.
For those who know better, what is your current bet for a JavaScript (or TypeScript for that matter) framework that will last* the next 15 years? Is Svelte on the list?
Highly unpopular opinion: by 2030, React will probably go the way of jQuery (i.e. a highly popular library that was once considered almost an "industry standard", but later ended up in a graveyard of projects, tutorials and articles).
Difficult to say what the replacement will be, but I suspect it will be some form of plain JS + MVVM architecture, with a VM (view model) with two-way bindings, possibly natively part of the DOM, or even the DOM itself being optimised and async-ed to a point where virtual DOM diffing and similar approaches are obsolete, and an M (model) basically providing a client-side interface for the server API with some level of local caching, and providing an event listener interface for the VM to update itself. You may recognise some of these features from much older libraries, but I think a lot of them will be available natively in browsers (hopefully standardised, or in a darker timeline, fragmented between major browser vendors).
Another possibility is HTMX-like partial updates getting more native browser support, essentially blurring the line between multi-page applications and SPAs.
2030 is an extremely long time horizon in tech years, so who knows what will happen by then.
By 2030 I think a more interesting possibility is WASM everywhere. Now all language ecosystems ask whether they want to provide some frameworks or DSL for their users to deploy to web.
Basically he says that we should use WASM for stuff like Figma (which already does use it) or other types of web apps while keeping the DOM for content based websites.
The last release of jQuery was last week. It's no longer popular, but still maintained and used.
Even if this happens to React, it means it will still be maintained and stable for at least another 15 year.
I also think React will evolve and adapt (see RSC which is kinda what you describe). The beauty of React in this aspect is that the scope is quite narrow so it can evolve, as it has done in the past.
COBOL had a release this year. Just because something is maintained for legacy applications, tells us nothing about is health/popularity for greenfield code.
I'm using Lit for the past 2 months after Svelte/SvelteKit for another 2 and although I liked sveltekit a lot coming from React, Lit tooling or lack of it is the greatest advantage in comparison.
Lit is a great tool to create your own framework while keeping it integrated with other lit-based frameworks and any other framework as it is based on custom Elements so it is an excellent way to write components that can be used together with React, vue, svelte. Another great advantage is that Lit already have top class UI libraries like shoelace, ui5, Lion and many more.
> For those who know better, what is your current bet for a JavaScript (or TypeScript for that matter) framework that will last the next 15 years? Is Svelte on the list?*
I don't know "better", but FWIW I just went through this same exercise and landed on TypeScript and Vue, with Vite as my build system. Vue is 9 years old (vs. React's 10), and I'm reasonably sure that I'm not going to need to learn a new front-end framework before 2040 unless I want to.
I think the jury's still out on whether Svelte will be around that long, although I'm rooting for it. IMHO, the key will be the ecosystem that grows (or doesn't) around it.
Agree, but my point was that choosing Vue today because it will still be around in 10 years doesn't mean much if it's no longer recognizable and you had to rewrite your code three times to get there.
Agree as well, but my point was that this distinction altogether is irrelevant because the world changes all the time. Just stick with what feels right, and it’s going to be okay. There aren’t really bad choices among the popular options right now.
Lindy effect (https://en.m.wikipedia.org/wiki/Lindy_effect) says that the best predictor for software longevity is how long has it been relevant already. So, React seems like what you want. It's considered "old" technology by the hype people, but I don't think you care since you said you're using Rails.
The problem is the part where you think about the framework instead of what you are building!
For 15 years: My bet is on React, see the amount of apps currently build on React, see multiple large companies backing it, see the #huge ecosystem, all the jobs. Even if it goes out of fashion we'll see another 15 years of it.
Other mentioning React will be like jQuery supports my point: Out of fashion, but well maintained and still used a lot. (Side note: Rails is also like that imo).
Svelte does an interesting thing with the compiler, but otherwise not that revolutionary, and in some parts questionable. In terms of longevity they have a ways to go.
But 15 year longevity seems like a strange criteria to me. Is the app you are building really that important that it will need to survive 15 years, but not important enough to update it to newer tech?
I think it's also good to realize that all the options are largely similar and only differ on details. It's a different flavor of the same thing. Learn one and you will be able to pick up the others very easily.
Is the app you are building really that important that it will need to survive 15 years, but not important enough to update it to newer tech?
I find that's not uncommon in large corporations. The app does what it does, and nobody particularly wants to rewrite it. It gradually both petrifies and rots, and yet a ton of workflows go through it.
For that scenario you want it in a framework that lasts, even if it's not the best one. Some poor schmuck has to keep it limping along, and then pass it off to some other poor schmuck.
Eventually the whole thing comes crashing down and you have to deal with Conway's Law -- the whole corporate structure has been built to reflect the scope of that elderly piece of software and everything cobbled to deal with it. You get to re-do it in the latest-and-greatest -- but hopefully one that will last another 15 years.
Comparing to Rails/Ruby is not really fair because Ruby’s popularity exploded due to Rails, especially in web context. As such both the primitive and the framework are closely tied (in web dev context).
Whereas JavaScript is a primitive, and frameworks have gone and come based on the needs of the time.
Depending on your web stack, you probably have a very different view of JavaScript. And actually I’d rather view it as that; JavaScript in the context of a web stack is just an extension of the serving framework.
If you say the backend is just a simple REST API, then you fall into the SSR or not camp.
If you’re not in SSR, I guess it doesn’t matter. But these days, things aren’t trending towards SSR.
So your question actually boils down to, which set of JavaScript libraries will be maintained for a given stack. So the answer is: the most popular JS framework for any established full stack web framework.
If not SSR though, I’d say react. Because it’s cheap and ubiquitous.
And I wouldn't call React a framework, it's a view library.
Let me explain.
While there was a new React router coming out every week in early 2010s, some teams picked a batteries included framework such as Ember.js and focused on productivity and shipping rather than bikeshedding which router to use or what folder structure to have.
And those teams have been upgrading their apps for over a decade since the early Ember.js versions (some even upgraded from before Ember was forked from Apple's SproutCore).
So do some Ember apps at Apple, LinkedIn, Microsoft and Heroku that have been going through this journey for years.
And they will carry on.
There's a new and faster rendering library out on the block?
That's easy. We'll just replace the rendering engine.
That's what Ember.js did in mid-late 2010s with Glimmer.js, where they dropped-in a complete replacement of Ember.js rendering engine with full backwards compatibility which was beating React in some benchmarks.
So frameworks such as Ember.js, Ruby on Rails and others will still be there in 15 years, alive, with people interested in productivity rather than tinkering keeping them fresh and alive.
View libraries? Yes, but in the same sense jQuery is today. It's there, it's being patched, thousands of sites use it, but there'll be better ways to do it.
There’s been more effort in the Ember community poured into telling us it’s not dead yet than into doing anything relevant outside the Ember community in the last decade.
Might as well have said Dojo and Knockout, it would have meant the same thing.
Because it's always be easier to learn and spin-up an Express.js or any front-end library with a single index.html and tinker away.
> than into doing anything relevant outside the Ember community in the last decade.
Quite dishonest, and not sure why you're turning this into measuring exercise, so I won't bite.
> Might as well have said Dojo and Knockout, it would have meant the same thing.
Someone should tell Apple, HashiCorp, DigitalOcean and Microsoft they're not cool anymore releasing new stuff in Ember.js, must pick a new JavaScript framework of the year!
Ember and Rails were both extremely popular at one time. They both went from web development darlings to being legacy products to support. There are still fanatics for both, but there are VB6 fanatics to this day too. Fanatics don't mean anything.
If you're going to call me a liar though you need to do better. What has Ember done but continually play catch up for years and years on end? Here, go look yourself: https://github.com/emberjs/ember.js/releases How many years do you have to scroll back to find anything that influenced anything outside of Ember? The last influential ideas might have been EmberObject to fill gaps in the Javascript language before ES6 became a thing, or the idea of Ember Data as a front end opinionated ORM, though that has mixed results depending on your backend team's buy in.
> Someone should tell Apple, HashiCorp, DigitalOcean and Microsoft they're not cool anymore releasing new stuff in Ember.js, must pick a new JavaScript framework of the year!
If we're going to suggest any dishonesty is taking place, it would be the implication that these companies are Ember shops and not just dealing with lamentable choices that happen to still be in production and too costly to replace.
I don't know why are you turning this into measuring exercise or some sort of iOS vs Android flamewar at who's better and who's done more?
It sounds personal for you.
React is more popular than Ember.js will ever be.
However this is apples to oranges, one is a view library, the other one is a batteries included framework.
I think you're a little out of touch if you honestly believe Ember and especially Ruby on Rails are legacy products. We have multibillion tech companies shipping 10+ years old existing apps and building new apps in both of these frameworks.
This mindset of branding stuff "legacy" because it's not trendy on Twitter or reddit is one of many reasons why JavaScript fatigue exists.
All while Ruby on Rails developers are one of the most happiest and productive web developers shipping stuff because they don't need to reinvent the wheel and solve problems that have been solved a decade ago. (p.s. I've never done RoR, I just understand what convention over configuration does to developer productivity)
If you want recent examples, go look at Apple TV web[1] built in Ember (even though I personally wouldn't use Ember for such a project) or Hashicorp building all their products in Ember and releasing their new Helios design system[2] in Ember just few months ago.
Again, these examples don't matter.
I've hired full-stack JavaScript developers, I couldn't care less if they've done React, Ember, Angular, Vue, Svelte or whatnot.
Because it'll take any proficient JavaScript developer a week or two to understand the concepts and structure of any framework or library above. They all do the same thing - render pages and wire up buttons to run network requests, I don't understand why people make it sound knowing React, Vue or Ember is equivalent to knowing C++.
It's all JavaScript doing the same thing slightly differently.
> What has Ember done but continually play catch up for years and years on end?
> How many years do you have to scroll back to find anything that influenced anything outside of Ember?
I can tell you about ember-fastboot, ember-engines, miragejs, glimmer vm, i18n, accessibility and other things Ember and Ember community have done to SPAs in the last 15 years, but again, why does it matter right now?
Stop measuring who's done more. There's nothing I can tell you that will change your mind, just enjoy whatever you use now.
As someone who loved Knockout when the only alternative was jQuery, I can't wait for it to die. Same for jQuery and any other library that we've found better alternatives for.
I'm surprised by the number of people swearing by React as if it's some holy grail of UI technology that will never die. Popularity is meaningful, but only for a while.
I don’t think React is the final way to do web development but there are tangible benefits to a large community of users that aging competitors want to pretend don’t exist.
Just like there used to be a jQuery plugin for anything you wanted, there’s probably a similar React solution for anything you want. Outside of React or Vue you’re often reinventing a wheel. It’s doable but not productive.
I am pretty sure in 15 years React and Vue and Svelte will still be used frequently. Unless everything gets replaced by AI.
We're approaching the diminishing returns when it comes to front end frameworks. All the big ones are decent. I don't feel a need to have a better framework.
My bottleneck is how fast I can write logic and CSS. With complex components a lot of time is spent on managing state correctly, implementing all the minute details that the designers came up with.
I think we are reaching diminishing returns in the current paradigm that was sparked by React, but the iterative nature of the web means that a new paradigm is bound to appear. I think there are a number ways this can go.
- Some older language or tech is upgraded and crosses over via WASM
- Immediate mode GUIs rendered with Canvas
- Heavier reliance on the base web standards without as much build processes. Either SSR like HTMX or an event driven rehash of MVC for SPAs.
15 years? No one will do webdev with a keyboard by then.
You'll be arranging UI blocks in augmented reality IDE completely powered by AI. AI will use WASM and upon request it will gladly convert to your language/framework of choice so you can view its source. Us old timers won't trust that it converted the code correctly for us to read, but the kids won't care. They'll just give it a new context/edge case examples, and have the AI rewrite everything on demand whenever they run into a problem. Looking at code will be outdated.
Rails itself is only 19 years old. 15 years is too long to talk about what will or won’t exist with anything like a concrete prediction. At best you can say that legacy systems will still be around. If you’re a hobbyist and you tinker with your personal site or app once every couple of years and you want it to last indefinitely, just make it vanilla JS. For everyone else, it’s not a big deal to do a rewrite every five years as part of the normal maintenance cycle.
> not a big deal to do a rewrite every five years as part of the normal maintenance cycle.
I see that mind often and it makes me very sad. 40+ years of computer science, bookshelves, many now must-read classics, written on software maintenance, and this is what we end up with: just throw it out.
I despise this mindset in other industries (electronics, phones, toys, furniture) where, instead of designing stuff to both last, and be repairable, we just buy a new couch, phone, or blender once anything breaks. And I dislike it even more in software.
I honestly cannot, an will not accept the common statement by random web agency that rebuilding this bakeries WordPress site from scratch, is cheaper than salvaging and repairing it. Nor that rebuilding some Rails backend in Go, or Nest.js the easiest. I mean: I know it often is the cheapest or easiest. But only because those in charge of the previous version never bothered about maintainability.
Read Programming as if People Mattered from 1991. Even back then frontend was a mess of spaghetti code that needed to be periodically tossed out. That’s just how frontend works. UI is ephemeral. The backend can be pure, crystal logic that lasts for decades or maybe centuries. The frontend is a rat’s nest of conditions that will get junked as soon as fashions change.
It’s the difference between manufacturing denim and selling jeans. The denim business is forever. The jeans business is constantly changing.
It's not always a bad thing. It gives you the chance to do it better.
When is the last time you looked at your work from 10 years ago and thought you'd do it exactly the same way today?
And the cost to destroy and rebuild software is so much smaller than other industries that produce things that exist in the physical world. Why not take advantage of that?
Rails is a niche that went through a hype phase 10-15 years ago. It's not going to die any time soon, but it's also one of these languages that hasn't as many job opportunities (especially outside of major tech hubs) as other stacks.
The amount of frontend JS developers is many times larger than the amount of Ruby on Rails developers so the fact that there is less "stability" is hardly surprising.
I believe you're thinking unstable as in "it breaks all the time". That's not it; it's that anything written before React Hooks were introduced is now squarely in the category of legacy code (https://react.dev/reference/react/legacy).
I think React is always going to be a big hitter. Someone else mentioned jQuery - I don't think that's the perfect comparison, because part of what made jQuery kind of obsolete is that the browser APIs improved to the point where it just wasn't needed any more - that's just not happening with React because browsers aren't looking to ship a whole framework. But the long tail of jQuery projects is a big thing, and I think that's going to be true of React as well, at some point in the future.
That said, I think it's becoming increasingly hard to see what value React specifically (as opposed to any other framework) is bringing to new projects. It's slow and heavy, but without the pre-made structure that you get from, say, Angular. It has a great ecosystem, but it's typically harder to integrate with non-React projects libraries.
I know Vercel/NextJS are pushing really hard to make the big advantage of React be server-side rendering, islands, suspense, etc - the idea that you can build your entire app in React, but shipping only the code needed to change the few pieces that actually get updated in the UI. There's some merit to this in that all your templating/rendering lives in one place (and you get to use frontend templating tools, which at this point are pretty good), but I think React is the worst framework to take advantage of this idea. Partly that's because it's just very big and slow, and shipping smaller bundles is going to have diminishing returns when React is already half your bundle size, but mainly that's because React doesn't really have the architecture for these sorts of situations. There is a big assumption in React that it controls the world, which makes things like nested island very hard, and means that you need to ship lots of rendering code even if the only thing changing on screen is a CSS class.
I'm talking a lot about why React isn't a good candidate for the future, which isn't really answering your question, but that's because it truly is the elephant in the room in these discussions. No-one ever got fired for choosing React, and probably won't for the foreseeable future, even if it isn't perfect.
My answer, though, is Vue. Personally, it doesn't do a lot for me, I just like JSX too much and find the excessive Proxy stuff too complicated. But they've got one big advantage over React right now, and that's that they have the right architecture: signals. Signals, when done right, are a great way of skipping a lot of work and VDOM-based updates by directly updating the changes attributes. For example, if you have a class name that depends on some data, and that data changes, you don't rerender the entire component, you just update the class name directly.
Currently Vue doesn't do that, but they're working on a new renderer that takes a lot of the idea from SolidJS, and that will drastically improve performance and decrease bundle size (they've released performance benchmarks that have Vue beating Svelte, although obviously take that with a grain of salt!). This is great for client-side rendering, but the best big improvement would obviously be to do less rendering overall. This comes back to Vercel and their big push for islands. One of the things you can do with Signals is, rather than do the whole SSR/hydration dance that Vercel are doing, is to ship only the signals (i.e. the application state and instructions needed to update the page). At that point, you don't even need a client-side renderer - everything just gets updated in the DOM directly. This is the direction that projects like QwikJS are going in.
Of the three big frameworks, the only one that's really in a state to take advantage of these advanced is Vue. The React team aren't interested in exploring signals right now, and while the Angular team are moving in the direction, there's a lot of legacy stuff there that's going to make large changes hard.
The other alternatives are smaller frameworks like SolidJS, Svelte, etc, but I think they're just too small to really get a huge amount of market share. They make great testbeds for new ideas, but are too nice overall.
That said, if you're interested in the craft of frontend development, give SolidJS a go. It's pretty much pure signals, but with a React-like interface. You can explore the compiled output and get an idea of what the compiler is actually doing, and the whole thing is amazingly lightweight and fast - only marginal overheads compared to vanilla code, but with a declarative structure.
I don’t think the article is a good intro to svelte or gives you much sense of using it. The title is positively incoherent.
You’d be better off going through the main site’s tutorial. And since you’d presumably be interested in building full web apps as well, take a look at the sveltekit site and docs as well.
The idea that there’s nothing to learn is nonsense. It’s not large and I think it’s straightforward, but there are various things to learn.
IMO, the strength is that you write your HTML in HTML albeit with a simple templating extension, the reactive JS/TS is in the same context, and the reactivity model is simple/predictable and performs well (at least in my experience).
Hey the author here, I totally agree with going through the official tutorial. That's what the article recommended tbh. The goal was to convince more people to give Svelte a try, as IMO, it's getting way less attention than it deserves.
Anyway, thanks for the feedback, I'm quite new to blogging and writing in general. Will definately incorporate your suggestions in future work.
Hey, totally agree with that, the article was an exaggeration to grab peoples attention and pull it towards the awesome framework that Svelte is.
I don't think there's ever going to be an abstraction that's both useful and has nothing to learn. The point is that the amount of stuff in Svelte you need to know before you start building real stuff is very minimal.
Posts like these tend to disappoint me. Seems like the author is really excited about it and wants me to have some kind of revelation about how simple Svelte is, but the first example with the "$:" raised so many questions... What is that $? It's a label? How does it know that the variable changed value? Can I have more than one $ if I import another file that uses it?
It also gave me a bunch of tiny snippets as examples, but that's never representative of a real codebase. How do you reuse these components? How do you deal with component lifecycle?
It peaks my interest, but kills it with a bunch of magic and unanswered questions.
Very clickbaity title, this is definitely not "just Javascript you already know":
<script>
import counts from './store.ts';
import {onMount} from 'svelte';
</script>
<button on:click={() => $counts.a += 1}>
Increment A ({$counts.a})
</button>
In that tiny snippet there's so many non-js things, like "where did that onMount go?", "why does $counts come from? is it from 'count'?", "how do events work?", "does the onclick update the value later on?", "can I do $counts.a++ instead? once? twice?" etc.
"It's just plain JavaScript," says the article, and goes on to describe the special syntax — the dollar sign, the bindings, the templating language, something called writeable...
"It's just plain JavaScript," say React advocates, and go on to describe the special rules — never invoke a hook under a conditional, assign keys to list items, remember to list all dependencies next to hook callbacks…
React is "simple", too, in introductory tutorials where you build a todo-list app. Does Svelte stay simple as your constraints and needs become complex?
In my anecdotal experience — no. We started with Svelte and quickly migrated to solid (which has it's own handful of headaches but is much more manageable). Svelte was originally designed for little pieces of interactive content (in the nytimes), and it scaled like that for us back in 2021
Not OP but I'll give my 2 cents. I much prefer Solid because it's explicit as far as which variables will be manipulated. However. I ended up usually using Svelte because it's so much less boilerplate than anything else.
So I guess it's worth first discussing ecosystem. Ecosystem is something I understand that people want, but we've generally avoided. Especially in react, there's a large worry about quality. Building something quickly that's taylor made for our business needs is much easier than parsing documentation, reading source code for QA, and then inevitably hitting an edge case. There are a couple instances where we did find ourselves missing an ecosystem (the first example that comes to mind is WYSIWYG editors), but for the most part we build it ourselves, and that's been fine. From what I recall of the Svelte ecosystem, it had a much more monolithic "this is how you do it" with the packages. By contrast, solid has a much larger focus on primitives — composing something you need from a set of modular tools. This also extends to our grievances with Svelte itself. I wish I could recall exact examples, but we transitioned 3 years ago and unfortunately I never recorded the exact issues. I do remember it distilled to a very similar problem. Things go great with the magic, until you hit some sort of problem that the framework authors did not anticipate, and you basically learn "you cannot do this". By contrast, solid gives you tons [0] of primitives. Almost every issue relating to state can be addressed with these primitives, and if not, you can easily compose your own (in fact, very few of the provided primitives are entangled with the core library. They themselves are built upon lower and lower level primitives).
Also, with Svelte there were a considerable amount of design decisions I disagreed with. For instance, the context API uses strings instead of imports as identifiers, which breaks intelisense. I guess they want it to feel monolithic and integrated, but it's just frustrating. How do I extend this context system in Svelte?
Everything really comes down to this fundamental decision between a "framework" and a "toolbox". Even the file structure reflects this. Solid, in some way, encourages small components — you can have multiple functions in a file, vs svelte where you can only have one. Each component in Svelte has significantly higher size overhead than solid, I suppose because you aren't supposed to have as many. In my opinion, the toolbox philosophy is much better equipped to handle the complexities of a large application.
Sorry for such a long ramble without concrete examples. As I said, I really wish I wrote this out 3 years ago when we made the switch.
As for Solid vs. React, there's plenty of discussions of this already. Aside from the much better performance, the solid model fixes almost all the footguns relating to state and rendering performance that react introduces, basically because it's closer to vanilla JavaScript (each function only runs "once")
e: I've checked back on this thread and I find myself agreeing with other people like gushogg-blake and spuz. Worth checking their comments out as well.
That is extremely helpful, even without many specific examples, thanks! It’s definitely something to be aware of at the start of a new project. If you anticipate the project will not get too large or complex, then Svelte is probably a good choice for the productivity and performance. But if it could grow over the years into something large and complex, then Solid’s primitives-focus and toolbox approach may be better.
I wonder if Svelte5 will retain the framework philosophy or move toward the toolbox approach.
> If you anticipate the project will not get too large or complex, then Svelte is probably a good choice for the productivity and performance.
Yup. If I found myself trying to hack together something a weekend I'd be willing to use Svelte again! It's really quite productive at the beginning. Plenty of times when you just want simple reactivity without any other mental overhead.
Of course not. The closer you get to JavaScript, the bigger mess you are going to make.
React's limitations is its greatest asset, it forces a team of engineers to stick to a common ground the must agree on: JSX, hooks, component life-cycle, etc.
React is one of the few popular libraries well known for it's lack of opinion. Every React project is different and it's hard to consolidate developers on how things should be done. If you want common ground you'd go for Angular. React is the exact opposite of common ground.
It does allow different ways of writing code and I agree that projects can be quite different architecture wise, but if I look at a component, I can be fairly certain that:
- Its return value is a some kind of UI (I know about contexts)
- Not using hooks, the variables in the JSX are side effect free
- Using hooks will trigger a state update or you can prevent one
- A re-rendered component re-renders the whole subtree
I meant that these few assumptions are shared in a project by every developer touching the project and they must work with these in mind. Abusing these will result in a rejected PR.
Can you still write bad react code? Absolutely, but at least I don't have to go back Adam and Eve to find what the hell is going on.
Recently I've really liked Vue's composition API. The whole business of refs, emits being the only thing you need is really nice. Not too much to learn. JSX is there too - the old Vue API was simply a non starter for me.
Remix with react (just for the Jsx) seems like the sweet spot for me. 90% html and Js apis, with minimal magic to keep things component based and dynamic. Feels like the good ol days of PHP and ajax forms
I hate the title of this. the quotes do so much heavy lifting.
I was hoping for a post about removing Svelte and embracing the simplicity of vanilla javascript.
Nothing against svelte.
This weekend I went through the svelte/sveltekit tutorial, and I can't wait to use it in a project (several in mind in fact). I haven't felt this stoked about a front end library, its simplicity and apparent minimal painfulness, since Rails
I suspect that, like rails, it is simple at first but then becomes quite complex as the project grows or you want to do something that goes against the grain of the framework.
Getting excited and then jumping all in on new frameworks has bitten me more than once.
Rails is an order of magnitude more complicated then Svelte/SvelteKit. There are so many conventions you have to know. Svelte/Kit isn't anything like that. It doesn't even come with an ORM.
That simplicity, and we could say the same thing for React, makes it the worse candidate for developing apps. The building blocks are so small that it is almost impossible for juniors/mids to write well-written/well-structured code.
I don’t get this narrative and Svelte isn’t the only community guilty of pushing it.
Granted, the bulk of the logic you will write using the framework is ‘just JS’ but that is true of most frameworks.
Most of the code you write in ReactJS is ‘just JS’ as I am sure is true for VueJS and god knows what else.
However, Svelte, as with all frameworks, has a learning curve.
Even the example pretty high up on the page is not ‘just JS’ nor is the JS used very standard, who on earth labels a scope with `$` in vanilla JS land?
If I saw that while doing code review (in a vanilla codebase) I’d be instantly asking what the purpose is and for a more self explanatory label than a dollar sign, if a label was even required.
Further down the page you get an example with a redux comparison using a hook called `writeable` which exposes a `subscribe` and `update` method. Neither of the three are standard JS.
I realise this sounds like I’m bagging on Svelte, I’m not. I’m actually quite intrigued and want to try it out. I just cannot deal with all the false claims of ‘it’s just JS’, ‘you know it already’, ‘there is no learning curve’ etc. when there clearly is a learning curve and it clearly is not ‘just JS’.
The framework is doing solid work and should be celebrated for what it is and not what it isn’t.
if anyone is wondering why i am perma supporting react and combating seemingly random react haters all throughout this thread, i have to say that i'm exhausted from sneaky anti-react posts popping up approximately every 2 weeks at this point
theyre always exciting and fresh at first glance, but if you dig into any real engineering or large scale use cases, 99% of the arguments fall apart. reply to this comment if you have doubts, i'll share my decade+ experience with counter arguments
if you stop and think for just a moment, a single moment, why react is the most popular frontend framework...
I sorta get it-- Svelte is simpler than React (at least at face value).
What I don't get is why as an industry we are hung up on this need to do so much with JavaScript. In the end, Svelte is an incremental improvement over the thing that came before it. It will remain so until Svelte++ or whatever comes next.
Great... but who cares? I wish we would spend more time thinking through new (or old) solutions to the problem we are solving. It's why HTMX gained some hype... but it's just the beginning.
Shifting the focus from JavaScript to HTML doesn't eradicate the problems. I enjoy HTMX, but I can't stand the current hype cycle regarding it being a revolutionary different take unlike those JS frameworks. You're just winding up doing the exact same thing that caused the React dilemma!
I don't think the answer is shifting focus to HTML. The answer seems to be in relinquishing some control back to the browser, but finding a way to make the experience smoother and add interactivity as needed without handicapping the browser's control in the process.
The problem seems to stem from interactivity on the web. Of course, there's a spectrum here... static content pages on one side and games on the other.
The problem as it stands today is most web pages are on the static/low interactivity side but use solutions from the other end of the spectrum.
People keep reaching for the high interactivity solutions... why? Is it the education systems today pushing people to reach for the hammer they know? Is it the tooling/experience on the other side is so bad people avoid it?
My bold prediction is that reactive frameworks will eventually be considered a mistake, as will its functional programming paradigms.
It's all very computer-sciency and academic but it's simply not intuitive enough when used by a mediocre developer with no strong computer science background. They are leaky abstractions with lots of magic involved that get in your way. There's too many ways to do the same thing and it's way too easy to make a mess of things.
I honestly find functional programming paradigms to be simpler; coming from someone without any sort of comp sci background. Data goes in, UI comes out, seems pretty reasonable to me.
But I will say, I do get being weirded out by magic. Hooks in React specifically, where they're being memoized so you get persistent values out of them, just feels to hacky to me still. Data and the old data from the last time this method was called goes in... and the UI is the combination of that? Class components were at least pretty straight forward, if a little verbose.
>it's simply not intuitive enough when used by a mediocre developer with no strong computer science background
If so, you should look into upgrading the developer into not-mediocore developer. When People are able to get upto speed on rust after a few months, How much trouble can react / vue be?
Is the claim about simplicity true? What I want is Javascript helper library that's easy to jump back into. Every time I do it something in react, I feel like I need to go through the trouble of relearning it again(along with the build system) . I don't spend enough time writing js that whatever I learn really sticks after a while.
Javascript on its own is just a language so I can just get going on a code base.
> What I want is Javascript helper library that's easy to jump back into
YMMV, but this is precisely why I've standardized on svelte both for work and hobby projects. There are times when I've come back to project that I haven't touched in over a year and it was really easy to get my bearings quickly because there wasn't all kinds of code noise to sift through.
I’ve been trying to master HTMX/hypermedia ever since the GitHub accelerator bloggery a week or so ago. It kind of works for my smooth brain. I thought it was the new way to go after React, is it more likely Svelt is the way to go? Is it more like React or more like Angular? I hated both…
There is one thing that Svelte isn't is simple javascript. It is not even javascript, the files are named .svelte for a reason. Svelte is great but I won't be changing React for something so similar but without vdom. Lit.dev is where the real simplicity of JavaScript shines imo.
The files are named '.svelte' because each one encapsulates the relevant Javascript, HTML, and styles.
But why do you want the vdom exactly? Like, what does it give you? Seems like its presence is more an implementation detail of a framework than something a user of the framework would want, no?
Virtual DOM offers nothing but slowness. If I can get the same things without it why would I need it. It's a solution to a problem compilers like Solid and Svelte don't have so it's so odd to see someone argue for it. Like complaining a about missing dependency injection in a functional language.
the alternative is a global query / state management / whatever against the entire DOM tree - much less performant and exactly WHY the virtual dom was invented
TL;DR: It feels like React interacts the reverse of how I think, but Svelte feels like it promises some of the straight-forwardness I used to know 25 years ago.
As a backend person who last touched the frontend when jQuery was all the rage, I spent the last two weekends starting to get familiar with React and then Svelte. I really, really like what I've seen in Svelte so far. It makes sense. I can reason about what components talk to which other components and how, more easily than in React. After 8 hours of a React tutorial (which had several incompatibilities from the version in which the tutorial was written that I had to reason through), and after going through the Svelte tutorial for maybe half that at learn.svelte.dev, I came away feeling confident I can build a site in Svelte and not entirely sure what that would look like in React. I had to start looking at other projects in React to understand how I should organize my secure part of my site vs my public parts. It is clear in Svelte, for instance, where I can enable server side rendering on my more marketing / landing focused pages and how to group pages via the directory structure that require authentication.
It's just "JavaScript" in that it needs a translation layer and has a bunch of special syntax/semantics around reactive variables. Lol.
I don't understand the cult following around Svelte. There's a lot of magic and complexity hiding in there.
At the end of the day state management is not trivial and something has to handle it. React doesn't impose a specific state solution which is what I like about it. But while React isn't perfect, Svelte is not the next step imho.
I’ve been using Svelte for a about 3 years on smaller visualization projects and it works really well in that context. Being able to declaratively define your UI behavior is massive for tools like D3js compared to the more traditional imperative JS style. This unlocks the ability to abstract your UI in really nice ways for defining complex visualization behavior.
The other thing that I really like about Svelte is that’s a compiler and not a runtime framework. This keeps builds performant and makes it easy to import vanilla JS packages without needing framework-specific bindings
I also find Svelte’s syntax to be very intuitive and easy to pick up. The Svelte REPL tutorial docs are some of the best I’ve seen as far as getting up to speed with the tooling.
> React doesn't impose a specific state solution which is what I like about it. But while React isn't perfect, Svelte is not the next step imho.
This one area where we’re going to disagree. Svelte feels more like Rails in that it ships with most of your basic utilities to build a UI, which allows the community to agree on a preferred solution to a given problem. I prefer this because it makes it easier to find solutions to problems that aren’t dependent on some package that I don’t have. Solution discoverability is a massive pain point in react compared to Rails, where there’s pretty uniform agreement on how to solve problems.
All that said, I’ve never worked on a large commercial Svelte codebase so I can’t speak to the ways it which it becomes painful. For smaller projects, I find the DX to be far superior than react.
Perhaps, but given the issues I’ve seen with the larger react codebases I’ve worked with around performance and shifting best practices, I wouldn’t necessarily write Svelte off without giving it a fair shot. It’s not like large React apps are much fun to work on either.
Ultimately, big codebases are hard to manage, regardless of the language or framework. I don’t see a particular dealbreaker with Svelte compared to React in this regard.
> There's a lot of magic and complexity hiding in there
I mean there's a lot of magic and complexity hidden in frameworks, interpreters, compilers, all the way down, not to mention browser engines. Or did I miss something?
when you code in svelte you name the files .svelte, it can't be parsed as javascript. This is more than framework magic, it is a new language. You can't create a preact like framework based on svelte.
Magic is only magic to the ignorant. Complexity is only complex because of humans (mostly). My issue with all of this is that vanilla is better than any framework. It’s fast, it’s has dependency trees, module loading, components, it works well with npm, and it doesn’t force me to learn yet another flavor of the same broken concept.
> I don't understand the cult following around Svelte. There's a lot of magic and complexity hiding in there.
What's new is old again :) People started doing React because they got tired of mixing languages for logic, structure and styles, why not do it all in JS? They got tired of that, so why not separate them? They got tired of manually doing bindings, so now that's hidden behind abstractions ("Hello 2000s templating magic"). I wonder what they'll get tired of next.
My point being: If I ask you today, I'm very likely to get a difference answer compared to in 2-3 years, and if I wait yet again 2-3 years, another answer :)
Next is writing code entirely. Whatever has the most robust documentation will be the next big thing, since AI agents will be writing the code for the programmers.
I'm concerned about the opposite possibility. All the effort will go into tweaking models and adjusting their training data until they generate acceptable output, and documentation for human consumption will be an afterthought.
> documentation for human consumption will be an afterthought.
The documentation just changed a layer upwards in the abstraction ladder. Instead of docs for the code that runs on the machines, we'll write docs for the programs we've built that can generate the code that runs on the machines.
>There's a lot of magic and complexity hiding in there.
That's kind of the point. It's for people who want that magic, not for people who are likely just going to start using Rust instead of continuing to force such rigidity and verbosity into JS/TS.
>> There's a lot of magic and complexity hiding in there.
> That's kind of the point.
But it goes against the title of this post: "You Don't Need to “Learn” Svelte: Embracing the Simplicity of JavaScript". If the point of Svelte is the magic, why tell people they don't need to learn anything? The magic isn't part of JavaScript, so they'll have to learn it.
There's complexity in there, but magic? I'm not sure what you mean. Metaprogramming? The reactivity layer? Otherwise, it's hardly more complex than competing "frameworks". The internals of the rendering engine are a bit cryptic but are otherwise very straight forward to figure out if you want to add custom behavior.
Reactive declarations using label syntax definitely qualify as magic. It’s clever, maybe even the good kind of clever, but it’s definitely magic. And it’s definitely not “just JavaScript”.
Most front-end devs already use a translation layer - Typescript. So I don't understand the need to draw an arbitrary line between what can and cannot be used to make a good web application.
Alright but the types are a wholly different language and cannot be parsed by JavaScript linters. Same as Svelte. People need to learn Typescript in order to use it, it does not come naturally. I don't understand how the same argument cannot be applied for Typescript. I do remember people complaining about Typescript before it became popular. Eventually people understood it made their projects more maintainable and dropped the purist arguments that provide no value to the product.
>I don't understand the cult following around Svelte.
What I don't get is how I never (at least on HN) see any criticism of it. Like... never ever. And sure I've probably missed the odd negative post about it, but as someone who has never used it and whose entire knowledge of it is based on what I've read on here, I couldn't tell you a single supposed downside of using Svelte. And sure, it could just be That Good, but... I dunno? There's something off about that.
My team switched from React to Svelte a couple of years ago. We were working on new app, not refactoring or rewriting an old one, so we had the opportunity to choose whatever tooling we wanted.
The whole team loved Svelte. It did the stuff React did, without a lot of the ceremony or boilerplate. It was easy for the junior devs to pick up, and powerful enough for the senior devs to what needed doing.
We weren't pushing it very hard; the app was basically data entry and data display, and I assume that if you got deep enough into corner cases, it would break down like any other framework. But for our purposes, Svelte felt like someone had taken the time to understand React's issues, and fixed them.
If you want to see some criticism of svelte, one of the core maintainers recently asked about some things that could be improved about svelte in the next major version: https://twitter.com/trueadm/status/1676694161188159490
That should give you some rough ideas about the things that the community itself thinks need improvements.
I have no expectations, but I thought I might as well ask: do you know if there are any apps that will unroll a Twitter thread given a link like the one in your comment? The web version of Twitter no longer shows threads, and I've spent enough time scrolling through the shitty Twitter user page UI looking for old tweets that I'd really prefer an alternative if there is one.
I tried using it 2 years ago on a mid complexity webapp and it blew up in my face as soon as things got a little more complex. The hidden mechanics of everything made it absolutely horrible to debug. Including some serverside rendering issues in the svelte code base at the time. The pain wasn't worth it in the end. I'm probably never gonna touch svelte again without having to.
Similar experience with preact.
It works till it doesn't.
In many cases, compared to what people were using before, it really is that good.
That's not to say it doesn't have its flaws, but when people talk about how it's cleaner, they can dev and debug faster, it takes less of a cognitive load, etc. - they are being genuine.
Some of it is subjective probably, but I'd die if I had to go back to e.g. React. :)
I've been using Svelte exclusively for my projects (and at my day job) for the last 3 years. I've converted several large projects over from React to Svelte. I also do some part time work as contractor on a very large React app. I can provide you with some downsides for Svelte:
1. The developer experience with Svelte just isn't that great. Unfortunately, the Svelte team has (understandably) optimized for VS Code. I've been a WebStorm user for about 8 years and have no plans of switching over to VS Code. They just introduced Svelte LSP integration in WebStorm, but it's buggy. For the longest time you didn't get autocomplete on props with the Svelte plugin. With the Svelte LSP, you do, but I'm getting a bunch of errors from the LSP saying "x is not a module". This may be a configuration issue (I'm using pnpm workspaces and TS path aliasing). But I don't really want to go down that rabbit hole, so I just turn the LSP stuff off. It has gotten better, but it comes nowhere near the DX you get with React.
2. You technically can spread props down the component tree using $$props and $$restProps, but the documentation recommends you don't because there's a performance hit. So for stuff like "aria-" attributes, you either need to define them explicitly as props (e.g. "export let ariaLabel"), which is sort of gross, or you bite the bullet and use $$props or $$restProps.
3. Unless I'm doing something totally wrong here, using CSS nesting doesn't work the way I expect it to for scoped styles. I get that they are scoped, which is good. But if I have a button element with a child Icon component, and I want to change some CSS property in the Icon component's inner svg element using CSS nesting, it won't work:
<script>
// Icon has an inner svg element:
import Icon from "./Icon.svelte";
</script>
<style>
button {
& svg {
width: 1rem;
height: 1rem;
}
}
</style>
<button><Icon name="close" /></button>
The Icon's svg won't pick up that 1rem x 1rem sizing. I guess this makes sense because that is essentially just button > svg, which also doesn't work. But I end up having to fall back to CSS modules (or Emotion, which I stopped using because it needs a runtime).
4. I feel like the whole "$" reactivity gets overused, which leads to confusing and, in some cases, difficult to debug code. Maybe this is the ol' React dev in me (one way data flow), but 9 times out of 10, instead of binding a value to an input component, and listening for changes in a "$" block, I'm going to use the "on:input" or "on:change" event listener to capture that and just reassign the value variable.
<script>
let value = "";
// Instead of this:
$: {
// Do something with value.
}
// I do this:
function handleValueChange(event) {
value = event.currentTarget.value;
// Do something with value.
}
</script>
<input id="use-binding" bind:value />
<input id="use-event" {value} on:change={handleValueChange} />
5. This isn't a Svelte-specific issue, but I'm not crazy about single file components. I really like how components === functions in React, so you can put multiple components in the same file. In lieu of a function that returns a bunch of JSX based on some args, you can switch that over to a component with props. I think that's a really clean design that encourages good separation of concerns. In Svelte, you either end up with a bunch of extra files that need to use context + store or prop passing for state, or a giant component file.
6. Unless there have been major improvements in the testing space that I haven't taken advantage of recently, you can pretty much throw any hopes of reliable test coverage out of the window. At some point I just stopped testing my Svelte components and moved as much logic as I could outside of of the component so I could write unit/integration tests against that to get reliable branch coverage. This sort of ties into point #1, but I feel pretty strongly about having a comprehensive test suite to avoid regressions (enough to make this it's own bullet point). I don't put a lot of emphasis on the coverage percentage because that way lies madness, but it is nice to see at a glance if I'm missing a test case for a branch in the coverage report.
There's probably a few more minor gripes that I can't think of right now, but those are the heavy hitters. That all being said, two of the biggest advantages Svelte offers over React:
1. No virtual DOM. This allows you to do things like change the style of something based solely on an HTML attribute using CSS, no state variable needed. Also mentioned in the original post: you can use plain ol' JS libraries and everything just works. This is a big deal for stuff like D3, because you don't need to add any wrappers. I've had problems with React + D3 in the past, and it drove me bananas.
2. Much fewer footguns. I know this is a controversial take, but I don't like React Hooks. They're a pretty big footgun. They often require you to break up a component needlessly so you adhere to the "Rules of Hooks". Stale closures are a thing. I never had a problem with class components. I never understood the confusion around "this", which was a common defense for using hooks whenever the topic of the weirdness of hooks came up. If writing class components was still acceptable, I would be more amenable to using React in my projects. But whenever anyone I work with at the contractor gig encounters a class component, they immediately want to refactor it to a functional component with hooks. It's never even up for debate, class components bad, functional components good. Svelte doesn't have anything analogous to a hook, which makes me happy.
> It doesn't throw a bunch of alien syntax at you, expecting you to decipher it like an ancient scroll
Sounds promising, but the first examples contrasts a React `useEffect` hook (a simple function call, into which you pass a callback and a dependency array) with
- Oh, is `$` a label? [I googled this to confirm it is]
- I thought JavaScript didn't have a `goto` statement? [I googled this to confirm it doesn't]
- How does this ever get invoked? [I still don't know the answer to this question -- MDN says that labels can only be used with `break` and `continue` statements]
- Does it get invoked only when `count` changes?
- If so, how?
- If not, how do I specify the dependencies?
It might 'just work', but it's also not 'just JavaScript'.
Initially the same way it would without the $: { ... } wrapper - that is true both for Svelte and vanilla JavaScript.
> Does it get invoked only when `count` changes?
It's invoked whenever a named variable that is mentioned in the block is explicitly assigned to.
That's the whole "magic" here really. It's "just" JS in the sense that there's no additional syntax introduced that would make it incompatible with any of the available JS parsers, so by extension TS parsers as well.
Sure -- I did run that code in a JS REPL and saw that it invoked the block immediately, but that isn't necessarily what I want if I'm writing reactive code. I then tried typing `break $` and `continue $` and got SyntaxErrors for my trouble, confirming my hypothesis that this couldn't be plain JavaScript of the sort I was familiar with.
> It's invoked whenever a named variable that is mentioned in the block is explicitly assigned to.
This makes sense in the sense that it's a contract that I can accept and use, but it does imply the existence of a parsing pipeline & runtime of unknown (to me) complexity & capabilities -- exactly the sort of thing a prospective user of the framework would need to learn about sooner or later.
Well, yeah - there's a reason why it's called a framework-compiler.
In any case you can always just look into the unminified output where you'll see how your code is instrumented - it even includes comments detailing which variables are being dirty-checked.
JavaScript syntax, yes, but with Svelte semantics rather than JavaScript semantics. Everything else follows from that point. It gets invoked by the Svelte compiler transforming it. In order to work, `count` must have been defined as a property (`let count` or `export let count`), so that the compiler can run that code again when `count` changes. Reactive dependencies are specified purely by mention of their names. (Well, there’s stores too, via the $ prefix on variable names.)
> It might 'just work', but it's also not 'just JavaScript'.
Via magic: Reactive blocks are ordered via simple static analysis at compile time, and all the compiler looks at are the variables that are assigned to and used within the block itself, not in any functions called by them.
Goto is control flow. You can’t do control flow with function calls in the sorts of languages we’re talking about, so goto has to be built into the language, typically as a statement.
(In some of these languages you can do awful hacks like using hooks intended for debuggers <https://entrian.com/goto/> or rewriting bytecode <https://github.com/snoack/python-goto>, and frankly what Svelte does is quite similar, just implemented as a compilation step rather than at runtime.)
No, and that's one of the things that's really nice, at least for our team: we really want our web designers to own the HTML/CSS from start to finish. If you use something like React (i.e. where there is code that emits chunks of HTML elements), you sometimes either force the designer to learn React or the designer no longer owns the markup once it gets handed off to a dev. For us at least, that was a maintenance nightmare and hindered our ability to add new features or freshen up the layout.
Svelte combines a component's HTML, Javascript, and styles into a .svelte file, so it all lives in one place, but each of those 3 things lives in their own section. The HTML looks very close to what it looks like when it was originally created by the designer, with a few key changes such as markers conditional blocks or loops and additional element attributes to set up data and event bindings. Explaining these to a web designer takes about 10 minutes and they are fine with it, especially if they've ever seen a templating language before.
This setup also leads to one of two really good workflows between dev and design; we end up using both of them and choose one based on the specific scenario. In the first, the designer goes from visual design all the way to valid HTML/CSS, and then hands it off to a dev to "wire it up" (make it functional). In the second, a dev will rough in the HTML and make it functional but hideous looking, and then hand it off to the designer to de-uglify it. In both cases, the dev owns the behavior and the designer owns styling/layout/etc. from then on, and it's rare for there to be any conflicts. YMMV of course, but it's been fantastic for us. :)
I haven't really used Svelte, but according to their website, they definitely seem to have a custom language that I don't think I've seen before (eg. not mustache, liquid, handlebars, erb). From their own examples [1]:
Hmm... apologies, but it seems like we're talking past each other. You thought that Svelte used a "completely custom template language that doesn’t even look like HTML", and I replied that no, compared to something like React, it looks very much like ordinary HTML, with a few exceptions around things like loops and hooks for data bindings, and you replied with a chunk of HTML annotated the way I described. :)
Point being that if you take the HTML from a web designer and put it into your svelte app, it looks very similar to the original. For example, our web designers have no trouble continuing to "own" the HTML even after a dev has gone in and made it functional - the overall structure is the same, all of the elements they created are still there (with the exception that if they had e.g. a bunch of dummy rows in a table, those are replaced with one instance of the row and wrapped in a loop construct), the CSS doesn't break because new elements have been added, etc.
Our experience with React was very different: once the devs took it, the result was so far removed from the original that the web designers couldn't effectively own it anymore. Maybe for some companies that's not a big deal, but for us it's hard to express just how much better the Svelte way is.
That post describes "something followed by a colon is a label in certain contexts", so you need to extrapolate a tiny bit to realize that "$:" is a label, even if the post doesn't explicitly enumerate all possible labels.
I would guess they just wanted to make it work with existing tooling, so
that e.g. standard JS syntax highlighters wouldn't break on code written in
this framework.
I disagree with the notion of TFA, and perhaps useEffect is closer, but I'd like to note that the entire function/component rerunning every time a dependency changes is as far removed from original JavaScript as a framework could be.
Not helping this, it's not particularly well documented. For example, recently I had to learn about the onDestroy function which accepts as an argument a lambda. The docs [1] state that the lambda is run when the component is "unmounted", but offers no further information about exactly how or when this occurs. There is no official documentation on all the various lifecycle stages of a component and how or when each transition occurs. I find myself simply relying on a lot of trial and error or asking in the Discord forum.
[1] https://svelte.dev/docs/svelte#ondestroy