Svelte 4
svelte.dev
svelte.dev
Wow, that’s a pretty big reduction.
create-nextjs-app is installing React, React Router, Webpack, Tailwind, ESLint, Jest, etc.
create-nextjs-app is by design an "everything and the kitchen sink" approach.
> 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
Its not zero but quite a big dependency reduction
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."
Sorry, HR rep, I thought we were just slinging pithy aphorisms!
Eh, that's not a fair comparison, Windows bundles the .NET standard libraries and runtime.
> 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).
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.
Edit: The AOT compilation was called "Reactivity Transform" and dropped due to the aforementioned shift away from "real" JavaScript: https://vuejs.org/guide/extras/reactivity-in-depth.html#runt...
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.
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
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?
e.g. https://devclass.com/2023/05/11/typescript-is-not-worth-it-f...
anyway, Svelte is fairly similar to Vue, just a subjectively slightly nicer style. do both tutorials and see which you like I guess?
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.
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.
It's just the problem with the VS Code Svelte extension, not the framework itself nor because of Typescript. Also for my case, it happens because I prefer to not use semicolons in my code, not because it is typescript.
> you clearly don't know what you are talking about.
huh?
Come now. Only one of React and Svelte needs a custom compiler to run in the browser, and it isn't React...
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.
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.
> 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.
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).
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.
I suspect author (Evan) lost interest, given the Vue 2/3 situation (similar to Python 2/3) and the lost battle against React.
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.
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.
The virtual DOM was created to solve browser performance issues with the actual DOM. This may not be relevant anymore, but that's why it was made.
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.
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.
Adore this. Would love to see more JS frameworks reduce their dependency trees.
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!
https://frontendmasters.com/courses/svelte-v2/
From the migration there does appear to be some breaking changes, don't know how that aligns with the course which I planned to take.
His old course was good as well, but that relied on Sapper.
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.
Caveat: since I went react -> svelte it's possible I was just warmed up to JS by that point
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'll be happy to know that those are no longer the default in Svelte 4!
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.
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.
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.
Yeah that toggle has been on there for months now actually
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.
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.
FWIW for simple state management in React I've heard lots of good things about zustand: https://github.com/pmndrs/zustand
It's really quite simple and elegant. Svelte's model would likely be more complex tbh.
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.
Prop drilling in Svelte is exactly the same complexity.
useState() wouldn’t exist because Svelte doesn’t need a virtual DOM and the compiler takes care of reactivity (per the famous React vs Svelte meme).
Stores are way, way simpler than redux reflux whatever else.
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.
- 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.
But I can't come up with any coffee analogy for that, there's just no mapping between those spaces that makes any sense.
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.
Disclaimer: I <3 alpine.js
- 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.
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 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.
> copying similar code over and over
This isn’t true. Svelte is more than capable of reusing code internally.
Just look at their "Hello World" application on the Svelte website. 5 lines of code transform into 45 lines of 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.
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
also
> 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.
All sounds great anyway, congrats to the team!
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)
SolidJS is the one I am really excited about moreso though, since it uses JSX and works even moreso with the DOM.
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)
Svelte isn't a subset of js/html/css, it just uses them. Svelte does support typescript as well.
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).
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.
there are better libraries out there like zustand or react-query which helps on most of these stuff.
Svelte clicked after like 3 hours.
Also it's more "fun" than React ever was.
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.
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.
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.
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 believe the new 1Password app is powered by Svelte.)
But in general electron was a pain, slow builds - had an adhoc solution for the svelte dev server, but its not great.
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.
1: https://learn.svelte.dev/tutorial/welcome-to-svelte 2: https://svelte.dev/blog/svelte-for-new-developers
You'll be up and running in seconds. This is all you need to know:
# npm 6.x
npm create vite@latest my-svelte-app --template svelte
# npm 7+, extra double-dash is needed:
npm create vite@latest my-svelte-app -- --template svelte
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
If I had to guess, I'd say it packages Javascript up into an application that runs locally, but... ¯\_(ツ)_/¯
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
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.
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.
[1] https://devblogs.microsoft.com/typescript/announcing-typescr...
As well as Bloomberg and the NYT sites, and Brave search.
I'm sure there are more, but for some reason people aren't talking about it a ton yet, and it's definitely not as ubiquitous as React
Swing by the official Svelte Discord, we're happy to discuss your questions! https://discord.com/invite/svelte
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.
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!
like git clone repo and then npm run dev ?
StencilJS
SolidJS
Svelte
React
Vue
Angular
> "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."
This seems eminently reasonable to me.
> "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.