Live data from Hacker News

Comparing Svelte and React

jackfranklin.co.uk

311–320 of 338 posts

Re: Comparing Svelte and React

#311
post #168

Earlier quoted context omitted.

Until you try to do something svelte doesn't understand. Then it'd silently break. Templates are powerful _because_ of the restrictions they place, not in spite of them. I think a much better recommendation would be an existing template language, iff svelte could understand it with perfect parity. I hate being handed normal syntax to use when not all of it is normal, or when using it has different semantics than the…

I was saying elsewhere on the thread - I am not suggesting that each should be turned into a runtime call. Instead, 'svelte.each()' callsites are easy to identify in the AST and transform in the compiler. So the errors remain compile-time, not run-time.

The danger is that a developer will use `svelte.each()`, thinking it uses the same rules as normal JS syntax, but it turns out Svelte applies its own rules which _are_ slightly different (hypothetically).

So the developer must remember a new rule: "JS rules when calling foo.each(), Svelte rules when calling svelte.each()". A little harder to remember. Having a unique non-JS syntax makes the distinction obvious.

(Just playing Devil's Advocate here)

Re: Comparing Svelte and React

#312
post #309

Earlier quoted context omitted.

> I personally think your example is convoluted for such a simple example, but that's just me. It is indeed all a matter of taste in the end, but I mean it's the exact transcription of a textbook FSM. I don't think your example would get that much simpler with a stable identifier, which brings me to: > I don't have to create a monolithic state transition table logic It doesn't have to be monolithic. I just created a…

> transitions are not (but rather methods attached to states) whose type signature has start and end state > first-class entities a string

> whose type signature has start and end state

As do the reducers. For example the following is a valid type signature.

  function onToOff(initialState: "on", transition: "toggle"): "off"
In each of the if clauses those are what the types are inferred as, exactly equivalent in type safety to the classes (and more flexible because you can dispatch on action).

I chose string for simplicity (string literals happen to be distinct types on their own, I could easily use anything else other than strings, e.g. interfaces). Heck it could just be integers and be even simpler.

Re: Comparing Svelte and React

#313

I really do not understand the appeal of Svelte, it seems to be making all the same horrendous mistakes as Vue (bad templating/DSL that shoehorns control flow and bindings into DOM representation, esoteric lifecycle hooks etc) and the only advantage it clearly has over other frameworks that I can see is simple components can generally be written more concisely. Are there actually any tangible benefits to using it ove…

Simpler to write, batteries included and with better performance (in both bundle size and runtime performance) than React.

Re: Comparing Svelte and React

#314
post #309

Earlier quoted context omitted.

> transitions are not (but rather methods attached to states) whose type signature has start and end state > first-class entities a string

> whose type signature has start and end state As do the reducers. For example the following is a valid type signature. function onToOff(initialState: "on", transition: "toggle"): "off" In each of the if clauses those are what the types are inferred as, exactly equivalent in type safety to the classes (and more flexible because you can dispatch on action). I chose string for simplicity (string literals happen to be d…

wow a typescript lesson, because no one's ever heard of this

> Heck it could just be integers and be even simpler.

statement that has zero point, why make them?

> As do the reducers

like this? A | B | C => B | C | D

does that look like a state machine? Because state machine is this A => B & B => C & C => D

Re: Comparing Svelte and React

#316
post #188

Earlier quoted context omitted.

> but don't have a good handle on fundamental concepts like the difference between the two kinds of function syntax There is more than 2 now. :) You have the keyword function, you have const myFunc = (param) => { //body } and then you have the various types that can occur within a class, which can have a little bit different behavior based on which syntax you use. Fun times! And remember, arrow functions within a cla…

> And remember, arrow functions within a class have a this, but arrow functions outside of a class don't have a this! This is not correct. Arrow functions have the `this` value of the outer context. I recommend this article to understand `this`: https://web.dev/javascript-this/

> This is not correct. Arrow functions have the `this` value of the outer context.

You are correct, I wasn't clear. I was describing the end effect of free floating arrow functions VS an arrow function declared within a class.

When free floating, trying to access 'this' can (will) result in unexpected behavior, when inside a class arrow functions operate exactly as people expect a class member function to operate in other languages. (In contrast to having to otherwise bind JS functions to 'this')

In both cases the arrow function is acting the same way, but most intro to JS lessons don't explain it.

Indeed the way it was originally explained to me is that "arrow functions in classes auto bind to this" which is hilariously inaccurate, but the end effect is as if that was happening.

Re: Comparing Svelte and React

#317

I really do not understand the appeal of Svelte, it seems to be making all the same horrendous mistakes as Vue (bad templating/DSL that shoehorns control flow and bindings into DOM representation, esoteric lifecycle hooks etc) and the only advantage it clearly has over other frameworks that I can see is simple components can generally be written more concisely. Are there actually any tangible benefits to using it ove…

Tangible benefits? It's simple.

I would argue requiring your whole team to learn a new framework-specific templating language and patterns is not simple, compared to using something that is plain JS/TS which the whole team already knows. It also complicates hiring, as programmers who know JS/TS and can pick up React/Angular/etc are a dime a dozen, in contrast to trying to hire programmers to work with a niche framework which has a lot of domain specific knowledge.

Re: Comparing Svelte and React

#318

Earlier quoted context omitted.

Tangible benefits? It's simple.

I would argue requiring your whole team to learn a new framework-specific templating language and patterns is not simple, compared to using something that is plain JS/TS which the whole team already knows. It also complicates hiring, as programmers who know JS/TS and can pick up React/Angular/etc are a dime a dozen, in contrast to trying to hire programmers to work with a niche framework which has a lot of domain spe…

It sounds like you are claiming that it's easier for a javascript Dev to learn react than svelte.

Sure, there's more devs who currently know react.

But "easier to learn react" is crazy. The svelte tutorial is short and awesome.

Re: Comparing Svelte and React

#319

Earlier quoted context omitted.

What do you mean by "a certain event-sourcing something idea?" I really do mean "pure." That doesn't mean that Redux doesn't provide other facilities on top, such as React interop, error-handling, logging, etc. But if you don't need any of that and you use the core of Redux, it really is just a state machine representation. Let's write out the classic finite state machine representation of a locked/unlocked item. Sta…

If you think that's the simplest you could get, more power to you. I personally think your example is convoluted for such a simple example, but that's just me. However, I should point out something that is not actually trivial about your code, by proposing a refactor: your FSM adequately models a car lock button interface, but not the lock itself. If we are modeling the lock, you have two invalid transitions...becaus…

Let's step back. I think your approach work really well if you model state machine for internal usage.

However, Redux is meant to be for UI work, which is a side effect. You cannot control side-effect. You cannot guarantee that user will not try to turn switch off twice.

Even in idiomatic Redux, the switch case for reducer always include `default:` which mean everything else go here.

As you said, the Redux FSM models a car lock button interface which is exactly what Redux try model.

Re: Comparing Svelte and React

#320
post #127

Earlier quoted context omitted.

I don’t think any of your arguments in favour of react are sufficient. JQuery had a huge number of libraries and could be used to make websites that worked. Angular was backed by Google who generally have more clout than Facebook. I think most comparisons would find that jQuery does not solve the same problems and that angular resembles the kind of steaming brown thing one might find behind a cow—and that’s before yo…

Your counter points don’t check out too much though? > jQuery Just not possible to compose, which makes full applications difficult. No answers for state management or such either, completely a different scope than frameworks > Google more clout than FB In some domains sure, but I’ve never understood how people don’t think FB are masters of UI. There is probably no org with more UI clout than FB, they built their own…

You ended a statement in a question mark?
Post reply on HN