Rich Harris joins Vercel to work on Svelte full time

https://twitter.com/Rich_Harris/status/1458822051263823875

by leodriesch • 5 years ago

907 522 5 years ago

twitter.com

pier255• 5 years ago

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!

leerob12• 5 years ago

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-...

dceddia15• 5 years ago

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!

gnrlst• 5 years ago

I see your app is MacOS only at the moment. Are you re-writing it in Electron or what? Very curious

protonimitate2• 5 years ago

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).

dceddia15• 5 years ago

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.

kingcharles• 5 years ago

Looks cool - what is the timescale for Windows?

dceddia15• 5 years ago

Weeks to months, hopefully by the end of the year? We’ll see! A lot depends on what other challenges come up, heh.

Tade0• 5 years ago

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.

dceddia15• 5 years ago

Love me some good old synchronous code! :D

vgel2• 5 years ago

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).

dceddia15• 5 years ago

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.

MisterBastahrd• 5 years ago

It'd be more fun if I could do it in something that wasn't in Javascript or one of its Frankenstein cousins.

tempest_• 5 years ago

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.

cutler4• 5 years ago

Don't forget Clojurescript.

tormeh• 5 years ago

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.

clivestaples• 5 years ago

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.

slantyyz2• 5 years ago

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.

jhgb• 5 years ago

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.

rglover9• 5 years ago

JavaScript-based but plain HTML/CSS/JS. No Mary Shelley: https://github.com/cheatcode/joystick

arberx2• 5 years ago

Svelte is fucking awesome.

Long way to go to catch up to React, but it'll get there. No brainer.

Donckele3• 5 years ago

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.

arberx2• 5 years ago

Catch up in terms of hirability/company usage.

Donckele3• 5 years ago

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.

throwawayjklalf• 5 years ago

svelte + deno should be the perfect combination for the next age of web development.

ergo14• 5 years ago

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.

dang3• 5 years ago

We changed the url from https://vercel.com/blog/vercel-welcomes-rich-harris-creator-... to Rich's own post.

There were two other submissions - one to an interview (Svelte Creator Rich Harris: Web development should be more fun - https://news.ycombinator.com/item?id=29189209) and the other to this Twitter link (https://news.ycombinator.com/item?id=29189467). I've merged those threads into the current submission because it was posted first.

pier255• 5 years ago

Thanks dang! This was the right move.

leerob12• 5 years ago

Agreed, thank you so much.

owlbynight• 5 years ago

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.

falafelite• 5 years ago

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.

gavinray4• 5 years ago

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 =(

systemvoltage4• 5 years ago

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.

dexwiz4• 5 years ago

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.

romero-jk• 5 years ago

You can "sprinkle" react too

GordonS• 5 years ago

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.

leerob12• 5 years ago

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!

gavinray4• 5 years ago

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).

_benj3• 5 years ago

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! :)

sxiao11• 5 years ago

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?

Keats• 5 years ago

Svelte doesn't support JSX/TSX though =(

You have https://www.solidjs.com/ that does

gavinray4• 5 years ago

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:

   // UtilComponents.tsx
   export function Button() {}
   export function Modal() {}
   export function Icon() {}

And then in my .vue file I can do:

   <script setup lang="ts">
   import { Button, Modal, Icon } from "./UtilComponents"
   // ...
   </script>

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.

protonimitate2• 5 years ago

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.

pjungwir• 5 years ago

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.

rglover9• 5 years ago

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.

ravenstine4• 5 years ago

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.

pier255• 5 years ago

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.

DonHopkins13• 5 years ago

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.

rawoke0836004• 5 years ago

It actually supports the next best thing: HTML!

Haha - Oh where will our crazy tech take us next :D

uzername• 5 years ago

Is this a bet against React or a bet for ecosystem variety and choice? I feel it's the latter right now.

hunterb12317• 5 years ago

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.

dexwiz4• 5 years ago

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.

leerob12• 5 years ago

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.

dexwiz4• 5 years ago

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.

penjelly5• 5 years ago

react is used so many places professionally that i think someone would just fork or remake react from scratch if they ever did that.

tekkk• 5 years ago

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.

benmccann4• 5 years ago

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!)

sxiao11• 5 years ago

Ben, please don't surprise us and tell that you are the next one on Vercel's payroll.

for1nner• 5 years ago

Bless you.

kall12• 5 years ago

Well if there‘s any place to learn from next.js it‘s probably Vercel. Looks like great news for Svelte.

FractalHQ3• 5 years ago

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.

noir_lord3• 5 years ago

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.

jeswin3• 5 years ago

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.

nodejs_rulez_1• 5 years ago

Hearing about a JS framework "X" that is surely that much more elegant than "Y" feels like it's 2010s again!

bGl2YW5j3• 5 years ago

At least this time Svelte is a step closer toward the native browser stack rather than yet another abstraction layer.

WORMS_EAT_WORMS5• 5 years ago

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).

friedman23• 5 years ago

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.

leerob12• 5 years ago

Vercel's infrastructure is multi-cloud, primarily using AWS. We're currently using Workers specifically for Edge Functions (https://vercel.com/edge).

rabaut• 5 years ago

Do you have a reference for this? Curious to learn more. I thought Vercel was built on AWS.

lmeyerov• 5 years ago

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

systemvoltage4• 5 years ago

I predict that Cloudflare will acquire Vercel one day.

WORMS_EAT_WORMS5• 5 years ago

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.

admn2• 5 years ago

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.

blackandsqueaky• 5 years ago

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

Rauchg3• 5 years ago

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://news.ycombinator.com/item?id=29003089

[2] https://news.ycombinator.com/item?id=29158742

[3] https://twitter.com/swyx/status/1456665048949018626

ksubedi2• 5 years ago

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.

WORMS_EAT_WORMS5• 5 years ago

This is not Cloudflare:

Flareact is an experiment created by Josh Larson in August 2020.

andrew_• 5 years ago

Denoflare (https://news.ycombinator.com/item?id=29142772) is compelling.

WORMS_EAT_WORMS5• 5 years ago

Also not Cloudflare (to my knowledge)

johanndev• 5 years ago

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

rce• 5 years ago

SvelteKit has an out-of-the-box adapter for Cloudflare workers: https://github.com/sveltejs/kit/tree/master/packages/adapter...

WORMS_EAT_WORMS5• 5 years ago

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.

mwcampbell• 5 years ago

I hope that Rich joining Vercel doesn't end up compromising SvelteKit's current neutrality when it comes to deployment targets.

kall12• 5 years ago

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.

penjelly5• 5 years ago

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

midrus9• 5 years ago

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.

penjelly5• 5 years ago

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.

didip• 5 years ago

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?

rglover9• 5 years ago

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).

bdougherty5• 5 years ago

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.

jitl• 5 years ago

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:

    const MyComponent = {
      mount(parent) {
        const element = document.createElement('div')
        div.innerHTML = "Here's <b>bold text</b>"
        parent.appendChild(div)
      },
      update() { /* no-op */ }
    }

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.

tuan• 5 years ago

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.

ravenstine4• 5 years ago

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.

cobertos• 5 years ago

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.

ravenstine4• 5 years ago

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

sxiao11• 5 years ago

This is so HN, in an Svelte thread memories from Ember (sharing your sentiments though).

leerob12• 5 years ago

What could be improved in the documentation?

sxiao11• 5 years ago

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)?

afavour4• 5 years ago

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.

brightball• 5 years ago

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?

dceddia15• 5 years ago

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.

barelysapient• 5 years ago

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.

solarmist6• 5 years ago

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.

yroc922• 5 years ago

There is typescript support.

aarpmcgee• 5 years ago

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

tropix1263• 5 years ago

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.

solarmist6• 5 years ago

They take full advantage of Svelte being...

They? Libraries?

gherkinnn2• 5 years ago

Interesting. Vercel already hired both the main Webpack and SWC devs.

yumraj• 5 years ago

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.

ryanSrich• 5 years ago

Used to be called Now. It’s a PaaS.

inglor• 5 years ago

They are a competitor with other clouds like AWS/Azure/GCP/DigitalOcean with a focus on JAMStack and modern workflows.

dbbk3• 5 years ago

More like a competitor to Netlify, GitHub Pages, etc

_fat_santa3• 5 years ago

Vercel is a hosting provider for static websites. I see it as a simplified versions of AWS, specifically for static websites.

leerob12• 5 years ago

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.

ronvoluted2• 5 years ago

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 :)

midrus9• 5 years ago

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.

solarmist6• 5 years ago

What bits were misdirected? What worries did you have?

midrus9• 5 years ago

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.

burlesona• 5 years ago

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.

midrus9• 5 years ago

Yeah, I really like the middle ground approach, but having tried almost everything in the category, my favourite by a long margin is Unpoly.

_benj3• 5 years ago

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!

solarmist6• 5 years ago

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.

_benj3• 5 years ago

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

midrus9• 5 years ago

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.

Glench• 5 years ago

Awesome. Been using Svelte exclusively for a couple years in my projects and don't see myself using React ever again.

toastercat9• 5 years ago

This is awesome. Next.js is garbage so hopefully SvelteKit gets all the love and attention from now on.

_fat_santa3• 5 years ago

My biggest issue with NextJS is next/image vendor locks you into Vercel.

bradleyg_• 5 years ago

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

leerob12• 5 years ago

`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...

_puk• 5 years ago

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.

kevinak• 5 years ago

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

ramraj07• 5 years ago

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..

tnzk• 5 years ago

Meetup with people who share an interest itself fun?

DonHopkins13• 5 years ago

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.

candu• 5 years ago

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.)

joshgrib• 5 years ago

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!

sxiao11• 5 years ago

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.

exhaze• 5 years ago

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 :)

waterglassFull• 5 years ago

Feel free to make your own alternative, the world's your oyster.

swyx3• 5 years ago

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.

tnolet• 5 years ago

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.

mixmastamyk• 5 years ago

The framework appears to have an MIT license and lots of contributors so I wouldn't worry too much.

afavour4• 5 years ago

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.

6gvONxR4sf7o• 5 years ago

This is all that’s wrong with open source free software. You’re disappointed by how someone chooses to give you free stuff.

rich_harris• 5 years ago

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.

sanitycheck• 5 years ago

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.

dang3• 5 years ago

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

sxiao11• 5 years ago

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?

sxiao11• 5 years ago

@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!

rglover9• 5 years ago

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.

arendtio• 5 years ago

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?

PaulBGD_• 5 years ago

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.

stevenpetryk• 5 years ago

Vercel's increasing control over the frontend ecosystem worries me a lot.

rglover9• 5 years ago

There's hope: https://github.com/cheatcode/joystick.

solarmist6• 5 years ago

Any Svelte UI component libraries with good i18n and a11y support?

tropix1263• 5 years ago

Carbon and SMUI are both good.

d1sxeyes3• 5 years ago

Not Svelte specific but daisyUI is pretty nice. It’s just Tailwind though, so any i18n and a11y are up to you to implement.

Graffur• 5 years ago

Because of redwoodjs, I've gone off Svelte a bit

cphoover12• 5 years ago

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.

d23• 5 years ago

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.

SparkyMcUnicorn• 5 years ago

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.

wishinghand• 5 years ago

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.

locallost• 5 years ago

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.

rglover9• 5 years ago

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).

sam0x17• 5 years ago

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.

ramesh31• 5 years ago

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.

lowbloodsugar• 5 years ago

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?"

tshaddox3• 5 years ago

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.”

winphone19742• 5 years ago

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

fendy3002• 5 years ago

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.

ratww2• 5 years ago

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.

cutler4• 5 years ago

It sounds like you'd be better off with something like Ruby's Hotwire/Stimulus, ASP.Net Core/Blazor or Elixir/Phoenix Live View.

rk062• 5 years ago

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

RoboticWater• 5 years ago

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.

fron• 5 years ago

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.

cphoover12• 5 years ago

What how can you say that???

      <ul>{myItems.map({id, title}) => 
          <li key={id}>{title}</li>
      }</ul>

vs... svelte

     <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.

nnoitra• 5 years ago

What boilerplate does React have? Do you mean Babel?

adamnemecek• 5 years ago

The templating language is the easiest thing to learn. The hardest is architecture.

tpict• 5 years ago

JSX is syntactic sugar for `React.createElement(...)` (most commonly), so React pretty much is plain JavaScript.

kall12• 5 years ago

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.

rglover9• 5 years ago

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.

hijodelsol• 5 years ago

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.

kall12• 5 years ago

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?

tootie• 5 years ago

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.

cphoover12• 5 years ago

Very true... How can I debug this thing when it breaks that's a great question. I wonder how sourcemaps work with svelte

brundolf8• 5 years ago

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”

cphoover12• 5 years ago

100% no more js frankensteins...

Id prefer to learn a new language altogether

bryans2• 5 years ago

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.

gherkinnn2• 5 years ago

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.

block_dagger• 5 years ago

This is why I have focused on backend for the last decade.

Tarks• 5 years ago

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"

timeon2• 5 years ago

And then you have ended up with shadow DOM.

jitix• 5 years ago

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.

travisl12• 5 years ago

My solution is pretty easy to this problem: I don't.

dbbk3• 5 years ago

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.

unclebucknasty3• 5 years ago

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.

kall12• 5 years ago

What would that look like for you? Something like SwiftUI or Flutter (which feel React inspired) or a totally different thing?

cphoover12• 5 years ago

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?

chrbp2• 5 years ago

No one says you have to learn new languages or frameworks. It's really your own choice.

danny_taco• 5 years ago

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.

ratww2• 5 years ago

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.

cutler4• 5 years ago

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.

gaws• 5 years ago

You're getting flamed on Twitter for this comment lol: https://twitter.com/dancow/status/1458906853488967684

joppy• 5 years ago

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.

Aeolun5• 5 years ago

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.

richeyryan2• 5 years ago

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.

miohtama• 5 years ago

Because if we do not keep constantly learning and get better, we would be stuck writing COBOL and BASIC.

cphoover12• 5 years ago

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.

intrasight• 5 years ago

They are all just trying to replicate XSLT - but by mixing imperative with declarative syntaxes.

lhorie• 5 years ago

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

midrus9• 5 years ago

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).

DonHopkins13• 5 years ago

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.

slantyyz2• 5 years ago

My favorite feature of Sveltekit is probably the server-side endpoints. It's so easy to create an API using them.

DonHopkins13• 5 years ago

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. ;)

aogaili2• 5 years ago

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 :)

aogaili2• 5 years ago

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.

crummy• 5 years ago

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?

dbbk3• 5 years ago

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.

swyx3• 5 years ago

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

travisd2• 5 years ago

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).

samc98• 5 years ago

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

travisd2• 5 years ago

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.

fuzzy2• 5 years ago

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.

cphoover12• 5 years ago

[deleted]

ithkuil• 5 years ago

I heard about vercel before but this announcement made me try it out.

Oh boy, what an amazing onboarding experience!

whiddershins2• 5 years ago

We have used Svelte for a major internal project and it has been an absolute joy to work with.

This is really exciting news.

kosolam2• 5 years ago

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

xrd• 5 years ago

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.

ummonk2• 5 years ago

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?

timeon2• 5 years ago

And how about shadow DOM?

ummonk2• 5 years ago

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.

bdougherty5• 5 years ago

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.

whiddershins2• 5 years ago

Svelte's main differences include being compiled, and being truly reactive.

sholladay2• 5 years ago

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.

enumjorge2• 5 years ago

Maybe I'm misreading your comment, but Richard Harris did not create esbuild. Evan Wallace, co-founder of Figma, is the person behind it.

dragonshed• 5 years ago

Rich created rollup :)

beeandapenguin• 5 years ago

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/

deepakkarki• 5 years ago

You did misread.

Until esbuild came along, Rollup was the only sane JS bundler

Rich Harris did create Rollup

leerob12• 5 years ago

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.

sholladay2• 5 years ago

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

rudian• 5 years ago

"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.

bartq• 5 years ago

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.

dissent• 5 years ago

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.

bGl2YW5j3• 5 years ago

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.

Aeolun5• 5 years ago

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.

tshaddox3• 5 years ago

How about unstyled components like a dropdown menu or a multi-select with autocomplete?

joeyjojo• 5 years ago

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.

arxpoetica2• 5 years ago

Special syntax for reactivity is not javascript

That's because there is no syntax for reactivity in JavaScript, period.

Sammi• 5 years ago

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.

JimDabell7• 5 years ago

- 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.

veidelis• 5 years ago

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.

zdragnar• 5 years ago

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.

malcolmstill• 5 years ago

Things that are easy in React at runtime turn out to be surprisingly difficult in Svelte

Do you have some specific examples?

bdougherty5• 5 years ago

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.

jakelazaroff• 5 years ago

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.

brundolf8• 5 years ago

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...

  const foo = obj.foo;
  foo.bar = 'baz';

> ...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.

toastercat9• 5 years ago

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.

jeswin3• 5 years ago

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.

hbbio2• 5 years ago

JSX popularized it but we built it with opalang.org first (also with strong static typing before TS)

conradfr• 5 years ago

Funny as when I used React back in 2015 it was my least favorite feature (I moved to Vue since then).

lucasyvas3• 5 years ago

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.

el_dev_hell2• 5 years ago

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.

cageface• 5 years ago

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.

toshk• 5 years ago

Yeah useEffects was the start over overcomplicating react.

midrus9• 5 years ago

Yes, clearly it is not for purists.

Donckele3• 5 years ago

“ - 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.

korla• 5 years ago

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.

tuukkah4• 5 years ago

- 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.

brundolf8• 5 years ago

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.

brundolf8• 5 years ago

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?

FractalHQ3• 5 years ago

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!

arxpoetica2• 5 years ago

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.

_ta_2231234• 5 years ago

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.

merrywhether2• 5 years ago

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.

StaticChamp• 5 years ago

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 ==============

merrywhether2• 5 years ago

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.

DonHopkins13• 5 years ago

- 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.

taurath• 5 years ago

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.

jseban• 5 years ago

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

sngz• 5 years ago

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.

brailsafe• 5 years ago

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.

seanstrom• 5 years ago

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.

bl4ckm0r3• 5 years ago

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!

HeavyStorm• 5 years ago

Excellent news, I love svelte and this could increase adoption

Rich Harris joins Vercel to work on Svelte full time

Related Stories