Live data from Hacker News

Rich Harris joins Vercel to work on Svelte full time

twitter.com

401–410 of 571 posts

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

#401

Earlier quoted context omitted.

We’re not splitting hairs. It is, quite literally, not JavaScript in a fundamental way. If you want to go around telling people it’s a non-standard extension to JavaScript or if you want to go around telling people it’s a superset of JavaScript, then by all means do that. But it is simply not JavaScript . Why do you insist on saying otherwise? All that does is start completely pointless arguments. What do you gain fr…

I think you're getting a little too worked up. The point is this small extension to JS grammar lets you do templating with normal JS, instead of #for you can use .forEach, .map and other array methods. You can use JS instead of replacing tokens in a template. It's not a superset of JS, that's not accurate, it's an extension of the spec. I hope the JSX spec is added to the standard sometime to stop this stupid debate.…

> The point is this small extension to JS grammar lets you…

If that’s the point, why are you telling people it’s JavaScript? You can make that point just fine without starting arguments.

Saying “This is an extension to JavaScript” is fine. Saying “This is JavaScript” starts arguments. What is your goal here?

> I hope the JSX spec is added to the standard sometime to stop this stupid debate.

But you are starting this stupid debate by telling people it’s JavaScript when it isn’t. If you are tired of people pointing this out when you call it JavaScript, why do you do it? There seems to be absolutely nothing to gain from that except “a stupid debate”.

> Until you realize what JSX is

I know what JSX is. I’ve written plenty of JSX.

> you don't realize the full potential it has over templates.

We are not talking about the value of JSX, merely whether it is JavaScript or not. JSX could cure cancer, but it still wouldn’t be JavaScript.

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

#402

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…

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

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

#403

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

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.

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

#404

Earlier quoted context omitted.

I think you're getting a little too worked up. The point is this small extension to JS grammar lets you do templating with normal JS, instead of #for you can use .forEach, .map and other array methods. You can use JS instead of replacing tokens in a template. It's not a superset of JS, that's not accurate, it's an extension of the spec. I hope the JSX spec is added to the standard sometime to stop this stupid debate.…

> The point is this small extension to JS grammar lets you… If that’s the point, why are you telling people it’s JavaScript? You can make that point just fine without starting arguments. Saying “This is an extension to JavaScript” is fine. Saying “This is JavaScript” starts arguments. What is your goal here? > I hope the JSX spec is added to the standard sometime to stop this stupid debate. But you are starting this…

> If that’s the point, why are you telling people it’s JavaScript? You can make that point just fine without starting arguments.

First, I say it's JS because it is. Just as decorators are JS. By being an extension of JS it is JS. The two are mutually inclusive.

Second, I didn't want to start an argument, I wanted to call out the very wrong blog post, how it referenced React not JSX, how the spec is an extension of JS, explain the limitations, etc. Until now it was more of a debate. Now it's a bit more of a semantics debate unfortunately.

> But you are starting this stupid debate by telling people it’s JavaScript when it isn’t. If you are tired of people pointing this out when you call it JavaScript, why do you do it? There seems to be absolutely nothing to gain from that except “a stupid debate”.

Actually if you go up the comment chain you'll see I didn't start this debate. If you're tired, just don't participate.

> We are not talking about the value of JSX, merely whether it is JavaScript or not. JSX could cure cancer, but it still wouldn’t be JavaScript.

Oh but we are, again if you go up the comment chain, it's being compared to Svelte's template system, that's how it got brought up, and that's usually why this topic gets brought up. You don't have to create a whole template system. You just use nested functions. To use pretty brackets it needs a small extension of the spec. You don't have to come up with a loop system, a conditional system, etc.

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

#405

Earlier quoted context omitted.

> - Special syntax for reactivity is not javascript > - I find the javascript-native flexibility of JSX far more expressive than any custom templating These are odd points to combine – JSX is special syntax not JavaScript as well.

Sure, but it maps 100% to an expected JS syntax and improves readability (subjective). From {children} To React.createElement("div", { attr1: "str" }, children) Custom templating is not like that.

Subjective indeed. If the goal is to leverage the full expressiveness of JavaScript, you could just alias React.createElement to something like `h`. Or use something like https://github.com/caderek/react-plain

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

#406

Earlier quoted context omitted.

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

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.

2-way data binding is still a useful pattern with discipline, and still also common in React (using event handlers).

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

#407

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

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

#408

Earlier quoted context omitted.

Sure, but it maps 100% to an expected JS syntax and improves readability (subjective). From {children} To React.createElement("div", { attr1: "str" }, children) Custom templating is not like that.

Subjective indeed. If the goal is to leverage the full expressiveness of JavaScript, you could just alias React.createElement to something like `h`. Or use something like https://github.com/caderek/react-plain

Yeah, but that's harder in practice. You often copy html snippets into your code, for example from tailwind or bootstrap samples. This is easier in JSX syntax; you'd just need to copy and fix up some attribute names.

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

#409

Earlier quoted context omitted.

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

You are misreading. He's saying that rollup[1] was the only other option for bundling static assets besides webpack until esbuild was created. Rollup was created by Rich. - [1]: https://rollupjs.org/guide/en/

That makes more sense. Thanks for clarifying!

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

#410

Earlier quoted context omitted.

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.

2-way data binding is still a useful pattern with discipline, and still also common in React (using event handlers).

Any error-prone pattern can remain useful with enough discipline, but we've learned time and time again that relying solely on discipline to cover for error-prone patterns doesn't scale.
Post reply on HN