Hacker News Reader

Comment by benmccann | Hacker News Reader

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 deal with as an end user of the framework.

If Svelte were using JSX, I don't know that it'd be possible to do everything else that it does so simply because you can write anything that's valid JavaScript in JSX whereas Svelte has just a couple of basic control structures that its compiler can parse and convert to runnable code.

View on HN

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.

    <div>
        {#await someFetch(property)}
            <div>Loading...</div>
        {:then data}
        
            {#each data as item, index}
                <div>{item}</div>
            {/each}
    
        {/await}
    </div>

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.

Isn't it actually the opposite? Svelte code is compiled to plain JS whereas React has a large runtime.

Nah, JSX also gets converted to Javascript. The difference is in that the React runtime re-renders whole components every time something changes, and Svelte is more granular about it even during the compilation step.

https://svelte.dev/tutorial/await-blocks Explains it better.

His point is you don't have to read some project's documentation to know how some "await blocks" work.

With JSX you can use native JS features instead, you only need to know the language.

For example, instead of looking up how to loop in the template syntax, you use an iterator.

> The thing I like most about react is that it’s just executing plain Javascript most of the time.

Then explain what hooks do ;)

Hooks are decidedly not Javascript (even if they look like Javascript), and are a much more weird construct than {#await promise}

No, they are JavaScript, it is array based programming wrapped in a reactive functional-declarative approach. Simply array of objects cascading with state. {#await promise} is more cryptic than any useHook function implementation.

> No, they are JavaScript, it is array based programming wrapped

Javascript has no support for array-based programming.

So, hooks are not Javascript: they look like regular function calls, but:

- they can only be declared and called before rendering

- they can't be called out of order

- they cannot be called conditionally

- they have to be called a specific name to be handled correctly by React runtime

- some (but not all of them) require dependency lists that determine how they are invoked

> {#await promise} is more cryptic than any useHook function implementation.

usEffect documentation is something like 20 pages long. The use of {#await promise} is immediately understandable from the code example, and its entire documentation fits on a page and a half

They are definitely javascript. I can click to definition of the useEffect function and see exactly what it is doing.

I completely agree that learning them is a bit crazy, but ultimately every hook comes down to being a function execution.

> They are definitely javascript.

How come they break Javascript semantics and execution flow?

> but ultimately every hook comes down to being a function execution.

That's really beside the point when it comes to understand what something is and using them.

{#await promise} is immediately understandable from its use.

Hooks are... well, I already said above.

> How come they break Javascript semantics and execution flow?

wait what? since when do they break execution flow and javascript semantics?!

useEffect(function () { }); when exactly do you think the function will be called? - correct only the "framework" defines that, but that's completly normal javascript execution and semantic.

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

Reply on news.ycombinator.com