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

141–150 of 338 posts

Re: Comparing Svelte and React

#141

Post by com2kid »

brundolf wrote: post #40
ljm wrote: post #33

Earlier quoted context omitted.

React's hooks (and some JSX style things in general) are quite pernicious there because they essentially break JS: you can't use them inside an `if` or a `for` or a `while`, or even within another function. You're no longer writing Javascript, you're writing a restricted subset to avoid undefined behaviour. That alone is a concern, because any junior programmer getting an introduction through React is going to get a…

In some ways JS is an excellent first language- beyond its broad applicability, it has an extremely "average of all the others" set of features and primary syntaxes. An experienced JS programmer will be conceptually comfortable with Python and Ruby, syntactically comfortable with Java and C, etc. But in terms of the industry-standard practices/ecosystem, it is a terrible first language if you want to gain a generaliz…

> 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 class have a this, but arrow functions outside of a class don't have a this!

Re: Comparing Svelte and React

#142

Post by acemarke »

dmitriid wrote: post #103
acemarke wrote: post #87

Earlier quoted context omitted.

I do get the arguments that you're making here about Svelte, and don't disagree. That said, "Modern Redux" code is very different than what you've probably seen even just a couple years ago. We've introduced newer APIs like Redux Toolkit, which is a set of utilities that provide a light abstraction to simplify the most common Redux tasks, and the React-Redux hooks API, which is generally easier to use than the tradit…

I can agree on redux hooks being a better alternative to the whole mapToState cycle. But if you go into the new tutorials, they quickly devolve into the same old: https://redux.js.org/tutorials/fundamentals/part-8-modern-re... Oh, look, slices, and thunks, and asyncThunks, and extraReducers, and adapters, and fifteen files to tie all this together for every small piece of api or data that you want to send around. Mos…

I'm not sure how you're looking at that docs page and saying that it "devolves into the same old". That page explicitly shows how RTK simplifies existing Redux patterns. Yes, concepts like "thunks" and "reducers" still exist. Yes, there are new APIs like `createSlice` and `createEntityAdapter`, which have their own options. That's because we've seen how people are using Redux, and have built those APIs to help solve the use cases people are dealing with. But no, the code you write today is drastically different, and we've gotten tons of positive feedback about how much people enjoy using RTK.

It's also definitely _not_ "15 files to tie this all together". In fact, we specifically recommend writing all the Redux logic for a given feature in a single "slice file":

- https://redux.js.org/style-guide/style-guide#structure-files...

- https://redux.js.org/tutorials/essentials/part-2-app-structu...

Re: Comparing Svelte and React

#143

Post by jeswin »

I think it's a misunderstanding that Svelte is fast because it is "compiled" into imperative DOM updates. This is partly because the documentation says so, and the early blog posts emphasized this aspect.

Compilation actually has nothing to do with it. Svelte is fast because it doesn't do all the Virtual DOM stuff, and the DOM diffing. You could very well build Svelte as a library without the compiler, and it would be just as fast.

But the compiler helps a bit with the ergonomics - it's cleaner to do count+=1, rather than setState({count:count+1}).

Re: Comparing Svelte and React

#144

Post by brundolf »

orangecat wrote: post #129
brundolf wrote: post #68

Earlier quoted context omitted.

It's baffling to me how distant of a second it is in terms of popularity. Instead of forcing you to contort your program into a special paradigm in order to deal with reactivity in a sane way, it simply makes reactivity a non-concern (while remaining pretty simple and predictable when you do actually care to dig beneath the magic). You can write code in a way that's natural and simply not think about reactivity most…

And then there's Vue.js which essentially has MobX functionality built in. When you want to update the state, you just...update the state, which can be a plain JS object that knows nothing about the front-end framework. I've used it for several medium-size projects and haven't gotten close to needing anything like Redux or Vuex.

Yeah, although when I played with Vue a couple years ago it seemed like it wasn't quite as powerful as MobX (particularly when you start stacking up a graph of computed values, or when you want to create side-effects of your own). But definitely a similar idea.

Re: Comparing Svelte and React

#145

Post by nsonha »

lhorie wrote: post #138
nsonha wrote: post #134

Earlier quoted context omitted.

could you stop saying redux, in my other comment I said the solution could be anything from react's setState to old-style encapsulation. The point is, it's kind of odd that someone'd put mutating states in their tutorial proudly as a "feature". It's a thing that you do very conservatively at best.

> it's kind of odd that someone'd put mutating states in their tutorial proudly as a "feature" Mutating state is actually the de-facto standard across most of the industry. Look at Vue or iOS or Android or Unity or Rails or J2EE... People literally use ORMs to make things more mutable than SQL. Yes, you can use React setState, but surely it's not lost on you that this is wrapping over a lot of mutable operations too?…

again with the mechanical definition of mutability. Ok "controlled" is the word, as I mentioned in other comment state encapsulation (which ORM is) is another solution for this.

Re: Comparing Svelte and React

#146

Post by brailsafe »

deckard1 wrote: post #69

I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed the…

Sounds like you're describing Vue. Is their any substantial advantage over Vue that you're aware of? I think a lot of people, including myself, are just uninterested in arbitrarily and subtley different solutions to the same problem. I've used react, and it's just not as compelling as anyone made it out to be. Neither is Vue compared to React for that matter, but it appeals to me a little more.

Re: Comparing Svelte and React

#147

Post by darksaints »

dwohnitmok wrote: post #136
darksaints wrote: post #130

Earlier quoted context omitted.

Redux was shit. It made apps less comprehensible and less performant. Immutable state isn't really a great idea for stateful applications, and UI development is an almost purely stateful activity. It can easily be said that any UI is fundamentally a state machine...the state of your UI defines the set of actions that are available to it, and the actions taken define the future state of the UI. This is not just true f…

> 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 state tree to determine which option is selected in my select dropdown? Why should I bundle the varying hyperlocalized implications of onChange actions vs onSelect actions with the business implications of things like payment submission states? Why does the state of one button for basic user A have to be bundled in the same data structure as an input element three tabs over, two levels deeper, meant for admin user B with privileged access?

2. Robbed of the concept of benign localized state, all state transitions must be weaved through the entire complex functional tree that renders it. Small refactors of your UI, like moving a widget from one place to a different location in your application "tree", involve not just refactoring the component which renders the widget, but every single component that it passes through, to reroute the data to the right location. It is extremely high touch refactoring, exacerbated by javascript's dynamic nature which is already hard to refactor, and Redux's inability to play nice with static typing tools like Typescript.

Redux's bad ideas do not come from the fact that it models a state machine, it comes from the fact that it models it poorly and forces you into using a giant state machine, intricately threaded and tightly coupled throughout your entire application, when smaller state machines are easier to understand and easier to compose.

Luckily, there is another programming construct that allows you to easily model state machines, and allows you to build them arbitrarily large or small to meet your demands, and allows you to encapsulate data and actions extremely well so that state and associated actions do not leak. They're called classes.

Re: Comparing Svelte and React

#148

Post by ampdepolymerase »

mattgreenrocks wrote: post #110
deckard1 wrote: post #69

I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed the…

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.

Re: Comparing Svelte and React

#149

Post by jeswin »

robertoandred wrote: post #81
deckard1 wrote: post #69

I'm a big fan of Svelte. I've raved about their documentation before, but it bears repeating: this should be the gold standard. You can read it all in a day. There are examples to follow right next to the documentation. Svelte is both succinct and powerful. I find this in contrast to React which is often baffling and incoherent. I say this as someone that has used React professionally for 6 years. They've changed the…

How is Svelte "just JavaScript" when it uses custom templates and file types?

Actually React can stake a better claim to being "just JavaScript" than Svelte. Once you know what JSX compiles to (the rules are fairly basic), React does become "just JavaScript".

That's not the case with Vue, Angular or Svelte. There's framework specific syntax that you need to learn. Eg: '{#each things as thing}' from Svelte's documentation.

Re: Comparing Svelte and React

#150

Post by raihansaputra »

amelius wrote: post #76
beaconstudios wrote: post #60

The svelte approach of implementing better paradigms using compilation rather than using abstractions just seems infinitely better, and a better way to scale up a program in general. I do wonder why this idea never caught on; I think Alan Kay was investigating building a programming platform based on this idea but that's just academic.

It's kind of funny that a NYT graphic designer (Rich Harris) outsmarted so many CS academics in finding the right software engineering tools.

I think it's an academics vs practitioners thing. Rich is willing and can use Svelte and Svelte/kit in actual production workloads in NYT. Kind of similar in how most Rails abstractions are pulled out from Basecamp's implementation. Doesn't hurt that Rails HEAD is directly used (in % deploy) by Shopify etc too.
Post reply on HN