This seems like a huge positive step forward for Svelte and the community. Big congrats to Rich!
I've been excited about Svelte for a while and recently chose to use it as the UI for a cross-platform video editing app (https://getrecut.com), with the back end in Rust. I've found it a pleasure to work with -- Svelte Stores and the Context system are especially great for sharing state, and the app feels snappy. Last few weeks most of the focus has been on the Rust backend but I'm really looking forward to building out more of the UI soon.
I've also been happy to find that its generated code is pretty readable. On one little performance-tuning side quest, I was profiling to figure out why the app was performing a Layout on every video frame, and I was able to step through the compiled Svelte component code and narrow it down to one of my own functions. I also briefly went down a path of trying to manually set the text content on an element, to see if it'd be faster than letting Svelte do it. Turned out the answer was no, but it was nice to know that level of control is available if I need it some day.
Excited to see where the Svelte community goes from here!
Also curious - I'm spinning up a small side project with Rust and Svelte. Was looking in Tauri as a replacement for Electron but wondering what other approaches people have worked with (assuming this is a cross platform desktop app, that is).
Tauri seems like a nice option. It's not as full-featured as Electron yet but their focus on security is great to see (last I saw they were getting the codebase professionally audited). The main reason I didn't go with it was just that doesn't seem to (yet?) suit my use case with zero-copy data transfer between Rust <-> Browser.
My hope is that by writing most of my backend in Rust, that it'd be easy-ish to switch to Tauri or other options if something changes down the road.
I'm using quickjs (rquickjs specifically) to bind GTK's C API to Javascript and adding a light DOM wrapper (get/setAttribute, add/removeEventListener, etc) that covers all the functionality Svelte needs. I've had to make a few modifications to the compiler (<10 lines total) to get binding and CSS working but so far it's been great.
Working in GTK with hot reload and instantaneous esbuild rebuilds is.... insane.
Yeah, rewriting it with Electron + Svelte + a Rust backend for the heavy lifting.
I looked at alternatives to Electron because I wanted to avoid the bloat, but nothing felt like the right fit. Tauri (https://tauri.studio/) is the most exciting, but I couldn't find a good way to get raw video frames into the UI without a bunch of expensive copies or serialization. I also looked at native toolkits like Qt (I've worked with it in the past) but I didn't love the idea of building lots of custom UI components without the benefit of HTML + CSS. So for now it's Rust + Electron, and I'm paying extra attention to performance.
My thought process was, if I’m gonna have to rewrite the app, I may as well use the web dev skills I already have, so that at least the UI work will be in my wheelhouse. Rust is new to me, as is low-level ffmpeg stuff, both of which I’ve had to learn from scratch.
I learned Swift in order to build the Mac app, and I know from that experience that building custom UI controls while learning a new ecosystem slowed me down a lot. I didn’t love the idea of repeating that experience, and where I’m headed there’s gonna be a good bit of custom UI.
Sounds like an easier process for you, but at the cost of your users. This proliferation of web tooling when it clearly doesn't suit the environment (desktop) is part of the reason why our software is getting slower, even as our hardware is improving.
If dceddia is able to add features and fixes more quickly, that's good for users too.
And if Svelte on the desktop becomes popular, people will likely come up with more efficient options. For example, a more efficient Electron or something like "Svelte Native", which could be a good thing.
I'd love if all software were more efficient, but getting up to speed on a new platform has a huge opportunity cost too.
Being very conscious of those downsides, I'm putting in extra effort to make sure it's fast. So far it seems to be working!
It uses less CPU than any other Electron-based video apps I've seen (and even less than a few Qt-based editors I tried) and it feels snappy.
I think tools like Figma have shown what's possible when enough attention is paid to performance early on – but yeah, it's one of my main worries with going with Electron and I'm trying to avoid the downsides as much as I'm able.
The ones I have less control over are memory usage and disk space. I'd love to get those down but it seems like that'd require digging into Chromium and ripping things out. Which, honestly, I looked at doing, but that code base is a beast and I'd rather get something into peoples' hands sooner.
On a related note: I think there's a real opportunity for an "Electron Lite", like some kind of custom Electron/Chromium build that turns off stuff you don't need. I suspect it could help disk usage + memory usage + startup time. Chromium's build system has lots of flags that make it seem like you can turn things off. But it didn't work that way when I tried, so I think it probably requires source-level changes, which then means maintaining those patches across Chromium updates etc. But really, though: I don't need WebRTC, or printing, or media codecs, or probably a zillion other things. It'd be so cool to be able to turn those things off at will.
That sounds like a responsible way to divide focus. Kudos
I forget the word or the link, but I think there was a "rule of thumb" thing that circulated HN about having a limited budget for taking-risks/being-bleeding-edge, and focus in spending that on differentiating properties of your projects, while the rest should stay "old and boring"
React-native might be the close to what you're looking for at the moment. But the ecosystem is still tiny on Desktop, and I don't think it supports desktop linux at all.
Are you referring to ease in complexity of creating components compared to the alternatives? Because I end up with the same choice when sieving frameworks to use crossplatform. But I've been looking nto Flutter recently, although it's still in beta, it has potential.
Yeah. I talked about this in another reply but I’ve had mostly web development experience over the past few years and UI work is familiar. I didn’t love the idea of having the entire tech stack being unfamiliar. (I’m already new to Rust and ffmpeg/video stuff)
I looked into it at one point and it sounded like WASM isn't as fast as native (yet?), and the main benefit would be the ability to run in a browser. That'd be useful for making a web version and I might look into it again, but for now, if I'm already shipping an Electron app, WASM seems like extra hassle with less speed. I might be wrong about this though! Happy to hear if there are benefits I'm missing.
It's pretty dam close to native. I would consider researching it again. You could do away with Electron altogether and just run it in browser. You can make it a PWA to give it that "Native app" feel so the users are none the wiser but you don't have to deal with the complexities of Electron and managing releases etc. If you want to launch a new release just deploy it to your web host and you're done for all platforms.
This is all assuming there isn't some specific OS level requirements in your app. I know there are other video editors using WASM successfully and apps like Figma.
Do you have a mailing list I can toss my email on for when this is available on Linux? Honestly I was ready to buy it instantly before I saw the platform limitation, but it would be even better if it could run some basic filters like removing pops and de-essing, which I always struggle to get working right in Audacity (I have a screenshot saved of my filter curve because Audacity doesn't save it, it's so stupid).
It's not Linux-specific but you can sign up to hear about the Windows one (click the "Get Notified" button on the home page) and I'll let everyone know if/when there's a Linux version.
Fair warning I haven't even tried getting it to run on Linux yet... but I've been meaning to try it out, if only for the profiling and debugging tools! (rr looks really cool!)
In theory it runs everywhere because Electron, but my gut says the difficulty with supporting other platforms will come down to compiling and packaging. That's been the biggest hurdle with Windows so far anyway.
Linux packaging can definitely be confusing -- as a user I definitely prefer something like an AppImage for a program like this, which should be easy enough to provide. I wouldn't worry about making distribution specific deb and rpm packages, personally.
That's still all web tech, though. Druid and Iced look more interesting, as they are general UI frameworks which lets you build both web and desktop apps without dealing with HTML or CSS.
I do React for my day job. For personal projects and MVPs, I came back to Rails and it has been insanely fun. I can drop in whatever frontend framework I want or none at all.
With Sveltekit, you can actually build your back end with it as well. The path based routing is so nice and intuitive (compared to my recollection of Rails 3.x), and if you compile your SvelteKit application with the node adapter, it will include a back-end server too.
The only catch of course, is that you have to like both Svelte and NodeJS.
Is there any reason why something like Svelte couldn't be written in one of the lisply languages? The compiler approach seems definitely like a good fit.
Consider trying to hire outside Svelte - Anyone that can write using the major frameworks will do just fine. If the problem is candidates uninterested in using it, that's a different problem.
I think the problem Svelte is having in this area is folks looks at it the same way they look at React, Angular and Vue. All those frameworks (especially React and Angular) have their own way of doing things, so you have to know "HTML, CSS, JS and React/Angular".
I think folks think that Svelte is the same way, while it does have it's own special sauce, it's nothing compared to React/Angular. Like others have said, when hiring for Svelte, you don't really need the candidate to have Svelte experience.
I think stencil or Lit are more interesting. I'm not sure I'm the fan of small libs like Lit or preact - I think for scenarios where you have more than 2-3 elements you will have less bytes over the wire very quickly.
Started learning JS a few years ago. Picked svelte for my front end stuff because the other frameworks seemed saturated with experienced devs already and I wanted to be closer to the ground floor on something. I've been waffling the last year or so, wondering if I should focus more on NextJS because it was backed by Vercel.
I breathe a little easier today! This is great and can only be a good thing for svelte and sveltekit.
Thrilled to hear it! As someone who has primarily written back-end code, I found Svelte to be the most accessible (readable, good/simple docs with lots of examples, easy getting started instructions, clear conceptual framework). Eager to see what comes out of this.
Well, this is awesome -- but fuck me: Vue is the only major player not under the Vercel umbrella now, haha.
Looks like I might have to phone in half a decade of experience.
Svelte is close enough to Vue with "script setup" mode anyways, the major difference is whether your logic/keywords go INSIDE the HTML tags or OUTSIDE.
I love Vue because I come from a bygone era of HTML + sprinkling jQuery as needed. 99% of the websites don't need a full blown JS frontend but everyone is doing it, I must be wrong.
Do you work with a designer? I’m convinced most of the push for JS apps as pages is mostly perpetuated by designers who don’t know how the DOM works and feel the need to redesign the wheel on every project. I work within a company that provides a design system and a platform of hundreds of generic component, but individual designers still always want to push their particular vision.
I think if most designers took existing web elements and tried to build a UI, instead of drawing an arbitrary picture and asked devs to implement, we would have much less JS overall.
No, we don't have a design team, we're too small for that.
Just that our backend is already built using Django many many years ago. If I need to add some interactivity, I use jQuery currently. Looked into Vue and it allows us to keep everything as is in the backend and use it like jQuery.
I shudder everytime I need to install npm, webpack, gulp, etc..all the JS tools feel super flaky, unnecessary and does not inspire confidence in the tooling. That's my take anyways.
Lot of developers don't have the priviledge of starting a new project. It's an existing doctors appointment website or some shit people cobbled up in PHP in 2004 that is still running and we need to maintain it.
> "I shudder everytime I need to install npm, webpack, gulp, etc..all the JS tools feel super flaky, unnecessary and does not inspire confidence in the tooling. That's my take anyways."
For context, I started doing web dev back in ES5 JS, jQuery, Angular.js (1), and server-side templated HTML views days.
I write in a lot of other languages as well, and I would hear people say this and not get it. I thought to myself:
"It's not THAT bad. I think the experience is fine."
Then I wrote an app recently on the JVM. Sweet jesus the JS/Node ecosystem is a nightmare + house of cards.
The JVM and CLR (.NET) have their stuff together. I need like ~10 dependency libraries to do a large project, and often times they are over a decade old.
The tooling is on another level.
I don't have PROBLEMS writing TS apps, and the experience is good. But some of them have a dependency tree that span thousands of packages, and I've come back 2-3 years later to try to run a project and had some downstream dep break, and then updating fails, and then...
I know it's somewhat of a meme, but this is unironically why I find Deno interesting. (Disclaimer: Haven't shipped anything with it)
Especially since with the most recent release, they have an option to emit Node-compatible JS bundles from Deno code.
I totally identify with your aversion to build tools, but things have changed for the better in the last few years.
My advice would be to check out Vite, and use it with Vue. I've introduced Vite/Vue2 to a pre-existing Django project and couldn't be happier. I've explored a number of different approaches for integrating Vite and Django, and this blog had the best approach, IMO: https://weautomate.org/articles/using-vite-js-with-django/
I find that Svelte is the most "jQuery-friendly" of the frameworks. I can easily add a single Svelte component back into other wise static pages without requiring anything other than a simple build tool to output the JS + css. It's really the best of both worlds – sprinkle it in where needed, or go whole-hog.
Yeah, I really like Svelte for this. I did a whole blog post this way, with little embedded animations to show various operations on linked lists. Each of the animations is a Svelte component, but the surrounding page is just a static HTML page created from Markdown (using Jekyll as the generator).
It's nice that Svelte components can be independently mounted like that.
To be fair, the same thing would be possible with React or the other frameworks. I do like that it's only 29kb of JS for all those animations though (and most of that is the SVGs, I think).
Product designer and HTML/CSS person here, and in my experience it is the opposite. Designers and front-end focused people wh get a chance to work with Vue love it because it actually respects basic HTML/CSS/JS and doesn't encourage doing everything in JS, unlike React which basically forces your hand. This makes working in Vue (and Svelte) so much more accessible to people who are great at HTML and CSS but not JS as much (and in my experience many React devs are great at JS and terrible at HTML/CSS).
Designers more often know HTML and CSS over JS, so it is unlikely they are the ones pushing for JS solutions. It is the developers who don't know how to implement designs without falling back on JS for everything who are causing this paradigm.
That being said I blame a lot of this on design tooling as well. Figma and Sketch are custom rendering engines that just don't understand HTML and CSS and therefore give no opportunities for designers to learn how the web works. Fortunately a new generation of design tools are coming that are built on HTML/CSS renderers that feel like Figma but actually output usable code for devs to interpret into their projects.
> Fortunately a new generation of design tools are coming that are built on HTML/CSS renderers
These days I spend more time in browser devtools than Figma, and honestly I'd prefer a more visual way to edit code directly. Something like Webflow but without all the cruft behind it. Preferably built into devtools, maybe as an extension
Well, I guess I'm wrong too then, as most web apps I create are SSR (with dotnet), with a sprinkling of vanilla JavaScript. Previously I used jQuery, but we're finally at the point where it's not necessary.
Lee from Vercel here. The governance of Svelte isn't changing – it's still the same independent, open-source project and community. We're just supporting Rich and helping the project grow!
Absolutely, but in my mind this means Rich/Svelte have been "blessed", and I've built enough Next.js apps to know that you aren't going to find a better Dev UX/superior experience to what Vercel is providing.
Benefits of being a framework owned by a business that makes a lot of money off of it.
Next.js 12 as any indicator, I'm just going with whatever falls under the Vercel umbrella now -- I can tell you that Nuxt is not a competitor (as an unbiased voice and someone who doesn't particularly love React).
> We're just supporting Rich and helping the project grow!
I'll admit that I have a negative bias towards this... in spite of Basecamp+RoR, Mozilla+Rust, or all the great OSS HashiCorp makes, it's still hard for me to believe that business do anything out of the goodness of their heart.
Is there a strategic goal for hiring Rich? is it that Svelte is used so much in house that it only made sense to support it? Is it to get more cred with developer by supporting projects they love?
Again, sorry if this question is to skeptic and cynical... I love to be wrong on this! :)
In the case of Vercel, I'd imagine that improving svelte's reach positively affects them commercially seeing as they're a major player in the relatively small market of svelte hosting.
This is the standard narrative when OSS contributors got hired but ok, I'd write the same.
But then just tell us what was the motivation of Vercel's shareholders and CEO to acquire Rich for such a high price (he is the compensation and ESOP you pay absolutely worth) but what's your gain? "Just supporting Rich and helping the project grow" or just buying him out of the market?
On a high level: if Svelte succeeds, the Web succeeds and Vercel succeeds.
More concretely: we want Rich to help shape Vercel's support for frameworks as an open platform. We want to hear how, as a framework creator, the platform can best serve him. We project this work will have ripple effects like making Astro or Remix better on Vercel, or the next framework you invent. You'll hear about this work soon.
We want to hear what edge infrastructure would make Svelte the fastest for developers and visitors. We want to also help him build a better Svelte by connecting him with customers who are betting on it in production. We want to learn from his DX expertise so that we can make better products.
We are very excited about this and we think betting on Open Source for the SDK together with an Open Platform for infrastructure is the only way to succeed in our space.
This is a really cool idea. This has always been my biggest beef with single file components. It never occurred to me that you could do this with Vue. Thanks for the tip
Admittedly I haven't followed Svelte super closely, but isn't "no JSX/TSX" kind of a major ideological point? From reading the intro docs, it seems like separation of js/css/html is a selling point. JSX/TSX would contradict that, no?
Just wondering if my read is correct or if there's some other reason it's been left off the table.
Nobody truly separates JS from HTML. You either have to put something HTMLish in the JS, or something JSish in the HTML (HTML itself supports this of course).
IMO the HTML-in-JS solutions (i.e. JSX) are superior to the JS-in-HTML solutions (e.g. Angular/Vue Templates) because they put the standardised turing-complete language in the driving seat rather than the propriety, hard to extend template language.
Still, it's way easier to integrate a js library in a svelte component than in a react component. So maybe the two approaches have different tradeoffs and respective advantages
I've been using Solidjs the last month for a project, and I really like it. Small bundle size, super fast, not much to learn, not too much magic, lots of control. Basically instead of having a vdom the framework is able to track finer-grained reactive sites and update those when the data changes.
If no one has managed to add JSX, I believe it would be feasible to implement. The Svelte compiler is pretty straight forward to interact with. However, I have little experience with the semi-standard build toolchain for Svelte that most people are using. You would of course need to import React.
Now in all seriousness, JSX does have its benefits like being able to write a small function that returns a piece of JSX. But in my experience, using Svelte is a huge productivity booster than I don't mind losing JSX's benefits.
>Let's retire the 'virtual DOM is fast' myth once and for all
>Rich Harris, THU DEC 27 2018
>If you've used JavaScript frameworks in the last few years, you've probably heard the phrase 'the virtual DOM is fast', often said to mean that it's faster than the real DOM. It's a surprisingly resilient meme — for example people have asked how Svelte can be fast when it doesn't use a virtual DOM.
>It's time to take a closer look.
>[...great article...]
>Why do frameworks use the virtual DOM then?
>It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones.
>But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in.
Seems more like variety. React is in a league of it's own with React Native. For web tech Svelte is cool, for app tech it's not on the radar.
I used to be a web developer, now I'm a React Native / RNW developer.
I don't use web tech unless I'm making a simple web page, when I do I use vanilla HTML/CSS/optional JS.
You get a web app for free when you make a RN app. You can share 95% of code among 5 platforms. (web, windows, macos, ios, android)
Conditionals can change any styling you need amongst them. You can swap out scripts depending on platforms, you can access any extra native platform function with extensions.
Svelte doesn't work for me because you need JS. I don't want to need JS for simple web pages, for apps I need cross-platform.
Svelte could work well for edge computing like CF workers.
How is RN? I have seen several teams try to consolidate their App Devs into RN devs, only to split back into iOS/Android devs. From what I’m told, if your app could be a webpage, RN is great. But if you need to really leverage the specific platforms, it’s hard to do that.
> But if you need to really leverage the specific platforms, it’s hard to do that.
Not my experience. I have a production app for web, ios, and android, with desktop platforms coming.
You can swap out anything per platform and write any extension for any native functionality you don't have, but the std and community extensions are plentiful.
RN sucks for "web pages", great for apps. In fact sometimes I embed web pages inside my RN apps. (surveys, etc.)
I haven't heard a single good argument of why it doesn't work. If you were going to write a native app you can write a native extension and share the common parts in JS.
RN is not Cordova, it's not a black box, it's very flexible and extensible.
-- @Jcampuzano2 because of post limit --
Earlier yes there's some fickleness with the toolchain, I don't really have issues now, it's fine unless you're on bleeding edge versions or old versions. Performance issues usually relate to the JS bridge, JSI will alleviate that, most devs won't experience an issue. I don't know why others struggle with RN, it works well for me. Flutter is a no go because it emulates native, it's not true native. You can feel the difference on iOS and the web part sucks so hard.
Weird because this is the exact opposite of everything I hear from most developers I know.
I personally also worked with React Native for a while, and sure, you can write native extensions for everything, but the biggest complaint is how fickle it is when it comes to upgrading, package management, mind boggling errors related to the metro bundler, etc.
I.E. It's great when it works and you have something simple, but things broke so often compared to native development when you had to do anything complex. And the performance characteristics weren't very great on top of this.
I haven't done React Native in a bit more than a year but from people I talk to not much has changed, and most people I talk to who were all in on React Native mention to use Flutter instead nowadays if you really want cross platform UI.
react native can definitely ship production ready applications that large teams work on. bundler problems arent even react native related.. theyre webpack/babel etc. Package management? how is that related to RN?
Because you never have to deal with that stuff in mobile apps unless you use react native? So sure maybe it’s not directly react native’s fault but it is an issue.
you will always have to manage dependencies somehow. Maybe you prefer the model used by flutter or something, thats preference. Its not a matter of whether of one is unsustainable or not. react native is fine for professional or hobby projects. even if you have problems with babel/webpack/etc bundle server (which btw can be worked around using inline bundling...)
This thread initially started by me comparing Svelte to React.
React uses webpack usually, RN uses metro usually, you can use esbuild, swc, etc for either though.
Svelte is a web tech, and thus uses web bundlers like webpack, thus has the same "faults", though I'm not sure what specifically is being critiqued.
When comparing RN to other cross platform solutions like Flutter you're wanting to compare it's package manager / bundler to Metro and the native dependency systems such as Cocoapods.
My experience with the tool chain was abysmal. It's been almost 3 years away now for me, so I don't know the current state of things. I hope it has improved.
But every update was a large effort in bringing the app back into compliance with the new changes. The debugging platform used a different interpreter than in app resulting in things that worked in the debugger but not in production. Odd bugs at boundary layers nobody could (easily) decipher. The inability to even catch or do anything with some crashes.
It was the worst experience I ever had with a development tool chain in my entire career.
Disclaimer, these memories are about 3 years old...
> What discrepancies did you notice? It depends on the target platform which JS engine is used. Sometimes the debugging platform shares the same engine.
Exactly what I said, there would be some code that would run differently in the two environments. I know more now than I did then, but I believe the example was specifically on iOS the app was using JavaScriptCore and the desktop dev tools was using v8.
> I'm not sure I understand, could you provide an example?
> Strange, you're able to catch and debug both JS and native crashes currently. I'm not aware of a past limitation but I could be wrong.
Best as I recall, there was a semi-frequent bug that happened down in our logging system. When it blew up we got a native stack trace instead of JS. My best guess is some kind of handshaking problem between the two layers. Neither used code we wrote and maintained.
Because the whole thing happened inside our error reporting engine, it wouldn't end up in our logs other than a high level apparent failure. It was a mess, and we had limited native experience on the team when it happened. We hired a dev with more native experience, but we still didn't ever figure it out while I was there.
The tool chain always felt like it was a hacked together early beta. To complicate our experience our internal APIs were a mess and unreliable and our React Native codebase wasn't dramatically better. Between our internal problems and all the idiosyncrasies and unintuitive issues in the tool chain it was really miserable.
It wasn't unusual for everyone on the team to spend more than a day simply trying to get the app running again after an update, that is after a dev had completed a 1 to 2 week migration required after the update.
To me, it's uplifting the entire web ecosystem. There will always be developers who pick Svelte and friends over React, even if that reason is just syntax preference. Those developers should still have the best infrastructure for their apps. Better to be pragmatic than over-prescriptive.
If you are building a platform for web dev, it’s better to be able to control your technology. Any change FB makes to React may leave you scrambling to patch your tech. Or What if one day FB decides to stop supporting React, or they make a design decision incompatible with your business? While it sounds unlikely, it’s bitter pill to swallow from a business angle.
And then you would probably be forced to support classic FB React for customers that didn't want to migrate, and forked React.
The real issue is if you build any special sauce on top of React. Say you went all in on providing a customized React.Component that worked like a React.Component, but had your platform's logging, perf metrics, etc built in. Then React comes out with hooks and functional components and then you are stuck trying to reimplement your special sauce using these. Or you have to tell customers, "we only support class based components." While functional components are old, FB has shown it will introduce paradigm changes into React, and you are left holding the bag when it comes to supporting them in your platform. And if customers saw a new React feature previewed yesterday, be sure they will be asking for support for it today. FB isn't likely to hand over React to Apache or any sort of open governance model, so changes can be easily made without a huge amount of forewarning, or even a business relationship. Last time I checked FB wasn't selling support contracts or partnerships for React.
Wow, this should be great news for Svelte and SvelteKit! Hopefully with Vercel's backing these projects will fly off.
Having worked with React for about 5 years (with a project in Vue in-between) and now having dabbled with Svelte, there is just something more appealing working with less higher-level abstractions. Sure with large apps React does have its benefits and its ecosystem is larger by a good amount.
But there is just something about being less annoying that to me is perhaps one of the most important things with any tool. If I enjoy using it, I don't mind that it may not be the "current best choice" of the moment. People who enjoy MobX especially I think ought to find Svelte quite nice.
Sure though would wish SvelteKit was at the same level with Next.js. Fixing dev server errors is a little distracting at times.
> Fixing dev server errors is a little distracting at times
You will be very pleased with the upcoming release of Vite 2.7! It's by far the most impactful release of Vite thus far for SvelteKit. All the major known issues we've been tracking have been addressed in the latest Vite 2.7 beta (assuming that one of the PRs we're still working out the kinks of doesn't get rolled back, but either way it'll be a huge improvement!)
Svelte’s ecosystem is, in practice, actually much larger than React and any other framework because Vanilla JS works out of the box without framework specific wrappers. So just about any JavaScript package can be imported into a Svelte file and used without hassle.
The last place I worked was a React shop, before that I did most of the frontend as well and used Vue, Current place uses Svelte and I'm really glad they did/do, the continual surprise is how Svelte makes easy things easy and hard things doable.
Cloudflare will regret not having a developer go-to framework for their advanced Worker stuff one day.
I think they are waiting for someone else to build for it which is IMO the completely wrong approach for the dream of the serverless app. You got to own the full stack including software.
I can easily see Vercel becoming the pretty much only go-to in this space just from the developer trust they have created with Next (and now Svelte). The general getting started experience between the two serverless providers is night and day.
One is where do I begin / how should I do this (cloudflare).
The other is simply code... and... go! (vercel)
I'll be all in on whatever Rich makes there. Been waiting for a solid Cloudflare Worker framework for literally years bridging front-end and back-end. Instead, we got Pages (which is cool, just boring for the fun stuff).
Vercel is built on cloudflare workers meaning vercel winning means cloudflare wins. Also I think building out the datacenters across the globe is a much harder problem than building out a framework.
That animation in the background could use a little optimization. It's redrawing nonstop for no reason. Left the site open for a few mins and it got my humble Thinkpad's fans going hard (Vivaldi).
making a framework popular is harder than making data center stuff; people successfully rack boxes and crank rust/go/js/.. every day, but most js frameworks fail
I do think it's interesting how they've positioned Cloudflare Pages. Kind of an "Amazon" move. Unlimited bandwidth and seats. Will be interesting to see though if it works for Cloudflare, they still don't even have Gitlab integration.
Cloudflare currently markets successfully to a very different calibre of engineer. Meanwhile, Vercel don't even support 2FA login yet, and publish mandatory cache-busting query string parameters to the public Internet. Their "CDN" is a BYOIP range running on AWS Global Accelerator
Hey! Guillermo, CEO of Vercel here. Security is the absolute top priority at Vercel, and you should be seeing continued progress in that area in the coming weeks and months.
We're heavily investing in security all the way from the SDK and its supply chain[1] to platform, product and cloud.
We proudly use the best infrastructure and products available to help our customers scale without stress. AGA is quite incredible[2] and so is Cloudflare[3] and we are honored to be able to work closely with the purveyors of the finest infrastructure on the Internet!
Thanks for chiming in here. Unrelated, I saw that Vercel is ramping up hiring for designers. I’ve always worked in consumer-facing design spaces (banking, travel, etc.) and want to make a change toward something more dev-oriented like Vercel, but I worry being told that “I don’t have the right experience”. Does Vercel hire folks looking to change the industry they design for? I’m a senior IC in design systems, so the extent of what I design for devs is mainly documentation sites.
Absolutely. A core goal for us is to Lower the Barrier of Entry[1] to building for the Web.
Building a beautiful and fast Web experience needs to feel myspace-code-easy (or as Rich Harris puts it: it has to be fun!). I think ultimately that's what makes the Web win long term. It's open and accessible.
The best way to contribute to this mission is to come in with a fresh mindset, passion and big ambitions. Please reach out: https://vercel.com/careers
They do have https://flareact.com/ and although it is still early, it is very promising. They have used patterns from Next.js so it is easy for developers to migrate.
Cloudflare seems to be disciplined about releasing solid lower-level platform building blocks first (e.g. durable objects), and leaving the "developer go-to framework for their advanced Worker stuff" to be built on top later.
Seems like a smart approach to me, but I agree the space is moving fast and even though they release stuff at a pretty rapid pace, it never seems fast enough for early adopters
As a heavy contributor to SvelteKit, I can't see a loss in neutrality happening. I personally use other hosting platforms frequently with SvelteKit, both Rich and Vercel have expressed they want to avoid this outcome, and other SvelteKit maintainers work full-time at Vercel competitors and also wouldn't let that happen ;-)
Yes! To compete, cloudflare really needs a nicer "full-stack" experience where you have one repo, one config file, one CLI and one codebase that is shipped automatically into pages and however many workers, dns rules, kv stores, durable objects, Images and Stream deployments etc. They have Wrangler but it doesn‘t really feel "complete". At least they should rename it to cloudflare-cli and cloudflare.toml.
i just started rebuilding my personal site with nextjs but the enthusiasm here is pushing me to try svelte for the first time.. guess ill have to take a look at the feature list
It is really worth it. Svelte is sooooo much better than React. Believe me, I was one of the skepticals about the entire SPA thing but after trying Svelte I think my problem was with React, not with the concept per se.
i dont actually have any problem with react, but im definitely open to new things this thread reveals to me that this Rich character has some useful information i should look into.
Surgical = "It checks a diff of what the component rendered before an update vs. after and then only patches or updates the parts of the DOM that need to be changed (as opposed to replacing the entire DOM, which is slow)." Similar to React. Svelte may not be using the exact same mechanisms but this is in the ballpark.
Virtual DOM is just an in-memory representation of the DOM that describes which child elements (e.g., a <p /> nested within a <div />) belong to which parents, and which attributes/values those elements need at render time. When a change happens, you can generate an updated virtual DOM and diff it against the previous (or current) version and pick out what specifically needs to be changed in the DOM (read: surgically).
There is no diff going on with Svelte. And there doesn't need to be an in-memory representation of anything. Because it is compiling the code, it knows exactly what will change and in response to what.
For example in that repl, you can see that it makes a call to `$$invalidate` when the input value changes (see `input_input_handler()`) which triggers a `set_data` call (see `p()`) to update just the textNode that contains the name. This is what is meant by surgical. No other work is done other than what is required to update the specific places where a variable is used.
When your React component renders, it returns an object that describes the
desired state of the component tree. Take this component:
function MyComponent() {
return <div>Here's <b>bold text</b></div>
}
At runtime, React calls your component function and then applies the returned
data to the DOM imperatively. If your component has rendered before, React needs
to _diff_ the virtual DOM your latest render returned against the VDOM React last
applied to the real DOM. Very simplified idea of what happens on every render:
function reactInternalRenderLoop(root) {
const newVdom = MyComponent({})
const diff = diffVdoms(root.prevVdom, newVdom)
for (const change of diff) {
change.applyToDOM(root.domNode)
}
root.prevVdom = newVdom
}
React's runtime time complexity is fundamentally limited by this `diffVdoms`
function, and React's memory usage is fundamentally limited by the size of the
VDOM returned by components.
What Svelte does is entirely eliminate this whole process involving diffing and
what-not. At compile time, Svelte analyzes the data dependencies between the
rendered template and reactive values in the app, and generates self-contained
components that know how to update their own DOMs. You can think of it as
essentially moving the entire `reactInternalRenderLoop` function from _runtime_
to _compile time_. There is no more diffVdoms function call on your user's
devices. There is no more big allocation of VDOM data structures.
Svelte might compile `MyComponent` to something that looks like this:
And since the Svelte compiler knows the contents of MyComponent never change,
the mount function will only be called once for the entire runtime of your app.
So it sounds like the tradeoff here is that the generated bundle is more complicated/bigger. I'm not familiar with Svelt, but wondering about bundle size + debuggability.
When I tried Svelte a while back (year or two ago) I had difficulty working with code in the debugger, couldn't seem to get source maps to work correctly, I wonder if it's fixed.
At a certain size, yeah the bundle will be larger, but it would take a lot to get to that point. For pretty much anything you would do, the bundle will be much smaller. Especially if you use SvelteKit which is smarter about what is bundled and when it loads.
As for complexity, the generated Svelte code is extremely readable. Take a look at the generated JS tab in the repl: https://svelte.dev/repl
Awesome news! Having worked with frontend frameworks for years, I've grown pessimistic about them in general, but I'm enthusiastic about Svelte because it does so many things right that actually avoid a lot of the issues other frameworks claim to solve but actually make worse.
Interacting with the Svelte compiler is ridiculously easy. Though the documentation can be improved, I found it trivial to import the Svelte compiler and prerender a component into an HTML string. Yes, this is somewhat of a niche thing to do, but I appreciate it when libraries and frameworks make it easy to access its internals. Heck, I pretty easily managed to implement Typescript support for Svelte components using Deno's `emit` function; hooking into Svelte's preprocessing was trivial, the complexity I ran into being on the Deno side.
Contrast that with Ember, which seems to have an attitude of "no one would or should ever want to do that", making it really hard to do anything slightly off the beaten path without lots of trial and error or entering the Ember inner-circle.
Yes, I know I'm comparing a component library to a framework, but what I'm commenting on is more about development philosophy.
It's good to hear the creator of Svelte will be able to dedicate his time to it and be able to provide project guidance. I think he has the right vision for what Svelte should be.
Ember was the first framework I used and also the most frustrating. At least with Vue and React I can poke at the internals and they make sense, but Ember's internals had so many oddities that thoroughly confused me.
What I like about Ember is that it gives a lot of rigid structure that, at least at one point, made it comparatively easy to work on multiple Ember based projects and be productive sooner.
As you've pointed out, a problem with that project is that there's a ton of intimate knowledge for how things work under the hood or why things are the way they are. They also seem to oscillate between opting for simplicity and opting for complexity and magic.
One example would be the latest version of Ember which doesn't even ship with `@ember/render-modifiers` by default despite how everyone will end up installing it out of necessity anyway.
Why might that be, you may ask?
> [...] we recommend using these modifiers with caution. They are very useful for quickly bridging the gap between classic components and Glimmer components, but they are still generally an anti-pattern.
Why on earth did they reinvent components and ship them without providing the supposedly correct way of interacting with their lifecycle? You actually have to install a separate add-on to develop a production-ready app with Ember, which completely flies in the face of the idea that you can run `ember new` and have pretty much everything you need. Go ahead and try interacting with individual elements of a Glimmer component in a vanilla Ember project and see how productive and ambitious your web app will be.
Strangely (and thankfully), the RFC for what I think is a needlessly complicated alternative for lifecycle interaction is effectively stalled:
By their own verbiage, the only official way to interact with component/element lifecycle is an antipattern.
So far Svelte and SvelteKit are avoiding all that extra crap. The day that Svelte calls its own solutions "antipatterns" and spends years pontificating things like the actor pattern will be a sad one.
And I shouldn't have made it about that. As I get older I the more I just get tired of extra things. There's always a price when you add more things. Svelte technically does add things, but I think it has better bang for its buck. The fact it doesn't pointlessly impose OOP constructs upon the end-developer is a big win for me.
Why is this 'awesome news' for us devs, the market and competition if one vendor now controls all modern SSR frameworks plus significant parts of the tool chain (swc)?
Does Vercel actually “control” Svelte, though? The existing governance structure is untouched, they’re just paying the salary of the lead (and definitely not only) developer.
Not sure if this topic is worth our time to debate. There are millions of ways of subtly controlling/influencing entities. And it's much easier if you pay money, ESOP and pay even more money if future goals and exits come alive.
Yes sure and it's not Vercel's fault that there's no other competitor left out there. I would have hired Rich as well if I were Vercel. But the market will suffer because one (and the better) player just left the market. We can only blame Rich who got weak but yeah, nobody is perfect.
Calling someone weak is a personal attack. You are not Rich. Don’t speak for him or his attributes. Keep the discussion constructive, you’ve already been asked in this post to calm down the personal attacks even after Rich gave you a kind reply
Even if Vercel came out and said “we’ve bought Rich Harris’s voice, every choice will be controlled by us” (which they haven’t!) they still wouldn’t control the project because Rich isn’t a BDFL.
If we have such trustworthy markets and competition, then how the hell did we end up with React and Angular, huh?
Ayn Rand sucks at software design, as much as she sucks at philosophy and economics and social design and writing. Your trust in her is certainly misplaced.
Anyway, why do you have such a huge problem with Rich acting in his own best self interest, that you found a need to personally attack him so viciously and often as you did in this discussion for all that he's done for himself and the Svelte community?
Don't you believe the invisible hand of the market, which you trust so much, will prosecute your vengeance on Rich, who you find so untrustworthy?
The Zope Corporation hired Guido van Rossum to work on Zope for three years (a Python web application server and content management system), then he moved on. That didn't destroy Guido, or Zope, or Python.
>He has worked for various research institutes, including the Centrum Wiskunde & Informatica (CWI) in the Netherlands, the U.S. National Institute of Standards and Technology (NIST), and the Corporation for National Research Initiatives (CNRI). From 2000 until 2003 he worked for Zope Corporation. In 2003 Van Rossum left Zope for Elemental Security. While there he worked on a custom programming language for the organization. From 2005 to December 2012, he worked at Google, where he spent half of his time developing the Python language. In January 2013, he started working for Dropbox. In October 2019, Van Rossum officially retired before coming out of retirement the following year to join Microsoft.
Guido and Rich are both uncontrollable forces of nature!
I'm definitely curious about it. I'm one of those "swore off frontend framework" people who's attracted to tools like Phoenix Liveview so I never have to deal with it.
Svelte does look pretty sharp and simple though. I wonder how well it works with something like LiveView? Does it really depend on the styling structure mentioned or can I use it with Tailwind?
It works great with Tailwind, I’m doing that in a project right now. I haven’t tried pairing Svelte with LiveView and I’d worry they would end up fighting over elements of the page, but I’d think you could have them control separate parts of the same page, or have them controlling distinct pages just fine.
This is my first look at Svelte. It looks amazing. I hope for day when front-end development is more language primitives and less frameworks--what with their 'useEffectOf' and @Component's of the world.
2. Compared to React yes, because Svelte ships no runtime (or at least a very minimal one). There is a curve though, and very large apps (in the hundreds of components) will eventually be overtaken by something like Preact or vue.
3. No runtime means no restrictions on what they include in the framework. They take full advantage of Svelte being a compiler and include things like complex state management in the form of stores, a built-in transition/animation system with support for springs. Also the included syntax is extremely concise, if you're familliar with vue it'll be fairly easy to pick up.
Hey! I'm Lee, Head of DevRel at Vercel :) Happy to answer any questions you have.
Vercel is a frontend cloud platform that integrates with any framework you prefer (or just plain HTML!). We are also the creators of Next.js, which is a React framework. We try to make it as easy as possible for you to write some code and put it on the web, globally.
Hey Lee, just listened to your chat with swyx the other day. It was great hearing how Vercel positions itself and your thoughts on devrel!
I know Vercel has a great developer relations team already— what would the appetite be for more Svelte DevRels in future? I've been working as a developer advocate and love Svelte enough to have even given talks on it. Would be an opportunity I could see myself in for years :)
I've been pretty skeptical about SPAs but having tried out Svelte for a few side projects, I have to admin I was probably directing my skepticism to the wrong thing, probably React was the cause of my dislike for SPAs. Svelte looks really awesome and the simplicity it brings back is invaluable. I really wish it takes off, for real. Looks very promising.
The complexity and the over engineering going on, mostly.
Things such as redux, rxjs, observables, thunks, etc really put me off when you compare that to just MVC with Rails for example, plus most applications I worked with React were just forms anyway, with some fancy controls/widgets on top.
Not having a clear way, even today with Next, to load data (client side, without doing SSR) before a route transition happens (which leads to spinners everywhere), and now the solution seems to be all the server components, concurrent mode, suspense, etc, etc which to me is just mind blowing how complex things became.
Also hooks which conceptually they make a lot of sense and I like them, but then you have to do all the dependencies tracking manually, they have a lot of gotchas (async in useEffect, ordering, etc).
The "rerendering of everything" and the need for manual memo, useMemo, useCallback, etc and the whole "don't optimize it until you need it" (guess what, a my company as in many others it never was a product priority to make it fast).
Now, take the good parts of the approach, remove all these complications, and you have a very nice and clean approach to do web apps. To me that is what Svelte brings back.
Yes. I totally agree with this. That's why I chose Vue as well. As I've gotten into it more I've found chunks that certainly feel over engineered here and there too.
I don't agree that everything has to revolve around MVC. It's not a hammer for every problem. This is why other patterns like MVVM, MVP and other abbreviations were introduced to solve broader needs.
React starting as purely a UI library paved the way for people to find new ways to manage state and data for different kinds of applications and needs. That's how we ended up with what we have today. You can say what you wan't, but I think it's remarkable what people came up with in the past 10 years.
And these solutions are just optional things you can choose in case you have a need for them. React comes with a lot of things for building rich UI. Sure some things may require more code, but so is the nature of writing applications with specific requirements.
Server components, Concurrent Mode and Suspense came out of the frustrations that it was hard to provide great user experience and avoid common pitfalls with async I/O and high performance because they were limited by React. The solutions they came up with, while not perfect (or even ready yet) aims to solve these issues, while avoiding breaking backwards compatibility and that could be further improved upon while also avoiding breaking the API.
With regards to hooks, I agree that it can be annoying to have to manually pass dependencies. But this is unfortunately the nature of JavaScript and React's mission to not break things. The alternative would require massively changing the API. We've seen other attempts at remedying this with projects like CrankJS and SolidJS that takes a clean slate, preserving the concept of React, but taking a more modern approach on these concepts, as they have freedom of designing their own API from scratch.
We seem to agree. I'm not saying React's approach isn't justifiable. It is what it is for reasons.
I just don't agree all that complexity is worth when you need to ship things fast with a decent robustness and performance. Specially when you don't have 100s of devs in the project.
I'm just saying that given React vs Rails, for 80% of projects I'd pick Rails+hotwire+etc... But given Svelte vs Rails, I'm more inclined to pick Svelte now, because it is not so complex, for now at least.
FWIW I would give Inertia a look. I’ve been using it as the glue between an SPA and my backend, and for me it’s been a best of both worlds experience. Nearly stateless front-end, atomic deploys, easy to understand, no client side routing. Yet you still get the very snappy SPA experience and the nice DX from componentization of your UI. I highly recommend it.
This is such great news! I've been vaguely aware of svelte for some time now but it wasn't until a few months ago that I started using it professionally and it is such a joy to use!
I recently did an onboarding and explained why svelte instead of react of vue, and svelte code, to me, is so much more intuitive and clean!
Thanks for the awesome work Rich and best of luck in this new chapter!
I'd like to hear more. What were your conclusions? I'm particularly interested in it compared to Vue.
I picked Vue because of most people's complaints about React, so most of the comments I'm seeing are about specific gripes with React and don't really help me make an informed opinion.
For React, I agree with the complaints. The change from class components to functional components and the addition of hooks for we was a step backwards.
As for vue, most of my experience is with vue 2, never really spent a lot of time with the features of vue 3.
To the the some of the syntax of svelte makes more sense than that of vue. For example, to list something in vue an html with v-for is needed, or <template v-for... >. This always felt a little awkward to me. In svelte you iterate on the data, not on an html element. So you have an array and just put {#each item i items} ... {/each}, not need for extra html or pseudo <template>
I also prefer svelte's computed properties to vue's.
All it takes is a $: value = a + b and from there whenever a or b changes value also changes. Sometimes my computed property on vue will start growing a little too much.
Something similar in vue and svelte that I enjoy a lot is that the code is separated from the html and from the style. Some people are fans of JSX but I can't stand it! It allows me to shoot myself in the feet and I do it way too often.
The store is VERY VERY nice too! it's lighter than vuex but seems to have some of the limitations that redux/mobx have, say, it has to be functional. I haven't had to write any reducers like with redux tho, but stuff like [].push() won't update.
Overall I really really like it because it's almost transparent. I really didn't have to "learn" svelte as I had to vue or react. It was similar enough to HTML/CSS/JS that it took no time picking it up.
> I really didn't have to "learn" svelte as I had to vue or react
As someone who is primarily a back end dev with limited experience with frontend frameworks (very little react, somewhat decent amount of vue), this was the biggest surprise when working on a project with svelte. You know the saying "hit the ground running"? This was the first time I felt like that with a frontend framework.
I've used React extensively, and now I'm about into 1 year of Vue 2 with Nuxt after having switched jobs.
My gripes with Vue are:
- Despite they say it is not a "Python 2 to 3 like" situation, it is. Every library you find specifies if it is for Vue 2 or 3, some have versions for both, some are only for 2 and will never be upgraded to 3, others are just for 3.
- Vue doesn't have any spirit or ideas of its own. It just copies over every feature from every framework trying to be all to everyone, which leads to too many different ways of doing the same thing.
- There is a horrible culture of auto importing things (components, functions, ref sugar, etc) . This breaks tooling and editors, then they patch those to auto detect these tricks, then introduce a new one and everything breaks, then again..
- Many, many times I was trying to investigate a problem and you end up in a Github Issue which has part of the discussion in Chinese. Doesn't happen as much in official repos, but it happens in many of the third party libraries you end up needing anyway. Some libraries don't even have a readme in English.
- In the part of Europe I'm in, nobody wants to use Vue, so it is difficult to hire.
- Nuxt.js is terrible compared to Next.js. They're also in this "2 to 3" rewrite, and have been terrible at communicating. Probably our project at work will never move to Vue 3 and/or Nuxt.
- Community feels an order of magnitude smaller than react.
On the good site:
- It has a far, far, far better reactivity system than React. No need to manually track dependencies, memoize callbacks and components, etc.
- It is a lot more easy and intuitive, a lot less foot guns.
- It is a real framework, as you have an official router, state management solution, styling approach, etc. I love this.
`next/image` works self-hosted (it uses either Squoosh or optionally Sharp) as well as with any third-party solution you want. Vercel is just one choice!
I love Svelte, and have been using it for a year or so now, but lack of community mindshare means that I've had to roll a lot of my own components.
That said, I think Netlify missed the boat on this one - happily using Netlify with Sveltekit, and it would have been great to have the competition in the PaaS space.
570 comments
[ 2.4 ms ] story [ 309 ms ] threadI can only speculate as to the reasons behind this decision by Vercel. Why Svelte and not Preact for example?
In any case, congrats Rich!
More here: https://vercel.com/blog/vercel-welcomes-rich-harris-creator-...
I've been excited about Svelte for a while and recently chose to use it as the UI for a cross-platform video editing app (https://getrecut.com), with the back end in Rust. I've found it a pleasure to work with -- Svelte Stores and the Context system are especially great for sharing state, and the app feels snappy. Last few weeks most of the focus has been on the Rust backend but I'm really looking forward to building out more of the UI soon.
I've also been happy to find that its generated code is pretty readable. On one little performance-tuning side quest, I was profiling to figure out why the app was performing a Layout on every video frame, and I was able to step through the compiled Svelte component code and narrow it down to one of my own functions. I also briefly went down a path of trying to manually set the text content on an element, to see if it'd be faster than letting Svelte do it. Turned out the answer was no, but it was nice to know that level of control is available if I need it some day.
Excited to see where the Svelte community goes from here!
My hope is that by writing most of my backend in Rust, that it'd be easy-ish to switch to Tauri or other options if something changes down the road.
Working in GTK with hot reload and instantaneous esbuild rebuilds is.... insane.
I looked at alternatives to Electron because I wanted to avoid the bloat, but nothing felt like the right fit. Tauri (https://tauri.studio/) is the most exciting, but I couldn't find a good way to get raw video frames into the UI without a bunch of expensive copies or serialization. I also looked at native toolkits like Qt (I've worked with it in the past) but I didn't love the idea of building lots of custom UI components without the benefit of HTML + CSS. So for now it's Rust + Electron, and I'm paying extra attention to performance.
I learned Swift in order to build the Mac app, and I know from that experience that building custom UI controls while learning a new ecosystem slowed me down a lot. I didn’t love the idea of repeating that experience, and where I’m headed there’s gonna be a good bit of custom UI.
If dceddia is able to add features and fixes more quickly, that's good for users too.
And if Svelte on the desktop becomes popular, people will likely come up with more efficient options. For example, a more efficient Electron or something like "Svelte Native", which could be a good thing.
I'd love if all software were more efficient, but getting up to speed on a new platform has a huge opportunity cost too.
https://github.com/halfnelson/svelte-native
It's a Svelte renderer for NativeScript (a framework targeting iOS and Android), rather than being a port of React Native to Svelte.
It uses less CPU than any other Electron-based video apps I've seen (and even less than a few Qt-based editors I tried) and it feels snappy.
I think tools like Figma have shown what's possible when enough attention is paid to performance early on – but yeah, it's one of my main worries with going with Electron and I'm trying to avoid the downsides as much as I'm able.
The ones I have less control over are memory usage and disk space. I'd love to get those down but it seems like that'd require digging into Chromium and ripping things out. Which, honestly, I looked at doing, but that code base is a beast and I'd rather get something into peoples' hands sooner.
On a related note: I think there's a real opportunity for an "Electron Lite", like some kind of custom Electron/Chromium build that turns off stuff you don't need. I suspect it could help disk usage + memory usage + startup time. Chromium's build system has lots of flags that make it seem like you can turn things off. But it didn't work that way when I tried, so I think it probably requires source-level changes, which then means maintaining those patches across Chromium updates etc. But really, though: I don't need WebRTC, or printing, or media codecs, or probably a zillion other things. It'd be so cool to be able to turn those things off at will.
I forget the word or the link, but I think there was a "rule of thumb" thing that circulated HN about having a limited budget for taking-risks/being-bleeding-edge, and focus in spending that on differentiating properties of your projects, while the rest should stay "old and boring"
The idea of spending fewer "innovation tokens" was definitely on my mind when I was thinking through this.
Are you referring to ease in complexity of creating components compared to the alternatives? Because I end up with the same choice when sieving frameworks to use crossplatform. But I've been looking nto Flutter recently, although it's still in beta, it has potential.
This is all assuming there isn't some specific OS level requirements in your app. I know there are other video editors using WASM successfully and apps like Figma.
This is the best part about next-gen frontend frameworks. We can go back to having a stack trace uncluttered by layers of asynchronous abstractions.
Fair warning I haven't even tried getting it to run on Linux yet... but I've been meaning to try it out, if only for the profiling and debugging tools! (rr looks really cool!)
In theory it runs everywhere because Electron, but my gut says the difficulty with supporting other platforms will come down to compiling and packaging. That's been the biggest hurdle with Windows so far anyway.
Elm is interesting, though it's developer is a bit polarizing
Also there are a host of nascent Rust/WASM frameworks starting to pop up. They really like the tree puns. There is Yew, Sycamore and Seed.
The only catch of course, is that you have to like both Svelte and NodeJS.
Long way to go to catch up to React, but it'll get there. No brainer.
I think folks think that Svelte is the same way, while it does have it's own special sauce, it's nothing compared to React/Angular. Like others have said, when hiring for Svelte, you don't really need the candidate to have Svelte experience.
There were two other submissions - one to an interview (Svelte Creator Rich Harris: Web development should be more fun - https://news.ycombinator.com/item?id=29189209) and the other to this Twitter link (https://news.ycombinator.com/item?id=29189467). I've merged those threads into the current submission because it was posted first.
I breathe a little easier today! This is great and can only be a good thing for svelte and sveltekit.
Looks like I might have to phone in half a decade of experience.
Svelte is close enough to Vue with "script setup" mode anyways, the major difference is whether your logic/keywords go INSIDE the HTML tags or OUTSIDE.
Svelte doesn't support JSX/TSX though =(
I think if most designers took existing web elements and tried to build a UI, instead of drawing an arbitrary picture and asked devs to implement, we would have much less JS overall.
Just that our backend is already built using Django many many years ago. If I need to add some interactivity, I use jQuery currently. Looked into Vue and it allows us to keep everything as is in the backend and use it like jQuery.
I shudder everytime I need to install npm, webpack, gulp, etc..all the JS tools feel super flaky, unnecessary and does not inspire confidence in the tooling. That's my take anyways.
Lot of developers don't have the priviledge of starting a new project. It's an existing doctors appointment website or some shit people cobbled up in PHP in 2004 that is still running and we need to maintain it.
I write in a lot of other languages as well, and I would hear people say this and not get it. I thought to myself:
"It's not THAT bad. I think the experience is fine."
Then I wrote an app recently on the JVM. Sweet jesus the JS/Node ecosystem is a nightmare + house of cards.
The JVM and CLR (.NET) have their stuff together. I need like ~10 dependency libraries to do a large project, and often times they are over a decade old.
The tooling is on another level.
I don't have PROBLEMS writing TS apps, and the experience is good. But some of them have a dependency tree that span thousands of packages, and I've come back 2-3 years later to try to run a project and had some downstream dep break, and then updating fails, and then...
I know it's somewhat of a meme, but this is unironically why I find Deno interesting. (Disclaimer: Haven't shipped anything with it)
Especially since with the most recent release, they have an option to emit Node-compatible JS bundles from Deno code.
My advice would be to check out Vite, and use it with Vue. I've introduced Vite/Vue2 to a pre-existing Django project and couldn't be happier. I've explored a number of different approaches for integrating Vite and Django, and this blog had the best approach, IMO: https://weautomate.org/articles/using-vite-js-with-django/
It's nice that Svelte components can be independently mounted like that.
Right click > View Page Source, and scroll to the bottom to see how all the Svelte components are mounted: https://daveceddia.com/linked-lists-javascript/
To be fair, the same thing would be possible with React or the other frameworks. I do like that it's only 29kb of JS for all those animations though (and most of that is the SVGs, I think).
Designers more often know HTML and CSS over JS, so it is unlikely they are the ones pushing for JS solutions. It is the developers who don't know how to implement designs without falling back on JS for everything who are causing this paradigm.
That being said I blame a lot of this on design tooling as well. Figma and Sketch are custom rendering engines that just don't understand HTML and CSS and therefore give no opportunities for designers to learn how the web works. Fortunately a new generation of design tools are coming that are built on HTML/CSS renderers that feel like Figma but actually output usable code for devs to interpret into their projects.
These days I spend more time in browser devtools than Figma, and honestly I'd prefer a more visual way to edit code directly. Something like Webflow but without all the cruft behind it. Preferably built into devtools, maybe as an extension
It sounds like an issue that can be resolved with some communication
Vue is just straight forward exactly like jQuery: https://www.smashingmagazine.com/2018/02/jquery-vue-javascri...
Benefits of being a framework owned by a business that makes a lot of money off of it.
Next.js 12 as any indicator, I'm just going with whatever falls under the Vercel umbrella now -- I can tell you that Nuxt is not a competitor (as an unbiased voice and someone who doesn't particularly love React).
> We're just supporting Rich and helping the project grow!
I'll admit that I have a negative bias towards this... in spite of Basecamp+RoR, Mozilla+Rust, or all the great OSS HashiCorp makes, it's still hard for me to believe that business do anything out of the goodness of their heart.
Is there a strategic goal for hiring Rich? is it that Svelte is used so much in house that it only made sense to support it? Is it to get more cred with developer by supporting projects they love?
Again, sorry if this question is to skeptic and cynical... I love to be wrong on this! :)
This is the standard narrative when OSS contributors got hired but ok, I'd write the same.
But then just tell us what was the motivation of Vercel's shareholders and CEO to acquire Rich for such a high price (he is the compensation and ESOP you pay absolutely worth) but what's your gain? "Just supporting Rich and helping the project grow" or just buying him out of the market?
More concretely: we want Rich to help shape Vercel's support for frameworks as an open platform. We want to hear how, as a framework creator, the platform can best serve him. We project this work will have ripple effects like making Astro or Remix better on Vercel, or the next framework you invent. You'll hear about this work soon.
We want to hear what edge infrastructure would make Svelte the fastest for developers and visitors. We want to also help him build a better Svelte by connecting him with customers who are betting on it in production. We want to learn from his DX expertise so that we can make better products.
We are very excited about this and we think betting on Open Source for the SDK together with an Open Platform for infrastructure is the only way to succeed in our space.
You have https://www.solidjs.com/ that does
But what is unique about Vue is that it lets you arbitrarily mix ".vue" and ".jsx/.tsx" files in the same project.
So if you need to define say 50 really tiny helper components, like "Button", "Modal", etc. it's great.
I can write one TSX file and do:
And then in my .vue file I can do: This is not a popular approach, almost nobody uses Vue's JSX/TSX and I'm not sure if people even know you can mix and match arbitrarily like this.But I've been doing this for a long time and it works great for me haha.
Just wondering if my read is correct or if there's some other reason it's been left off the table.
IMO the HTML-in-JS solutions (i.e. JSX) are superior to the JS-in-HTML solutions (e.g. Angular/Vue Templates) because they put the standardised turing-complete language in the driving seat rather than the propriety, hard to extend template language.
No JSX or other templating languages, just plain HTML.
It actually supports the next best thing: HTML!
Now in all seriousness, JSX does have its benefits like being able to write a small function that returns a piece of JSX. But in my experience, using Svelte is a huge productivity booster than I don't mind losing JSX's benefits.
https://svelte.dev/blog/virtual-dom-is-pure-overhead
>Virtual DOM is pure overhead
>Let's retire the 'virtual DOM is fast' myth once and for all
>Rich Harris, THU DEC 27 2018
>If you've used JavaScript frameworks in the last few years, you've probably heard the phrase 'the virtual DOM is fast', often said to mean that it's faster than the real DOM. It's a surprisingly resilient meme — for example people have asked how Svelte can be fast when it doesn't use a virtual DOM.
>It's time to take a closer look.
>[...great article...]
>Why do frameworks use the virtual DOM then?
>It's important to understand that virtual DOM isn't a feature. It's a means to an end, the end being declarative, state-driven UI development. Virtual DOM is valuable because it allows you to build apps without thinking about state transitions, with performance that is generally good enough. That means less buggy code, and more time spent on creative tasks instead of tedious ones.
>But it turns out that we can achieve a similar programming model without using virtual DOM — and that's where Svelte comes in.
If you mean React + JSX then yeah, but JSX is just a DSL and doesn't imply using a virtual DOM.
For example, Solid js uses JSX and doesn't have a virtual DOM.
https://www.solidjs.com/
Haha - Oh where will our crazy tech take us next :D
I used to be a web developer, now I'm a React Native / RNW developer.
I don't use web tech unless I'm making a simple web page, when I do I use vanilla HTML/CSS/optional JS.
You get a web app for free when you make a RN app. You can share 95% of code among 5 platforms. (web, windows, macos, ios, android)
Conditionals can change any styling you need amongst them. You can swap out scripts depending on platforms, you can access any extra native platform function with extensions.
Svelte doesn't work for me because you need JS. I don't want to need JS for simple web pages, for apps I need cross-platform.
Svelte could work well for edge computing like CF workers.
Not my experience. I have a production app for web, ios, and android, with desktop platforms coming.
You can swap out anything per platform and write any extension for any native functionality you don't have, but the std and community extensions are plentiful.
RN sucks for "web pages", great for apps. In fact sometimes I embed web pages inside my RN apps. (surveys, etc.)
I haven't heard a single good argument of why it doesn't work. If you were going to write a native app you can write a native extension and share the common parts in JS.
RN is not Cordova, it's not a black box, it's very flexible and extensible.
-- @Jcampuzano2 because of post limit --
Earlier yes there's some fickleness with the toolchain, I don't really have issues now, it's fine unless you're on bleeding edge versions or old versions. Performance issues usually relate to the JS bridge, JSI will alleviate that, most devs won't experience an issue. I don't know why others struggle with RN, it works well for me. Flutter is a no go because it emulates native, it's not true native. You can feel the difference on iOS and the web part sucks so hard.
I personally also worked with React Native for a while, and sure, you can write native extensions for everything, but the biggest complaint is how fickle it is when it comes to upgrading, package management, mind boggling errors related to the metro bundler, etc.
I.E. It's great when it works and you have something simple, but things broke so often compared to native development when you had to do anything complex. And the performance characteristics weren't very great on top of this.
I haven't done React Native in a bit more than a year but from people I talk to not much has changed, and most people I talk to who were all in on React Native mention to use Flutter instead nowadays if you really want cross platform UI.
React uses webpack usually, RN uses metro usually, you can use esbuild, swc, etc for either though.
Svelte is a web tech, and thus uses web bundlers like webpack, thus has the same "faults", though I'm not sure what specifically is being critiqued.
When comparing RN to other cross platform solutions like Flutter you're wanting to compare it's package manager / bundler to Metro and the native dependency systems such as Cocoapods.
Just wanted to clear that up.
But every update was a large effort in bringing the app back into compliance with the new changes. The debugging platform used a different interpreter than in app resulting in things that worked in the debugger but not in production. Odd bugs at boundary layers nobody could (easily) decipher. The inability to even catch or do anything with some crashes.
It was the worst experience I ever had with a development tool chain in my entire career.
What discrepancies did you notice? It depends on the target platform which JS engine is used. Sometimes the debugging platform shares the same engine.
> Odd bugs at boundary layers nobody could (easily) decipher.
I'm not sure I understand, could you provide an example?
> The inability to even catch or do anything with some crashes.
Strange, you're able to catch and debug both JS and native crashes currently. I'm not aware of a past limitation but I could be wrong.
> What discrepancies did you notice? It depends on the target platform which JS engine is used. Sometimes the debugging platform shares the same engine.
Exactly what I said, there would be some code that would run differently in the two environments. I know more now than I did then, but I believe the example was specifically on iOS the app was using JavaScriptCore and the desktop dev tools was using v8.
> I'm not sure I understand, could you provide an example?
> Strange, you're able to catch and debug both JS and native crashes currently. I'm not aware of a past limitation but I could be wrong.
Best as I recall, there was a semi-frequent bug that happened down in our logging system. When it blew up we got a native stack trace instead of JS. My best guess is some kind of handshaking problem between the two layers. Neither used code we wrote and maintained.
Because the whole thing happened inside our error reporting engine, it wouldn't end up in our logs other than a high level apparent failure. It was a mess, and we had limited native experience on the team when it happened. We hired a dev with more native experience, but we still didn't ever figure it out while I was there.
The tool chain always felt like it was a hacked together early beta. To complicate our experience our internal APIs were a mess and unreliable and our React Native codebase wasn't dramatically better. Between our internal problems and all the idiosyncrasies and unintuitive issues in the tool chain it was really miserable.
It wasn't unusual for everyone on the team to spend more than a day simply trying to get the app running again after an update, that is after a dev had completed a 1 to 2 week migration required after the update.
The real issue is if you build any special sauce on top of React. Say you went all in on providing a customized React.Component that worked like a React.Component, but had your platform's logging, perf metrics, etc built in. Then React comes out with hooks and functional components and then you are stuck trying to reimplement your special sauce using these. Or you have to tell customers, "we only support class based components." While functional components are old, FB has shown it will introduce paradigm changes into React, and you are left holding the bag when it comes to supporting them in your platform. And if customers saw a new React feature previewed yesterday, be sure they will be asking for support for it today. FB isn't likely to hand over React to Apache or any sort of open governance model, so changes can be easily made without a huge amount of forewarning, or even a business relationship. Last time I checked FB wasn't selling support contracts or partnerships for React.
Having worked with React for about 5 years (with a project in Vue in-between) and now having dabbled with Svelte, there is just something more appealing working with less higher-level abstractions. Sure with large apps React does have its benefits and its ecosystem is larger by a good amount.
But there is just something about being less annoying that to me is perhaps one of the most important things with any tool. If I enjoy using it, I don't mind that it may not be the "current best choice" of the moment. People who enjoy MobX especially I think ought to find Svelte quite nice.
Sure though would wish SvelteKit was at the same level with Next.js. Fixing dev server errors is a little distracting at times.
You will be very pleased with the upcoming release of Vite 2.7! It's by far the most impactful release of Vite thus far for SvelteKit. All the major known issues we've been tracking have been addressed in the latest Vite 2.7 beta (assuming that one of the PRs we're still working out the kinks of doesn't get rolled back, but either way it'll be a huge improvement!)
Good news and the most underrated and overseen comment in this thread. Nice man!
Svelte’s ecosystem is, in practice, actually much larger than React and any other framework because Vanilla JS works out of the box without framework specific wrappers. So just about any JavaScript package can be imported into a Svelte file and used without hassle.
The last place I worked was a React shop, before that I did most of the frontend as well and used Vue, Current place uses Svelte and I'm really glad they did/do, the continual surprise is how Svelte makes easy things easy and hard things doable.
But you can import any package into React (or any other framework) as well.
I think they are waiting for someone else to build for it which is IMO the completely wrong approach for the dream of the serverless app. You got to own the full stack including software.
I can easily see Vercel becoming the pretty much only go-to in this space just from the developer trust they have created with Next (and now Svelte). The general getting started experience between the two serverless providers is night and day.
One is where do I begin / how should I do this (cloudflare).
The other is simply code... and... go! (vercel)
I'll be all in on whatever Rich makes there. Been waiting for a solid Cloudflare Worker framework for literally years bridging front-end and back-end. Instead, we got Pages (which is cool, just boring for the fun stuff).
If I were Vercel, absolutely would not sell either. They aren't like "Netlify" and positioned to be truly the goat of serverless.
What do you mean by this?
We're heavily investing in security all the way from the SDK and its supply chain[1] to platform, product and cloud.
We proudly use the best infrastructure and products available to help our customers scale without stress. AGA is quite incredible[2] and so is Cloudflare[3] and we are honored to be able to work closely with the purveyors of the finest infrastructure on the Internet!
[1] https://news.ycombinator.com/item?id=29003089
[2] https://news.ycombinator.com/item?id=29158742
[3] https://twitter.com/swyx/status/1456665048949018626
Thanks for chiming in here. Unrelated, I saw that Vercel is ramping up hiring for designers. I’ve always worked in consumer-facing design spaces (banking, travel, etc.) and want to make a change toward something more dev-oriented like Vercel, but I worry being told that “I don’t have the right experience”. Does Vercel hire folks looking to change the industry they design for? I’m a senior IC in design systems, so the extent of what I design for devs is mainly documentation sites.
Building a beautiful and fast Web experience needs to feel myspace-code-easy (or as Rich Harris puts it: it has to be fun!). I think ultimately that's what makes the Web win long term. It's open and accessible.
The best way to contribute to this mission is to come in with a fresh mindset, passion and big ambitions. Please reach out: https://vercel.com/careers
[1] https://rauchg.com/2021/making-the-web-faster#realtime
> Flareact is an experiment created by Josh Larson in August 2020.
Cloudflare seems to be disciplined about releasing solid lower-level platform building blocks first (e.g. durable objects), and leaving the "developer go-to framework for their advanced Worker stuff" to be built on top later.
Seems like a smart approach to me, but I agree the space is moving fast and even though they release stuff at a pretty rapid pace, it never seems fast enough for early adopters
I'd be a bit nervous right now if I built my business / app on that.
How does it "surgically" update the DOM? Why is it better than virtual DOM?
Virtual DOM is just an in-memory representation of the DOM that describes which child elements (e.g., a <p /> nested within a <div />) belong to which parents, and which attributes/values those elements need at render time. When a change happens, you can generate an updated virtual DOM and diff it against the previous (or current) version and pick out what specifically needs to be changed in the DOM (read: surgically).
https://svelte.dev/repl/7161f10f8eb645d8984fb231a0bc3982?ver...
For example in that repl, you can see that it makes a call to `$$invalidate` when the input value changes (see `input_input_handler()`) which triggers a `set_data` call (see `p()`) to update just the textNode that contains the name. This is what is meant by surgical. No other work is done other than what is required to update the specific places where a variable is used.
What Svelte does is entirely eliminate this whole process involving diffing and what-not. At compile time, Svelte analyzes the data dependencies between the rendered template and reactive values in the app, and generates self-contained components that know how to update their own DOMs. You can think of it as essentially moving the entire `reactInternalRenderLoop` function from _runtime_ to _compile time_. There is no more diffVdoms function call on your user's devices. There is no more big allocation of VDOM data structures.
Svelte might compile `MyComponent` to something that looks like this:
And since the Svelte compiler knows the contents of MyComponent never change, the mount function will only be called once for the entire runtime of your app.As for complexity, the generated Svelte code is extremely readable. Take a look at the generated JS tab in the repl: https://svelte.dev/repl
Interacting with the Svelte compiler is ridiculously easy. Though the documentation can be improved, I found it trivial to import the Svelte compiler and prerender a component into an HTML string. Yes, this is somewhat of a niche thing to do, but I appreciate it when libraries and frameworks make it easy to access its internals. Heck, I pretty easily managed to implement Typescript support for Svelte components using Deno's `emit` function; hooking into Svelte's preprocessing was trivial, the complexity I ran into being on the Deno side.
Contrast that with Ember, which seems to have an attitude of "no one would or should ever want to do that", making it really hard to do anything slightly off the beaten path without lots of trial and error or entering the Ember inner-circle.
Yes, I know I'm comparing a component library to a framework, but what I'm commenting on is more about development philosophy.
It's good to hear the creator of Svelte will be able to dedicate his time to it and be able to provide project guidance. I think he has the right vision for what Svelte should be.
As you've pointed out, a problem with that project is that there's a ton of intimate knowledge for how things work under the hood or why things are the way they are. They also seem to oscillate between opting for simplicity and opting for complexity and magic.
One example would be the latest version of Ember which doesn't even ship with `@ember/render-modifiers` by default despite how everyone will end up installing it out of necessity anyway.
Why might that be, you may ask?
> [...] we recommend using these modifiers with caution. They are very useful for quickly bridging the gap between classic components and Glimmer components, but they are still generally an anti-pattern.
https://github.com/emberjs/ember-render-modifiers
Why on earth did they reinvent components and ship them without providing the supposedly correct way of interacting with their lifecycle? You actually have to install a separate add-on to develop a production-ready app with Ember, which completely flies in the face of the idea that you can run `ember new` and have pretty much everything you need. Go ahead and try interacting with individual elements of a Glimmer component in a vanilla Ember project and see how productive and ambitious your web app will be.
Strangely (and thankfully), the RFC for what I think is a needlessly complicated alternative for lifecycle interaction is effectively stalled:
https://github.com/emberjs/rfcs/pull/567
By their own verbiage, the only official way to interact with component/element lifecycle is an antipattern.
So far Svelte and SvelteKit are avoiding all that extra crap. The day that Svelte calls its own solutions "antipatterns" and spends years pontificating things like the actor pattern will be a sad one.
/rant
I try not to go full HN, but sometimes you do.
And I shouldn't have made it about that. As I get older I the more I just get tired of extra things. There's always a price when you add more things. Svelte technically does add things, but I think it has better bang for its buck. The fact it doesn't pointlessly impose OOP constructs upon the end-developer is a big win for me.
this comment. just wow.
https://news.ycombinator.com/newsguidelines.html
Ayn Rand sucks at software design, as much as she sucks at philosophy and economics and social design and writing. Your trust in her is certainly misplaced.
Anyway, why do you have such a huge problem with Rich acting in his own best self interest, that you found a need to personally attack him so viciously and often as you did in this discussion for all that he's done for himself and the Svelte community?
Don't you believe the invisible hand of the market, which you trust so much, will prosecute your vengeance on Rich, who you find so untrustworthy?
https://en.wikipedia.org/wiki/Zope
https://en.wikipedia.org/wiki/Guido_van_Rossum#Work
>He has worked for various research institutes, including the Centrum Wiskunde & Informatica (CWI) in the Netherlands, the U.S. National Institute of Standards and Technology (NIST), and the Corporation for National Research Initiatives (CNRI). From 2000 until 2003 he worked for Zope Corporation. In 2003 Van Rossum left Zope for Elemental Security. While there he worked on a custom programming language for the organization. From 2005 to December 2012, he worked at Google, where he spent half of his time developing the Python language. In January 2013, he started working for Dropbox. In October 2019, Van Rossum officially retired before coming out of retirement the following year to join Microsoft.
Guido and Rich are both uncontrollable forces of nature!
Svelte does look pretty sharp and simple though. I wonder how well it works with something like LiveView? Does it really depend on the styling structure mentioned or can I use it with Tailwind?
Why would I want to rethink that and try out Svelte?
Reading about svelte the main advantage seems to be everything building to raw JS making it faster.
Questions:
Is there typescript support? I would assume, but...
Does this end up with smaller bundles/js files?
Any other major advantages?
From some reading syntax seems pretty similar to Vue as well.
2. Compared to React yes, because Svelte ships no runtime (or at least a very minimal one). There is a curve though, and very large apps (in the hundreds of components) will eventually be overtaken by something like Preact or vue.
3. No runtime means no restrictions on what they include in the framework. They take full advantage of Svelte being a compiler and include things like complex state management in the form of stores, a built-in transition/animation system with support for springs. Also the included syntax is extremely concise, if you're familliar with vue it'll be fairly easy to pick up.
They? Libraries?
I'm familiar with Svelte, but interestingly not with Vercel. A scan of their website wasn't completely clear, but that is probably just me.
Edit: thanks to all who answered, very helpful.
Vercel is a frontend cloud platform that integrates with any framework you prefer (or just plain HTML!). We are also the creators of Next.js, which is a React framework. We try to make it as easy as possible for you to write some code and put it on the web, globally.
I know Vercel has a great developer relations team already— what would the appetite be for more Svelte DevRels in future? I've been working as a developer advocate and love Svelte enough to have even given talks on it. Would be an opportunity I could see myself in for years :)
Things such as redux, rxjs, observables, thunks, etc really put me off when you compare that to just MVC with Rails for example, plus most applications I worked with React were just forms anyway, with some fancy controls/widgets on top.
Not having a clear way, even today with Next, to load data (client side, without doing SSR) before a route transition happens (which leads to spinners everywhere), and now the solution seems to be all the server components, concurrent mode, suspense, etc, etc which to me is just mind blowing how complex things became.
Also hooks which conceptually they make a lot of sense and I like them, but then you have to do all the dependencies tracking manually, they have a lot of gotchas (async in useEffect, ordering, etc).
The "rerendering of everything" and the need for manual memo, useMemo, useCallback, etc and the whole "don't optimize it until you need it" (guess what, a my company as in many others it never was a product priority to make it fast).
Now, take the good parts of the approach, remove all these complications, and you have a very nice and clean approach to do web apps. To me that is what Svelte brings back.
Yes. I totally agree with this. That's why I chose Vue as well. As I've gotten into it more I've found chunks that certainly feel over engineered here and there too.
React starting as purely a UI library paved the way for people to find new ways to manage state and data for different kinds of applications and needs. That's how we ended up with what we have today. You can say what you wan't, but I think it's remarkable what people came up with in the past 10 years.
And these solutions are just optional things you can choose in case you have a need for them. React comes with a lot of things for building rich UI. Sure some things may require more code, but so is the nature of writing applications with specific requirements.
Server components, Concurrent Mode and Suspense came out of the frustrations that it was hard to provide great user experience and avoid common pitfalls with async I/O and high performance because they were limited by React. The solutions they came up with, while not perfect (or even ready yet) aims to solve these issues, while avoiding breaking backwards compatibility and that could be further improved upon while also avoiding breaking the API.
With regards to hooks, I agree that it can be annoying to have to manually pass dependencies. But this is unfortunately the nature of JavaScript and React's mission to not break things. The alternative would require massively changing the API. We've seen other attempts at remedying this with projects like CrankJS and SolidJS that takes a clean slate, preserving the concept of React, but taking a more modern approach on these concepts, as they have freedom of designing their own API from scratch.
I just don't agree all that complexity is worth when you need to ship things fast with a decent robustness and performance. Specially when you don't have 100s of devs in the project.
I'm just saying that given React vs Rails, for 80% of projects I'd pick Rails+hotwire+etc... But given Svelte vs Rails, I'm more inclined to pick Svelte now, because it is not so complex, for now at least.
I recently did an onboarding and explained why svelte instead of react of vue, and svelte code, to me, is so much more intuitive and clean!
Thanks for the awesome work Rich and best of luck in this new chapter!
I picked Vue because of most people's complaints about React, so most of the comments I'm seeing are about specific gripes with React and don't really help me make an informed opinion.
As for vue, most of my experience is with vue 2, never really spent a lot of time with the features of vue 3.
To the the some of the syntax of svelte makes more sense than that of vue. For example, to list something in vue an html with v-for is needed, or <template v-for... >. This always felt a little awkward to me. In svelte you iterate on the data, not on an html element. So you have an array and just put {#each item i items} ... {/each}, not need for extra html or pseudo <template>
I also prefer svelte's computed properties to vue's. All it takes is a $: value = a + b and from there whenever a or b changes value also changes. Sometimes my computed property on vue will start growing a little too much.
Something similar in vue and svelte that I enjoy a lot is that the code is separated from the html and from the style. Some people are fans of JSX but I can't stand it! It allows me to shoot myself in the feet and I do it way too often.
The store is VERY VERY nice too! it's lighter than vuex but seems to have some of the limitations that redux/mobx have, say, it has to be functional. I haven't had to write any reducers like with redux tho, but stuff like [].push() won't update.
Overall I really really like it because it's almost transparent. I really didn't have to "learn" svelte as I had to vue or react. It was similar enough to HTML/CSS/JS that it took no time picking it up.
But, that's just me
As someone who is primarily a back end dev with limited experience with frontend frameworks (very little react, somewhat decent amount of vue), this was the biggest surprise when working on a project with svelte. You know the saying "hit the ground running"? This was the first time I felt like that with a frontend framework.
My gripes with Vue are:
- Despite they say it is not a "Python 2 to 3 like" situation, it is. Every library you find specifies if it is for Vue 2 or 3, some have versions for both, some are only for 2 and will never be upgraded to 3, others are just for 3.
- Vue doesn't have any spirit or ideas of its own. It just copies over every feature from every framework trying to be all to everyone, which leads to too many different ways of doing the same thing.
- There is a horrible culture of auto importing things (components, functions, ref sugar, etc) . This breaks tooling and editors, then they patch those to auto detect these tricks, then introduce a new one and everything breaks, then again..
- Many, many times I was trying to investigate a problem and you end up in a Github Issue which has part of the discussion in Chinese. Doesn't happen as much in official repos, but it happens in many of the third party libraries you end up needing anyway. Some libraries don't even have a readme in English.
- In the part of Europe I'm in, nobody wants to use Vue, so it is difficult to hire.
- Nuxt.js is terrible compared to Next.js. They're also in this "2 to 3" rewrite, and have been terrible at communicating. Probably our project at work will never move to Vue 3 and/or Nuxt.
- Community feels an order of magnitude smaller than react.
On the good site:
- It has a far, far, far better reactivity system than React. No need to manually track dependencies, memoize callbacks and components, etc.
- It is a lot more easy and intuitive, a lot less foot guns.
- It is a real framework, as you have an official router, state management solution, styling approach, etc. I love this.
And of course any regular NodeJS server works with next/image - https://nextjs.org/docs/deployment#other-hosting-options
https://nextjs.org/docs/basic-features/image-optimization#lo...
I love Svelte, and have been using it for a year or so now, but lack of community mindshare means that I've had to roll a lot of my own components.
That said, I think Netlify missed the boat on this one - happily using Netlify with Sveltekit, and it would have been great to have the competition in the PaaS space.