Live data from Hacker News

Comparing Svelte and React

jackfranklin.co.uk

251–260 of 338 posts

Re: Comparing Svelte and React

#251

Earlier quoted context omitted.

When it comes to primitives you can only pass by value, but with objects and arrays you can only pass by reference . And this applies to comparisons too: when comparing objects or arrays you are comparing by reference , not deeply by their inner values. If you want to compare them deeply you have to take some additional steps to make that possible, and all of the different strategies for doing so have different trade…

You don't pass by reference in JS. You pass references by value. Passing by reference has a well defined meaning in computer language terminology. It means passing something that references the variable outside the function. Something you can't do in JavaScript void someFunc(ref int v) { v = 456; } var foo = 123; someFunc(foo); write(foo); // output 456 Above we are not passing 123 (the value of foo) into someFumc, w…

I would argue that Javascript is a hybrid of pass by reference because of the case below though.

    function someFunc(v) {
      v.myvar = 456;
      v = someOtherObject;
    }

    var foo = someObject;
    foo.myvar = 123;
    someFunc(foo);
    // foo still refers to someObject
    // foo.myvar is 456
Banning our team from passing objects around except in specific, discussed, cases got rid of lots of difficult to track down bugs.

Re: Comparing Svelte and React

#252
How come I rarely see mention of Aurelia when discussing JS frameworks? Aurelia 2 will be out soon, and I find things well thought out even in v1. You basically write just html and pretty much plain javascript. It is batteries included with DI/router/Event listener/validation etc.

Re: Comparing Svelte and React

#253

> 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 this is the problem with the React ecosystem. I'm intimately familiar with this stack and used to use redux with "duck" modules professionally, complete with sagas and epics, and rxjs and the whole kitten, so it's not that I don't understand all the terms and am just overwhelmed. It's just that once you stop using Redux, it becomes so much easier to build and manage your app, and you don't even realize how much…

>You don't even realize how bad the boilerplate is until it's all gone

I 100% agree with this, I also started out working with Redux in the fairly early days of React and while I do feel that I did learn a lot from it and have used Redux-inspired patterns for certain parts of applications since then, the productivity gains I got from switching to MobX for state management can't be overstated.

Sure, you could argue it's less "clean" or whatever, but honestly 99% of the time it just works, and I'm happy to have the 1% of time where you're debugging where you forgot to add "observable" or whatever in exchange for the 99% productivity boost.

Svelte does look really interesting and follows a similar kind of model to how I work with React and MobX, and does away with some boilerplate/gotchas.

My main concern using it would be around maturity of libraries... while it does seem pretty batteries-included, I have got used to being able to just pull in a library for x, y or z in React and I'd be worried if I started a big Svelte project, I might find myself kicking myself down the line e.g. if I need some component (data table or whatever) that has a mature option available in React. Perhaps people who've worked with Svelte professionally can comment on whether this is a valid concern?

Re: Comparing Svelte and React

#254

Earlier quoted context omitted.

I think many people adopted React because Facebook was behind it, and using it in production, the ecosystem is huge, there is a react- package for everything you can image, there is also react-native, I don't like it, but there it is, you can reuse the knowledge to build native mobile apps. Now Svelte, I haven't been following, but I think the creators are working in what's going to be next and even better framework[…

It's so boringly cynical to suggest that people use something because they're lemmings rather than any of the great reasons to use something. Go watch the original React debut talk and ask yourself if React had/has anything going for it beyond Facebook's backing. I know I, and most developers I know, dropped Backbone/Knockout/whatever instantly to use React because it was so obviously better. Now that unidirectional…

> to suggest that people use something because they're lemmings

That's not what I intended to say, of course that's not the only reason people choose React, but I think they are valid reasons to help you decide.

For example let's say two libraries are technically different but equivalent productive and nifty, choosing the one that has a bigger ecosystem is a totally valid choice.

Many people had to sell React to their bosses, and the fact that there was a presentation by Facebook, helped a lot, I don't see how stating the obvious is calling lemmings to anyone.

At the end of the day, it depends on your goals and motivations, I can't talk for everyone, I was actually saying some of the reasons that helped me decide on choosing React.

Re: Comparing Svelte and React

#255

No mention of Typescript. You'd be mad to consider writing a significant app without it, and React has really great Typescript support - even templates are type checked properly thanks to JSX/TSX, and basically all tools support JSX these days. Vue doesn't come close to that, but it does look like Svelte is at least a bit better: https://svelte.dev/blog/svelte-and-typescript I'd still be wary that there are big cavea…

The one place where react typings are disappointing to me is that all elements are typed as JSX.Element, meaning you can’t assert a specific type of child element. Usually not a big deal but would be useful in a number of cases.

It's a limitation of TS, not react. Flow for example can type elements more accurately.

Re: Comparing Svelte and React

#256
post #79

Earlier quoted context omitted.

It is also fucking magic. I love it when it works, but I have no idea why it doesn’t when it breaks. The same is not true for Redux, which is so simple I can build a house with it.

The "magic" is very simple and understandable if you read the docs; I fairly quickly gained an understanding of it that allowed me to dig into the odd performance issue or bug without much trouble 1) Observables are properties on objects; when their getter is called, it becomes "tracked" (subscribed to) by the currently-running tracked function. When their setter is called, it publishes to all subscribers. This happe…

Great explanation! And keep fighting the good fight pushing MobX ;) Pretty much everyone I know who has tried it has ended up loving it, but it can be hard to convince people to give it a go (because of FUD around "mutability" or "magic" or whatever...).

Re: Comparing Svelte and React

#257
post #166

When compared to Svelte, it's like React developers wake up every day and choose complexity.

It's actually very simple. React devs choose to write code in code. People of other frameworks write code in code and templates, which, to react devs, is complexity.

Re: Comparing Svelte and React

#258

Earlier quoted context omitted.

I also don't like having all those constants like LOADING_PRODUCTS ... And I don't have them, instead this is how you create a type safes actions with typesafe-actions package. export const signIn = { request: createAction("auth/signin/request")(), success: createAction("auth/signin/success") (), error: createAction("auth/signin/error") (), }; getType is a function from typesafe-actions as well. Not trying to sell yo…

We specifically recommend using our official Redux Toolkit package, rather than `typesafe-actions`. RTK is already written in TS and designed for a solid TS usage experience: https://redux-toolkit.js.org

thanks! I resisted redux-toolkit when it came out, but looking at the website, it might be the time to update the stack :)

Re: Comparing Svelte and React

#259
post #118
post #115

Earlier quoted context omitted.

biggest issue of Svelte (and vue and others) is that mutable state is marketed as a feature. If you don't like mutable state anyway then it just seems like an inferior way of writing code.

Yes. To be fair, after looking how the whole Redux story went, I think the mainstream simply wasn't ready for immutable state.

Yeah, I feel for dirty admitting this in this forum, but I still use React & MobX for state management. I get to use simple classes with observable state management. Works just dandy for me.

Re: Comparing Svelte and React

#260

Earlier quoted context omitted.

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…

> That page explicitly shows how RTK simplifies existing Redux patterns. The page is a tutorial for a TODO list with only the simplest and the happiest paths. It's not a forum just because you called it a forum, by the way. OT: I wish the JS world would stop doing TODO lists. A TODO list is a glorified `Array.push`. If it takes your library/framework 10 000 words to explain how to do Array.push, it doesn't mean that…

Your comment really cuts through to the truth about Redux, and gave me flashbacks to my “what the hell” moment the first time I needed to perform a fetch, and the subsequent painful mentoring of a junior dev who just couldn’t get it. Two other junior devs quit because they inherited a React codebase using RX. I couldn’t really blame them.
Post reply on HN