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! :)
In the case of Vercel, I'd imagine that improving svelte's reach positively affects them commercially seeing as they're a major player in the relatively small market of svelte hosting.
This is the standard narrative when OSS contributors got hired but ok, I'd write the same.
But then just tell us what was the motivation of Vercel's shareholders and CEO to acquire Rich for such a high price (he is the compensation and ESOP you pay absolutely worth) but what's your gain? "Just supporting Rich and helping the project grow" or just buying him out of the market?
On a high level: if Svelte succeeds, the Web succeeds and Vercel succeeds.
More concretely: we want Rich to help shape Vercel's support for frameworks as an open platform. We want to hear how, as a framework creator, the platform can best serve him. We project this work will have ripple effects like making Astro or Remix better on Vercel, or the next framework you invent. You'll hear about this work soon.
We want to hear what edge infrastructure would make Svelte the fastest for developers and visitors. We want to also help him build a better Svelte by connecting him with customers who are betting on it in production. We want to learn from his DX expertise so that we can make better products.
We are very excited about this and we think betting on Open Source for the SDK together with an Open Platform for infrastructure is the only way to succeed in our space.
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.
Product designer and HTML/CSS person here, and in my experience it is the opposite. Designers and front-end focused people wh get a chance to work with Vue love it because it actually respects basic HTML/CSS/JS and doesn't encourage doing everything in JS, unlike React which basically forces your hand. This makes working in Vue (and Svelte) so much more accessible to people who are great at HTML and CSS but not JS as much (and in my experience many React devs are great at JS and terrible at HTML/CSS).
Designers more often know HTML and CSS over JS, so it is unlikely they are the ones pushing for JS solutions. It is the developers who don't know how to implement designs without falling back on JS for everything who are causing this paradigm.
That being said I blame a lot of this on design tooling as well. Figma and Sketch are custom rendering engines that just don't understand HTML and CSS and therefore give no opportunities for designers to learn how the web works. Fortunately a new generation of design tools are coming that are built on HTML/CSS renderers that feel like Figma but actually output usable code for devs to interpret into their projects.
> Fortunately a new generation of design tools are coming that are built on HTML/CSS renderers
These days I spend more time in browser devtools than Figma, and honestly I'd prefer a more visual way to edit code directly. Something like Webflow but without all the cruft behind it. Preferably built into devtools, maybe as an extension
No, we don't have a design team, we're too small for that.
Just that our backend is already built using Django many many years ago. If I need to add some interactivity, I use jQuery currently. Looked into Vue and it allows us to keep everything as is in the backend and use it like jQuery.
I shudder everytime I need to install npm, webpack, gulp, etc..all the JS tools feel super flaky, unnecessary and does not inspire confidence in the tooling. That's my take anyways.
Lot of developers don't have the priviledge of starting a new project. It's an existing doctors appointment website or some shit people cobbled up in PHP in 2004 that is still running and we need to maintain it.
> "I shudder everytime I need to install npm, webpack, gulp, etc..all the JS tools feel super flaky, unnecessary and does not inspire confidence in the tooling. That's my take anyways."
For context, I started doing web dev back in ES5 JS, jQuery, Angular.js (1), and server-side templated HTML views days.
I write in a lot of other languages as well, and I would hear people say this and not get it. I thought to myself:
"It's not THAT bad. I think the experience is fine."
Then I wrote an app recently on the JVM. Sweet jesus the JS/Node ecosystem is a nightmare + house of cards.
The JVM and CLR (.NET) have their stuff together. I need like ~10 dependency libraries to do a large project, and often times they are over a decade old.
The tooling is on another level.
I don't have PROBLEMS writing TS apps, and the experience is good. But some of them have a dependency tree that span thousands of packages, and I've come back 2-3 years later to try to run a project and had some downstream dep break, and then updating fails, and then...
I know it's somewhat of a meme, but this is unironically why I find Deno interesting. (Disclaimer: Haven't shipped anything with it)
Especially since with the most recent release, they have an option to emit Node-compatible JS bundles from Deno code.
I totally identify with your aversion to build tools, but things have changed for the better in the last few years.
My advice would be to check out Vite, and use it with Vue. I've introduced Vite/Vue2 to a pre-existing Django project and couldn't be happier. I've explored a number of different approaches for integrating Vite and Django, and this blog had the best approach, IMO: https://weautomate.org/articles/using-vite-js-with-django/
I find that Svelte is the most "jQuery-friendly" of the frameworks. I can easily add a single Svelte component back into other wise static pages without requiring anything other than a simple build tool to output the JS + css. It's really the best of both worlds – sprinkle it in where needed, or go whole-hog.
Yeah, I really like Svelte for this. I did a whole blog post this way, with little embedded animations to show various operations on linked lists. Each of the animations is a Svelte component, but the surrounding page is just a static HTML page created from Markdown (using Jekyll as the generator).
It's nice that Svelte components can be independently mounted like that.
To be fair, the same thing would be possible with React or the other frameworks. I do like that it's only 29kb of JS for all those animations though (and most of that is the SVGs, I think).
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.
This is a really cool idea. This has always been my biggest beef with single file components. It never occurred to me that you could do this with Vue. Thanks for the tip
Admittedly I haven't followed Svelte super closely, but isn't "no JSX/TSX" kind of a major ideological point? From reading the intro docs, it seems like separation of js/css/html is a selling point. JSX/TSX would contradict that, no?
Just wondering if my read is correct or if there's some other reason it's been left off the table.
Nobody truly separates JS from HTML. You either have to put something HTMLish in the JS, or something JSish in the HTML (HTML itself supports this of course).
IMO the HTML-in-JS solutions (i.e. JSX) are superior to the JS-in-HTML solutions (e.g. Angular/Vue Templates) because they put the standardised turing-complete language in the driving seat rather than the propriety, hard to extend template language.
Still, it's way easier to integrate a js library in a svelte component than in a react component. So maybe the two approaches have different tradeoffs and respective advantages
I've been using Solidjs the last month for a project, and I really like it. Small bundle size, super fast, not much to learn, not too much magic, lots of control. Basically instead of having a vdom the framework is able to track finer-grained reactive sites and update those when the data changes.
If no one has managed to add JSX, I believe it would be feasible to implement. The Svelte compiler is pretty straight forward to interact with. However, I have little experience with the semi-standard build toolchain for Svelte that most people are using. You would of course need to import React.
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 =(