Svelte is surprisingly easy to learn
kaviisuri.com
kaviisuri.com
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.
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
How are the use cases for these libraries different?
<div *ngFor="let product of products">
<h3>
{{ product.name }}
</h3>It was quite nice to work with, really simple. Though I was just not convinced by its ecosystem, who's gonna use this?
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.
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.
https://svelte.dev/repl/b946424a56d84a63a09856bc3df5803e?ver...
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.
- 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).
- Reactivity API - yes, with $: labels
- Lifecycle hooks - yes, similar to the ones mentioned
- 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
[1]: https://vuejs.org/guide/extras/composition-api-faq.html#what...
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).
There's some nuance, but roughly:
- getContext = provide
- setContext = inject
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.
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?
* maintained, with a rich and alive ecosystem
For one, in Svelte you're getting a legible stack trace - something that JS frameworks stopped delivering over a decade ago.
To finally know which change triggered the rendering that errored out just by looking at the stack trace is a game changer.
My advice is - if you want something that will be stable for 15 years, look for something that has already been stable for 15 years.
care to share a link, blog post, or study? i've built at this point dozens of apps on react, no "instabilities" to call home about
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.
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.
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.
I switched to it from React + Webpack, and it's so much better.
Maybe not, but there is a good chance that Vue in 2040 is nothing like Vue today.
Things change all the time. It’s okay.
If I had to make a project, I would bet on vue because it is community funded
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.
oh god, what would that mean for the web? an unreadable mangle of JS, HTML, and CSS, even when it's in source code format? count me out!
See: creative software like Adobe CC that technically saves to common formats
Nobody is going to pay programmers to write clean code if AI can write working code for 0.0001% of the price.
- 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.
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.
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.
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.
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.
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?
Also: job creation.
It’s the difference between manufacturing denim and selling jeans. The denim business is forever. The jeans business is constantly changing.
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.
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.
Ember.js and Angular.
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).
Intercom swears by it https://www.intercom.com/blog/evolution-of-ember-at-intercom...
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.
https://auth0.com/blog/face-off-virtual-dom-vs-incremental-d...
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.
Might as well have said Dojo and Knockout, it would have meant the same thing.
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.
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.
Neither will ever be popular.
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!
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!
Or I can just look at what front end jobs these companies are posting: https://www.indeed.com/q-apple-web-developer-jobs.html?vjk=b... https://www.indeed.com/jobs?q=hashicorp+front+end&l=&vjk=90c... https://www.indeed.com/jobs?q=Microsoft+web+development&l=&s...
and plainly see that they're not Ember, they're entirely React.
I can find ONE mention of Ember from your company list, and it's a nice-to-have skill for a backend role: https://www.indeed.com/viewjob?jk=7751f4d47fbf9760&tk=1h9hc6...
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.
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?
You can find your answer here https://www.intercom.com/blog/evolution-of-ember-at-intercom....
> 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.
All the best <3
[2] https://www.hashicorp.com/blog/introducing-helios-hashicorp-...
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.
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.
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.
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).
Anyway, thanks for the feedback, I'm quite new to blogging and writing in general. Will definately incorporate your suggestions in future work.
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.
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.
<script>
import counts from './store.ts';
import {onMount} from 'svelte';
</script>
<button on:click={() => $counts.a += 1}>
Increment A ({$counts.a})
</button>
- Why are these ESM imports allowed in a non-module script?
- Even if $counts somehow references counts, how is either in scope in any part of button?
Solid is newer than Svelte with less of an ecosystem, so it’s interesting to hear that you found it more manageable. What made it more manageable?
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")
[0] https://www.solidjs.com/docs/latest/api
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.
I wonder if Svelte5 will retain the framework philosophy or move toward the toolbox approach.
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.
I've been using Svelte for about 3 years now and haven't found any big scaling headaches.
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.
- 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.
Getting excited and then jumping all in on new frameworks has bitten me more than once.
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.
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...
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.
https://htmx.org/essays/hateoas/
that isn't without it's own problems, but it is very different than most JS libs today
i expect the hype will die down soon, as the reality of there being no silver bullet sinks in
> who cares? I wish we would spend more time thinking through new (or old) solutions to the problem we are solving
- What's "the problem"?
- How do you classify improvement vs solution?
Personally, I think people, in essence, have different problems that's why they create different solutions.
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?
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.
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.
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?
Javascript on its own is just a language so I can just get going on a code base.
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.
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?
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.
Like for instance golang doesn’t give much for abstraction, so it doesn’t create rockstars out of its build system / dsl / etc ?
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.
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.
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.
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.
> 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.
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?
>did I miss something?
Yes, that all of this is just code…
Vanilla JS is an abstraction over something else which in turn an abstraction over another and so on...
So your problem here isn't really with abstraction/magic/complexity in itself.
You like a 5 layers cake, you think it's just perfect, a group copied the recipe and added a layer because they want to add another flavor.
They didn't ruin your cake, they just have different taste.
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.
therein lies the entire drama
too many people probably get into svelte and realize only too late that its not intended / useful for larger projects
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 are many critiques that can be argued about Svelte, but state management is certainly not one of them.
Component reactivity seems magic but it's very predictable once you get the hang of it. And the productivity gains are immense compared to React.
For application reactive state (outside components) you get reactive primitives for free without any dependency like MobX.
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.
That should give you some rough ideas about the things that the community itself thinks need improvements.
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.
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. :)
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>
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} />
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.
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
<script>
$: {
console.log("Count Changed!", count)
}
</script>
<!-- html -->
- Is this actually just JavaScript?
- 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.
> 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.
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'.
You are completely correct.
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.
https://svelte.dev/docs/svelte-components#script-3-$-marks-a...
Goto is not a statement. It's a function. Frameworks can have functions...
(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.)
proceeds to show examples with a very magic $ syntax
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
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. :)
<ul>
{#each cats as { id, name }, i}
<li>
<a target="_blank" rel="noreferrer" href="https://www.youtube.com/watch?v={id}">
{i + 1}: {name}
</a>
</li>
{/each}
</ul>
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.
To be fair, that's valid JS, the syntax itself is not magic but what happens afterwards/how Svelte picks it up.
The templating though, that's some non-valid HTML/JS magic.