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.
useEffect makes easy things easy and hard things very hard indeed.
After building a few non trivial apps in React with hooks I'm convinced that what you really need for that model to work smoothly is a new language that tracks things like hook dependencies for you.
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'm looking forward to picking up Svelte and just going back OOP for state management. Immutable state with React was a massive eye opener, but right now I think OOP is just better for state management, especially with all the insights gained from using React.
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.
Is it surprising that two-way data binding is a source of bugs? We learned that lesson from Angular, and it influenced React’s preference for one-way dataflow.
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.
> Two way data binding is not a constant source of bugs
Every team using AngularJS _did_ have those problems (not to say it didn’t have some niceties also). It was one of the big architectural changes in Angular (2+) as a direct result. React does not have this feature; passing down a setter function is not the same as automatic 2-way binding.
As to your first point, different things feel like magic to different people, so it’s really hard to debate this with other people with different perspectives unless maybe your talking about single specific instances. It’s like trying to tell someone they don’t feel cold because you don’t feel cold or vice versa.
Sure, but it maps 100% to an expected JS syntax and improves readability (subjective).
From
<div attr1="str">{children}</div>
To
React.createElement("div", { attr1: "str" }, children)
Custom templating is not like that.
JSX is more akin to a macro than a DSL, which is why I strongly prefer it. Debugging errors in templating languages is invariably more frustrating and time consuming.
More on point, being constrained within the special language is miles away from the constraint of JSX, which is essentially limited to only allowing expressions, because the macro expands to expressions. Everything else is fair game, and that makes it far more expressive.
> 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.
As I see it, the main issue with new syntaxes is the fact that they break compatibility with existing tooling. JSX is not fundamentally different in this regard, except for the fact that it gained so much mindshare that it brute-forced its way to getting first-class support in editors, language servers, different frameworks, even TypeScript. I don't predict that very many new JS-adjacent syntaxes will get that treatment from the industry.
> 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.
You can 100% use style tags in React, they just aren’t automatically wrapped in module/component scope. Just like normal HTML style tags, actually.
As for JSX, I personally have always hated HTML template languages (“now which slightly-different version of the for iterator does this template get use?”) but I also recognize that there are other people who have opposite preferences. JSX-in-JS and template-directives-in-HTML are both valid approaches and it’s great that there are solutions to cater to various preferences. Trying to argue one down because you don’t like it is like arguing that your favorite color is factually superior.
> 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!
> 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.
This is the gist of the whole comment. The person posting is not complaining about a bad Svelte experience, they're complaining about bad programming practices.
>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
I read it as: Svelte is faster in theory, but since people write bad Svelte code, it is slower than the React code the same developers would write.
My interpretation is that this can be attributed to either svelte being hard to write, or people being used to React. Both of which are a challenge to companies looking to switch to 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.
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.
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).
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.
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.
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).
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.
Genuinely curious, what’s there to do about for an entire conference about a single library? For someone from academia, where conferences typically span an entire field of research, this seems extremely niche and quite boring after a bit..
Well - that might be overstating the matter; after all, academia also has workshops focused on very small niches...
...but also: it's not uncommon to find industry conferences about a specific framework, because it's not just about the framework - it's about the uses to which that framework can be put, and about interacting with the community around that framework. Both of those facets permit a lot of variety, especially for foundational tools (e.g. web application frameworks, UI libraries, database platforms, etc.)
Because the last Computer Science Conference I went to wasn't small and cozy enough that I got to hang out and personally chat with the leaders in the field.
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.
Hi Lee. I appreciate the offer but the simple answer is that Vercel abruptly pivoted away from backend oriented services. That broke everything I built on the Now v1 platform and there wasn't anything to do but switch to other providers. It was stated that migration to Now v2 would be simple but that never materialized in time for the Now v1 shut down. On top of that, I encountered a lot of bugs with the deployment system when the new infrastructure started coming online, where it would auto deploy to data centers that couldn't run Now v1 apps and then the CLI would crash. I tried to be understanding, given you were a startup in a competitive space. It was unfortunate but I decided to at least continue using your domains and DNS features. But then the format of the zeit.world nameservers changed a couple of times and again with relatively short notice. Other frustrations... the domain search & buy page used to be public, now it requires a login for seemingly no reason (trying to keep bots out?). The marketing of early Zeit was all about embracing open standards and now Vercel is basically the exact opposite, with proprietary solutions for running frontend projects being at the heart of the product. I can only guess as to why it unfolded that way, but the transition was extremely rough for people who bought into the original vision. I just logged in now to transfer out some domains I still have in there and discovered that years later you still don't have a way for customers to change their domain's nameservers other than contacting support. That's just user hostile. A lot of people would say that is a dark pattern. I've literally never encountered another registrar that didn't have a simple button to change my domain's nameservers. Having to contact support to do this was excusable when your company was only a year old, but at this point it looks negligent, if not deliberate.
It's only sane if you use it raw (i.e. ESM in, UMD out), but add plugins and suddenly you have a slower and less capable webpack with lengthy config.
I'm generally a fan of Rich’s tools but they only look good on the surface generally. Svelte itself changed face 3 times already, with each iteration completely incompatible with the old one.
You are misreading. He's saying that rollup[1] was the only other option for bundling static assets besides webpack until esbuild was created. Rollup was created by Rich.
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.
For all the use cases I deal with on a regular basis, Svelte looks more like vanilla HTML/JS than any equivalent React code.
And the reason these things change is because that's what needed changing. One of the topline features of Svelte is that is has less boilerplate than React, and it achieves that quite handily. Unless you're criticizing particular constructs in Svelte that are unjustifiably different, I don't think unfamiliarity is that damning a criticism.
Maybe I'm just used to switching up languages on a regular basis, but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task.
<ul>{#each myItems as item}
<li>{item.title}</li>
{/each}</ul>
One is literally just javascript and html the other is an entirely different template language. You might say... JSX is not HTML... well it's very very similar... If you know HTML you JSX is very intuitive.
> but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task.
I agree. As long as you understand the basic concepts, it's only a matter of learning the syntax, which is really not as big of a deal as the person you replied to is making it out to be.
As a backend guy who moved away from frontend long ago for these very reasons, I have to ask: why are people downvoting this? Is it wrong? I'm genuinely asking, because from a bystander's point of view, it certainly seems like the pattern of the Framework Du Jour hasn't really slowed down much in the frontend community.
It might be true, but it's a rant that just barely touches the actual topic, which is mostly: a company will pay somebody to work full time on an open source project that is still independent. And I think it's pretty nice. And also I think Rich Harris has given a lot to people for free and I'm happy for him that he will be paid to work on something that he loves.
So all in all it would be nice if we would for once be spared of rants how tiring, immature, half baked whatever whatever the JavaScript world is. Show us maybe how it should be really done, but maybe in a separate post please.
I didn't downvote, but I'll speak to my experience.
First off, you don't have to go learning every framework out there. Pick one and stick with it, or just go vanilla. That said, The features these frameworks provide gives a boost in productivity that far outweighs the low learning curve.
My pick was VueJS and I'm very happy with it. Using Single File Components is pretty similar to vanilla HTML/JS/CSS. Beginners that were under my guidance (with only HTML/CSS/JS experience) usually pick it up and were productive in the same day.
I disagree that React (JSX) is most similar to vanilla JS/HTML at all (I don't prefer it, but to each their own). Vue and Svelte are much further on the side of a vanilla-ish approach.
It is wrong because it has slowed down to a crawl compared to what we had from 2010-2014.
Most companies have settled on either React or Vue, which are extremely similar. Angular is used in some niches, almost always because teams already knew it.
Those three are responsible for almost 99% of the frontend positions you'll see.
Svelte is getting popular but so far it's still niche. It's more of an inspiration for others, but also a contender. And really, what's so wrong about having more options and more competition? Even if you want to stop learning new things, there'll be no shortage of job vacancies for the three frameworks above.
Also, since you're a backend dev, there are much more backend languages in use today than frontend frameworks, to give an example. And it's not hard to find companies using more than one.
Well in this case, it's more that svelte is the least of all evils when it comes to this. React and Vue have way more boilerplate and React in particular has the most framework-specific stuff of them all. Svelte is much closer to pure html/css, or so I'm told.
all of the js frameworks mentioned are view layer libraries. i.e. they create html. Hence they need a DSL for writing templated html, which will be used for generating final html
Hence, it is completely natural for them to offer a custom DSL as html does not have standard way of expressing those concepts.
Since each js framework has its own idiosyncrasies and motivations, custom DSLs reflect it.
If you were to go around and make a new js framework, you too are going to create a new DSL
I've used react for some years now and it's very very hard to do animation and event-driven operations with pure react render. You'll need extensive lifecycle events or hooks and refs to get animation or handle focus, etc well. It's due to how react render the components.
It doesn't make react bad but I guess some newer frameworks (vue, svelte, I haven't learned those yet) try to tackle this from different approach.
> I'm genuinely asking, because from a bystander's point of view, it certainly seems like the pattern of the Framework Du Jour hasn't really slowed down much in the frontend community.
Perhaps not in the "frontend community", no it hasn't slowed down. There will always be new frameworks coming and going, and people will work on them as fun open source projects or use them in their side projects or whatever. But people doing real work are almost unanimously settled upon React as an industry standard at this point. There's still a decent sized faction of contrarian Vue holdouts, but by and large the JS framework wars are over.
No, it's not wrong, it's absolutely correct. There's a lot of flexing around who can come up with the most elegant abstraction which ignores the important point: making sure what's necessary to understand the framework, use it long-term, and move away from it after is focusing on the core technologies of the web (HTML, CSS, and JavaScript).
The abstractions are cool, but completely unnecessary (see link to my framework above where I circumvent that problem entirely).
I assume because there's no value to it. What's the opposite side of the argument? You have an area with a lot of growth and many problems with the way we're solving these problems and something like svelte is not"completely reinventing the wheel" as the OP positions it, by nature it's try to solve specific problems using our existing tooling whenever possible. The original post is a shallow, feel-good rant
I don’t know about “wrong,” but my opinion on the overall theme of that first comment is that the requirement to learn is not at all a bad thing. I enjoy learning new things even when that is in some sense a “requirement.”
IMHO, syntax is the easiest part. Semantics are the tricky part. One very clear example of this is how Svelte and React deal with async stuff.
The Svelte approach follows the handlebar approach of having semantics be represented by DSL constructs - which is a very reasonable approach IMHO.
The Suspense semantics are so far off left field that someone literally wrote a whole framework specifically in response to its complexity[0].
And that complexity permeates every language construct used within a React component. Why can't we call hooks from inside if statements? Aren't if statements just JS? If you have to bring up React's internal implementation to explain, that's no longer "just Javascript", it's also a healthy chunk of very React-specific knowledge that you need to be aware of.
Vue is another example that provides a successful story of a very large algorithmic migration from a reactive system to virtual dom with virtually no disruption to consumers, thanks to the abstraction provided by its DSL. In contrast, try telling my wife (who's learning about class components in her React course) that functional components and hooks "are just JS, what's the big deal", and see how far that takes you :)
I completely agree with you, and I've yet to see a compelling argument against this. I've been doing this since the rise of the SPA, all the way from vanilla, jQuery, Backbone, Angular 1.0, Ember and React and after reading your comment all I can think of is "great, we're going back to handlebars templating again".
There is no net-gain in re-inventing the wheel. It just becomes yet another thing to master to stay relevant. In a decade of doing JS front-end applications things have only gotten more complex and more time-consuming.
Thankfully I've found a sweet spot where complexity, velocity and quality are in balance using technologies considered no longer cool and that's fine with me. I get to focus on the actual problem at hand instead of trying to figure out the inner workings of this new shiny thing.
The youngest framework of your list is 8 years old already. Svelte itself is gonna be 5 years old in a couple weeks, and there's absolutely no need to pick it up right now.
The meme that there are new frontends daily is extremely tired and has been totally false for several years now.
Also the only thing those baseless complaints achieve are flamewars and shitting in other people's work.
For me Vue 3 with <script setup> get's pretty close to pure JavaScript/TypeScript. 90% of the code will be exactly like JS code, the only difference being the use of computed(), ref() and reactive() to achieve (something JS simply doesn't provide but is necessary for every non-trivial application). Your HTML code and CSS code are not mixed with JS and look and feel like the real thing as well.
Other than the reactivity indication and the occasional onMounted(), etc. Vue 3 with <script setup> does away with all boilerplate and unidiomatic parts of Vue 2 and imo is the framework that most closely resembles pure HTML/CSS/JS while allowing for far greater productivity.
Are we still taking about vue <template>? I don‘t see how that is any way close to html when it has: custom conditional and loop syntax and semantics, arbitrary js expressions and a unique concept of scope?
I don’t love that aspect myself, but I have to point out that in Svelte’s case it is definitely not “without a very compelling reason”. The special build-time processing is the entire point of Svelte.
Though personally I’d almost prefer it was a whole new language than a “kind of JS but with some (necessarily) new syntax”
Because Svelte can look through the template, and at compile-time determine exactly which parts of the output need to be "surgically updated" in the DOM when some of the inputs change, without needing any runtime like a virtual DOM implementation. I don't know how you could implement such a thing (with good ergonomics) without a template language.
SolidJS[https://www.solidjs.com/] does exactly that. That ability is more about fine grained reactivity than it is about templates. The use of templates and single file components is a stylistic choice by the Svelte team. You could argue Solid has poor ergonomic compared to Svelte I guess.
React is a free for all, you can render pretty much anything you want at any time. With templating languages, the DOM output can be statically analyzed at build time, so the amount of work needed to diff the HTML output when things change at runtime can be dramatically shortened.
I used to be full stack before the re-invention of wheel phenomenon got way out of hand in the js world. Keeping up with what’s going on with the ecosystem and employing the best practices became a huge chore that took time away from solving actual business problems.
Turning away from front end let me concentrate time on learning devops, cloud, ml and other things that aren’t as volatile in terms of design patterns and that lets me design more high level solutions to problems and create more overall value.
Maybe people just differ in how wide or deep information they could handle but I certainly can’t keep up with such a wide array of patterns and tools that do the same thing.
The problem with each of these frameworks is that they make the mistake of surfacing the underlying standards like HTML and the DOM. This is why they look remarkably similar and can only possibly be incrementally better, at best.
HTML and the DOM are still essentially modeled on static documents. Building apps that deal directly with these standards is an impedance mismatch that, remarkably, people keep trying to solve by adhering to those same standards, but in a slightly different way.
Why should we know or care about HTML or the DOM?
A robust, event-driven, component-based framework that manages the low level Web standards could offer true advancement.
I just don't get people complaining of trivial or superficial stuff such as how to do ifs, loops or binding handlers. When the most important part of these tools are the architecture, the trade offs, the state managements, the tools, the libraries and the ecosystem.
Complaining just because of the syntax is just trying to convince yourself you don't like it.
It's like when people just discard tailwind because they don't like how ugly many classes together look on the html, ignoring everything behind it which is what really matters (and that you can still like or dislike).
But I think, I'd rather learn an entirely new technology or language instead of every year having to learn a JS Frankenstein language!
I kind of regret posting my OP now... as its turned into a bit of a flame war. It was not my intent.
And I applaud people try and build anything new. I'm just ranting a bit about how it feels like UI development has a new framework/language/ecosystem every year or that is touted as the next big thing to supersede the rest! But then ends up reinventing much of the same constructs only with subtly different syntaxes.
This is very overdramatic and isn't actually based on reality. Svelte is far closer to vanilla JS/HTML than any other framework, while also using extremely similar patterns from the other modern frameworks. Yeah, it has some sugar, but it's not just some templating system any more than React is just some templating system, and the only "unique syntax" you could be referring to is the auto-subscription to stores using $, which is super convenient.
You're acting incredibly disinformative, and have no legitimate basis for your assertions.
No special languages or syntax. Plain HTML, CSS, and JavaScript with the same reactive UI stuff in all the other frameworks. It's also part of a full-stack framework so you can whip up lightweight, fast apps.
The best part is your skills are transferrable as I'm not introducing any domain-specific abstractions. You can go from learning HTML, CSS, and JS to this without any "gotcha" in the process.
Any new language/framework trying to sell me on it's improved ergonomics should not bother showing me syntax and instead show me a stack trace. Vue is really concise and expressive but seeing a pile of node internals on every typo is infuriating.
Agreed, I thought we were past this with the 4th generation of these frameworks, this is like knockoutjs all over again.
The moment the penny dropped for me was when I read something like this about React:
"We realised that inventing our own Yet Another Binding Language that was less expressive than javascript was harder and worse than doing the work to put the relatively simple HTML constructs into Javascript"
Yeah, It‘s my favorite templating abstraction because I could convert it by hand and so I don‘t really need to mentally model it as an additional layer.
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.
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.
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.
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.
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.
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.
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.
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! :)
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?
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.
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.
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.
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.
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.
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'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.
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).
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!
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.
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 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.
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.
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
Why has this discussion become a Svelte vs React war? React is not going anywhere, Svelte is pretty cool and very young and it's exciting and it will be fun to see what cool new patterns emerge from larger use, as much as React patterns changed with time.
I started with Emberjs (which i love and had some faults), then move to React (which i love and had some faults), then Vue (which i love and had some faults) and now I am trying Svelte, which i love and has some faults.
That's what maintainers do, make their frameworks better.
people saying that they don't understand the new toy as well as the old toy they are used to...i mean...yeah!
and people saying that devs write bad code because of the framework, remember how much logic and bad code was in the view layer of mvc frameworks, how much logic and bad code was in class initializers and lifecycle methods in react components etc.
Give svelte some time and contribute to make it better if you care!
Svelte is really great. It really needs this boost in cash to polish the rough edges and improve tooling etc.
I’d add that most people here who are hating on the syntax didn’t go to check what svelte is actually about. I say that even though I work with React professionally
So smart by Vercel. So many people will use their platform because of the association with Rich. This is a marketing expense that will show up on the books as headcount. Rich deserves this, he's created an amazing project with an amazing community.
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 :)
The cool thing about Svelte is that it compiles your code in a way so that when variables change, bindings in HTML change, but only that HTML and not an entire DOM re-render. (Right?)
So, if this is the case, how come React couldn't do the same thing? They'd lose the ability to just include react in a script file, but why can't a smart compiler look at your JSX and throw out the virtual DOM component, so your variables are directly bound to where they're used in the HTML?
i did try that - https://twitter.com/swyx/status/1294310598419689472 but when the core team is not interested in it there's only so much i want to push it on my own - rather just move to Svelte where the community already gets it
Looks great! Seems to me that there’s just not enough pain around this. Ironically, React being “good enough” at performance (in most cases) probably means that there’s not appetite for squeezing out the last few millimeters (again for the vast majority of use cases — clearly there is some need otherwise svelte wouldn’t exist).
This might be possible in simple cases, but there are two reasons I think.
1. React has an ethos of being “just JavaScript” (despite the JSX syntax which is purely sugar around calls to React.createElement). This means the core team doesn’t seem to be interested in adding an extra compiler step.
2. Related to the above, because React is just JS, you can do all the normal and horrible things with it you can do in JS. Wanna pass React elements around in context or even using global variables? That’s allowed. A compiler could probably handle a lot of simple cases but there’s a whole lot of things it wouldn’t be able to deal with.
Hm, I think this isn't possible with React. You'd have to impose lots of constraints on how a component renders. Currently it's basically anything goes. IMHO, the result just wouldn't be React anymore.
In fact, Angular works exactly like this. Only the DOM nodes that have bindings/directives attached are updated, the rest is static during a component's lifetime. Though all this still involves tons of runtime framework code.
I actually think Ember/Glimmer happens to have the best implementation of this, where their diff can be incredibly optimised because they know the semantics of the template and can just skip all work on static elements and attributes that never change.
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.
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.
I like React’s opinionated top-down model (with callbacks passed downwards as needed either directly as props or through a store / context) for handling state changes, as this improves composability and ability to reason about state.
My understanding is that Svelte’s main difference from React is that it is not opinionated in this way, and this is considered a positive feature by its proponents. Is my understanding incorrect?
I think it is so much easier to simply `bind:value` than have to write my own event handler to update inputs, etc. Similarly, it's much simpler to have the parent bind to a property of the child rather than passing the value down along with a function to update the parent every single time. In effect it works the exact same way, but I have much less to do to get there.
Store-wise, Svelte stores aren't fundamentally different from having all of your state in Redux, and I prefer that it encourages smaller stores rather than one giant one.
On top of that, it just feels better to me writing HTML, CSS, and JS instead of trying to shoehorn everything into JS.
Virtual DOM? That’s the internal machinery that allows you to specify (and update) the UI declaratively while applying only localized updates on the actual DOM. It’s a feature, not a drawback, when you want to code declaratively.
Next just bought its biggest upcoming competitor—SvelteKit. Next is the best that React has to offer but it still has flaws. Svelte and SvelteKit are so awesome you cannot believe it before you've built something bigger and so much ahead of the entire React ecosystem.
We migrated a huge/complex React app in a month and the difference is night and day (performance/bundle size/dev productivity). React was great but it's time to move on.
I'm disappointed by Rich. Instead of thinking bigger, raising money (it would have been so easy, Rich, instead of doing proud conference talk after talk why didn't you talk to a VC??)—he just cashed out (sky-high compensation and ESOP). Not a rant and to give you some background, one major reason we went with SvelteKit was not to rely on the Next team. And now, I am again with them...
Now we have a monopoly of rare, modern SSR frameworks.
I understand this perspective! But as anyone who knows me will tell you, I would be the worst person in the world to try and build a business around Svelte. As others have said, the expectations from investors would make it far less likely that Svelte could remain a community-centric project.
It's important to clarify that Vercel (which has earned its open source bona fides) hasn't 'bought' Svelte or SvelteKit. It's more accurate to say that they're supporting Svelte's development by paying for a full time engineer to work on it. There's a healthy core team of developers who certainly won't relinquish _their_ independence because of _my_ career choices.
It's fair to be sceptical about all this! But I've had multiple conversations throughout this process where the importance of maintaining independence was expressed by both sides, and I truly believe this is the best outcome for Svelte and its community.
Congrats on the job, Rich! I've been using Svelte, Typescript & Babel in the past couple of months to build a set of TV apps targeting some fairly slow and ancient devices and it's been brilliant. Totally impossible to do that with React, I do know some people who tried it though.
Rich, I know where you come from, and I wholeheartedly believe what you say. But this is just the start of a relationship between you and Vercel. And you know that relationships will change over time and so on. And you won't.be.independent. There is just too much money on the table. Nobody will give you orders, there are much smarter ways.
The point is, Vercel did everything right, no blame to them, great CEO, awesome Tim, they are masterminds and their great social media army does their best to celebrate this event in all social networks atm. But you know yourself very well that one player just left the market. We will face less competition and possibly stagnation in some areas. This doesn't hurt Vercel nor you but us.
Ofc you will be dependent, they pay you, you want Vercel to be successful (ESOP). We will see, e.g. that Vercel will be a first-class citizen as deployment option. There are many more fields where Vercel can/will get a special treatment, so subtly that nobody will get it. Business is more sophisticated than many might think.
Or think this the way around, there endless possibilities to drive somebody down, demotivate and degenerate him to a point where he looses all his drive and motivation. Look at yourself today, look how much energy and charisma you have when holding speeches about Svelte. In 2 years, go back to this comment and ask yourself if you are the same energetic Rich, if you are happy and if sold out too early 2 year ago.
> I would be the worst person in the world to try and build a business around Svelte.
No you just underestimate yourself. What are you doing right now? Giving talks, writing, communicating. People, masses follow you not just because Svelte is great, no because you can communicate well and know how to lead people. This is what a CEO is doing 99% of his day. This is building a business, communicating, finding and winning the best people.
You found already the best people, just look in your repos and look which contributors work for Svelte! And you were the leader, had an as good team as Vercel and follow now...
And if I watch you talking there is a strong desire to be more (not that a dev is less!). Whatever, I'd have expected that you at least went shopping with Vercel's offer to CloudFlare. I mean they do real rocket science (Durable Objects) and you opt for Next which started to renovate their stack (esm, swc) just recently after years.
Oh man, I like you too much to be too angry but yeah, not happy.
We're all lucky that you got a polite, substantive reply, but please don't cross into personal attack like this in HN comments. It generally causes discussion quality to tank drastically.
@dang, second reply and apologies, now I know what you mean, I edited some part away which you probably meant and which is still in quotes of others' comments. Sorry, I'll try to improve and thanks for the hint!
Can't follow you, what do you mean/where did I cross into personal attacks? I highly appreciate Rich but the elephant in the room had to be addressed, especially on HN.
I wonder that I am the only one that questions his move and that you also approach me instead of welcoming a healthy debate. Whatever, I guess you just do your job.
Btw, when does HN get proper pagination and a darkmode?
Do I get shadowbanned now for asking too many questions?
> Instead of thinking bigger, raising money (it would have been so easy, Rich, instead of doing proud conference talk after talk why didn't you talk to a VC??)
In no world would taking VC funding have been easier. They’d want cash returns and hockey stick growth, and soon. So instead of focusing on making the framework as good as it could be, Rich’s attention would be diverted.
When SvelteKit becomes a framework impossible to run on anything that isn’t a Vercel platform, then maybe I’ll be outraged. Until then, subjecting an incredibly talented developer to the day-to-day whims of VCs seems like just about the worst outcome for everyone.
I don’t normally mean to sound uncharitable but your original comment is pretty uncharitable to Rich, so: if you want a stable platform that will live for many years to come, the absolute last thing you want is for it to take VC investment. That you don’t see this speaks volumes to your understanding of how any of this works.
> In no world would taking VC funding have been easier.
Did I say that? Or that Rich should have taken the easier path? No, everyone should always take the harder path. But this is a deeper discussion.
> I don’t normally mean to sound uncharitable but your original comment is pretty uncharitable to Rich,
But your tone towards me is better?
> That you don’t see this speaks volumes to your understanding of how any of this works.
If you think so, fine, but I'm pretty sure that I've raised more money and more rounds than you but this shouldn't qualify me to be right or wrong. I focus on what you write and what I've written and I think I brought good arguments that a market turned into a monopoly and this is not great. Can we blame Rich, probably not. Can be disappointed and still respecting him? Yes.
interesting that you think talking to a VC and starting a startup (where he would be spending >50% time on business things and be forced to come up with a monetization plan) is better for svelte than getting fulltime sponsorship to solely work on Svelte and working with the top tier talent at Vercel.
Svelte and Vue got started when someone just went and did it. If you think it's so important to have many competitors in this space, just go and do it :)
No desire to be acquired (open to investment but that's it), just build a business around accompanying features/services.
Goal is fast, simple, and friendly regardless of your skillset. No lock-in as the entire thing is a thin abstraction over Node.js/Express.js and components are built using plain HTML, CSS, and JS (no special languages or syntax). Also adding in a lot of helper stuff so you're not stuck cobbling together random packages for common stuff (i18n, form validation, etc).
Feel free to email me if you or your team have questions: ryan.glover@cheatcode.co.
> I'm disappointed by Rich. Instead of thinking bigger, raising money (it would have been so easy, Rich, instead of doing proud conference talk after talk why didn't you talk to a VC??)—he just cashed out (sky-high compensation and ESOP). I lost all my respect. Not a rant to give you some background, one major reason we went with SvelteKit was not to rely on the Next team. And now, I am again with them.
Who the hell do you think you are? You don't know his situation. You don't know anything. How do you know he doesn't have a gravely ill family member and needs a steady income more than he needs to "think big" about a fucking javascript framework? How do you know he's not deeply in debt from a past mistake? How do you know he doesn't find the tech obsession with "VC" funding repugnant? No one needs sxiao's judgment.
I'm sure he'll see this soon, so congrats Rich! Svelte has been a cool project since the beginning, and I'm excited to see Rich have more time to work on this. As an early contributor I've seen Svelte go through a lot of maturing and it's exciting to see it finally getting the recognition it deserves lately.
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.
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.
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.
I've been a fan of Svelte and Vercel for a while so it's cool to see Rich working with them, and for Svelte to get more support. Very excited to see what comes of this!
Feels like a good move. How else could framework be developed than implementing some requirements. Vercel should provide lots of them.
What else can be added to Svelte btw? It looks like a finished project already. People can only invent in Svelte area if browser standards move forward, right? Otherwise Svelte can only be used to support needs of some platform.
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.
Honestly, don’t really know much or care much about Svelte for my own use. But hearing that someone is going to be sponsored to work on their invention full-time is wonderful. Glad to witness this personal victory and sending good vibes to help make Svelte great.
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.
Cancel culture and wokism is alive in well in the svelte community. I was banned twice from discord and again from reddit's sveltejs sub.
The bay area svelte group is looking for a new moderator, I was going to do it, but after this experience I decided I will just wait until something better than svelte comes along.
`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!
Didn't know who Rich Harris was. Could probably include that in the title, or link to the blog post on the Vercel website. Clicking on his Twitter picture requires logging in and only through the Vercel blog post headline did I find out.
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.
I guess I'm not a fan of seeing investors money expand it's control over the open source ecosystem. I like open source because it empower the little guys. But I don't expect others to share my values and perspective and perhaps Rich Harris turns out to be a robinhood. Why not doing something like the creator of Vue? With that said I look forward to see what comes out of their shop. Good luck :)
People downvoting...I've bootstrapped my own business so I can speak my mind freely and don't mind being disliked, as long as my customers like my work.
Now for today's topic:
1) life 101: nobody gives you money for nothing
2) If they give you 5% they will act as if they have given you 90%, it will happen gradually
3) Vercel is seeking monopoly over front-end deployment using investors money and buying open source contributors, of all the major frameworks, they would have done the same with ReactJS and Vue if they could and they will try doing it with any framework that gains momentum. It is a fine strategy, not my cup of tea.
4) I'd rather support bootstrapped business and solo developers
5) I personally wonder how someone with the portfolio of Rich Harris couldn't manage to get sufficient sponsorship to go full-time given how much value he has generated to the community, I think this is something open source community need to tackle, perhaps crypto can help contributors make money earning easier? How about 1 token for each download, fork or install something like that that would help open source contributors generate money just by creating value...something is really broken here and I think there is a room to innovate with micropayments, I mean we know the likes, forks, issues, we have the entire repo content, we have the history of the contributors, given all the fuss about crypto, I wonder why haven't we seen anything in that direction yet, am I missing something? I think monetization of open source should be built within the platform (Github or some modern alternative), with different options on how contributors can run their content creation business. They can choose to give it free, free up to a point, or charge from day one, it is still open source, etc. Lots of room for innovation.
6) Many people share my mindset, but afraid to speak out, so here it, is plain and simple.
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.
Agree 100%. The migration from componentDidMount, componentDidUpdate, etc to useEffect was a major regression in terms of readability.
The return function in useEffect vs. componentWillUnmount is just terrible. This is always a bizarre topic for juniors.
16 replies →
useEffect makes easy things easy and hard things very hard indeed.
After building a few non trivial apps in React with hooks I'm convinced that what you really need for that model to work smoothly is a new language that tracks things like hook dependencies for you.
5 replies →
Yeah useEffects was the start over overcomplicating react.
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.
Redux is not React specific. I assume you could use it with Svelte somehow.
That said, most React components are lightyears ahead of native Javascript components, simply because everyone uses React.
1 reply →
I'm looking forward to picking up Svelte and just going back OOP for state management. Immutable state with React was a massive eye opener, but right now I think OOP is just better for state management, especially with all the insights gained from using React.
How about unstyled components like a dropdown menu or a multi-select with autocomplete?
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.
Is it surprising that two-way data binding is a source of bugs? We learned that lesson from Angular, and it influenced React’s preference for one-way dataflow.
10 replies →
Not the GP, but here's an example of abstraction leaking straight from their intro tutorial:
> A simple rule of thumb: the name of the updated variable must appear on the left hand side of the assignment. For example this...
> ...won't trigger reactivity on obj.foo.bar, unless you follow it up with obj = obj.
This looks like a huge footgun to me, and it's not even an exotic usecase. It's in the very first page talking about reactivity in the docs.
3 replies →
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.
> Two way data binding is not a constant source of bugs
Every team using AngularJS _did_ have those problems (not to say it didn’t have some niceties also). It was one of the big architectural changes in Angular (2+) as a direct result. React does not have this feature; passing down a setter function is not the same as automatic 2-way binding.
As to your first point, different things feel like magic to different people, so it’s really hard to debate this with other people with different perspectives unless maybe your talking about single specific instances. It’s like trying to tell someone they don’t feel cold because you don’t feel cold or vice versa.
> - Special syntax for reactivity is not javascript
> - 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.
Sure, but it maps 100% to an expected JS syntax and improves readability (subjective). From <div attr1="str">{children}</div> To React.createElement("div", { attr1: "str" }, children) Custom templating is not like that.
5 replies →
JSX is more akin to a macro than a DSL, which is why I strongly prefer it. Debugging errors in templating languages is invariably more frustrating and time consuming.
More on point, being constrained within the special language is miles away from the constraint of JSX, which is essentially limited to only allowing expressions, because the macro expands to expressions. Everything else is fair game, and that makes it far more expressive.
> 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.
As I see it, the main issue with new syntaxes is the fact that they break compatibility with existing tooling. JSX is not fundamentally different in this regard, except for the fact that it gained so much mindshare that it brute-forced its way to getting first-class support in editors, language servers, different frameworks, even TypeScript. I don't predict that very many new JS-adjacent syntaxes will get that treatment from the industry.
4 replies →
> 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.
JSX popularized it but we built it with opalang.org first (also with strong static typing before TS)
2 replies →
Funny as when I used React back in 2015 it was my least favorite feature (I moved to Vue since then).
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.
============== Svelte > React ==============
> And why doesn't it allow style tags?
You can 100% use style tags in React, they just aren’t automatically wrapped in module/component scope. Just like normal HTML style tags, actually.
As for JSX, I personally have always hated HTML template languages (“now which slightly-different version of the for iterator does this template get use?”) but I also recognize that there are other people who have opposite preferences. JSX-in-JS and template-directives-in-HTML are both valid approaches and it’s great that there are solutions to cater to various preferences. Trying to argue one down because you don’t like it is like arguing that your favorite color is factually superior.
> 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
> Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte
Do you have some specific examples?
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!
> 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.
This is the gist of the whole comment. The person posting is not complaining about a bad Svelte experience, they're complaining about bad programming practices.
>- Special syntax for reactivity is not javascript
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.
> Special syntax for reactivity is not javascript
That's because there is no syntax for reactivity in JavaScript, period.
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
What are some examples of this?
“ - 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.”
What? Can you expand on that? Makes no sense.
I read it as: Svelte is faster in theory, but since people write bad Svelte code, it is slower than the React code the same developers would write.
My interpretation is that this can be attributed to either svelte being hard to write, or people being used to React. Both of which are a challenge to companies looking to switch to Svelte.
Yes, clearly it is not for purists.
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!)
Ben, please don't surprise us and tell that you are the next one on Vercel's payroll.
2 replies →
Bless you.
> ecosystem is larger by a good amount.
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.
It's also really easy to use with typescript.
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.
> So just about any JavaScript package can be imported into a Svelte file and used without hassle.
But you can import any package into React (or any other framework) as well.
1 reply →
Hearing about a JS framework "X" that is surely that much more elegant than "Y" feels like it's 2010s again!
At least this time Svelte is a step closer toward the native browser stack rather than yet another abstraction layer.
2 replies →
Well if there‘s any place to learn from next.js it‘s probably Vercel. Looks like great news for Svelte.
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!
> I was able to step through the compiled Svelte component code and narrow it down to one of my own functions.
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.
Love me some good old synchronous code! :D
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.
1 reply →
I see your app is MacOS only at the moment. Are you re-writing it in Electron or what? Very curious
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.
17 replies →
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).
2 replies →
Looks cool - what is the timescale for Windows?
Weeks to months, hopefully by the end of the year? We’ll see! A lot depends on what other challenges come up, heh.
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.
Links: - https://lu.ma/sveltenyc - https://lu.ma/sveltesummit-2021-mainz
Genuinely curious, what’s there to do about for an entire conference about a single library? For someone from academia, where conferences typically span an entire field of research, this seems extremely niche and quite boring after a bit..
Well - that might be overstating the matter; after all, academia also has workshops focused on very small niches...
...but also: it's not uncommon to find industry conferences about a specific framework, because it's not just about the framework - it's about the uses to which that framework can be put, and about interacting with the community around that framework. Both of those facets permit a lot of variety, especially for foundational tools (e.g. web application frameworks, UI libraries, database platforms, etc.)
Because the last Computer Science Conference I went to wasn't small and cozy enough that I got to hang out and personally chat with the leaders in the field.
Meetup with people who share an interest itself fun?
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.
Hey, Lee from Vercel. I'm sorry you had a bad experience here. If you want to email lee @ vercel, I'd love to hear what we could have done better.
Hi Lee. I appreciate the offer but the simple answer is that Vercel abruptly pivoted away from backend oriented services. That broke everything I built on the Now v1 platform and there wasn't anything to do but switch to other providers. It was stated that migration to Now v2 would be simple but that never materialized in time for the Now v1 shut down. On top of that, I encountered a lot of bugs with the deployment system when the new infrastructure started coming online, where it would auto deploy to data centers that couldn't run Now v1 apps and then the CLI would crash. I tried to be understanding, given you were a startup in a competitive space. It was unfortunate but I decided to at least continue using your domains and DNS features. But then the format of the zeit.world nameservers changed a couple of times and again with relatively short notice. Other frustrations... the domain search & buy page used to be public, now it requires a login for seemingly no reason (trying to keep bots out?). The marketing of early Zeit was all about embracing open standards and now Vercel is basically the exact opposite, with proprietary solutions for running frontend projects being at the heart of the product. I can only guess as to why it unfolded that way, but the transition was extremely rough for people who bought into the original vision. I just logged in now to transfer out some domains I still have in there and discovered that years later you still don't have a way for customers to change their domain's nameservers other than contacting support. That's just user hostile. A lot of people would say that is a dark pattern. I've literally never encountered another registrar that didn't have a simple button to change my domain's nameservers. Having to contact support to do this was excusable when your company was only a year old, but at this point it looks negligent, if not deliberate.
If you want more details, my contact info is here: https://seth-holladay.com/contact
"Sane" lol have you ever used it?
It's only sane if you use it raw (i.e. ESM in, UMD out), but add plugins and suddenly you have a slower and less capable webpack with lengthy config.
I'm generally a fan of Rich’s tools but they only look good on the surface generally. Svelte itself changed face 3 times already, with each iteration completely incompatible with the old one.
Be ready for Svelte 4 I guess.
Maybe I'm misreading your comment, but Richard Harris did not create esbuild. Evan Wallace, co-founder of Figma, is the person behind it.
You are misreading. He's saying that rollup[1] was the only other option for bundling static assets besides webpack until esbuild was created. Rollup was created by Rich.
- [1]: https://rollupjs.org/guide/en/
1 reply →
You did misread.
> Until esbuild came along, Rollup was the only sane JS bundler
Rich Harris did create Rollup
Rich created rollup :)
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.
For all the use cases I deal with on a regular basis, Svelte looks more like vanilla HTML/JS than any equivalent React code.
And the reason these things change is because that's what needed changing. One of the topline features of Svelte is that is has less boilerplate than React, and it achieves that quite handily. Unless you're criticizing particular constructs in Svelte that are unjustifiably different, I don't think unfamiliarity is that damning a criticism.
Maybe I'm just used to switching up languages on a regular basis, but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task.
What how can you say that???
vs... svelte
One is literally just javascript and html the other is an entirely different template language. You might say... JSX is not HTML... well it's very very similar... If you know HTML you JSX is very intuitive.
84 replies →
> but the idea of having to learn different language constructs for loops and the like doesn't seem that herculean of a task.
I agree. As long as you understand the basic concepts, it's only a matter of learning the syntax, which is really not as big of a deal as the person you replied to is making it out to be.
6 replies →
What boilerplate does React have? Do you mean Babel?
2 replies →
As a backend guy who moved away from frontend long ago for these very reasons, I have to ask: why are people downvoting this? Is it wrong? I'm genuinely asking, because from a bystander's point of view, it certainly seems like the pattern of the Framework Du Jour hasn't really slowed down much in the frontend community.
It might be true, but it's a rant that just barely touches the actual topic, which is mostly: a company will pay somebody to work full time on an open source project that is still independent. And I think it's pretty nice. And also I think Rich Harris has given a lot to people for free and I'm happy for him that he will be paid to work on something that he loves.
So all in all it would be nice if we would for once be spared of rants how tiring, immature, half baked whatever whatever the JavaScript world is. Show us maybe how it should be really done, but maybe in a separate post please.
I didn't downvote, but I'll speak to my experience.
First off, you don't have to go learning every framework out there. Pick one and stick with it, or just go vanilla. That said, The features these frameworks provide gives a boost in productivity that far outweighs the low learning curve.
My pick was VueJS and I'm very happy with it. Using Single File Components is pretty similar to vanilla HTML/JS/CSS. Beginners that were under my guidance (with only HTML/CSS/JS experience) usually pick it up and were productive in the same day.
I disagree that React (JSX) is most similar to vanilla JS/HTML at all (I don't prefer it, but to each their own). Vue and Svelte are much further on the side of a vanilla-ish approach.
16 replies →
It is wrong because it has slowed down to a crawl compared to what we had from 2010-2014.
Most companies have settled on either React or Vue, which are extremely similar. Angular is used in some niches, almost always because teams already knew it.
Those three are responsible for almost 99% of the frontend positions you'll see.
Svelte is getting popular but so far it's still niche. It's more of an inspiration for others, but also a contender. And really, what's so wrong about having more options and more competition? Even if you want to stop learning new things, there'll be no shortage of job vacancies for the three frameworks above.
Also, since you're a backend dev, there are much more backend languages in use today than frontend frameworks, to give an example. And it's not hard to find companies using more than one.
It's a false truth that anyone has to learn yet another one of these. Even Angular 1 and Backbone.js are still in production.
3 replies →
Well in this case, it's more that svelte is the least of all evils when it comes to this. React and Vue have way more boilerplate and React in particular has the most framework-specific stuff of them all. Svelte is much closer to pure html/css, or so I'm told.
The comment is negative and incorrect
all of the js frameworks mentioned are view layer libraries. i.e. they create html. Hence they need a DSL for writing templated html, which will be used for generating final html
Hence, it is completely natural for them to offer a custom DSL as html does not have standard way of expressing those concepts.
Since each js framework has its own idiosyncrasies and motivations, custom DSLs reflect it.
If you were to go around and make a new js framework, you too are going to create a new DSL
I've used react for some years now and it's very very hard to do animation and event-driven operations with pure react render. You'll need extensive lifecycle events or hooks and refs to get animation or handle focus, etc well. It's due to how react render the components.
It doesn't make react bad but I guess some newer frameworks (vue, svelte, I haven't learned those yet) try to tackle this from different approach.
> I'm genuinely asking, because from a bystander's point of view, it certainly seems like the pattern of the Framework Du Jour hasn't really slowed down much in the frontend community.
Perhaps not in the "frontend community", no it hasn't slowed down. There will always be new frameworks coming and going, and people will work on them as fun open source projects or use them in their side projects or whatever. But people doing real work are almost unanimously settled upon React as an industry standard at this point. There's still a decent sized faction of contrarian Vue holdouts, but by and large the JS framework wars are over.
Didn't downvote either. Almost consider upvoting for visibility of the hilarity displayed.
"There are too many frameworks! Why does everyone keep re-inventing the wheel? Why can't everyone just use the one that I like?"
2 replies →
No, it's not wrong, it's absolutely correct. There's a lot of flexing around who can come up with the most elegant abstraction which ignores the important point: making sure what's necessary to understand the framework, use it long-term, and move away from it after is focusing on the core technologies of the web (HTML, CSS, and JavaScript).
The abstractions are cool, but completely unnecessary (see link to my framework above where I circumvent that problem entirely).
2 replies →
I assume because there's no value to it. What's the opposite side of the argument? You have an area with a lot of growth and many problems with the way we're solving these problems and something like svelte is not"completely reinventing the wheel" as the OP positions it, by nature it's try to solve specific problems using our existing tooling whenever possible. The original post is a shallow, feel-good rant
I don’t know about “wrong,” but my opinion on the overall theme of that first comment is that the requirement to learn is not at all a bad thing. I enjoy learning new things even when that is in some sense a “requirement.”
It sounds like you'd be better off with something like Ruby's Hotwire/Stimulus, ASP.Net Core/Blazor or Elixir/Phoenix Live View.
IMHO, syntax is the easiest part. Semantics are the tricky part. One very clear example of this is how Svelte and React deal with async stuff.
The Svelte approach follows the handlebar approach of having semantics be represented by DSL constructs - which is a very reasonable approach IMHO.
The Suspense semantics are so far off left field that someone literally wrote a whole framework specifically in response to its complexity[0].
And that complexity permeates every language construct used within a React component. Why can't we call hooks from inside if statements? Aren't if statements just JS? If you have to bring up React's internal implementation to explain, that's no longer "just Javascript", it's also a healthy chunk of very React-specific knowledge that you need to be aware of.
Vue is another example that provides a successful story of a very large algorithmic migration from a reactive system to virtual dom with virtually no disruption to consumers, thanks to the abstraction provided by its DSL. In contrast, try telling my wife (who's learning about class components in her React course) that functional components and hooks "are just JS, what's the big deal", and see how far that takes you :)
[0] https://crank.js.org/blog/introducing-crank
I completely agree with you, and I've yet to see a compelling argument against this. I've been doing this since the rise of the SPA, all the way from vanilla, jQuery, Backbone, Angular 1.0, Ember and React and after reading your comment all I can think of is "great, we're going back to handlebars templating again".
There is no net-gain in re-inventing the wheel. It just becomes yet another thing to master to stay relevant. In a decade of doing JS front-end applications things have only gotten more complex and more time-consuming.
Thankfully I've found a sweet spot where complexity, velocity and quality are in balance using technologies considered no longer cool and that's fine with me. I get to focus on the actual problem at hand instead of trying to figure out the inner workings of this new shiny thing.
The youngest framework of your list is 8 years old already. Svelte itself is gonna be 5 years old in a couple weeks, and there's absolutely no need to pick it up right now.
The meme that there are new frontends daily is extremely tired and has been totally false for several years now.
Also the only thing those baseless complaints achieve are flamewars and shitting in other people's work.
1 reply →
I think the pendulum may be swinging back with options like Rails/Hotwire, ASP.Net Core/Blazor and Elixir/Phoenix Live View. Let's hope so.
For me Vue 3 with <script setup> get's pretty close to pure JavaScript/TypeScript. 90% of the code will be exactly like JS code, the only difference being the use of computed(), ref() and reactive() to achieve (something JS simply doesn't provide but is necessary for every non-trivial application). Your HTML code and CSS code are not mixed with JS and look and feel like the real thing as well. Other than the reactivity indication and the occasional onMounted(), etc. Vue 3 with <script setup> does away with all boilerplate and unidiomatic parts of Vue 2 and imo is the framework that most closely resembles pure HTML/CSS/JS while allowing for far greater productivity.
Are we still taking about vue <template>? I don‘t see how that is any way close to html when it has: custom conditional and loop syntax and semantics, arbitrary js expressions and a unique concept of scope?
3 replies →
You don't need to know every framework. And that little bit of custom syntax is peanuts compared to how the rest of these differ.
Even if Angular and React shared the same templating syntax, you'd still be left with 95% of work ahead of you.
I don’t love that aspect myself, but I have to point out that in Svelte’s case it is definitely not “without a very compelling reason”. The special build-time processing is the entire point of Svelte.
Though personally I’d almost prefer it was a whole new language than a “kind of JS but with some (necessarily) new syntax”
100% no more js frankensteins...
Id prefer to learn a new language altogether
Because Svelte can look through the template, and at compile-time determine exactly which parts of the output need to be "surgically updated" in the DOM when some of the inputs change, without needing any runtime like a virtual DOM implementation. I don't know how you could implement such a thing (with good ergonomics) without a template language.
SolidJS[https://www.solidjs.com/] does exactly that. That ability is more about fine grained reactivity than it is about templates. The use of templates and single file components is a stylistic choice by the Svelte team. You could argue Solid has poor ergonomic compared to Svelte I guess.
> I don't know how you could implement such a thing (with good ergonomics) without a template language.
Parse Javascript? I don’t see how it would be any different, except you have more constructs to work through.
1 reply →
React is a free for all, you can render pretty much anything you want at any time. With templating languages, the DOM output can be statically analyzed at build time, so the amount of work needed to diff the HTML output when things change at runtime can be dramatically shortened.
I used to be full stack before the re-invention of wheel phenomenon got way out of hand in the js world. Keeping up with what’s going on with the ecosystem and employing the best practices became a huge chore that took time away from solving actual business problems.
Turning away from front end let me concentrate time on learning devops, cloud, ml and other things that aren’t as volatile in terms of design patterns and that lets me design more high level solutions to problems and create more overall value.
Maybe people just differ in how wide or deep information they could handle but I certainly can’t keep up with such a wide array of patterns and tools that do the same thing.
The problem with each of these frameworks is that they make the mistake of surfacing the underlying standards like HTML and the DOM. This is why they look remarkably similar and can only possibly be incrementally better, at best.
HTML and the DOM are still essentially modeled on static documents. Building apps that deal directly with these standards is an impedance mismatch that, remarkably, people keep trying to solve by adhering to those same standards, but in a slightly different way.
Why should we know or care about HTML or the DOM?
A robust, event-driven, component-based framework that manages the low level Web standards could offer true advancement.
What would that look like for you? Something like SwiftUI or Flutter (which feel React inspired) or a totally different thing?
2 replies →
perhaps you are right about DOM but isn't HTML/XML just a way of representing an object tree... I don't see anything inherently wrong with this?
1 reply →
The templating language is the easiest thing to learn. The hardest is architecture.
I just don't get people complaining of trivial or superficial stuff such as how to do ifs, loops or binding handlers. When the most important part of these tools are the architecture, the trade offs, the state managements, the tools, the libraries and the ecosystem.
Complaining just because of the syntax is just trying to convince yourself you don't like it.
It's like when people just discard tailwind because they don't like how ugly many classes together look on the html, ignoring everything behind it which is what really matters (and that you can still like or dislike).
Because if we do not keep constantly learning and get better, we would be stuck writing COBOL and BASIC.
haha fair enough!
But I think, I'd rather learn an entirely new technology or language instead of every year having to learn a JS Frankenstein language!
I kind of regret posting my OP now... as its turned into a bit of a flame war. It was not my intent.
And I applaud people try and build anything new. I'm just ranting a bit about how it feels like UI development has a new framework/language/ecosystem every year or that is touted as the next big thing to supersede the rest! But then ends up reinventing much of the same constructs only with subtly different syntaxes.
You're getting flamed on Twitter for this comment lol: https://twitter.com/dancow/status/1458906853488967684
This is very overdramatic and isn't actually based on reality. Svelte is far closer to vanilla JS/HTML than any other framework, while also using extremely similar patterns from the other modern frameworks. Yeah, it has some sugar, but it's not just some templating system any more than React is just some templating system, and the only "unique syntax" you could be referring to is the auto-subscription to stores using $, which is super convenient.
You're acting incredibly disinformative, and have no legitimate basis for your assertions.
You'd like https://github.com/cheatcode/joystick.
No special languages or syntax. Plain HTML, CSS, and JavaScript with the same reactive UI stuff in all the other frameworks. It's also part of a full-stack framework so you can whip up lightweight, fast apps.
The best part is your skills are transferrable as I'm not introducing any domain-specific abstractions. You can go from learning HTML, CSS, and JS to this without any "gotcha" in the process.
Any new language/framework trying to sell me on it's improved ergonomics should not bother showing me syntax and instead show me a stack trace. Vue is really concise and expressive but seeing a pile of node internals on every typo is infuriating.
Very true... How can I debug this thing when it breaks that's a great question. I wonder how sourcemaps work with svelte
No one says you have to learn new languages or frameworks. It's really your own choice.
Agreed, I thought we were past this with the 4th generation of these frameworks, this is like knockoutjs all over again.
The moment the penny dropped for me was when I read something like this about React:
"We realised that inventing our own Yet Another Binding Language that was less expressive than javascript was harder and worse than doing the work to put the relatively simple HTML constructs into Javascript"
And then you have ended up with shadow DOM.
They are all just trying to replicate XSLT - but by mixing imperative with declarative syntaxes.
This is why I have focused on backend for the last decade.
My solution is pretty easy to this problem: I don't.
JSX is syntactic sugar for `React.createElement(...)` (most commonly), so React pretty much is plain JavaScript.
Yeah, It‘s my favorite templating abstraction because I could convert it by hand and so I don‘t really need to mentally model it as an additional layer.
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.
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.
Yeah, I really like the middle ground approach, but having tried almost everything in the category, my favourite by a long margin is Unpoly.
What bits were misdirected? What worries did you have?
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.
3 replies →
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.
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
This is so HN, in an Svelte thread memories from Ember (sharing your sentiments though).
2 replies →
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.
10 replies →
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.
What could be improved in the documentation?
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.
Svelte doesn't support JSX/TSX though =(
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).
Glad to see you here Lee!
> 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! :)
2 replies →
> The governance of Svelte isn't changing
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?
1 reply →
> Svelte doesn't support JSX/TSX though =(
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.
Plus JSX is based on a "Virtual DOM", and "Virtual DOM is Pure Overhead":
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.
1 reply →
>It actually supports the next best thing: HTML!
Haha - Oh where will our crazy tech take us next :D
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.
8 replies →
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.
You can "sprinkle" react too
2 replies →
> Svelte doesn't support JSX/TSX though =(
You have https://www.solidjs.com/ that does
Solid is really cool, and I love the posts by it's author describing the journey to performance that is some years old now.
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.
1 reply →
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.
3 replies →
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.
Check out what I'm working on. I'm staying indie indefinitely: https://github.com/cheatcode/joystick.
No JSX or other templating languages, just plain HTML.
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.
But, that's just me
1 reply →
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.
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.
We changed the url from https://news.ycombinator.com/item?id=29189467). I've merged those threads into the current submission because it was posted first.
Thanks dang! This was the right move.
Agreed, thank you so much.
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.
This is absolutely fantastic news!
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.
Rich Harris Coined the Term “FauxSS”: Fake OSS!
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. ;)
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.
My favorite feature of Sveltekit is probably the server-side endpoints. It's so easy to create an API using them.
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.
Svelte is fucking awesome.
Long way to go to catch up to React, but it'll get there. No brainer.
Yes, it is good. In many ways I hope it doesn’t catch up to React - it’s running a different journey which I also prefer.
Catch up in terms of hirability/company usage.
7 replies →
Woah as a Svelte user I'm super happy and this is going to change everything.
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!
We love Svelte and are super excited to help it grow. IMO it's fun, easy to learn, and is fresh take on modern web development.
More here: https://vercel.com/blog/vercel-welcomes-rich-harris-creator-...
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).
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!
[1] https://twitter.com/swyx/status/1456665048949018626
2 replies →
SvelteKit has an out-of-the-box adapter for Cloudflare workers: https://github.com/sveltejs/kit/tree/master/packages/adapter...
I hope that Rich joining Vercel doesn't end up compromising SvelteKit's current neutrality when it comes to deployment targets.
1 reply →
This is kind of exactly my point in not owning the full stack with Serverless.
I'd be a bit nervous right now if I built my business / app on that.
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.
This is not Cloudflare:
> Flareact is an experiment created by Josh Larson in August 2020.
1 reply →
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 predict that Cloudflare will acquire Vercel one day.
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.
1 reply →
I think an executive has commented before that is not going to happen. Things can change though.
If I were Vercel, absolutely would not sell either. They aren't like "Netlify" and positioned to be truly the goat of serverless.
1 reply →
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.
Vercel's infrastructure is multi-cloud, primarily using AWS. We're currently using Workers specifically for Edge Functions (https://vercel.com/edge).
2 replies →
Do you have a reference for this? Curious to learn more. I thought Vercel was built on AWS.
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
Denoflare (https://news.ycombinator.com/item?id=29142772) is compelling.
Do you have experience with denoflare? I really would like to try it, but I can't even get the basic `hello-worker` sample working, see https://github.com/skymethod/denoflare/issues/2
1 reply →
Also not Cloudflare (to my knowledge)
1 reply →
Great news for everyone using Svelte - a good move by Vercel and wish Rich gets more resources and freedom to continue the refinement of Svelte.
Why has this discussion become a Svelte vs React war? React is not going anywhere, Svelte is pretty cool and very young and it's exciting and it will be fun to see what cool new patterns emerge from larger use, as much as React patterns changed with time. I started with Emberjs (which i love and had some faults), then move to React (which i love and had some faults), then Vue (which i love and had some faults) and now I am trying Svelte, which i love and has some faults. That's what maintainers do, make their frameworks better.
people saying that they don't understand the new toy as well as the old toy they are used to...i mean...yeah! and people saying that devs write bad code because of the framework, remember how much logic and bad code was in the view layer of mvc frameworks, how much logic and bad code was in class initializers and lifecycle methods in react components etc.
Give svelte some time and contribute to make it better if you care!
Awesome. Been using Svelte exclusively for a couple years in my projects and don't see myself using React ever again.
Svelte is really great. It really needs this boost in cash to polish the rough edges and improve tooling etc. I’d add that most people here who are hating on the syntax didn’t go to check what svelte is actually about. I say that even though I work with React professionally
So smart by Vercel. So many people will use their platform because of the association with Rich. This is a marketing expense that will show up on the books as headcount. Rich deserves this, he's created an amazing project with an amazing community.
Can someone explain what Vercel does.
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.
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 :)
2 replies →
They are a competitor with other clouds like AWS/Azure/GCP/DigitalOcean with a focus on JAMStack and modern workflows.
More like a competitor to Netlify, GitHub Pages, etc
Vercel is a hosting provider for static websites. I see it as a simplified versions of AWS, specifically for static websites.
Used to be called Now. It’s a PaaS.
We have used Svelte for a major internal project and it has been an absolute joy to work with.
This is really exciting news.
I have a stupid question:
The cool thing about Svelte is that it compiles your code in a way so that when variables change, bindings in HTML change, but only that HTML and not an entire DOM re-render. (Right?)
So, if this is the case, how come React couldn't do the same thing? They'd lose the ability to just include react in a script file, but why can't a smart compiler look at your JSX and throw out the virtual DOM component, so your variables are directly bound to where they're used in the HTML?
i did try that - https://twitter.com/swyx/status/1294310598419689472 but when the core team is not interested in it there's only so much i want to push it on my own - rather just move to Svelte where the community already gets it
Looks great! Seems to me that there’s just not enough pain around this. Ironically, React being “good enough” at performance (in most cases) probably means that there’s not appetite for squeezing out the last few millimeters (again for the vast majority of use cases — clearly there is some need otherwise svelte wouldn’t exist).
2 replies →
The React team had explorations of a compiler for React, I believe -
https://github.com/facebook/react/issues/9223 https://github.com/facebook/react/issues/7323 https://github.com/facebook/react/issues/7324
I also think this is why facebook had been investing in `prepack` - https://github.com/facebook/prepack
This might be possible in simple cases, but there are two reasons I think.
1. React has an ethos of being “just JavaScript” (despite the JSX syntax which is purely sugar around calls to React.createElement). This means the core team doesn’t seem to be interested in adding an extra compiler step. 2. Related to the above, because React is just JS, you can do all the normal and horrible things with it you can do in JS. Wanna pass React elements around in context or even using global variables? That’s allowed. A compiler could probably handle a lot of simple cases but there’s a whole lot of things it wouldn’t be able to deal with.
Hm, I think this isn't possible with React. You'd have to impose lots of constraints on how a component renders. Currently it's basically anything goes. IMHO, the result just wouldn't be React anymore.
In fact, Angular works exactly like this. Only the DOM nodes that have bindings/directives attached are updated, the rest is static during a component's lifetime. Though all this still involves tons of runtime framework code.
I actually think Ember/Glimmer happens to have the best implementation of this, where their diff can be incredibly optimised because they know the semantics of the template and can just skip all work on static elements and attributes that never change.
[deleted]
Can someone teach me how Svelte does what it does? The front page is not telling me much?
How does it "surgically" update the DOM? Why is it better than virtual DOM?
When your React component renders, it returns an object that describes the desired state of the component tree. Take this component:
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:
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.
2 replies →
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.
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.
1 reply →
I like React’s opinionated top-down model (with callbacks passed downwards as needed either directly as props or through a store / context) for handling state changes, as this improves composability and ability to reason about state.
My understanding is that Svelte’s main difference from React is that it is not opinionated in this way, and this is considered a positive feature by its proponents. Is my understanding incorrect?
Yep, at least it is for me.
I think it is so much easier to simply `bind:value` than have to write my own event handler to update inputs, etc. Similarly, it's much simpler to have the parent bind to a property of the child rather than passing the value down along with a function to update the parent every single time. In effect it works the exact same way, but I have much less to do to get there.
Store-wise, Svelte stores aren't fundamentally different from having all of your state in Redux, and I prefer that it encourages smaller stores rather than one giant one.
On top of that, it just feels better to me writing HTML, CSS, and JS instead of trying to shoehorn everything into JS.
Svelte's main differences include being compiled, and being truly reactive.
And how about shadow DOM?
Virtual DOM? That’s the internal machinery that allows you to specify (and update) the UI declaratively while applying only localized updates on the actual DOM. It’s a feature, not a drawback, when you want to code declaratively.
Am I the only one?
Next just bought its biggest upcoming competitor—SvelteKit. Next is the best that React has to offer but it still has flaws. Svelte and SvelteKit are so awesome you cannot believe it before you've built something bigger and so much ahead of the entire React ecosystem. We migrated a huge/complex React app in a month and the difference is night and day (performance/bundle size/dev productivity). React was great but it's time to move on.
I'm disappointed by Rich. Instead of thinking bigger, raising money (it would have been so easy, Rich, instead of doing proud conference talk after talk why didn't you talk to a VC??)—he just cashed out (sky-high compensation and ESOP). Not a rant and to give you some background, one major reason we went with SvelteKit was not to rely on the Next team. And now, I am again with them...
Now we have a monopoly of rare, modern SSR frameworks.
I understand this perspective! But as anyone who knows me will tell you, I would be the worst person in the world to try and build a business around Svelte. As others have said, the expectations from investors would make it far less likely that Svelte could remain a community-centric project.
It's important to clarify that Vercel (which has earned its open source bona fides) hasn't 'bought' Svelte or SvelteKit. It's more accurate to say that they're supporting Svelte's development by paying for a full time engineer to work on it. There's a healthy core team of developers who certainly won't relinquish _their_ independence because of _my_ career choices.
It's fair to be sceptical about all this! But I've had multiple conversations throughout this process where the importance of maintaining independence was expressed by both sides, and I truly believe this is the best outcome for Svelte and its community.
Congrats on the job, Rich! I've been using Svelte, Typescript & Babel in the past couple of months to build a set of TV apps targeting some fairly slow and ancient devices and it's been brilliant. Totally impossible to do that with React, I do know some people who tried it though.
Rich, I know where you come from, and I wholeheartedly believe what you say. But this is just the start of a relationship between you and Vercel. And you know that relationships will change over time and so on. And you won't.be.independent. There is just too much money on the table. Nobody will give you orders, there are much smarter ways.
The point is, Vercel did everything right, no blame to them, great CEO, awesome Tim, they are masterminds and their great social media army does their best to celebrate this event in all social networks atm. But you know yourself very well that one player just left the market. We will face less competition and possibly stagnation in some areas. This doesn't hurt Vercel nor you but us.
Ofc you will be dependent, they pay you, you want Vercel to be successful (ESOP). We will see, e.g. that Vercel will be a first-class citizen as deployment option. There are many more fields where Vercel can/will get a special treatment, so subtly that nobody will get it. Business is more sophisticated than many might think.
Or think this the way around, there endless possibilities to drive somebody down, demotivate and degenerate him to a point where he looses all his drive and motivation. Look at yourself today, look how much energy and charisma you have when holding speeches about Svelte. In 2 years, go back to this comment and ask yourself if you are the same energetic Rich, if you are happy and if sold out too early 2 year ago.
> I would be the worst person in the world to try and build a business around Svelte.
No you just underestimate yourself. What are you doing right now? Giving talks, writing, communicating. People, masses follow you not just because Svelte is great, no because you can communicate well and know how to lead people. This is what a CEO is doing 99% of his day. This is building a business, communicating, finding and winning the best people.
You found already the best people, just look in your repos and look which contributors work for Svelte! And you were the leader, had an as good team as Vercel and follow now...
And if I watch you talking there is a strong desire to be more (not that a dev is less!). Whatever, I'd have expected that you at least went shopping with Vercel's offer to CloudFlare. I mean they do real rocket science (Durable Objects) and you opt for Next which started to renovate their stack (esm, swc) just recently after years.
Oh man, I like you too much to be too angry but yeah, not happy.
We're all lucky that you got a polite, substantive reply, but please don't cross into personal attack like this in HN comments. It generally causes discussion quality to tank drastically.
https://news.ycombinator.com/newsguidelines.html
@dang, second reply and apologies, now I know what you mean, I edited some part away which you probably meant and which is still in quotes of others' comments. Sorry, I'll try to improve and thanks for the hint!
Can't follow you, what do you mean/where did I cross into personal attacks? I highly appreciate Rich but the elephant in the room had to be addressed, especially on HN.
I wonder that I am the only one that questions his move and that you also approach me instead of welcoming a healthy debate. Whatever, I guess you just do your job.
Btw, when does HN get proper pagination and a darkmode?
Do I get shadowbanned now for asking too many questions?
1 reply →
> Instead of thinking bigger, raising money (it would have been so easy, Rich, instead of doing proud conference talk after talk why didn't you talk to a VC??)
In no world would taking VC funding have been easier. They’d want cash returns and hockey stick growth, and soon. So instead of focusing on making the framework as good as it could be, Rich’s attention would be diverted.
When SvelteKit becomes a framework impossible to run on anything that isn’t a Vercel platform, then maybe I’ll be outraged. Until then, subjecting an incredibly talented developer to the day-to-day whims of VCs seems like just about the worst outcome for everyone.
I don’t normally mean to sound uncharitable but your original comment is pretty uncharitable to Rich, so: if you want a stable platform that will live for many years to come, the absolute last thing you want is for it to take VC investment. That you don’t see this speaks volumes to your understanding of how any of this works.
> In no world would taking VC funding have been easier.
Did I say that? Or that Rich should have taken the easier path? No, everyone should always take the harder path. But this is a deeper discussion.
> I don’t normally mean to sound uncharitable but your original comment is pretty uncharitable to Rich,
But your tone towards me is better?
> That you don’t see this speaks volumes to your understanding of how any of this works.
If you think so, fine, but I'm pretty sure that I've raised more money and more rounds than you but this shouldn't qualify me to be right or wrong. I focus on what you write and what I've written and I think I brought good arguments that a market turned into a monopoly and this is not great. Can we blame Rich, probably not. Can be disappointed and still respecting him? Yes.
interesting that you think talking to a VC and starting a startup (where he would be spending >50% time on business things and be forced to come up with a monetization plan) is better for svelte than getting fulltime sponsorship to solely work on Svelte and working with the top tier talent at Vercel.
Exactly. I think the OP does not know what it means to "raise money" and go at it. It would turn that person into a full time business owner.
Svelte and Vue got started when someone just went and did it. If you think it's so important to have many competitors in this space, just go and do it :)
This is all that’s wrong with open source free software. You’re disappointed by how someone chooses to give you free stuff.
I built this to avoid this exact problem: https://github.com/cheatcode/joystick.
No desire to be acquired (open to investment but that's it), just build a business around accompanying features/services.
Goal is fast, simple, and friendly regardless of your skillset. No lock-in as the entire thing is a thin abstraction over Node.js/Express.js and components are built using plain HTML, CSS, and JS (no special languages or syntax). Also adding in a lot of helper stuff so you're not stuck cobbling together random packages for common stuff (i18n, form validation, etc).
Feel free to email me if you or your team have questions: ryan.glover@cheatcode.co.
Feel free to make your own alternative, the world's your oyster.
The framework appears to have an MIT license and lots of contributors so I wouldn't worry too much.
> I'm disappointed by Rich. Instead of thinking bigger, raising money (it would have been so easy, Rich, instead of doing proud conference talk after talk why didn't you talk to a VC??)—he just cashed out (sky-high compensation and ESOP). I lost all my respect. Not a rant to give you some background, one major reason we went with SvelteKit was not to rely on the Next team. And now, I am again with them.
Who the hell do you think you are? You don't know his situation. You don't know anything. How do you know he doesn't have a gravely ill family member and needs a steady income more than he needs to "think big" about a fucking javascript framework? How do you know he's not deeply in debt from a past mistake? How do you know he doesn't find the tech obsession with "VC" funding repugnant? No one needs sxiao's judgment.
Please don't respond to something bad by breaking the site guidelines yourself. It only makes things worse.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so....
I'm sure he'll see this soon, so congrats Rich! Svelte has been a cool project since the beginning, and I'm excited to see Rich have more time to work on this. As an early contributor I've seen Svelte go through a lot of maturing and it's exciting to see it finally getting the recognition it deserves lately.
svelte + deno should be the perfect combination for the next age of web development.
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.
Is this a bet against React or a bet for ecosystem variety and choice? I feel it's the latter right now.
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.
10 replies →
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.
react is used so many places professionally that i think someone would just fork or remake react from scratch if they ever did that.
1 reply →
I've been a fan of Svelte and Vercel for a while so it's cool to see Rich working with them, and for Svelte to get more support. Very excited to see what comes of this!
Feels like a good move. How else could framework be developed than implementing some requirements. Vercel should provide lots of them. What else can be added to Svelte btw? It looks like a finished project already. People can only invent in Svelte area if browser standards move forward, right? Otherwise Svelte can only be used to support needs of some platform.
So I'm a backend engineering, but have experience with Vue.js and like it.
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.
1. Yes there is typescript support.
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 take full advantage of Svelte being...
They? Libraries?
1 reply →
There is typescript support.
The TS ergonomics still have a long way to go, imo. Typing components is a little bizarre -https://github.com/sveltejs/language-tools/issues/442
1 reply →
I heard about vercel before but this announcement made me try it out.
Oh boy, what an amazing onboarding experience!
Honestly, don’t really know much or care much about Svelte for my own use. But hearing that someone is going to be sponsored to work on their invention full-time is wonderful. Glad to witness this personal victory and sending good vibes to help make Svelte great.
Vercel's increasing control over the frontend ecosystem worries me a lot.
There's hope: https://github.com/cheatcode/joystick.
Interesting. Vercel already hired both the main Webpack and SWC devs.
Any Svelte UI component libraries with good i18n and a11y support?
Carbon and SMUI are both good.
Not Svelte specific but daisyUI is pretty nice. It’s just Tailwind though, so any i18n and a11y are up to you to implement.
great news. as someone that really dislikes react but is forced to work with it I hope someday I'll be able to use svelte on my project.
First time I took a few more minutes to look into svelte. To me it looks like it could be successor of Vue.
Do you know of other high potential candidates?
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.
Excellent news, I love svelte and this could increase adoption
Because of redwoodjs, I've gone off Svelte a bit
Cancel culture and wokism is alive in well in the svelte community. I was banned twice from discord and again from reddit's sveltejs sub.
The bay area svelte group is looking for a new moderator, I was going to do it, but after this experience I decided I will just wait until something better than svelte comes along.
I guess you could say I don't care.
Whoever and whatever that is.
how
This is awesome. Next.js is garbage so hopefully SvelteKit gets all the love and attention from now on.
My biggest issue with NextJS is next/image vendor locks you into Vercel.
You can use netlify-plugin-nextjs - https://github.com/netlify/netlify-plugin-nextjs/blob/v3/doc... to host on Netlify.
And of course any regular NodeJS server works with next/image - https://nextjs.org/docs/deployment#other-hosting-options
`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!
https://nextjs.org/docs/basic-features/image-optimization#lo...
Didn't know who Rich Harris was. Could probably include that in the title, or link to the blog post on the Vercel website. Clicking on his Twitter picture requires logging in and only through the Vercel blog post headline did I find out.
It'd be more fun if I could do it in something that wasn't in Javascript or one of its Frankenstein cousins.
You can!
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.
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.
Don't forget Clojurescript.
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.
JavaScript-based but plain HTML/CSS/JS. No Mary Shelley: https://github.com/cheatcode/joystick
Personally I have mixed feeling about this.
I guess I'm not a fan of seeing investors money expand it's control over the open source ecosystem. I like open source because it empower the little guys. But I don't expect others to share my values and perspective and perhaps Rich Harris turns out to be a robinhood. Why not doing something like the creator of Vue? With that said I look forward to see what comes out of their shop. Good luck :)
People downvoting...I've bootstrapped my own business so I can speak my mind freely and don't mind being disliked, as long as my customers like my work.
Now for today's topic:
1) life 101: nobody gives you money for nothing
2) If they give you 5% they will act as if they have given you 90%, it will happen gradually
3) Vercel is seeking monopoly over front-end deployment using investors money and buying open source contributors, of all the major frameworks, they would have done the same with ReactJS and Vue if they could and they will try doing it with any framework that gains momentum. It is a fine strategy, not my cup of tea.
4) I'd rather support bootstrapped business and solo developers
5) I personally wonder how someone with the portfolio of Rich Harris couldn't manage to get sufficient sponsorship to go full-time given how much value he has generated to the community, I think this is something open source community need to tackle, perhaps crypto can help contributors make money earning easier? How about 1 token for each download, fork or install something like that that would help open source contributors generate money just by creating value...something is really broken here and I think there is a room to innovate with micropayments, I mean we know the likes, forks, issues, we have the entire repo content, we have the history of the contributors, given all the fuss about crypto, I wonder why haven't we seen anything in that direction yet, am I missing something? I think monetization of open source should be built within the platform (Github or some modern alternative), with different options on how contributors can run their content creation business. They can choose to give it free, free up to a point, or charge from day one, it is still open source, etc. Lots of room for innovation.
6) Many people share my mindset, but afraid to speak out, so here it, is plain and simple.