Live data from Hacker News

Rich Harris joins Vercel to work on Svelte full time

twitter.com

411–420 of 571 posts

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

#411

Earlier quoted context omitted.

Is it false though? If it’s true, then maybe we need to look at why it’s true. It’s not just front end developers though. I think other domains and their frameworks went through the same thing. This is just the time for front end.

Indeed, it’s false. React is 8 years old, and when React was first released jQuery was only 7 years old. I follow this stuff pretty closely and I can only think of maybe 10 JS UI frameworks that have attracted remotely significant use and active development at any point in the past 15 years.

Java is 26. Spring is 19. Struts 2 is 15.

Python is 30. Django is 16.

I’m just picking a few frameworks and languages I’ve used in the past and are still used. Obviously there are still new frameworks and libraries that come out for these languages. But sometimes the big projects fold those in. Or they write their own or whatever. I can pick the popular names and do pretty much what I need.

JavaScript is 25. But most of that time we weren’t doing what we can now. And most frameworks are fairly young. Angular is 11. But most people (and jobs) have jumped ship to React(8) and now there is Svelte(4) which also looks good. And I think there will be more changes to come.

These JS frameworks aren’t exactly veterans that are impossible to supplant. Not yet anyway.

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

#412
post #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.

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

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

#413

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

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

#414

Earlier quoted context omitted.

My experience with the tool chain was abysmal. It's been almost 3 years away now for me, so I don't know the current state of things. I hope it has improved. But every update was a large effort in bringing the app back into compliance with the new changes. The debugging platform used a different interpreter than in app resulting in things that worked in the debugger but not in production. Odd bugs at boundary layers…

> The debugging platform used a different interpreter than in app What discrepancies did you notice? It depends on the target platform which JS engine is used. Sometimes the debugging platform shares the same engine. > Odd bugs at boundary layers nobody could (easily) decipher. I'm not sure I understand, could you provide an example? > The inability to even catch or do anything with some crashes. Strange, you're able…

Disclaimer, these memories are about 3 years old...

> What discrepancies did you notice? It depends on the target platform which JS engine is used. Sometimes the debugging platform shares the same engine.

Exactly what I said, there would be some code that would run differently in the two environments. I know more now than I did then, but I believe the example was specifically on iOS the app was using JavaScriptCore and the desktop dev tools was using v8.

> I'm not sure I understand, could you provide an example?

> Strange, you're able to catch and debug both JS and native crashes currently. I'm not aware of a past limitation but I could be wrong.

Best as I recall, there was a semi-frequent bug that happened down in our logging system. When it blew up we got a native stack trace instead of JS. My best guess is some kind of handshaking problem between the two layers. Neither used code we wrote and maintained.

Because the whole thing happened inside our error reporting engine, it wouldn't end up in our logs other than a high level apparent failure. It was a mess, and we had limited native experience on the team when it happened. We hired a dev with more native experience, but we still didn't ever figure it out while I was there.

The tool chain always felt like it was a hacked together early beta. To complicate our experience our internal APIs were a mess and unreliable and our React Native codebase wasn't dramatically better. Between our internal problems and all the idiosyncrasies and unintuitive issues in the tool chain it was really miserable.

It wasn't unusual for everyone on the team to spend more than a day simply trying to get the app running again after an update, that is after a dev had completed a 1 to 2 week migration required after the update.

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

#415

Earlier quoted context omitted.

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

> By being an extension of JS it is JS. The two are mutually inclusive.

This is absurd. If JSX were JavaScript, JavaScript wouldn’t need to be extended to include JSX. The whole point of it being an extension is that JavaScript doesn’t include it, therefore JSX extends it. If JSX were JavaScript, then JavaScript wouldn’t need to be extended. The two are mutually exclusive.

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

In the context of “Is JSX JavaScript?”, the value of JSX is irrelevant. Whether JSX is useless, useful, or amazing makes zero difference to the question of whether JSX is JavaScript or not.

You can still go around telling people JSX is great. It doesn’t have to be JavaScript for you to do that. People telling you that it isn’t JavaScript aren’t telling you that it’s worthless. They are just telling you that it isn’t JavaScript.

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

#416

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'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 un…

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.

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

#417
post #268

Earlier quoted context omitted.

Consider trying to hire outside Svelte - Anyone that can write using the major frameworks will do just fine. If the problem is candidates uninterested in using it, that's a different problem.

This is what I've done, but it's still hard to find someone who will do things in idiomatic Svelte.

:(

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

#418
post #346
post #311

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

And how about shadow DOM?

Virtual DOM? That’s the internal machinery that allows you to specify (and update) the UI declaratively while applying only localized updates on the actual DOM. It’s a feature, not a drawback, when you want to code declaratively.

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

#419

Earlier quoted context omitted.

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

> By being an extension of JS it is JS. The two are mutually inclusive. This is absurd. If JSX were JavaScript, JavaScript wouldn’t need to be extended to include JSX. The whole point of it being an extension is that JavaScript doesn’t include it, therefore JSX extends it. If JSX were JavaScript, then JavaScript wouldn’t need to be extended. The two are mutually exclusive . > > We are not talking about the value of J…

Are decorators JS? Answer that question and I'll respond to the rest of your comment.

We're talking in circles a bit so I'd like to drill that down first.

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

#420

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

I don’t love that aspect myself, but I have to point out that in Svelte’s case it is definitely not “without a very compelling reason”. The special build-time processing is the entire point of Svelte. Though personally I’d almost prefer it was a whole new language than a “kind of JS but with some (necessarily) new syntax”

100% no more js frankensteins...

Id prefer to learn a new language altogether

Post reply on HN