Svelte 5 Released

I don't understand how React is so popular, still. With Svelte and Vue, I don't think anybody should do a new project with React.

I can’t speak for the majority, but for my team it’s because it’s not worth the distraction. We’ve got years of experience and tooling and “tradition” with one approach. Why do we want a second?

It’s also just not an interesting issue. In my experience, the actual coding (and later maintenance) of a web application is the least challenging, least interesting part of the project. At that stage, all the interesting problems have generally been solved in workflow, process, data structure design and general de-risking. Classes? Hooks? Binding style? Tabs or spaces? I really couldn’t care less. Just be consistent so you can all build and develop skills together.

I admit that when I was younger this kind of thing seemed to matter to me. I dunno if it’s because I’m now more focused on big picture or if I’m just tired and don’t care anymore. Maybe both!

I'm building a React app from scratch and since I have control this time, I'm following a strict pattern: all data manipulation (∆) happens outside of React components, and the components themselves are as lightweight as possible.

I feel like this change suddenly makes everything about the React paradigm make sense - it can be just a view layer, and when used that way, it works great.

But I can't say I've ever worked on a React app that followed this this pattern before. Perhaps this is React's fault, or perhaps it would be the same with every framework once an app gets big enough (in my limited experience with Vue and Angular, those didn't seem any different from React in this regard).

(∆) By data, I mean the data that is fed into the app from the database. There's a certain amount of data generated internally by components, I write small functional functions at the top level or in the same folder as the components to handle that, but not placed inside the component itself, which is common practice but ends up creating these huge hard to parse components.*

This sounds familiar. We know React, and while I’d dearly love more automatic performance, it’s not worth introducing a whole bunch of new complexity to do that.

I think that’s a smart approach. You might be interested in https://starfx.bower.sh which has similar design goals

I really like this anecdote, and I very much think you're speaking for a lot of people here. Tech is tooling. Some people make a hobby out of the tooling, others merely use the tools to build something.

It's totally valid to make a hobby out of tools (e.g. motorcycles), but it's easy to end up with all sorts of highfalutin' opinions about how the tools must or must not be used, that hinge on minute distinctions that fundamentally don't matter to someone looking to merely use them as tools.

From users' point of view, they only care about the performance really

Some e-commerce apps use React in WebView on Android and the apps will become unresponsive after visiting several product pages (more than 10 probably). They have to be force closed and opened to be used again

Yeah. And that’s basically the thing, right?

If I need to hit a certain performance because the business has concluded that it matters, and React can’t get us there, then I’m likely switching to Svelte or whatnot.

If none of my tools can do the job, I’m going to the store and buying a new tool and learning how to use it. I don’t feel ideologically attached to my palm sander. I’ll buy a belt sander if the palm doesn’t make sense for a task.

This is why I think react is still the best: In react you only deal with plain values. You never have to worry about wrapping a value in an observable or calling it in a function with a tracking context. Or .valueing it or whatever.

It looks like Svelte 5 is trying to make signals "disappear" but they still leak through. Reading the docs about shallow $state.raw vs deep proxying the default $state rune in svelte 5 makes me really appreciate the plain value and simpleness of react.

The react compiler will make the biggest headache of react go away, that being useMemo, memo, and useCallback.

React has the biggest and highest quality ecosystem. It has the smartest and brightest people in this space working either on react directly or in the immediate surrounding ecosystem. React has by far the most $ backing it.

Looking ahead I think react makes the best immediate AI target. Long term AI will go past react but while we still want to vet the code with humans react will probably be the best target.

Thought of another important reason why I love react:

- It has the best TypeScript support of any framework. Partly because MS is so invested in react the typescript team is very incentivized to have good support for them.

Oh yeah and this one is imporant:

- React Native with expo is the best way to make cross platform mobile apps. Yes its better than Flutter.

But your tools can't do the "performance" job right now, it's just that there is enough "friction" in the management/decision chain that it may not be decided on by "the business".

Though the desire to improve without external pressure could be considered ideological

Having used both a fair bit I much prefer Flutter. RN always felt like fragile pile of hacks to me with extremely brittle builds. Flutter feels like a stack engineered for purpose from the ground up and the tooling, ecosystem and performance have been consistently great.

Also RN has no real desktop app story.

Hora do you know that? I've seen really well optimized React apps and very poorly optimized Svelte apps. It's not like using Svelte magically makes performance good. Just like using Unreal Engine doesn't mean that a game is optimized. You just have different, maybe better, tools to improve performance.

> all data manipulation (∆) happens outside of React components,

I do something similar. State and its management lives outside the React components, which only consume this state via hooks. Keeping the state in chunks, and outside the tree lets me access a chunk of state only in the components that need it.

This results into minimum amount of re-rendering of components. Component code also looks cleaner and easier to read.

My workplace will adopt React for the sole purpose of being easy to find new React developers as it's the most popular library for reactive UI.

Everyone at the company knows a little React already. We are not good at it and we don't like it, but I guess for them it's a safe bet.

This has the essential bits of one of the most common critiques of React, its claimed slowness.

As a seasoned React dev of 10 years (aka a heavily biased person) I would claim 99% of this issue is better explained by: - React is the most popular choice => used in all kinds of places by all kinds of people - with varying skill - under all kinds of business pressure to deliver features => a lot of slow apps in React

I'm not saying a case for specific areas where React is slow can not be made, these anecdotes just don't do it for me.

We do have the synthetic framework benchmark, where React is indeed one of the slower candidates. I have yet to build an app with functionality akin to adding 10s of millions of rows, so it has not been an instructive decision driver for technology choice. The project I have been working on (also in Vue, Svelte, SwiftUI) had their bottlenecks in other places.

The non-synthetic argument in favor of React passing the performance test is billions of people using FB, Insta, Netflix, MS Office (to name some of the big React apps), about which I have not much in terms of complaints.\ This is usually where the second big React critique kicks in: it being a Fortune-500 framework. That has not been my non-fortune-ate experience.

I think a residual argument can still survive this: I/my org has not been able to write performant React. I'd be curious to read someone go into the details of where it broke down and how switching view layers solved for that specific situation (I hope that does not read cynical, I'd really be curious).

I think being able to use React Native and Expo are a huge differentiator.

This many years on and we are still trying to figure out state management. Wasn't React designed for the view?

There was a sweet spot in the past when React was actually simple and clean.

I really do want to escape it these days but quite frankly every frontend framework is the same and they are just shitty in different ways, not really better than React.

Haha, reminds me of 20 years ago when someone said they are building a PHP app from scratch and this time they won't have HTML, business logic and SQL all in one .php file. We learn as we go ;)

My React fomula is React + MobX, keep the hook use to minimum, single state object per component (the classic React way), do not bother with server components at this point, you should be fine.

The marketing has kept changing.

I have always found state management easier in React if I keep it out of React.