Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Comparing Svelte and React

jackfranklin.co.uk

Post reply on HN
Print view View original

171–180 of 338 posts

Re: Comparing Svelte and React

#171

Post by jeswin »

lhorie wrote: post #169
jeswin wrote: post #162

Earlier quoted context omitted.

> There are also technical reasons why `svelte.each` would be problematic... I am not suggesting that the svelte.each() call be moved into a library; I'm proposing that the callsite is trivial to identify in the AST. Svelte compiler could then do the same thing that it does now.

Yes, parsing is trivial, but compiling (in the traditional sense, not the transpilation sense) is a different story. The other sibling comment nails it. Grammar enforces where a grammar construct is allowed to exist. A custom grammar can be very restrictive (which it is, to great effect, in Svelte's case). If we reuse JS grammar, then that comes with expectations of what should semantically work. For example somethin…

You're right about it being complex (my experience [1]), but such work is within scope for what's perhaps a central design decision for a library. Yes there'll be bugs, but it'll stabilize over time.

Just to be clear, I am NOT saying that Svelte needed to do this. But merely suggesting options for discussion and learning.

[1]: https://github.com/jeswin-unmaintained/isotropy-ast-analyzer... - Here's for instance, some code I wrote for analyzing a JS sort expression. You'd think it'd take just a few hours, until you get to it. Btw, it uses an AST analysis framework I wrote called chimpanzee - it has only one user though. :) https://github.com/jeswin/chimpanzee

Re: Comparing Svelte and React

#172

Post by nsonha »

dwohnitmok wrote: post #153
darksaints wrote: post #147

Earlier quoted context omitted.

The problem with Redux is two fold: 1. The datastore is a massive global. This already brings to it many of the pitfalls that have caused programmers everywhere to avoid global variables like the plague. But in addition to that, for incredibly complex apps, it is a massive burden to maintain all of your state in one place, without any ability to encapsulate or localize trivial local states. Why do I need a global sta…

> The datastore is a massive global. A single global state machine and a bunch of small state machines can be losslessly transformed from one to the other. And indeed Redux offers tooling to transform from one to the other depending on preference (this is the Redux Toolkit). And indeed in that world they don't have to be bundled together. You can have separate state machines for different parts of the page. > Robbed…

> the important part of representing state machines is that you can inspect their state

Why? Is that because you need to know if a transition is valid for a given state? Do you have a citation for this?

> Classes are meant to be opaque; as you say their encapsulation is a feature.

This is true, but in practice, people do expose things in classes. I regularly implement state machines in classes as immutable builders.

> But their opaqueness prevents the usual state machine composition.

Not sure what you're refering to by this. Sounds like it's based on a specific implementation. I'm sure there are patterns that could help with this.

Re: Comparing Svelte and React

#173

Post by akdor1154 »

jeswin wrote: post #162
lhorie wrote: post #160

Earlier quoted context omitted.

FWIW, I did a mini-study a while back about the different possible syntaxes. It turns out there's more than meets the eye wrt what control flow structures need to do, and there are also DX reasons why the dedicated syntax might be more desirable: when you consider all permutations of loop flavors - w/ else clauses, keyed, exposing index, etc - the DSL consistently came out on top in terms of succinctness and readabil…

> There are also technical reasons why `svelte.each` would be problematic... I am not suggesting that the svelte.each() call be moved into a library; I'm proposing that the callsite is trivial to identify in the AST. Svelte compiler could then do the same thing that it does now.

I think you are persistently suggesting something to someone who knows more than you, without taking the proper time beforehand to understand the problem space.

Re: Comparing Svelte and React

#174

Post by jeswin »

akdor1154 wrote: post #173
jeswin wrote: post #162

Earlier quoted context omitted.

> There are also technical reasons why `svelte.each` would be problematic... I am not suggesting that the svelte.each() call be moved into a library; I'm proposing that the callsite is trivial to identify in the AST. Svelte compiler could then do the same thing that it does now.

I think you are persistently suggesting something to someone who knows more than you, without taking the proper time beforehand to understand the problem space.

I do believe I understand the problem space well enough to comment on it - both AST analysis and frontend frameworks. My comment above also included a clarification that I was not suggesting that this be turned into a runtime call. Just presenting an entirely subjective viewpoint (of avoiding new language syntax), but one that many people share.

Re: Comparing Svelte and React

#175

Post by dimitrios1 »

ampdepolymerase wrote: post #148
mattgreenrocks wrote: post #110

Earlier quoted context omitted.

IMO, Svelte’s biggest issue is it didn’t come out of FAANG.

In terms of influence on society, the New York Times is just as pernicious as any of the FAANGs.

This was true before the age of Trump and the ongoing internal war, highlighted by Bari Weiss and more, between the old guard and the new ideologues. I am most definitely not alone when I say the weight of their words have diminished greatly.

Re: Comparing Svelte and React

#176

Post by qudat »

darksaints wrote: post #147
dwohnitmok wrote: post #136

Earlier quoted context omitted.

> It can easily be said that any UI is fundamentally a state machine This doesn't make sense to me as a criticism of Redux. Redux is a giant state machine. That's all it is. Actions are transitions and the store is the current state. The state transition table is the reducer. The Redux architecture (and the Elm architecture that inspired it) is about the purest expression of a state machine you're likely to find in a…

The problem with Redux is two fold: 1. The datastore is a massive global. This already brings to it many of the pitfalls that have caused programmers everywhere to avoid global variables like the plague. But in addition to that, for incredibly complex apps, it is a massive burden to maintain all of your state in one place, without any ability to encapsulate or localize trivial local states. Why do I need a global sta…

I think you’re illustrating one of redux’s real downfalls: it can be used to hold the entire state for your UI, even though it shouldn’t. All your complaints are solved when adhering to the official recommendations. Maybe you got into redux early or worked on a codebase that took things too far.

A global state object is one of the nicer features when dealing with redux.

Re: Comparing Svelte and React

#177

Post by dudus »

Greek0 wrote: post #5

The author praises Firebase Auth for its ease-of-integration, but I'm leery of depending on Google products due to its support horror stories. Can anyone recommend good, easy-to-integrate alternatives?

Have been using firebase for years without significant hiccups. I was wary at first but I'm glad I moved over it. Support is strong if you have a paid plan and their documentation is fenomenal.

Re: Comparing Svelte and React

#178

Post by anonytrary » 

  1. Community support.
Svelte I think is the "more technically correct" approach, but React 16+ is good enough, concise enough, and it has thousands of community packages already. Svelte still needs way more buy-in for it to be a serious option at our company. We actually implemented a small part of our app in Svelte, but moved away from it because Svelte is still sort of a tinkerer's tool[0]. I really hope it gets more adoption, though. Until then, we're going to be using React 16+.

[0] https://trends.google.com/trends/explore?date=all&geo=US&q=s...

Re: Comparing Svelte and React

#179

Post by qudat »

ljm wrote: post #25
alfonsodev wrote: post #18

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

5 of those items are the same thing (hooks).

Dispatch is how you emit an event (pub in pub/sub). Action is the event being emitted.

Ducks is a code organization paradigm (colocation, organize by feature instead of layer).

Reducers are what they sound like: a reduce function.

Sagas and observables are how to perform side-effects in your application.

There is nothing new here. You could argue that hooks are the weird ones but they are heavily inspired by algebraic effects.

Re: Comparing Svelte and React

#180

Post by hombre_fatal »

jeswin wrote: post #162
lhorie wrote: post #160

Earlier quoted context omitted.

FWIW, I did a mini-study a while back about the different possible syntaxes. It turns out there's more than meets the eye wrt what control flow structures need to do, and there are also DX reasons why the dedicated syntax might be more desirable: when you consider all permutations of loop flavors - w/ else clauses, keyed, exposing index, etc - the DSL consistently came out on top in terms of succinctness and readabil…

> There are also technical reasons why `svelte.each` would be problematic... I am not suggesting that the svelte.each() call be moved into a library; I'm proposing that the callsite is trivial to identify in the AST. Svelte compiler could then do the same thing that it does now.

To deal with the issues they're talking about, you usually end up encumbering `svelte.each` with limitations such that it only looks like Javascript superficially.

In such a case, I think it's less confusing at the end of the day to just have a custom DSL for looping so that there's no clashing with its list of arbitrary limitations.

Post reply on HN