Rich Harris joins Vercel to work on Svelte full time • Hacker News Board

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

#441

Post by wruza » Fri, Nov 12, 2021, 4:56 AM UTC

noir_lord wrote: post #300

benmccann wrote: post #259

Earlier quoted context omitted.

But React isn't just JSX. It's also the entire runtime library, hooks, event handling, forms, state handling, etc. The example you shared is a bit too simple to understand where Svelte shines because it doesn't introduce any of those concerns. By having it's own templating language, Svelte is able to compile the templates to JavaScript in a way that addresses many of those concerns in a way that I think it easier to…

Not to mention it takes reactivity to new heights while adding amazingly little actual syntax. When property changes, the fetch refires, loading appears until the fetch resolves then it displays whatever array someFetch resolved to. I came from Vue and that plus the way Svelte does stores (literally nothing special about them) was a breath of fresh air. {#await someFetch(property)} Loading... {:then data} {#each data…

I’m neither of (react, vue, svelte) guy, but isn’t that snippet equivalent to some:

  div
    Await promise={mypromise}
      div Loading…
      {res => res.map(…)}
      div Error: {err => err.message}

(writing in pug-like because I can’t stand closing these tags on the phone)

Isn’t it easier in both react and vue to create Await component with children=(ifwaiting, ifresolved, ifrejected) than suffering all over the code?

Edit: I messed data flow up in the error handler, wontfix but you get the idea

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

#442

Post by toastercat » Fri, Nov 12, 2021, 4:57 AM UTC

eins1234 wrote: post #410

toastercat wrote: post #406

Earlier quoted context omitted.

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.

Define "we". :) I understand this sentiment though, and I also understand designing a flexible system with zero footguns is nigh impossible. My point however was that two-way databinding is not rare in React, and there are other potential footguns to be had in idiomatic React anyway (hooks, React Context).

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

#443

Post by francislavoie » Fri, Nov 12, 2021, 4:57 AM UTC

TranquilMarmot wrote: post #438

francislavoie wrote: post #430

Earlier quoted context omitted.

Nothing about its usage implies what it actually does. It's about API affordances. You can't simply just read the code as someone inexperienced with React and say "oh, I know what this does". Returning a closure as the result of another closure has no inherent meaning as to when that closure would be called, because there's no "name" for that functionality. And don't even get me started about the dependencies array,…

If I hadn't been using React for many years before they introduced useEffect and various other hooks, they would have all been incredibly confusing. They still are really confusing when used in "clever" ways, especially with developers being allergic to writing comments. Even something as simple as `// this will do X when the component unmounts` make reading usages of useEffect 10x easier (vs. having to remember what…

Totally agree re comments. They're necessary. Hooks do have huge advantages for composability and flexibility, and that can't be denied. But the API is just so arcane.

If my company wasn't a React shop, I'd probably be using Vue. I used Vue at my previous company and liked it a lot.

Headless libraries like `react-table` that use hooks are a revelation though. So nice to get pretty much all the behaviour you could ever need, without it making UI decisions for you. Difficult to use at first and wrap your head around, but hoo boy is it great to have the power to fully control the rendering!

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

#444

Post by noahtallen » Fri, Nov 12, 2021, 5:03 AM UTC

Aeolun wrote: post #369

noir_lord wrote: post #300

Earlier quoted context omitted.

Not to mention it takes reactivity to new heights while adding amazingly little actual syntax. When property changes, the fetch refires, loading appears until the fetch resolves then it displays whatever array someFetch resolved to. I came from Vue and that plus the way Svelte does stores (literally nothing special about them) was a breath of fresh air. {#await someFetch(property)} Loading... {:then data} {#each data…

But what does ‘#await someFetch’ actually do ? The thing I like most about react is that it’s just executing plain Javascript most of the time.

Not just most of the time — all of the time! JSX is converted to plain JS (react.createElement) before it gets to the browser.

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

#445

Post by wruza » Fri, Nov 12, 2021, 5:06 AM UTC

dwaltrip wrote: post #273

DonHopkins wrote: post #247

Earlier quoted context omitted.

And JSX isn't JavaScript and it isn't HTML, and if you know JavaScript and HTML you still don't know JSX, so you're still using "yet another language" in addition to JavaScript and HTML.

Come on… If you know JavaScript and HTML you are 95% of the way to being fluent in JSX. It’s basically just JavaScript expressions.

And if you know javascript and html you are 100% fluent in any sort of hyperscript, which is just js expressions.

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

#446

Post by wruza » Fri, Nov 12, 2021, 5:20 AM UTC

hunterb123 wrote: post #257

DonHopkins wrote: post #247

Earlier quoted context omitted.

And JSX isn't JavaScript and it isn't HTML, and if you know JavaScript and HTML you still don't know JSX, so you're still using "yet another language" in addition to JavaScript and HTML.

JSX is JS. Nested brackets are simply converted to nested function calls & objects, attributes convert to properties. This is evident when comparing conditionals, loops, etc. Instead of learning template syntax you simply use JS syntax, albeit a declarative subset (no branches). JSX is simply syntactical sugar for nested JS, you can use it without, but it's prettier with. One could add this syntactical sugar natively…

Jsx is not js, it’s python!

  
    {text}
  

  import react
  react.create_element("div", {"className":red}, text)

By the same logic we could call any structured format “is js”, because it is homomorphic to some js expressions. Are xml, pug, plist, dbf, all js? Nope, it’s all python.

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

#447

Post by [deleted] » Fri, Nov 12, 2021, 5:27 AM UTC

toastercat wrote: post #442

eins1234 wrote: post #410

Earlier quoted context omitted.

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.

Define "we". :) I understand this sentiment though, and I also understand designing a flexible system with zero footguns is nigh impossible. My point however was that two-way databinding is not rare in React, and there are other potential footguns to be had in idiomatic React anyway (hooks, React Context).

[deleted]

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

#448

Post by wruza » Fri, Nov 12, 2021, 5:29 AM UTC

bGl2YW5j wrote: post #360

cphoover wrote: post #231

Earlier quoted context omitted.

What how can you say that??? {myItems.map({id, title}) => {title} } vs... svelte {#each myItems as item} {item.title} {/each} 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.

This JSX syntax is a perfect example of one of its subtleties: map() creates an array, and an array of elements is automatically expanded to single elements. I know that when I learnt JSX, this was not intuitive. The word 'each' conveys the intent of this code way more explicitly.

And this subtlety is based on a difference in React.createElement() interface. If you pass an array among its children, it automatically requires all of its items to be keyed, and if you pass it as …array, i.e. variadic arguments, it doesn’t. But I believe you either can’t do {…array.map()} in jsx or its creators decided that it is not tasty enough.

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

#449

Post by eins1234 » Fri, Nov 12, 2021, 5:33 AM UTC

toastercat wrote: post #442

eins1234 wrote: post #410

Earlier quoted context omitted.

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.

Define "we". :) I understand this sentiment though, and I also understand designing a flexible system with zero footguns is nigh impossible. My point however was that two-way databinding is not rare in React, and there are other potential footguns to be had in idiomatic React anyway (hooks, React Context).

I realized maybe we have different definitions of 2-way data-binding also haha...

My objection is towards the Angular 1 style patterns where by passing some local component state to some children, you also implicitly allow those children to update it by binding it to some prop or by mutating it directly. This means the moment you need to share some piece of state, you can no longer reason about the state of your component in isolation nor control the ways in which it can be updated. This is at the core of what makes this approach so error prone IME.

In React, state is passed from parent to children as read-only values for which direct modification has no effect (this is the "unidirectional data flow"). The only way for a child component to update the state of a parent component is for the parent to explicitly pass down a function that exposes that functionality as part of its explicit API contract with its children.

Even in the worst case where we just naively pass down state updater functions directly (this is the case that's most similar to Angular-style 2-way-binding, which might be what you're referring to), this still results in state updates that are far easier to trace and debug as you can simply follow the function reference down to the call sites (instead of having follow all use cases of the state you passed down and trying to figure out which use cases bind or mutate). In the best case, it allows for components to offer only the minimum possible API surface to children by further restricting the set of possible state transitions (i.e. passing down openModal, closeModal functions, instead of the setIsModalOpen state updater function directly), and you can look at the parent component in isolation and confidently assert that no other possible state updates can possibly occur.

FWIW I don't have much experience with Svelte, so can't speak for which approach it's more similar to. But when I hear 2-way data binding the Angular style is the first thing that pops up in my mind from all the PTSD, so if Svelte's approach is more similar to the React style then I have nothing to object to.

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

#450

Post by wruza » Fri, Nov 12, 2021, 5:45 AM UTC

cphoover wrote: post #318

ksdnjweusdnkl21 wrote: post #290

Earlier quoted context omitted.

Seems like svelte is superior for not needing a key.

fair criticism I wonder how svelte optimizes for rerendering of long component lists. React uses keys to avoid rerendering the entire list.

Keys are also essential to retaining an element identity, which is structurally more important than performance, because 1) code may have a reference to an element and think that it relates to some data, 2) an element may have an explicit state (like focused, animating, etc).

Keys are a hugely leaking abstraction, but are inevitable when you bridge a declarative immediate mode rendering into a stateful one.