Hacker News Reader

Comment by jemmyw | Hacker News Reader

> 2. The state of the art in SPAs moves so quickly it feels to me like you have to spend a significant amount of your productive time staying in place on the treadmill before you can even consider creating value for your end users.

I think this is no longer true, not how it used to be. Of course, you CAN chase the latest cool. However, if you stick with one of the more popular libraries then things should be stable. My react code now doesn't look very different to my react code in 2019. They've added new things but I haven't used them.

View on HN

> My react code now doesn't look very different to my react code in 2019

Server components, Next application directory breaking emotion for styling, stricter rules for hooks, the compiler breaking change tracking libraries such as MobX removing the need for useMemo and similar. This is just off the top of my head in React land.

You're complaining about MPA. Maybe if you choose SPA with vanilla React you would've felt that for the last 8 years there's been a flurry of conversation and innovation that's specifically not about SPA. The conversation around SPA has been frozen for nearly a decade.

Unless maybe you want to start talking about CRDTs? But that's kind of niche, and CRDTs are actually an old conversation, one which started before React was first released. That should give you a sense at the pace of conversation for SPAs.

Also, because next broke emotion, toolkits such as Mantine broke backward compatibility in order to move off of emotion, so second order instability effects still affect SPAs

react compiler breaking mobx is purely spa; progressively stricter rules of hooks too. Its bad.

React Compiler is in true beta™ mode at the moment, and you receive plenty of warning. It's basically not released.

If you have a very large project which uses MobX, I don't think the amount of warning matters. You'll most likely have to (eventually) completely rewrite large amount of code, to the point where it might be easier to migrate to SolidJS.

If you have a large project then it's your victory or fault for whatever comes of using software marked as not ready. The React team has been absolutely clear that it's not ready.

On an aside, SolidJS has been taking a huge momentum hit recently, I think the drop in downloads is a lagging indicator. It's not an easy space, I love SolidJS and recognize that Ryan Carniato likely took a career hit to work on Solid, but my bet is that Solid will fail to catch critical mass. Really sad as I love the Solid experience.

https://npmtrends.com/astro-vs-solid-js

> Server components

Nope, not using.

> Next application directory breaking emotion for styling

I'm not even sure what this is.

> stricter rules for hooks

I've always been strict with the code, no changes have been required.

> the compiler

The compiler is still in beta, I've not even tried it, let alone let it near production code. I'm not that excited by it tbh.

So you've pretty much confirmed what I said. None of these things were that important to jump on.

Important or not, libraries you depend on may jump on it and abandon backward compatibility

They may. One of the promises of the compiler though is that you don't need to change how you write your code. It will determine how to run.

That promise doesn't really make sense to me - although partial compilation will likely ameliorate most migraiton pain for library dependencies if they come pre-compiled with the compiler.

Code written with the react compiler in mind will inevitably be MUCH slower without the compiler, as its not going to manually add any memoization. Likely to the point where its not going to be usable without it.

Reply on news.ycombinator.com