Live data from Hacker News

Rich Harris joins Vercel to work on Svelte full time

twitter.com

381–390 of 571 posts

Re: Rich Harris joins Vercel to work on Svelte full time

#381
post #216

Earlier quoted context omitted.

I'd like to hear more. What were your conclusions? I'm particularly interested in it compared to Vue. I picked Vue because of most people's complaints about React, so most of the comments I'm seeing are about specific gripes with React and don't really help me make an informed opinion.

For React, I agree with the complaints. The change from class components to functional components and the addition of hooks for we was a step backwards. As for vue, most of my experience is with vue 2, never really spent a lot of time with the features of vue 3. To the the some of the syntax of svelte makes more sense than that of vue. For example, to list something in vue an html with v-for is needed, or . This alwa…

> I really didn't have to "learn" svelte as I had to vue or react

As someone who is primarily a back end dev with limited experience with frontend frameworks (very little react, somewhat decent amount of vue), this was the biggest surprise when working on a project with svelte. You know the saying "hit the ground running"? This was the first time I felt like that with a frontend framework.

Re: Rich Harris joins Vercel to work on Svelte full time

#382

Earlier quoted context omitted.

Interested to hear if you considered compiling Rust to WASM and what your thoughts were?

I looked into it at one point and it sounded like WASM isn't as fast as native (yet?), and the main benefit would be the ability to run in a browser. That'd be useful for making a web version and I might look into it again, but for now, if I'm already shipping an Electron app, WASM seems like extra hassle with less speed. I might be wrong about this though! Happy to hear if there are benefits I'm missing.

https://clipchamp.com/en/blog/clipchamp-pwa-case-study/

Re: Rich Harris joins Vercel to work on Svelte full time

#383

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…

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

Do you have some specific examples?

Re: Rich Harris joins Vercel to work on Svelte full time

#384
post #329

Earlier quoted context omitted.

> literally just javascript Repeating it over and over again does not make it true. https://linkedlist.ch/jsx_is_not_just_javascript_39/

Repeating a blog post over and over doesn't make it true. The author is wrong. Most of his statements are about React, not JSX. It's syntactical sugar for nested function calls, that's all. Brackets are turned into function statements, attributes are turned into object props. The author conflates React properties with JSX, which is wrong. The author also confused JSX limitations, you cannot do statements because it's…

Right from the very top of your source:

> JSX is an XML-like syntax extension to ECMAScript without any defined semantics. It's NOT intended to be implemented by engines or browsers. It's NOT a proposal to incorporate JSX into the ECMAScript spec itself. It's intended to be used by various preprocessors (transpilers) to transform these tokens into standard ECMAScript.

Further down:

> Why not just use that instead of inventing a syntax that's not part of ECMAScript?

It is not JavaScript.

Re: Rich Harris joins Vercel to work on Svelte full time

#385
post #329

Earlier quoted context omitted.

> literally just javascript Repeating it over and over again does not make it true. https://linkedlist.ch/jsx_is_not_just_javascript_39/

Repeating a blog post over and over doesn't make it true. The author is wrong. Most of his statements are about React, not JSX. It's syntactical sugar for nested function calls, that's all. Brackets are turned into function statements, attributes are turned into object props. The author conflates React properties with JSX, which is wrong. The author also confused JSX limitations, you cannot do statements because it's…

and if you really want to use statements, you can, using an IIFE for example. It’s not pretty but you can because… ehm… it‘s just javascript.

At this point the "is JSX just javascript" discussion has gone on a little to long imho. It feels like "is html a programming language". We all have strong convictions about the answer but it doesn‘t matter, really.

It‘s interesting that fans all of 3 frameworks constantly claim that it’s "just“ or "closer to vanilla" html or js. Should we really care anymore?

Re: Rich Harris joins Vercel to work on Svelte full time

#386
post #207

Earlier quoted context omitted.

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 t…

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

Oh but it‘s not just about the syntax, it‘s also about the semantics, scope rules etc. This is the reason I still like JSX best, because I have a fairly deep understanding of that stuff in javascript while vue templates still leave me scratching my head sometimes. But I can see the appeal either way.

Re: Rich Harris joins Vercel to work on Svelte full time

#387

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…

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.

Re: Rich Harris joins Vercel to work on Svelte full time

#388

Earlier quoted context omitted.

Repeating a blog post over and over doesn't make it true. The author is wrong. Most of his statements are about React, not JSX. It's syntactical sugar for nested function calls, that's all. Brackets are turned into function statements, attributes are turned into object props. The author conflates React properties with JSX, which is wrong. The author also confused JSX limitations, you cannot do statements because it's…

Right from the very top of your source: > JSX is an XML-like syntax extension to ECMAScript without any defined semantics. It's NOT intended to be implemented by engines or browsers. It's NOT a proposal to incorporate JSX into the ECMAScript spec itself. It's intended to be used by various preprocessors (transpilers) to transform these tokens into standard ECMAScript. Further down: > Why not just use that instead of…

We're splitting hairs now. It's an extension of the JS spec. Once a parser adds this grammar it is JS.

It's syntactical sugar, unlike template syntax #if, ng-if, etc.

Your argument is it's not part of the current Ecmascript spec, I never said it was, but if a parser or engine adds these two new PrimaryExpressions and attributes, it is JS.

The entire point is JSX extends JS to allow templating via nested JS functions w/ pretty brackets instead of creating an entire templating system.

Under your reasoning nothing that isn't in the current accepted Ecmascript spec implemented by browsers is JS. Does that mean decorators aren't JS? Were async functions not JS before they were in browsers?

Re: Rich Harris joins Vercel to work on Svelte full time

#389

Earlier quoted context omitted.

I looked into it at one point and it sounded like WASM isn't as fast as native (yet?), and the main benefit would be the ability to run in a browser. That'd be useful for making a web version and I might look into it again, but for now, if I'm already shipping an Electron app, WASM seems like extra hassle with less speed. I might be wrong about this though! Happy to hear if there are benefits I'm missing.

It's pretty dam close to native. I would consider researching it again. You could do away with Electron altogether and just run it in browser. You can make it a PWA to give it that "Native app" feel so the users are none the wiser but you don't have to deal with the complexities of Electron and managing releases etc. If you want to launch a new release just deploy it to your web host and you're done for all platforms…

Definitely worth another look. Thanks for the link!

Re: Rich Harris joins Vercel to work on Svelte full time

#390

Earlier quoted context omitted.

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 t…

What boilerplate does React have? Do you mean Babel?

useMemo and useCallback do feel a little boilerplate-y. Something is slow, I wrap it in the thing, I let eslint fill the dependencies and there‘s no big downside to doing it all the time anyway. Feels like something I maybe don‘t need to be typing?

useState is also something svelte eliminates, though I personally prefer to keep that explicit.

Post reply on HN