Hacker News Reader

Comment by slopinthebag | Hacker News Reader

> I’ll focus on React and Redux in some of my examples since that is what I have the most experience with, but much of this applies to other frameworks and to JS-heavy approaches in general.

That's not a fair assumption. Frameworks like Svelte, Solid, Vue etc have smaller bundle sizes and rendering speeds that approach the baseline vanilla-js cost.

I'm all for criticising Javascript, but moving everything to the server isn't a real solution either. Instead of slow React renders (50ms?), every interaction is a client-server round trip. The user pays the cost of the paradigm on each interaction instead of upfront with an initial JS payload. Etc.

View on HN

Yeah this article is only about React. But it makes sense that someone would think this way because many dev's think JS web apps==react only.

The problem is react is "good enough" for most cases and the performance degradations happen slow enough that the devs/project leads don't see it until it's too late and they are already overly invested in there project and switching would be too compliated/costly for them.

Svelte/kit and properly optimized packages solve almost all of the "problems" this article tries to bring up.

To be fair though, even with Svelte et al bundle sizes can balloon quickly when using UI toolkits and other libraries.

Yes but this is again nothing to do with svelte.

This is just how Node works, it's not a compiled language and you are not tree shaking all the components from libraries so this is bound to occur.

You can solve this by making your own libraries or just copying the individual source code for specific components into your project instead of including the whole package.

With sveltekit(and maybe nextjs aswell) you are only serving the necessary files to the client instead of including full library source code.

Wouldn't tree-shaking take care of this? i.e. If I only use 'Button' (from the UI library), nothing else should be included in the (production) bundle.

Not in practice, because these UI libraries usually have many intertwined interdependencies. <Button /> probably still imports all of the context providers, which also import their own dependencies, etc. So you end up including half of the library if not more just for a button, but if you use multiple components from the library the cost is amortised.

And typically if you're just using a single component it's one that is more complex than a button, like a popover or colour picker. Which then pulls in other components, etc.

Plus Redux is horrible for performance, slows things down and overcomplicates everything.

I never understood why state management is overcomplicated in React. For some reason most people use something like Redux which has a very unintuitive API. There are other state management packages available that are so much easier to use and understand, like MobX.

https://github.com/mobxjs/mobx

To shine a light on the mystery, before React had (a) hooks and (b) a stable context API and (c) tanstack-query/react-query or GraphQL - state handling WAS a mess. Thats when redux/mobx etc. made more sense. Try to build something with a pre-2019 version of react and you will understand the need.

Redux is an implementation of the elm architecture (Tea) which is used for UI state in a lot of languages and frameworks. JS/TS is just not a very ergonomic language for it so it becomes painful quickly.

https://guide.elm-lang.org/architecture/

Is this 2019?

> Instead of slow React renders (50ms?), every interaction is a client-server round trip.

This is true only if you use zero javascript, which isn't what the article is advocating for (and even with zero javascript there's quite a bit of client-side interactivity built-in to CSS and HTML). Besides: in practice most interactions in an SPA also involve network round trips, in addition to that slow react render.

Reply on news.ycombinator.com