I have recently joined a team that had invested in Svelte. I had previous experience in Angular and React. I was happy with React, but I decided to drink the koolaid and go all-in and do my best with Svelte.
6 months later, we're moving to React. It is partly because our Svelte code was messy enough to warrant a rewrite, and partly because we wanted to leverage the React ecosystem in that rewrite. It was also partly because I just don't like Svelte very much.
I think Svelte is clever, and interesting, and I'm glad it exists. But I found a few points insurmountable:
- Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. I noticed this threw our juniors off.
- Special syntax for reactivity is not javascript
- I find the javascript-native flexibility of JSX far more expressive than any custom templating
- There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
- Two-way data binding is a constant source of bugs
- Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code
- The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop)
- Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
- The strict one component per file approach can be cumbersome. It's not possible to write a one-line function component or similar
- Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above).
- The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.
I've not used any Svelte significantly yet, so your points may stand.
I have, however, written React for years. If anything in Svelte is more confusing to juniors than how useEffect works, especially in conjunction with unstable references, I would be literally amazed.
useEffect is a loaded automatic pointed at your face if you don't fully understand it. It is truly a terrible API due to how intimately you have to understand JavaScript for it to always work properly.
I can't imagine anything worse in Svelte. If there is, I'd love to hear it.
Perhaps a shift in mindset about how to approach using Svelte would help. Svelte is not React, and using React for an extended period really changes how you think about frontend code (structure-wise etc).
As a quick example, the Svelte 'ecosystem' is simply the Javascript ecosystem, which existed well before React. You can import any npm module to a Svelte app. Outside of the React-specific packages (which I argue are overkill), such as Redux or Redux-enabled form libraries, what are you missing? Pre-styled components like calendars, modals, popups, are available in a range of vanilla-JS packages. Anything more than that and it's possible that React thinking has over-complicated your approach.
I am really curious to hear about specific examples of some of these points. Specifically:
> The abstraction leaks and when it does, it requires a good mental model of Svelte's magic.
Maybe because I have familiarized myself with how Svelte works I haven't noticed anything like that.
> Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
I suspect this is from trying to use React patterns in Svelte, which I've seen quite a lot in people asking questions on Reddit. But I'm sure there are some things like that, could you give an example?
> Two-way data binding is a constant source of bugs
Again, very curious to see an example of this.
> It's not possible to write a one-line function component or similar
What was your use case here? I haven't found myself wanting to do that anywhere.
This is unfortunate for your team, but most of your conclusions are not adequate.
1. Actually, Svelte has much less "magic" involved than React. Sveltes abstractions are not leaky. The reactivity might be more difficult to understand. But the rules are well defined. They are strange - no doubt - but not leaky. When looking at the generated code it's actually much more obvious what is going on than what React is doing. React on the other hand has some leaky abstractions. The biggest one is the effort you have to put into to make it efficient (memoization). Also, hooks.
2. Two way data binding is not a constant source of bugs. Then every team using Vue, Svelte, Angular, React with MobX would have those troubles. I've done 8 years frontend dev in a large company using React and Angular (and recently Vue 3) with different teams. The bugs come from people not technology. I've seen no other correlation there.
Granted, React has the largest ecosystem of all of them, but what do you actually need?. In that regard, Vue hits the sweet spot.
> Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
I see this in every project where juniors or just undisciplined developers get to run without oversight. There's nothing special about Svelte stores here. Any store has this trap. There's no framework or library solution for good discipline about if, where, and how you share data.
> - Special syntax for reactivity is not javascript
Well, JSX syntax isn't JS either. And hooks semantics is not JS.
Learning new syntax is easy but we should consider how much the new semantics cause mistakes and to what extent they are incompatible with tools such as linters.
> I find the javascript-native flexibility of JSX far more expressive than any custom templating
JSX is the most significant contribution that React brought to front-end programming. Personally I don't always use React, but I use JSX quite often. It's intuitive in a way custom syntax (the dozens of) never will be.
React has special syntax for reactivity. What is useEffect? Is it a native JS function?
I don't understand why JSX is still being used. Why should I a HTML developer change how I write HTML for a framework? And why doesn't it allow style tags?
Svelte lets me use HTML, style tags even a script tag. The only framework that is close to HTML is Svelte. The second version even had .html extension which is now .svelte.
> Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
I don't see how having a reactive store has anything to do with the latter. But I find this ironic because every React codebase I've ever seen has components that import globals from other files (whether they be constants or POJOs). I don't find this inherently wrong, but it's exacerbated further by "Providers" and React.Context which seems idiomatic at this point.
Every reason you’ve stated are reasons I’ve switched from one proprietary or open source framework before react to react. 2 way data binding is a mental prison in big apps, I’m sure there’s a good implementation somewhere but I’ve yet to see it.
I don't like templating, it's too restrictive, feels like back to the 90s. This is typically aimed at coders who secretly don't want to code, and fall for tools that seems like they can avoid it.
What I like most about React is being able to break down views into functions and compose them. And if I have the choice, I prefer pure javascript and just a small helper function for Document.createElement instead of JSX, it makes it even more powerful, flexible and less verbose. You can already programmatically create elements in Javascript, I don't understand at all why people use "frameworks" for this, JS and HTML is already a view and a controller, just write the app? A complex single page application needs a couple of dozen lines of helper functions, that's all, why invent a whole new language on top of the language that in the end only restricts what you already have in the first place? This is spring framework enterprise hell all over again in the frontend
I've been developing websites and apps with Svelte for almost 2 years now, and my experience couldn't be more different from yours.
> - Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. I noticed this threw our juniors off.
Since Svelte runs vanilla JS and works with the DOM directly, my experience debugging any "magic" has been extremely straightforward compared to other frameworks. I'm curious what specific issues you have encountered.
> - I find the javascript-native flexibility of JSX far more expressive than any custom templating
Not once have I wished I had JSX in a Svelte project, and the readability of Svelte's minimal templating sugar is a breath of fresh air for myself. What's an example of a limitation you've faced in practice?
> - There are major trade offs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte.
I would love an example of this, as I've yet to run into any situations where I felt there was something I couldn't accomplish at runtime.
> - Two-way data binding is a constant source of bugs
It's rare that I use two-way data binding, but in the rare cases where it's appropriate, it's very convenient. The improper use of a utility doesn't necessarily discredit the value of said utility.
> - Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code
I'm not sure this is true- with access to JS modules, stores, nullish coalescing, and lifecycle hooks, let-style rebinding can be avoided entirely.
> - Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
Inexperienced developers will write bad code with or without powerful tools like Svelte stores. I don't think a framework is meant to replace experience, guidance, and coaching.
> - The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop)
Considering you Svelte lets you style things in a plethora of different ways (including the traditional method of external css files), I'm curious how you came to the conclusion that it's opinionated.
> - The strict one component per file approach can be cumbersome. It's not possible to write a one-line function component or similar
While it _can_ be, a single function shouldn't be a "component"- but Svelte "actions" are an awesome feature designed to make single functions easy to compose and reuse across components. That being said, there is talk of supporting multiple Svelte components per file (although it's rather controversial and largely unnecessary in Svelte projects).
> - Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above).
Considering any JS library (most importantly, ones that interact with the DOM) is plug-and-play in a Svelte file- I've never found myself needing something that didn't exist on NPM. Nonetheless, the DX and power of Svelte enables us to create complex libraries and components that would ordinarily be too cumbersome or time consuming to produce in-house, and with much less code than with React. This usually pays dividends in the long-run, as custom solutions are typically easier to debug and extend.
> - The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.
The runtime speed is pretty low on my list of reasons I prefer Svelte above other solutions. While the performance gains from Svelte are amazing for users (especially ones with low-end devices or shotty internet speeds), the unparalleled DX, development speed, maintainability (do more with less code = less bugs = easier to maintain), community, and overall fun involved in working with Svelte overshadow the free optimization done by the compiler at build-time.
Anyways, I hope that round 2 will be more fruitful for you and your team! I'm highly skeptical that React will solve more problems than it causes when your primary bottleneck is developer experience, but I'm sure we will both be able to learn from your experience regardless of the outcome!
>Any top-level statement (i.e. not inside a block or a function) can be made reactive by prefixing it with the $: JS label syntax. Reactive statements run immediately before the component updates, whenever the values that they depend on have changed.
>In the long list of cool features of svelte, The one which I use more often is this dollar label thing. Initially, it looked strange to me but later I realized it is a valid javascript syntax. You can use it for doing side effects like useEffect of React, there is also a syntactic sugar way of declaring computed properties.
The Svelte compiler does add special SEMANTICS to JavaScript (and that's what makes it so great), but it does NOT add any special SYNTAX at all.
Although it might mistakenly appear to you that it does, if you're not entirely familiar with the well documented standard JavaScript syntax definition that I linked to above.
Your off-the-shelf code highlighters and linters will work just fine inside the standard <script> tags in svelte files, exactly like they should. That was the whole point behind Svelte's design.
However that's not the case with JSX, because JSX is definitely NOT the same as JavaScript, no matter how fuzzy and inconsistent a definition of "equality" and how many equal signs you use.
Much of this I would have expected, but this was less obvious:
> There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
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.
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!
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).
This is such amazing news! Betting on Svelte was the best thing ever for both my career and sanity. I'm now heavily involved in the Svelte community and next Saturday we'll be hosting our fourth conference solely dedicated to Svelte.
If you're interested in checking it out the URL is here, it's free and will be streamed on YouTube: https://sveltesummit.com
There are also two watch parties that will be hosted in New York (Rich will attend!) and in Mainz, Germany.
Rich Harris has done a lot of great work. Until esbuild came along, Rollup was the only sane JS bundler for those of us who can’t stand Webpack. Svelte has some interesting concepts, albeit I am planning to stay with React. His code is always interesting to read.
Then there’s Vercel. I was a big advocate for them years ago, back when they were Zeit. I used them in production at multiple companies and I contributed to their CLI to improve its error handling. But they really screwed me as a vendor with changes to their hosting platform and then again with changes to their authoritative DNS service. They broke every promise or expectation they ever set with me and reversed practically every facet of their original philosophy as a platform. They are bordering on being on my “never again” list. I hope Rich is genuinely able to stay independent creatively.
I'm tired of having to learn yet another templating language without a very compelling reason.
Why do I have to learn, what is essentially, a new programming language for each of these frameworks (Angular, Svelte, Vue, React... Do I really need to learn yet another language construct for stuff like `loops`, `if/else`, event handlers...etc.
Why must all of these frameworks re-invent the wheel?
At least with React it is most close to the languages we already have learned, JavaScript, and HTML.
From what I can tell Svelte looks similar handlebars templating with it's own unique syntax variations... I can't count how many different versions of the same thing I've had to relearn again, and again.
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.
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.
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.
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!
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.
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.
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.
>You know, I guess all I can say is that we're thinking about this stuff too, and, like, we want the development velocity to be as fast as possible. But we also don't want Svelte to become like some, I don't know, some VC-funded FauxSS -- did I just coin that: FauxSS? I like that!
>It feels like there's more and more of that these days. There's a lot of people working on open source software, and then, like, you discover that there's a business model behind it.
>And I'm always a little bit skeptical about whether or not that is in the best interests of the software itself. And I don't want Svelte to become a thing that is run in the interests of the people building it, I want it to be a thing that is run in the interests of the community at large.
So what is the opposite of FauxSS? ProSS?
Hmm: "pross: a person who engages in sexual activity for money."
So I guess that means OSS is as great as sexual activity. ;)
I've been following Svelte, and it sounded great, so I've wanted to use it for some time. Now I've finally started a project with SvelteKit, and it's even better than I hoped, with extra layers of greatness I didn't even realize, like pre-rendering pages, at the same time as being very mobile SPA friendly.
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.
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).
[+] [-] dissent|4 years ago|reply
6 months later, we're moving to React. It is partly because our Svelte code was messy enough to warrant a rewrite, and partly because we wanted to leverage the React ecosystem in that rewrite. It was also partly because I just don't like Svelte very much.
I think Svelte is clever, and interesting, and I'm glad it exists. But I found a few points insurmountable:
- Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. I noticed this threw our juniors off.
- Special syntax for reactivity is not javascript
- I find the javascript-native flexibility of JSX far more expressive than any custom templating
- There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
- Two-way data binding is a constant source of bugs
- Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code
- The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop)
- Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
- The strict one component per file approach can be cumbersome. It's not possible to write a one-line function component or similar
- Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above).
- The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.
[+] [-] lucasyvas|4 years ago|reply
I have, however, written React for years. If anything in Svelte is more confusing to juniors than how useEffect works, especially in conjunction with unstable references, I would be literally amazed.
useEffect is a loaded automatic pointed at your face if you don't fully understand it. It is truly a terrible API due to how intimately you have to understand JavaScript for it to always work properly.
I can't imagine anything worse in Svelte. If there is, I'd love to hear it.
[+] [-] bGl2YW5j|4 years ago|reply
As a quick example, the Svelte 'ecosystem' is simply the Javascript ecosystem, which existed well before React. You can import any npm module to a Svelte app. Outside of the React-specific packages (which I argue are overkill), such as Redux or Redux-enabled form libraries, what are you missing? Pre-styled components like calendars, modals, popups, are available in a range of vanilla-JS packages. Anything more than that and it's possible that React thinking has over-complicated your approach.
[+] [-] bdougherty|4 years ago|reply
> The abstraction leaks and when it does, it requires a good mental model of Svelte's magic.
Maybe because I have familiarized myself with how Svelte works I haven't noticed anything like that.
> Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
I suspect this is from trying to use React patterns in Svelte, which I've seen quite a lot in people asking questions on Reddit. But I'm sure there are some things like that, could you give an example?
> Two-way data binding is a constant source of bugs
Again, very curious to see an example of this.
> It's not possible to write a one-line function component or similar
What was your use case here? I haven't found myself wanting to do that anywhere.
[+] [-] _ta_2231234|4 years ago|reply
1. Actually, Svelte has much less "magic" involved than React. Sveltes abstractions are not leaky. The reactivity might be more difficult to understand. But the rules are well defined. They are strange - no doubt - but not leaky. When looking at the generated code it's actually much more obvious what is going on than what React is doing. React on the other hand has some leaky abstractions. The biggest one is the effort you have to put into to make it efficient (memoization). Also, hooks.
2. Two way data binding is not a constant source of bugs. Then every team using Vue, Svelte, Angular, React with MobX would have those troubles. I've done 8 years frontend dev in a large company using React and Angular (and recently Vue 3) with different teams. The bugs come from people not technology. I've seen no other correlation there.
Granted, React has the largest ecosystem of all of them, but what do you actually need?. In that regard, Vue hits the sweet spot.
[+] [-] JimDabell|4 years ago|reply
> - I find the javascript-native flexibility of JSX far more expressive than any custom templating
These are odd points to combine – JSX is special syntax not JavaScript as well.
[+] [-] Sammi|4 years ago|reply
I see this in every project where juniors or just undisciplined developers get to run without oversight. There's nothing special about Svelte stores here. Any store has this trap. There's no framework or library solution for good discipline about if, where, and how you share data.
[+] [-] tuukkah|4 years ago|reply
Well, JSX syntax isn't JS either. And hooks semantics is not JS.
Learning new syntax is easy but we should consider how much the new semantics cause mistakes and to what extent they are incompatible with tools such as linters.
[+] [-] jeswin|4 years ago|reply
JSX is the most significant contribution that React brought to front-end programming. Personally I don't always use React, but I use JSX quite often. It's intuitive in a way custom syntax (the dozens of) never will be.
[+] [-] StaticChamp|4 years ago|reply
I don't understand why JSX is still being used. Why should I a HTML developer change how I write HTML for a framework? And why doesn't it allow style tags?
Svelte lets me use HTML, style tags even a script tag. The only framework that is close to HTML is Svelte. The second version even had .html extension which is now .svelte.
============== Svelte > React ==============
[+] [-] toastercat|4 years ago|reply
I don't see how having a reactive store has anything to do with the latter. But I find this ironic because every React codebase I've ever seen has components that import globals from other files (whether they be constants or POJOs). I don't find this inherently wrong, but it's exacerbated further by "Providers" and React.Context which seems idiomatic at this point.
[+] [-] taurath|4 years ago|reply
[+] [-] jseban|4 years ago|reply
What I like most about React is being able to break down views into functions and compose them. And if I have the choice, I prefer pure javascript and just a small helper function for Document.createElement instead of JSX, it makes it even more powerful, flexible and less verbose. You can already programmatically create elements in Javascript, I don't understand at all why people use "frameworks" for this, JS and HTML is already a view and a controller, just write the app? A complex single page application needs a couple of dozen lines of helper functions, that's all, why invent a whole new language on top of the language that in the end only restricts what you already have in the first place? This is spring framework enterprise hell all over again in the frontend
[+] [-] malcolmstill|4 years ago|reply
Do you have some specific examples?
[+] [-] FractalHQ|4 years ago|reply
> - Too much magic. The abstraction leaks and when it does, it requires a good mental model of Svelte's magic. I noticed this threw our juniors off.
Since Svelte runs vanilla JS and works with the DOM directly, my experience debugging any "magic" has been extremely straightforward compared to other frameworks. I'm curious what specific issues you have encountered.
> - I find the javascript-native flexibility of JSX far more expressive than any custom templating
Not once have I wished I had JSX in a Svelte project, and the readability of Svelte's minimal templating sugar is a breath of fresh air for myself. What's an example of a limitation you've faced in practice?
> - There are major trade offs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte.
I would love an example of this, as I've yet to run into any situations where I felt there was something I couldn't accomplish at runtime.
> - Two-way data binding is a constant source of bugs
It's rare that I use two-way data binding, but in the rare cases where it's appropriate, it's very convenient. The improper use of a utility doesn't necessarily discredit the value of said utility.
> - Svelte practically requires let-style variable rebinding, often at a file wide scope, which again caused our juniors in particular to write bad code
I'm not sure this is true- with access to JS modules, stores, nullish coalescing, and lifecycle hooks, let-style rebinding can be avoided entirely.
> - Built in reactive store is cool, but our developers all ended up using it for tight coupling and global variables
Inexperienced developers will write bad code with or without powerful tools like Svelte stores. I don't think a framework is meant to replace experience, guidance, and coaching.
> - The style system is too opinionated for me. I also find it necessary to break into the global scope for any minor restyling of a subcomponent (or worse, pass in the style as a prop)
Considering you Svelte lets you style things in a plethora of different ways (including the traditional method of external css files), I'm curious how you came to the conclusion that it's opinionated.
> - The strict one component per file approach can be cumbersome. It's not possible to write a one-line function component or similar
While it _can_ be, a single function shouldn't be a "component"- but Svelte "actions" are an awesome feature designed to make single functions easy to compose and reuse across components. That being said, there is talk of supporting multiple Svelte components per file (although it's rather controversial and largely unnecessary in Svelte projects).
> - Much smaller ecosystem than React, requiring much more to be done in house (exacerbated by all of the above).
Considering any JS library (most importantly, ones that interact with the DOM) is plug-and-play in a Svelte file- I've never found myself needing something that didn't exist on NPM. Nonetheless, the DX and power of Svelte enables us to create complex libraries and components that would ordinarily be too cumbersome or time consuming to produce in-house, and with much less code than with React. This usually pays dividends in the long-run, as custom solutions are typically easier to debug and extend.
> - The faster runtime speed in no way made up for any of the above. Bad Svelte code is still slow compared to good React code.
The runtime speed is pretty low on my list of reasons I prefer Svelte above other solutions. While the performance gains from Svelte are amazing for users (especially ones with low-end devices or shotty internet speeds), the unparalleled DX, development speed, maintainability (do more with less code = less bugs = easier to maintain), community, and overall fun involved in working with Svelte overshadow the free optimization done by the compiler at build-time.
Anyways, I hope that round 2 will be more fruitful for you and your team! I'm highly skeptical that React will solve more problems than it causes when your primary bottleneck is developer experience, but I'm sure we will both be able to learn from your experience regardless of the outcome!
[+] [-] DonHopkins|4 years ago|reply
Are you referring to Svelte using the $: dollar label prefix syntax for reactivity?
Yes, that is most certainly is standard JavaScript syntax. Read the docs:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
>label: The labeled statement can be used with break or continue statements. It is prefixing a statement with an identifier which you can refer to.
https://svelte.dev/docs
>3. $: marks a statement as reactive
>Any top-level statement (i.e. not inside a block or a function) can be made reactive by prefixing it with the $: JS label syntax. Reactive statements run immediately before the component updates, whenever the values that they depend on have changed.
https://dev.to/itsjzt/understanding-svelte-s-dollar-label-sy...
>Understanding Svelte's $: (dollar label) syntax
>In the long list of cool features of svelte, The one which I use more often is this dollar label thing. Initially, it looked strange to me but later I realized it is a valid javascript syntax. You can use it for doing side effects like useEffect of React, there is also a syntactic sugar way of declaring computed properties.
The Svelte compiler does add special SEMANTICS to JavaScript (and that's what makes it so great), but it does NOT add any special SYNTAX at all.
Although it might mistakenly appear to you that it does, if you're not entirely familiar with the well documented standard JavaScript syntax definition that I linked to above.
Your off-the-shelf code highlighters and linters will work just fine inside the standard <script> tags in svelte files, exactly like they should. That was the whole point behind Svelte's design.
However that's not the case with JSX, because JSX is definitely NOT the same as JavaScript, no matter how fuzzy and inconsistent a definition of "equality" and how many equal signs you use.
[+] [-] arxpoetica|4 years ago|reply
That's because there is no syntax for reactivity in JavaScript, period.
[+] [-] brundolf|4 years ago|reply
> There are major tradeoffs made by doing things at compile time. Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
What are some examples of this?
[+] [-] Donckele|4 years ago|reply
What? Can you expand on that? Makes no sense.
[+] [-] midrus|4 years ago|reply
[+] [-] tekkk|4 years ago|reply
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.
[+] [-] benmccann|4 years ago|reply
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!)
[+] [-] FractalHQ|4 years ago|reply
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.
[+] [-] nodejs_rulez_1|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] kall|4 years ago|reply
[+] [-] dceddia|4 years ago|reply
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!
[+] [-] Tade0|4 years ago|reply
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.
[+] [-] vgel|4 years ago|reply
[+] [-] gnrlst|4 years ago|reply
[+] [-] kingcharles|4 years ago|reply
[+] [-] kevinak|4 years ago|reply
If you're interested in checking it out the URL is here, it's free and will be streamed on YouTube: https://sveltesummit.com
There are also two watch parties that will be hosted in New York (Rich will attend!) and in Mainz, Germany.
Links: - https://lu.ma/sveltenyc - https://lu.ma/sveltesummit-2021-mainz
[+] [-] sholladay|4 years ago|reply
Then there’s Vercel. I was a big advocate for them years ago, back when they were Zeit. I used them in production at multiple companies and I contributed to their CLI to improve its error handling. But they really screwed me as a vendor with changes to their hosting platform and then again with changes to their authoritative DNS service. They broke every promise or expectation they ever set with me and reversed practically every facet of their original philosophy as a platform. They are bordering on being on my “never again” list. I hope Rich is genuinely able to stay independent creatively.
[+] [-] leerob|4 years ago|reply
[+] [-] cphoover|4 years ago|reply
Why do I have to learn, what is essentially, a new programming language for each of these frameworks (Angular, Svelte, Vue, React... Do I really need to learn yet another language construct for stuff like `loops`, `if/else`, event handlers...etc.
Why must all of these frameworks re-invent the wheel?
At least with React it is most close to the languages we already have learned, JavaScript, and HTML.
From what I can tell Svelte looks similar handlebars templating with it's own unique syntax variations... I can't count how many different versions of the same thing I've had to relearn again, and again.
[+] [-] midrus|4 years ago|reply
[+] [-] ravenstine|4 years ago|reply
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.
[+] [-] gavinray|4 years ago|reply
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 =(
[+] [-] _benj|4 years ago|reply
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!
[+] [-] falafelite|4 years ago|reply
[+] [-] dang|4 years ago|reply
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.
[+] [-] owlbynight|4 years ago|reply
I breathe a little easier today! This is great and can only be a good thing for svelte and sveltekit.
[+] [-] _puk|4 years ago|reply
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.
[+] [-] DonHopkins|4 years ago|reply
Svelte Summit Spring 2021: Rich Harris @6:07:00 (link with timecode):
https://www.youtube.com/watch?v=fnr9XWvjJHw&t=22020s
>You know, I guess all I can say is that we're thinking about this stuff too, and, like, we want the development velocity to be as fast as possible. But we also don't want Svelte to become like some, I don't know, some VC-funded FauxSS -- did I just coin that: FauxSS? I like that!
>It feels like there's more and more of that these days. There's a lot of people working on open source software, and then, like, you discover that there's a business model behind it.
>And I'm always a little bit skeptical about whether or not that is in the best interests of the software itself. And I don't want Svelte to become a thing that is run in the interests of the people building it, I want it to be a thing that is run in the interests of the community at large.
So what is the opposite of FauxSS? ProSS?
Hmm: "pross: a person who engages in sexual activity for money."
So I guess that means OSS is as great as sexual activity. ;)
[+] [-] DonHopkins|4 years ago|reply
[+] [-] barelysapient|4 years ago|reply
[+] [-] arberx|4 years ago|reply
Long way to go to catch up to React, but it'll get there. No brainer.
[+] [-] pier25|4 years ago|reply
I can only speculate as to the reasons behind this decision by Vercel. Why Svelte and not Preact for example?
In any case, congrats Rich!
[+] [-] leerob|4 years ago|reply
More here: https://vercel.com/blog/vercel-welcomes-rich-harris-creator-...
[+] [-] WORMS_EAT_WORMS|4 years ago|reply
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).