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

221–230 of 338 posts

Re: Comparing Svelte and React

#221

Post by selfmodruntime »

kabes wrote: post #216

I never got the appeal of state management in React. People now seem to rave about Svelte, because you can just do 'count += 1'. But you could do exactly this already in Angularjs (which, just like Svelte, had a template language). Ok, Angularjs worked different under-the-hood than Svelte. It was a dirty checking loop instead of compiler-generated change indicators, which didn't scale as well. But other than this sca…

It's because react works with immutable state.

Svelte instead opts for compile-time magicks to handle state.

Angular uses decorators to manage state. This has turned out to be an unwise descision because javascript decorators have changed in spec since then.

Re: Comparing Svelte and React

#222

Post by selfmodruntime »

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…

So what. I've been a backend dev before I turned to front-end and web stuff. React has like a dozen top level functions and approaches. No backend project I have ever seen was this simple to program. How much more simple does it have to get before people stop complaining?

Re: Comparing Svelte and React

#223

Post by selfmodruntime »

protonimitate wrote: post #20
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…

> a constant worry that I'll miss a dependency in my useEffect call and end up crashing my browser session. As an fyi for anyone not aware, there are eslint/tslint plugins for this to help avoid it.

You don't even need those. React itself will warn you directly in the browser console

Re: Comparing Svelte and React

#224

Post by littlecranky67 »

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…

This is nothing Frontend or JS specific. I've been around in BE (c#) long enough, and the "new shit" adds also terminologies that have nothing todo with C#/.NET itself and were basically "unknown" to any C# developer (or Java for that sake) 10 years ago:

- Dependency Injection/IoC - Containers, Resolvers, Scopes - Microservices (Circuit Breaker anyone?) - DDD + CQRS (i could fill a whole page with terms coined by those) - Mediator Pattern etc.

If you buy into a certain techstack, it will always bring associated patterns that have nothing to do with the original language/idiom.

Re: Comparing Svelte and React

#225

Post by kabes »

selfmodruntime wrote: post #221
kabes wrote: post #216

I never got the appeal of state management in React. People now seem to rave about Svelte, because you can just do 'count += 1'. But you could do exactly this already in Angularjs (which, just like Svelte, had a template language). Ok, Angularjs worked different under-the-hood than Svelte. It was a dirty checking loop instead of compiler-generated change indicators, which didn't scale as well. But other than this sca…

It's because react works with immutable state. Svelte instead opts for compile-time magicks to handle state. Angular uses decorators to manage state. This has turned out to be an unwise descision because javascript decorators have changed in spec since then.

I was talking about angularjs. not angular.

And like I said, react promised immutable state would solve a lot of problems, but it turns out you lose a lot of convenience as a developer while not gaining that much.

Re: Comparing Svelte and React

#226

Post by littlecranky67 »

avodonosov wrote: post #52
ljm wrote: post #25

Earlier quoted context omitted.

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…

Novel - not, in my opinion. How to do GUI is known from 1970-ties. Today's single page apolication frameworks slowly re-discover the wheel. It is funny to observe.

The very important difference is that we do distributed systems now (admitted, X originally was also distributed, but only the drawing/events parts, not on the data level). A SPA is a distributed system, with all its drawbacks & pitfalls.

If you ever did VB development in the 90s, you will know how easy it was to get a basic app running with those fancy Drag'n'Drop RAD tools. But there was no networking, everything worked offline. But then came the web and the networks, and now everything has to be a distributed system.

Re: Comparing Svelte and React

#227

Post by skvark »

acemarke wrote: post #88
alfonsodev wrote: post #62

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

Redux Toolkit is great and removes most of the usual Redux boilerplate which seems to be the most often used argument against Redux. Additionally, I usually use a function which uses createEntityAdapter, createSlice and createAsyncThunk methods to create Ducks bundles for each REST API resource automatically. As a result I get all async action creators, reducers and basic selectors for some REST API resource with a couple of lines of code.

Re: Comparing Svelte and React

#228

Post by littlecranky67 »

selfmodruntime wrote: post #222
ljm wrote: post #25

Earlier quoted context omitted.

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…

So what. I've been a backend dev before I turned to front-end and web stuff. React has like a dozen top level functions and approaches. No backend project I have ever seen was this simple to program. How much more simple does it have to get before people stop complaining?

No-Code is what they look for :)

Re: Comparing Svelte and React

#229

Post by kabes »

padolsey wrote: post #219
kabes wrote: post #216

I never got the appeal of state management in React. People now seem to rave about Svelte, because you can just do 'count += 1'. But you could do exactly this already in Angularjs (which, just like Svelte, had a template language). Ok, Angularjs worked different under-the-hood than Svelte. It was a dirty checking loop instead of compiler-generated change indicators, which didn't scale as well. But other than this sca…

What perf issue have you spotted with hooks? My biggest bugbear with them is just the sheer cognitive exhaustion that comes with figuring out "when" stuff is happening -- especially if you're implementing a bunch of your own useEffects. I remember just sitting there bemused by the complexity -- and the difficulty of debugging ostensibly simple state changes. I (truly!) miss the good old days of intuitely doing count+…

For example passing down a function which is not memoized can trigger a bunch of non-obvious side effects lower in the component tree when your component re-renders. I feel like with hooks/functional components I need to think way more about stuff like that.

Which comes down to your point: cognitive exhaustion. The promise of hooks and functional components was that it would make things 'easier to reason about' (among other things). But we all know now that this is just not the case in practice.

Re: Comparing Svelte and React

#230

Post by littlecranky67 »

michaelpb wrote: post #31
ljm wrote: post #25

Earlier quoted context omitted.

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…

Not to mention terms that do come from a general programming paradigm, but have a very narrow practical / framework-specific use within frontend dev that makes it even harder for beginners (e.g. "thunk" might be a general term, but I bet most people googling it are just trying to get some Redux tutorial to work, and will end up going down dozens of rabbit holes trying to understand the general concept) I really hate…

The mistake those beginner make is listening to some evagelists that will tell them they need everything, from React, TypeScript to Redux, routers, thunks/sagas etc.

As a beginner, you should start with plain JS/TS. When you dealt with the hell of manipulating DOM elements all over the place and untraceable UI updates after hours of debugging, you should move on to some UI library. Only then will you understand and see what problem it solves. Then you should go with React, but not hooks or redux. Use plain old classes. When you felt the pain of distributed mutable state all over place, you will be open to hooks or redux etc. Still, do not add a library for thunks. Only after you realize how much boiler plate code you write to deal with async stuff, you will see a value in the added abstraction.

A beginner should start simple, and really feel the pain. Only then will there be an "a-ha!" moment where you can judge if a library/framework actually helps you and provides value.

The biggest issue in FE world is people proclaiming some given conglomerate of a library/framework soup as the silver bullet to all problems.

Post reply on HN