Live data from Hacker News

Comparing Svelte and React

jackfranklin.co.uk

21–30 of 338 posts

Re: Comparing Svelte and React

#21
post #12
post #3

I recently rewrote a small UI from Preact to Svelte and while it was certainly a learning experience, I have to say working with Svelte is fantastic. My only complaint is that the Typescript support isn't quite perfect yet, but it's already very functional.

I use Svelte + TypeScript in my personal projects, what issues did you run into?

Last I checked it was impossible to parametrize component type. In React you can write ` users={...} />`.

Re: Comparing Svelte and React

#22
post #12
post #3

I recently rewrote a small UI from Preact to Svelte and while it was certainly a learning experience, I have to say working with Svelte is fantastic. My only complaint is that the Typescript support isn't quite perfect yet, but it's already very functional.

I use Svelte + TypeScript in my personal projects, what issues did you run into?

Lack of support for generics and explicitly typing Events/Props/Slots. There is an RFC but it's still a WIP: https://github.com/sveltejs/rfcs/pull/38

Re: Comparing Svelte and React

#23
post #12

Earlier quoted context omitted.

I use Svelte + TypeScript in my personal projects, what issues did you run into?

Last I checked it was impossible to parametrize component type. In React you can write ` users={...} />`.

Please don't. It looks awful. And I think it's not necessary. Typescript should inherit it's type depending on what you are passing into "users".

Re: Comparing Svelte and React

#24

> writing complex React components feels more like admin; a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. I don't understand this worry, but I guess that happens when you try to do everything with hooks, the way I settled in my approach is to use React components just for the view without hooks, nor lifecycle logic, just dumb components with ocasional local st…

Yeah I've moved to this and it is working so far. Hooks manage the data and etc, UI components are almost exclusively just UI that get some props.

The UI components all have an else render if for some reason they're missing something / it avoids a crash (along with other easy to see / figure out protections)

Re: Comparing Svelte and React

#25

> writing complex React components feels more like admin; a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. I don't understand this worry, but I guess that happens when you try to do everything with hooks, the way I settled in my approach is to use React components just for the view without hooks, nor lifecycle logic, just dumb components with ocasional local st…

This sounds really interesting, don't get me wrong, but it also shows just how insanely novel and complicated modern frontend dev is.

Let's break down the terminology:

- hooks

- useEffect

- useHistory

- useSelector

- dispatch

- action

- useDispatch

- ducks

- Actions

- Epics (Observables)

- Sagas (generators)

- Reducers

Most of those terminologies don't come from a general programming paradigm, but are the domain language of specific libraries. And I've seen more, with some places establishing patterns like Compound/Molecule/Atom and such. There's no consistent, underlying principle with them, though. If you're invested in Sagas then you're stuck with a bizarre threading model implemented with generator functions and it's pretty much all-or-nothing. If you're invested in Redux then there's no breaking out of that either, you're always going to be contending with shared global state.

Re: Comparing Svelte and React

#28

> writing complex React components feels more like admin; a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. I don't understand this worry, but I guess that happens when you try to do everything with hooks, the way I settled in my approach is to use React components just for the view without hooks, nor lifecycle logic, just dumb components with ocasional local st…

What ? So you put navigation state, query state for each route in redux ?

Re: Comparing Svelte and React

#29
post #17

Javascript n00b question... is there any difference between onMount(() => { return listenForAuthChanges() }) and onMount(() => listenForAuthChanges()) ?

They are the same. It's a matter of style. For that matter, you could also write: onMount(listenForAuthChanges) which is technically simpler -- you're not constructing a new anonymous function. But if you wanted to extend the code (to say, add a console.log), you'd need to do the top version, which already has the braces. It's up to your judgment of what's clearer and likely to be more maintainable.

This is a utility function I carry around between projects for the "logging within a pure expression" case:

  function log(expr) {
    console.log(expr);
    return expr;
  }

  onMount(() => log(listenForAuthChanges()))

Re: Comparing Svelte and React

#30
post #2

Half-OT: Svelte seems to be the pinnacle of the "bundling era" of frontend frameworks. What do you think comes next? XYZ-to-WASM? Back the roots with (non-)bundlers like Skypack? Anyone heard of next-gen experiments in that directions?

We are actually going the other direction. Currently I am experimenting with making a Blazor/Liveview (HTML over wire) runtime that can support many programming languages. And a GUI builder.
Post reply on HN