> Svelte 4 reduces the Svelte package size by nearly 75% (10.6 MB down to 2.8 MB), which means less waiting on npm install. This improvement will be especially noticeable for users who are loading our interactive learning experience on learn.svelte.dev for the first time, users of the Svelte REPL, and users with limited connectivity. The majority of the remaining package size is eslint support, which necessitates distributing a CJS build, and once the eslint rewrite is completed the Svelte package size can drop by over another 50%.
Speaking about size reduction, I once had a client who want me to update his product as it became extremely slow and buggy. The product was an MS Word Add-In that was run on an MS Surface which takes shots using webcam and insert them into the active document, it was built in .Net and the previous developer used, as I recall, OpenCV library to take the shots. The installation binary was around 300MB! And, to add insult to injury, both x86 & x64 of OpenCV were included in binary which made the final binary more than 600MB. I then used a tiny lib in C# to take webcam shots and rebuild the entire solution from scratch which generated a binary of around 1MB. The client had some concerns and suspicions about my delivery but once he tried it in a clean Surface, he realized what I did. It was like magic for him but not for me. I was happy because I made him happy :)
I might misused the term clean surface, I do not mean a fresh OS install but a surface tablet that hadn’t the old product installed so he can confirm my product do not use any of dependencies of the previous one.
The tiny lib was just a wrapper around some Windows API I guess to read shots from the webcam stream. Also, this lib is not specifically designed for surface laptops/tablets, it was generic, I used a Logitech webcam on dev PC and it worked just fine.
I remember when I was talking about some code my team wrote once and we'd managed to get an operation down from 6 hours to like 5 minutes.
Another manager said to me (fairly with hindsight) "If you get something down from two hours to one hour, that's an opimisation. Going from 6 hours to 5 minutes means it just wasn't finished."
> I _would_ say that this will result in no changes that are observable to users of the framework, but that's not quite true — it will result in smaller packages (no need to ship giant sourcemaps etc), and you'll be able to e.g. debug the framework by cmd-clicking on functions you import from `svelte` and its subpackages (instead of taking you to an unhelpful type declaration, it will take you to the actual source, which you'll be able to edit right inside `node_modules` to see changes happen).
Let's hope all baggage was not offloaded to some extra dependency ;) In all seriousness I would like to see more packages competing to reduce size and dependencies count to absolute minimum.
> The number of dependencies in Svelte has been greatly reduced from 61 down to 16. This means faster downloads for our users as well as less susceptibility to supply chain attacks
I'm used to Svelte, and I remember last year when I tried to install a basic NextJS starter template (create-nextjs-app) I had to wait a minute or so for all the npm dependencies to install. I then checked my project folder and it was 600MB....mindblowingly bloated.
yea but this more like install react more than nextjs, nextjs do to much magic to be comparable 600 mb is insane anyway but is important to be clear then we are comparing different things
and totally irrelevant. how is having 600mb of dependencies making your life so much harder compared to time savings and developer experience Nextjs provides
I wouldn't say it's totally irrelevant...it translates to slow dev builds, slow dev startup, etc. Especially considering SvelteKit may be ~150 mb, but npm i is a couple seconds and npm run dev is basically instant. I'm biased because I'm allergic to React and anything JSX touches, including NextJS, so in all honesty I wouldn't use it if it was 1kb.
As somebody looking for a more effcient (less re-rendering) and nicer DX (template based, stuff like exit animations) alternative to React, what actually makes Svelte measurably better than Vue? On first (and very naive) look the two seem pretty similar, with the biggest difference being that Vue seems to have the much bigger ecosystem and more mature tooling (I keep hearing about Svelte's flavor of JS basically being its own language now and it not playing all that well with Typescript). From what I remember they even once had a virtual DOM-replacing Ahead of Time compiler, so that might not be the biggest moat either.
Both can be fiddled around with to support rendering using JSX, but it seems to easier and better supported for Vue.
Now I wonder whether the performance benefit is big enough to justify using Svelte, especially since Vue already uses a "compiler informed virtual DOM".
Anecodally all Vue apps I have used felt fast while the React experience was more mixed, but the sample on the Vue side is also just really small.
> I keep hearing about Svelte's flavor of JS basically being its own language now and it not playing all that well with Typescript
it's a weird habit on HN to refer to random rumours that have discouraged you from trying something, and then explicitly not link to even the source of the random thing you're thinking of.
I would guess you're misremembering something about the *developers of Svelte* saying they didn't think Typescript was worth it for *developing libraries*, and so they were switching to using JSDoc annotations for developing Svelte, which has no impact at all on Typescript or Svelte or Svelte users using Typescript?
> it's a weird habit on HN to refer to random rumours that have discouraged you from trying something, and then explicitly not link to even the source of the random thing you're thinking of.
I don't know about you, but I don't keep a map of "random thought" to "url" anywhere. It seems totally fine/normal in a discussion forum to say "Hey i heard this thing, any substantiation to it?" without needing a source.
But Svelte obviously doesn't play well with TypeScript, and is kind of its own language - you don't need a source for that. Good luck e.g. getting reactive declarations to play well with TS's type narrowing or null analysis.
you clearly don't know what you are talking about.
reactive declarations do not change the type of the objects. it just that they can rerun when the dependencies change.
sure for the convenience of the users you do not need to type `let vars...` for every new variable declared in the reactive statement, but no one forbid you to write it before hand, or let the language server/plugin do it for you.
but Svelte indeed do not work perfectly with typescript, because it allows you to write code inside html template, which currently only support javascript expression.
Data-point of one, but I have definitely run into issues where Typescript can't understand what's going on in a reactive expression, and had to aggressively refactor my code to make everything happy. Most of the time it works great, but when it doesn't it can be really annoying. I wouldn't go so far as to say it doesn't play well, but the seams are definitely visible.
Could be the plugin was broken somehow. Happen all the time for me.
Even now the syntax highlighting and code formatting feature would break if I write the code the wrong way.
from my understanding the plugin does some clever tricks like insert some dummy code or create some dummy files to be consumed by the typescript language server. so it is not guaranteed to be correct 100% of the time.
This simply isn't true. For instance, if you narrow a variable from `1 | 2 | 3` to `1 | 2`, then trigger a reactive declaration, the reactive declaration can't understand that you've narrowed the variable, and you lose that information. Same thing happens if you go the opposite direction and broaden a variable. TS assumes that program flow roughly goes from top to bottom; if you break that invariant you lose a lot of handy features.
> you clearly don't know what you are talking about.
Then it's wrong too. Because it is perfectly valid js code. It is just that they repurpose the label syntax (used for breaking out of inner loops) for the reactive statement.
I couldn't disagree more. Compared to the mess of hooks in React, Svelte is closer to JavaScript in the script portion and closer to normal html in the markup portion. I use vite and TypeScript with each project and never once had a typing issue. Ive built several production apps and consider it far better for my brain than other libraries I tried, and I've been using React since before Redux was mainstream. Svelte is my go to now.
> I couldn't disagree more. Compared to the mess of hooks in React, Svelte is closer to JavaScript in the script portion and closer to normal html in the markup portion.
Come now. Only one of React and Svelte needs a custom compiler to run in the browser, and it isn't React...
Vue 3 (with <script setup> is quite close to Svelte in terms of DX, but Svelte has the edge here. Svelte is so simple, elegant and concise.
The biggest advantage of Vue is the ecosystem. However, Svelte is catching up. Some interesting UI component libs have recently arisen, e.g. https://skeleton.dev.
Performance wise, both are super fast.
Make sure to check out Sveltekit, even for building pure SPAs. The routing and data loading are worth it alone.
The performance difference is huge. A few years ago I launched an interactive consumer app on very resource constrained devices that would have been impossible with React or Vue (I empirically tested both). Think dual or quad core 1Ghz arm processors with zero GPU acceleration running electron.
The only optimization I had to implement was virtualization when showing hundreds of off screen images (an optimization I would have had to implement regardless of framework).
> From what I remember they even once had a virtual DOM-replacing Ahead of Time compiler, but walked back on it for some reason.
nope, its still there, just is less complicated than you make it sound with those adjectives in front of "compiler"
in the days of svelte 3 vs vue 2, i'd say the authoring experience was a lot more straightforward as vue had constraints around being a drop in framework. but then vue 3 came with "script setup" and other svelte inspired improvements that brought it a lot closer to svelte. am a bit uncomfortable with the 2->3 churn in the vue ecosystem (https://twitter.com/swyx/status/1482778158537801728) but havent actually tested it out since
I have little experience with Vue but to me Vue is very similar to React.
What sold me on svelte is the fact that I learned like all of it in maybe 3 hours. I have tried to pick up React here and there and I get the fundamentals but I hate that you need an architecture framework, a router framework etc. Svelte has a standard way of doing that.
Writing Svelte, I actually had "fun" building stuff, I can't say the same thing about my React attempts.
In my limited experience Vue felt more like React than Svelte felt like React. But I only used Svelte for a small personal project, and mostly only used Vue 2 + Nuxt for a couple of client marketing sites, so my experience might not be the best view into each.
> Vapor Mode will only support a subset of Vue features. In particular, Vapor Mode components will only support Composition API and <script setup>. However, this supported subset will work exactly the same between Vapor and non-Vapor components.
> Building an app with only Vapor components allows you to drop the Virtual DOM runtime from the bundle, significantly reducing the baseline runtime size.
This seems like a clear push in the direction of Solid and Svelte in this area.
> especially since Vue already uses a "compiler informed virtual DOM"
Not diffing at all against a virtual DOM and instead executing the pre-compiled DOM manipulations is an order of magnitude better in terms of processing. It also avoids diffing entirely. At a casual glance, the compiler hints and other VDOM optimisations in Vue reduce but do not obviate this burden (e.g., don't re-render static nodes, flatten the DOM tree to avoid traversing) But as ever, it's best to measure these things and I can't seem to find any recent benchmarks between the two platforms, and any benchmark would vary wildly depending on use-case, and with the exigencies of real-world development.
I haven't worked with Svelte (but with Vue, so def biased) but my feeling is that where Vue really shines (and always have, compared to other frameworks) is it's data reactivity system, making data (including but not limited to) stores very nice to author.
The composability of Vue 3 data stores makes it imo really nice to work with for anything a little bit more complex, and I've yet to see anything as good.
Svelte is more like a compiler than a library. The code you ship is plain JavaScript without any svelte dependency. That’s why svelte has always been simple and fast.
I've recently embraced Svelte for my side-projects, hackathons, and personal endeavors, and I must say, I'm absolutely enamored with its developer experience (DX) when compared to React. If you're interested, I've shared some of my thoughts about this on my personal website: https://www.kabirsewani.com/blog/why-svelte . (However, if personal links are not permitted, I'd be more than happy to provide a brief summary instead.)
The VDOM was never about performance problems with the actual dom. It was always slower as you still have to mutate the actual DOM. The "VDOM if faster" was always FUD.
The VDOM was invited to prevent bugs by removing the difficult of managing fine grade DOM mutations. Technically you are doing more work with a VDOM and diffing, than carefully mutating the DOM, it's slower.
Of course if you just threw away the whole DOM and re built it, then he's the VDOM was quicker, but that's not how anyone was building stuff.
It was not FUD. It’s not faster than carefully mutating the DOM, but back then, almost no one was “carefully mutating the DOM” all the time. It was a shit-show of ad hoc re-rendering strategies that often re-rendered excessively because no one has time to do it carefully for every case. For most common use cases, VDOM had great performance with little cognitive overhead.
There were other frameworks before React: AngularJS, Knockout.JS, Backbone.JS, ExtJS, and I'm probably missing few others... Most of them had a concept of props/dirty-checking/retained-mode and they were definitely faster than naive React.
What VDOM made easier (in terms of performance) was memoization, you could get faster if you carefully evaluated your dependencies, but to be fair, it introduced many edge-cases and many people avoid memoization to this day.
VDOM also made react-native possible, and it made cross-browser programming bearable (but other frameworks at the time did that too)
Now, one REALLY COOL thing about VDOM is fragments, because being able to render multiple elements from one component, makes certain layouts very easy using plain CSS - either with simple > * or even with CSS GRID.
I am not sure, if Svelte 4 can do that, but it's very simple thing to do with VDOM. And it certainly was not common feature for a very long time.
I understand this thought for external dependencies, but dependencies also includes internal ones, which I don't see a reason to reduce. Modularity and re-usability of individual pieces of code are a good sign for me.
Dependency managers like NPM don't differentiate between internal and external dependencies. I assumed that the Svelte devs were referring to this. Vue for example only has internal dependencies, but NPM shows them as any other: https://www.npmjs.com/package/vue?activeTab=dependencies
There are tradeoffs there. E.g. many of Svelte's dependencies are shared by bundlers such as Vite, Rollup, and their plugins. If you bundle those dependencies it means they have to be downloaded multiple times. It also means you can't use the cache from efficient package managers like pnpm. And lastly, it makes it harder to deal with security issues. If there's a security issue in a dependency then Svelte would need to ascertain whether it could affect users, upgrade the dependency, and file a CVE against Svelte itself. Users would then have to upgrade Svelte in addition to the dependency if it's shared by any other libraries.
@dang https://news.ycombinator.com/item?id=36432447 was on the front page and has substantially more discussion. It was somehow marked as a duplicate of this post. Could you merge them?
I tested the beta version of Svelte 4 on my app and it worked without requiring any changes other than running the migration script. Excellent work from the team!
The breaking changes aren't really gamechanging stuff, just cleaning up baggage in preparation for Svelte 4.x and Svelte 5. The course would still be fully applicable
Gotcha, thanks for the clarification. I really enjoyed his course last time, I also wish he would put out some data viz content too. I bet he develop lots of good insights during his tenure at the NYT, but understand he is tied up with Svelte atm :D
I took the course when he did it live. There is lots of good stuff in there. The meat of the course was mostly going through learn.svelte.dev. One day was on Svelte and one day was on Sveltekit. The most interesting part was the end of day sessions where you actually build apps.
I don't think you learn anything that wouldn't apply to Svelte 4. It's intended as a smaller update to prep them for bigger changes coming in Svelte 5.
Could someone give a one or two sentence explanation of why I would want to use Svelte over something like React? I have heard it is "better", but have never understood why.
JS frameworks are like coffee, some people like them milky and full of sugar, some people like them like them lean and black, some are obsessed with making the "worlds best coffee" at home every morning, and some drink whatever brown water comes out of a vending machine.
We all like our coffee different, just as we all have favourite features and designs of frameworks. There is no correct, or best, framework, only personal preference and what's good enough for the job in hand.
Svelte is a Flat White with locally roasted coffee beans from an independent coffee shop.
React is a Starbucks Vanilla Late.
Vue is a Starbucks Caramel Machiato.
Angular is the Vanilla Late from your staff canteen, it used to be a bit rough, but seems to be better in recent years.
Not using a framework, is carefully weighing out the "correct amount" of beans, grinding them by hand, tampering it with the "correct force", and then making the "perfect" espresso.
Big disagree on the not using a framework part: far too often that's not so much a lovingly honed craft but an echo of the "websites should work just fine without JavaScript" that has long been given up as a goal but still haunts decisionmaking as an ideal that now serves as an excuse to consider everything client side secondary citizen. "It's JavaScript, right? It's supposed to an unmaintainable mess." If you dig deeper you will often hear something like "And anyways, jquery 3 is still the latest major release so this is definitely state of the art"
It's definitely not a perfect metaphor but I enjoy working with vanilla JS or without a framework and I think it's very different from "no JS" (I mean... seems obvious given that it's JS).
You can technically do anything a framework does in your own JS, since they're all just opinionated JS libraries. You can make your own SPA or implement your own VDOM or SSG but it might take a long time and not be as battle tested. On the other hand you're also free to make your own optimizations that might work well for your needs without worrying about a huge framework.
I'm not saying that there's no good handcrafted bare browser code out there, and I guess some of the bad wasn't made without love at all. But I've just seen too much of the stuff that seems like it's still standing with half a leg in the age of internet explorer vs netscape, and that was perhaps crafted laboriously but certainly with more contempt than love to consider the loved stuff mow than a rare exception. I guess part of my gut reasoning goes like this: chances are the loved ones have been modernised three times over, while the contemptful implementations live on.
But I can't come up with any coffee analogy for that, there's just no mapping between those spaces that makes any sense.
I was curious how ChatGPT would actually compare these frameworks to each other in coffee metaphors, so here you go:
- Vue is like a latte. It's smooth, easy to drink, and has a nice balance of sweetness and bitterness. It's also very popular and widely available. Vue is a progressive, incrementally-adoptable JavaScript framework for building UI on the web. It has a good and intuitive documentation, a large community, and a simple syntax. Vue is also performant and fast, and supports component-based development.
- React is like an espresso. It's strong, concentrated, and gives you a lot of energy. It's also the most searched and used framework among the four. React is a JavaScript library for building user interfaces. It has a large community, a lot of resources, and a high performance. React also uses JSX, which is a syntax extension that allows you to write HTML in JavaScript.
- Angular is like a cappuccino. It's rich, creamy, and has a lot of foam on top. It's also very complex and requires a lot of skills to make and enjoy. Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. It has a fast server performance, an MVC architecture implementation, and a good documentation. Angular also has a steep learning curve and is very complex.
- Svelte is like a cold brew. It's refreshing, smooth, and has no bitterness. It's also relatively new and innovative in the coffee world. Svelte is a new way to build web applications. It's a compiler that takes your declarative components and converts them into efficient JavaScript that surgically updates the DOM. It has no virtual DOM, no frameworks on top of frameworks, and no framework at runtime. Svelte is also truly reactive, easy to learn and use, and supports component-based development.
This is always a personal judgement, but here's my personal list:
- I find it so much easier to understand. I don't have to useState/useEffect/whatever, I just assign variables and the component re-renders
the relevant parts whenever I assign a new value.
- Styling is "just" CSS. No messing around with CSS-in-JS libraries and their various ways of being invoked. The CSS is automatically scoped to your component without you having to think about it (though IMO there’s work to do there with CSS variables and the like)
- The end-user bundle is so much smaller. This doesn't matter so much if you're creating a giant web app (e.g. Gmail) but I often work on smaller sites and it's very gratifying for users to only have to download ~20KB of JS rather than the hundreds (if not megabytes) you'd get with React. Has a positive impact on page performance scores, SEO etc too.
> I find it so much easier to understand. I don't have to useState/useEffect/whatever, I just assign variables and the component re-renders the relevant parts whenever I assign a new value.
What's frustrating for me is that I'm so used to thinking in hooks that when I first gave Svelte a try, it didn't click. And I knew that was wrong, lol. The release of Svelte 4 is good timing, I might have a use-case at work for a small project to try it out, so I'm going to give it another shot.
I find reactive systems to be at least as complicated as React's declarative model. I was glad to move on from Knockout more than a decade ago and Svelte is conceptually the same thing in how they work, but with a different proprietary syntax and a faster renderer.
I also don't understand the styling complaint. React devs used "just CSS" for years before some of them started pushing for CSS-in-JS. In fact, SCSS/CSS is the default for the still nearly ubiquitous create react app system.
End-user bundle argument is a red herring. What is true for "hello world" isn't true for large applications. The overhead of React is a one-time payment while each new Svelte component drags along all the code needed to support it (copying similar code over and over).
React's F + N * C (where F is framework size, N is component count, and C is average component size) is smaller for large values of N than Svelte's N * (F + C) approach.
That N is very large. E.g. here's a page that talks about it: https://github.com/halfnelson/svelte-it-will-scale. I'll note that was done with Svelte 3 and that with Svelte 4 components are at least 10% smaller, so it's actually even better than that. SvelteKit is also very efficient at JS splitting per-route thanks to Vite. It ensures only the JS that is necessary for a page is loaded and you're extremely unlikely to be using anywhere near that many components. Based on the article above, you'd have to have three entire sites worth of components on a single page.
What code does Svelte use internally vs what code winds up compiled into your components? Last I checked, MOST of the code wound up in your components. In fact, this was their entire argument for why people should use Svelte when it launched.
Just look at their "Hello World" application on the Svelte website. 5 lines of code transform into 45 lines of code.
Massive reduction in boilerplate. As someone who attempted to onboard onto both react and svelte for a couple days each, react continued to feel hyper unintuitive with a bunch of magic constructs. Svelte felt like I could guess what would work and it just did.
Caveat: since I went react -> svelte it's possible I was just warmed up to JS by that point
It's the opposite for me. React can be verbose but that's because a lot of it is explicit and has escape hatches. Svelte has magic that works until it doesn't and then you're stuck in Svelte land. It's not "just JS" despite people marketing it as such
I was stuck once by abusing `bind:` and other time with global exit transitions + sveltekit routing, but that's about it.
React on the other hand feels like a pot warming up and we're the frogs being boiled alive at this point. You can write some perfectly valid, but naive React code and it's going to have some footguns. We're so used to write idiomatic React code we don't even notice that anymore. You learn to use stable references in callback functions, to be careful using Context, and so on. But the list is not short, and it only grows.
Wanna write some naive code in svelte two days in? There's a good chance it's the same code you'd write a year later. Maybe that's what people mean by "just JS".
> You learn to use stable references in callback functions, to be careful using Context, and so on. But the list is not short, and it only grows.
It doesn't though. React adds new features that are optional and everyone goes "Pfft, I'm moving to Vue because they added [blank]" I've got old React projects that still work fine.
There are languages/frameworks that move fast and break things and then there are languages that just move fast. And Javascript itself is also very backwards compatible. You could still just be using class components and Redux and be fine. I have no interest in these server components right now.
Less code as everyone else mentioned, single file components (CSS is inside your .svelte files too, and isolated automatically), and a general feeling of on railsness that React for me lacked.
State in Svelte goes in stores. State in react seems to go in one of eighteen different mechanisms, which all begin with a 45 minute video of the author’s opinions about the true nature of reactive programming, when all I want to do is store a string.
> State in Svelte goes in stores. State in react seems to go in one of eighteen different mechanisms, which all begin with a 45 minute video of the author’s opinions about the true nature of reactive programming, when all I want to do is store a string.
So... useState? :)
Of course then I got to thinking about how I'd answer the question "How can I put make that useState value accessible at different points in the component tree?" and the answer was "Make a new context with createContext and wrap the context provider in a component which provides the state and write a hook to easily consume the context within a child component" and, yeah, that's not exactly a frictionless dev experience.
I work on several large react apps that are very data heavy and what I would consider complex. Honestly we just use useState and prop drilling. Most state is stored at optimal position within the hierarchy, so there really aren't that many props being passed down. The only place context is used is for session information.
It's really quite simple and elegant. Svelte's model would likely be more complex tbh.
I prefer an explicit function call over compiler voodoo magic, especially when it comes to reactivity (of which can have performance implications). Any solution where a compiler is changing the semantics of my code on the fly is just a hard pass.
Yeah, I think it's something you just have to get a feel for over time. Sometimes prop drilling is the lesser of two evils, other times it makes more sense to break related state up into a shared context.
At least the React ecosystem as a whole seems to have broken free from the delusion that Redux is the be-all-end-all of state management. Those were dark days.
Most folks would probably say "it's faster" but I think the real upside of using Svelte is the DX. It's just massively simpler and way easier to be productive.
Svelte tries to improve upon the relatively complex/heavyweight runtime of something like React by shifting as much of that complexity to the build step as possible. It also takes a more "batteries-included" approach compared to React by including some opinionated features like state management, animation, transitions and the like.
I haven't dug too deeply into Svelte because last I checked it didn't play particularly nicely with TypeScript but this release may prompt me to give it another look.
One of the things released today was dedicated documentation for TypeScript: https://svelte.dev/docs/typescript. The site was also updated today to include a JS/TS toggle so that you can see all the examples written in TypeScript if you prefer it to JS.
I'm not sure how long ago you tried or what issues you ran into, but hopefully this will help with getting started with Svelte and TypeScript much more easily.
I'd argue that Svelte is less opinionated than React in most areas. The whole hook system depends on a ton of hidden state that React manages itself.
Svelte state management, for example, is just the `subscribe(callback: () => void) => Unsubscriber` interface. A couple of utility store functions are provided like `writable` and `derived` but state management libraries don't need to know anything about Svelte, just provide that single life cycle method. The context API looks almost exactly like React's.
The most important thing to know about Svelte is that it doesn't have a runtime. All the magic occurs in places that look magic, and all the magic happens at compile time; at runtime it's simply a library. By contrast, React's VDOM system not only adds significant cognitive complexity but performs terribly too.
As someone who came from a self-taught backend background (Python), Svelte is way easier to learn, read and write than React (to me) due to requiring was less boilerplate. The example in the “Developer Experience” section of this article was all I needed to see to ditch my attempts at learning React and go all-in on Svelte.
You get a legible stack trace that actually points to something looking very much like your code.
There's also stuff like generally fewer LoC, more incentive to use native APIs and rebuild times measured in hundreds of milliseconds, but that first thing is what got me sold on Svelte.
Because you can deliver a better product, faster, with Svelte. The total cost of development goes down, as the productivity is better, bugs per lines less, total lines of code less.
It's basically a different flavor of modern web app development. It's key difference is that it doesn't download a full JS library to the client. The saves some ms/s on initial load. For most applications, that is not really an issue but, of course, there are some scenarios that it suits.
The only problem I have with Svelte is that I can't find a job. Only seen one in the last six months and they bailed after we discussed pay.
I love Vue but I really wanted to work on an actual project with Svelte because the developer experience was fantastic. Guess I'll have to wait a few more years.
Almost every job is react, react, react. It's exhausting dealing with the cultists
> Svelte 4 reduces the Svelte package size by nearly 75% (10.6 MB down to 2.8 MB), which means less waiting on npm install. This improvement will be especially noticeable for users who are loading our interactive learning experience on learn.svelte.dev for the first time, users of the Svelte REPL, and users with limited connectivity. The majority of the remaining package size is eslint support, which necessitates distributing a CJS build, and once the eslint rewrite is completed the Svelte package size can drop by over another 50%.
I'd recommend it to anyone who is focused on actually just shipping UI and making progress (not bike shedding or wasting time, you know who I'm talking about lol).
It is a nice paradigm that lets devs focus on just writing HTML, CSS, and JS with a little bit of teeny tiny magic (it is actually easy to understand). That's it.
What an odd coincidence, after seeing Svelte for years I decided to actually try it for the first time yesterday, and now this drops. To be honest the timing of this is actually kind of a shame (just for me) as I haven't used it nearly enough to be particularly excited about this, but seeing as Svelte 3 was 4 years ago, I doubt I'll see another one anytime soon.
They seem to be doing something of a tick-tock update approach. Not sure if it’s planned or by accident. V2 was a small change, V3 was a big change, V4 is small, and as far as I understand they’re already working on something that might end up V5.
Svelte 5 is speculated to release as early as this year (2023)! Svelte 4 was mainly a maintenance release; updated dependencies, TS to JSDoc migration and more, in preparation for the development of Svelte 5. The reason Svelte 4 is a major version release is due to upgrading some dependencies like the Nodejs version making it a breaking change.
I'm curious what peoples' experiences have been using modern react vs svelte vs whatever else is popular these days. I used react a while back for a dashboard mockup and was pretty happy with it.
Something about svelte being a superset of standard html/js/css that gets compiled bothers me. I realize that the same can be said about typescript/tsx but I feel like in can trust it more... Maybe it's a maturity thing? Or that it's just one language getting compiled to its subset (with syntactic sugar for dom elements)
I hadn't built a proper web app in nearly 10 years until recently. I did do some experiments with React/Redux a while back, and some Angular. While both made logical sense, I found RR quite confusing and Angular very heavyweight.
I tried SvelteKit 2 weeks ago after working through learn.svelte.dev and it immediately appealed to me.
Starting with one file in a route that holds JS, HTML and CSS was great. Breaking it up into components as I went along was natural. I think TailwindCSS helped here too, because I barely had to do any CSS work and could focus on JS and HTML.
It took me a while to understand the value of stores and where to use them, but then I hit upon a use case (big complicated multiple nested tree of mutable data).
After a few refactorings I had a very nice compact and easy to understand solution - nothing like what I experienced with RR and Angular.
I'm a big fan of svelte vs. other frameworks. The closeness to vanilla js and natural coexistence with html+css makes it so smooth to work with and you feel productive right away. Recently built this with it: https://meoweler.com
At least for small projects like this, it's perfect. For something larger/complex I'd be a bit more weary.
* Main search (bottom center, not top right) taking over the screen when you click on desktop is terrible ux
* Should support some fuzzy search or misspelling tolerance, e.g. Cuzco for Cusco
* Valencia, Spain gives a 500 error
* No keyboard bindings when searching to navigate up/down between the matching results (e.g. type in 'Valencia' and I expect I can use the down key to choose which of the three results)
I feel like React is more complicated these days for little gain. I've worked in Knockout.js, Aurelia, Svelte, Vue 2, Vue 3, and now React.js. To me, React.js was more complicated to learn than almost all of them (Knockout.js is older so that felt more complicated to me). My favorite was either Vue 2 or Svelte - they're just simple to learn.
In my opinion I feel like React.js was ahead of its time, but now we're seeing some competitors achieve the same (or better results in terms of benchmarks) with simpler approaches.
Keep in mind these are just opinions, and I'm only about a month into React in a massive web application. That said, it took me like a literal day to learn Vue 2 because it was mostly just like native web development anyways.
I really do like TSX (react + typescript) for the exact things: Functional Components & Hooks - which are basically functional (albeit impure) building blocks for UI things and interactions. Sure, there goes on a lot behind the scenes and so on, but these two things is for me like "perfect" for composing UIs out of reusable building blocks.
But I really hate how react does not have a "blessed"/"official" router or state management, and a lot of "innovation" in this space simply looks like fashion waves nowadays, often reinventing the wheel, and are getting unpopular again over time.
I personally do use Meteor again these days to have real fullstack stuff easily, which has built-in state management (client-only collections work extremely well for state) when things become more complex than a few useState things. Also SSR "just works" with this, since a useTracker (from meteor) is executed during SSR cycle (as opposed to useEffect API calls), including rehydration with a fast-render package.
This absolutely is crucial for my projects, or else stuff like proper SEO is simply a pain in the ass. I would even pay money for react to have kind of renderToString on the server that simply BLOCKS (or awaits) during SSR so that the initial HTML contains fetched data. The discussion about react server components at this point is just comically absurd for me, as if they really want to make the simple SSR requirement as complex as possible for no reason, other than maybe force users into Nextjs so they can make more business from magically working hosting.
> But I really hate how react does not have a "blessed"/"official" router or state management, and a lot of "innovation" in this space simply looks like fashion waves nowadays, often reinventing the wheel, and are getting unpopular again over time.
From an ecosystem view point I think that's really cool! It means that they're not tied to anything and you can pick what works for you. The community, of course, has found its go-to solution anyway, fittingly named "React Router".
The state management situation is more complicated and I think that's even more beautiful, because someone liking Redux can just use it for themselves instead of it being forced on everyone.
The biggest pro to choosing the likes of Svelte (or Vue, htmx, long list of newer frameworks that have learned from React/Angular's shortcomings) is how few footguns there are.
That's really the big thing. I know everyone loves to believe they're masterclass programmers and falling for such traps is beneath them, but after seeing some of these masterclass programmer's react repos... it's very clear why the react docs is filled with many disclaimers and notes (which kudos to the react team for phenomenal docs).
you can download a html page from some website, rename it to `.svelte` and it will mostly work just fine with some minor modifications like remove the html wrapper tag and rename `<head>` to `<svelte:head>`.
I don't think the same thing apply for any other popular frontend frameworks.
I love Svelte because prototyping a new feature in it is really really trivial, even with keyboard interactions and animation effects.
I haven't used it as much as I used react based frameworks, or angular, but the little I've used it I really like the development experience. Plus the payload sent to the end user are much smaller.
Svelte isn't a subset of js/html/css, it just uses them. Svelte does support typescript as well.
Not sure about it being a superset, my understanding is that react is a renderer, whereas svelte is a compiler, basically removing unused code from its std lib, and even converting some code to native JS code. It tries to work with the DOM not around it.
SolidJS is the one I am really excited about moreso though, since it uses JSX and works even moreso with the DOM.
We did a pretty big one, integrated with a python/gtk app [yikes]. Anyways, svelte is a joy to work with, also on the note of libraries, svelte's community is smaller but I found by far my favourite component system I've ever used - https://carbon-components-svelte.onrender.com/.. surprising coming from IBM, but hey, I'll take it.
But in general electron was a pain, slow builds - had an adhoc solution for the svelte dev server, but its not great.
Thanks for sharing. Curious if you know the answer: what’s the difference between a “pictogram” and an “icon” in the components? I looked at a few and it seemed arbitrary?
Can someone point me to a concise location of getting a development environment setup for Docker.
Spent an hour or so after reading this and found conflicting information/out of date documentation. The tutorial[1] on the website is not helpful for actual deployment/development.
I found Svelte for New Developers[2] which is slightly better, however, when building according to the instructions what I expect to happen is not happening. i.e, a static index.html is rendered vs. the src/App.svelte getting rendered.
Wrangling all of this is the worst part of modern day Javascript.
I can't help you with a docker setup, but if I'd highly recommend Vite for standing up a working Svelte dev environment (or Sveltekit, or React, or Next for that matter): https://vitejs.dev/guide/
You'll be up and running in seconds. This is all you need to know:
npm run dev should start the dev server with a page that hot reloads when you make changes in the App.svelte. You selected Svelte and not Sveltekit?
I just went through it and there's an important step of changing into the directory created by `npm create ...` (named `my-svelte-app` in the example above) and then running `npm install` inside that directory.
Can confirm it works for me with npm version 8.5.5, node v15.15.0, on a macbook air with an Intel processor.
npm create vite@latest my-svelte-app -- --template svelt
cd my-svelte-app/
npm install
npm run dev
Started up the dev server, made a change in the App.svelte, and could see it reflected in the browser immediately.
I've heard of Svelte but am not sure exactly what it does. So this time I went to their homepage and it doesn't provide any concise summary of what it is.
If I had to guess, I'd say it packages Javascript up into an application that runs locally, but... ¯\_(ツ)_/¯
It's just a frontend framework for building fast, interactive frontends.
If you're interested in seeing what all the fuss is about and have 5-10 minutes to spare, you could start https://svelte.dev/tutorial/basics and get a pretty good sense of it in less than 10 minutes
One of the platforms I built before used jquery and bootstrap, while it obviously do the job but I was looking to revamp the whole UI, svelte was one of the options as it’s close to vanilla js, react is troublesome unless you enjoy your app breaks next time you update it. The only thing I’m looking for, is there any component based svelte UI I can choose from and quickly build my UI, similar to bootstrap if that make sense, as I usually do embedded development and last thing I want is to work wuth css.
To be more exact on what I want to do: is a dynamic dashboard, where users can add widgets or/and resize them per needed.
I don't use Svelte in my day-to-day (I use React) but I love reading about it and others in the space. We need new ideas and other packages are really pushing us forward!
I have a project I'd like to work on that shares a lot of similarities to how I imagine a "family tree maker" webapp might work, would Svelte be a good choice for it?
Basically I'd need the ability to drag and drop, move the tree around like a Map, detect clicks to add new nodes and new branches, stuff like that. I'm thinking an HTML5 canvas would be best but idk.
minimum TypeScript version is 5, eh? Seems strange since there's no reason listed and TypeScript doesn't do semver but power to 'em I guess for pushing people to stay up-to-date. :)
hope it adds a client side router, and provides a true SPA mode(not the sveltekit stuff), before then, no plan to use svelte again as my use cases is 100% SPA with 0% SSR, absolutely nothing with SSR.
It sounds like you have a misunderstanding about SvelteKit. It does have a client side router and you can use SvelteKit as a pure SPA today very easily, all you need is to set `export const ssr = false;` and `export const prerender = false;` in `src/routes/+layout.ts`. Then export with `adapter-static` and you're done.
I'm aware of that in fact, it's still far from the "pure" SPA as what React or Vue provides. SSR-first sveltekit is not the same as "pure" CSR SPA, and I do not need read all the SSR oriented doc to figure out how to do a CSR SPA. I spent a few months with Svelte(kit) and eventually returned to React.
If ever Svelte does CSR-first SPA with client side builtin router, I will definitely give a second try, until then, React will be my choice.
You would be hard pressed to find a functional difference between a SvelteKit project compiled with adapter-static and a "Create React App" app. If you have any concrete differences, do share them. They're functionally equivalent (except a SvelteKit project is a lot lighter in JS due to the compiler architecture).
There are unfortunately a lot of misunderstandings around SvelteKit because it is SSR-centric. SvelteKit has probably the best interactive docs of any framework at https://learn.svelte.dev/ and I do encourage everyone to go through them to get the full picture!
I just rebuilt a web app in Vue (and Vite), and first-class Single File Components are the dream. Is there anything that even approaches that simply joyful DX?
Just POJS/Vanilla JS with jQuery. I've had good experiences with earlier versions of Vue for other projects, so surely there's some familiarity bias there. I now see that Svelte has SFCs and that Vite supports Svelte, so I might give that a try for my next project.
I've used Svelte 3 and I like it, but honestly this is the problem I have with most JS projects. Svelte 3 had 3000+ experimental features and hacky stuff, why go into 4 when 3 itself has not mature yet?! Software support is basically the thousands of low-paid js dev jobs that companies hire to update their stack every 6 months?
I hear you, but you might be projecting a bit. FTA:
> "Svelte 3 was released more than four years ago! In JavaScript-framework-time, that's eons. Svelte’s freshness has persisted throughout, but Node.js and browser APIs have evolved during that time and today we’re updating Svelte to take advantage of some of these improvements. Svelte 4 is mainly a maintenance release, bumping minimum version requirements and tightening up the design in specific areas."
> "Svelte 3 was released more than four years ago... Svelte 4 is mainly a maintenance release, bumping minimum version requirements and tightening up the design in specific areas."
Major Changes
breaking: Minimum supported Node version is now Node 16 (#8566)
breaking: Minimum supported webpack version is now webpack 5 (#8515)
breaking: Bundlers must specify the browser condition when building a frontend bundle for the browser (#8516)
breaking: Minimum supported vite-plugin-svelte version is now 2.4.1. SvelteKit users can upgrade to 1.20.0 or newer to ensure a compatible version ([#8516] (#8516))
breaking: Minimum supported rollup-plugin-svelte version is now 7.1.5 (198dbcf)
breaking: Minimum supported svelte-loader is now 3.1.8 (198dbcf)
breaking: Minimum supported TypeScript version is now TypeScript 5 (it will likely work with lower versions, but we make no guarantees about that) ([#8488] (#8488))
breaking: Remove svelte/register hook, CJS runtime version and CJS compiler output (#8613)
breaking: Stricter types for createEventDispatcher (see PR for migration instructions) (#7224)
breaking: Stricter types for Action and ActionReturn (see PR for migration instructions) (#7442)
breaking: Stricter types for onMount - now throws a type error when returning a function asynchronously to catch potential mistakes around callback functions (see PR for migration instructions) (#8136)
breaking: Overhaul and drastically improve creating custom elements with Svelte (see PR for list of changes and migration instructions) ([#8457](https://github. com//pull/8457))
breaking: Deprecate SvelteComponentTyped in favor of SvelteComponent (#8512)
breaking: Make transitions local by default to prevent confusion around page navigations (#6686)
breaking: Error on falsy values instead of stores passed to derived (#7947)
breaking: Custom store implementers now need to pass an update function additionally to the set function ([#6750](https://github.com/sveltejs/svelte/pull/ 6750))
breaking: Do not expose default slot bindings to named slots and vice versa (#6049)
breaking: Change order in which preprocessors are applied (#8618)
breaking: The runtime now makes use of classList.toggle(name, boolean) which does not work in very old browsers ([#8629](https://github.com/sveltejs/svelte/ pull/8629))
breaking: apply inert to outroing elements (#8627)
breaking: use CustomEvent constructor instead of deprecated createEvent method (#8775)
These are just catch up releases, nothing seriously breaking.
to give you perspective, Nodejs went from v10 to v20 in the same time frame.
Wow, that’s a pretty big reduction.