Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If not React, then what?

infrequently.org

Post reply on HN
Print view View original

441–450 of 756 posts

Re: If not React, then what?

#441

Post by johnfn »

ramones13 wrote: post #404
johnfn wrote: post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

To your third point - the author would recommend doing research and prototyping with all the options you might consider based on your use-cases. He actively avoids being prescriptive in generic contexts like this because he wants to avoid arbitrary dogmatic solutions (like React tends to be). Source: I work closely with him and have been frustrated with this stance until I saw people using Next and Remix for things l…

(Sorry, somewhat copying this, since I responded to a similar point elsewhere.)

This is not practical advice for the vast majority of software engineering teams.

Most teams do not have the privilege of being able to do research and prototypes across multiple options, at least in a way representative of what their final product will look like. Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you were to run 5 different prototypes on A, you're going to be a bit upset when you end up at A' and you're likely to run horribly technically aground when you truly find the right thing to build.

Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.

Re: If not React, then what?

#442

Post by apatheticonion »

In my travels I have found React to be, generally, a poor choice for most applications - particularly in projects that have contributions from many developers with varying levels of experience.

While it _can_ be super fast, in practice, it requires quite advanced knowledge of React-isms to get it there. Those React-isms require more code with increasing complexity, combine that with contributions from developers that have varying levels of experience and you end up with spaghetti code.

Consequently, I have yet to walk into a new role where the React code isn't a dumpster fire.

In a way, React feels very much like writing raw C - it has a lot of power to be fast but most developers aren't as smart as you (joking, sarcasm) so unless you're the only contributor; you're better off using a higher level language with fewer footguns.

Modern Angular, for instance, is amazingly ergonomic and the opinionated approach makes it difficult to drag the project too far down the unmaintainable rabbit hole. The compiler handles optimizations for you so you don't need to worry about render cycles or how a functional component loops around - making it friendly (in theory) to developers with varying levels of experience.

These ergonomics fall apart when developers try to make Angular projects "React-y" with tools like ngrx but for me; the biggest downside is that you have no control over the tooling (test runner, TypeScript version, bundler, etc). That is the only reason I avoid it in personal projects.

Svelte and Vue on the other hand suffer from similar problems in that they are fantastically ergonomic, but use custom file formats with bespoke compilers that are difficult to integrate with other established tools (TypeScript, linting, formatting, testing).

One thing that saddens me is that toolmakers (specifically TypeScript) sleep on opportunities to have much better front end frameworks because they don't provide the capability to extend the LSP and transpiler.

For instance the inclusion of Rust-like compiler macros in TypeScript could enable projects like Vue, Svelte and Angular to integrate directly into the language without the need for bespoke compilers and adapters to connect to tooling.

That way, much like how TypeScript has a built in compiler for JSX, Vue could integrate their template compiler within TypeScript rather than using external tooling that targets .vue files - example:

    export const HelloComponent = {
      tag: 'app-hello',
      template: vue!(Hello {{name}})),
      data: () => ({
        name: "World"
      })
    }
And Angular

   class AppComponent {
     static tag = 'app-component'
     static template = angular!(Hello {{ name }})

     #[model]
     name = 'world'
   }
Alternatively, the completion of wasm would enable the use of languages with the appropriate feature-set required to build maintainable, multi-threaded & performant web applications - but at this point that seems like a distant pipe dream.

So ultimately, while React isn't really a great choice for web applications, it's attained a jquery-like status where it's not really good but the alternatives are worse so you kinda have to use it.

Re: If not React, then what?

#443

Post by phist_mcgee »

davedx wrote: post #213
lopatin wrote: post #143

I'll continue using vanilla React, for the same reason I use Java: it's reached the coveted "boring technology" status where it's mature, stable, fast enough, and has a huge community, resources, and ecosystem. I won't let go of that easily. However, this is a pretty epic rant nonetheless.

Amen. I adopted react for the first time in around 2014. It’s now “boring” and various predictable groups of people are desperate to replace it with /something/, while I’m getting on with my job of delivering software using a nice set of reasonably standardized tools, not having problems hiring, and just generally enjoying life. Long may the reign of typescript, nodejs and react continue.

My god.. A sensible take?

Re: If not React, then what?

#444

Post by phist_mcgee »

MarcelOlsz wrote: post #145
lopatin wrote: post #143

I'll continue using vanilla React, for the same reason I use Java: it's reached the coveted "boring technology" status where it's mature, stable, fast enough, and has a huge community, resources, and ecosystem. I won't let go of that easily. However, this is a pretty epic rant nonetheless.

You're going to love Vue. Took me about half an hour to switch and be productive and never looked back. I've switched multiple teams/devs to it as well. If not just for the devtools experience. I switched right before all the messy React stuff started getting released.

I think i'm passed splitting html, js and css into separate files. Having logic, presentation and styling all in one spot addressable via js and jsx feels so much more ergonomic for apps of reasonable complexity.

I will say though that solidjs seems like an improvement on react though.

Re: If not React, then what?

#445

Post by phist_mcgee »

xcrunner529 wrote: post #370
aerhardt wrote: post #166

Earlier quoted context omitted.

But why would OP or I switch away from React when we believe it's mature, stable, fast enough, and has a huge community, resources, and ecosystem? And perhaps most important of all: it's the tool we know.

Because it’s not and people hate these sites…I’m sorry…”apps” you make.

I'd say some SWEs hate the sites. The majority of laypeople don't care at all.

Re: If not React, then what?

#446

Post by hmeh »

satvikpendem wrote: post #424
hmeh wrote: post #252

Earlier quoted context omitted.

You literally cannot. You can bake two cakes. You can’t have your cake and eat it too. Server and client rendering? You must concern yourself with both. The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful. CSS-in-JS? I’ve used it and fought for it. Have you ever looked at the css output? That’s not a cake I’d want to eat. Compare it to a codebas…

> You literally cannot. You can bake two cakes. You can’t have your cake and eat it too. It is a common saying, not to be taken "literally." > The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful. Better than before with pure server side solutions like Rails or Django, however. I use RSCs and they work just fine, because you are using TypeScript…

I know what analogies are. I was extending yours. I was just saying that there are tradeoffs. You don’t think there are, and that’s fine. I can see them and I make my choices accordingly.

Re: If not React, then what?

#447

Post by oefrha »

peutetre wrote: post #365
harrall wrote: post #297

I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…

> React will be unseated like jQuery got unseated when someone makes something that looks nicer. The solution is WebAssembly. Make your code look as nice as you want, as readable as you want, in whatever language you want. No more JavaScript limitations.

Sure, I wrote nice code in Go, the language I want, and compiled to wasm. The most simple apps were 2MB+ of wasm compressed, browsers won’t even reliably cache blobs that large, got evicted all the time. And 100KB of react is bloated? Lol wtf.

Don’t tell me “whatever language you want” means “whatever language named Rust you want”, thank you.

Re: If not React, then what?

#448

Post by satvikpendem »

hmeh wrote: post #446
satvikpendem wrote: post #424

Earlier quoted context omitted.

> You literally cannot. You can bake two cakes. You can’t have your cake and eat it too. It is a common saying, not to be taken "literally." > The best frameworks will not perfect abstract this for you. They can’t, it’s leaky. When the cracks show, it will be painful. Better than before with pure server side solutions like Rails or Django, however. I use RSCs and they work just fine, because you are using TypeScript…

I know what analogies are. I was extending yours. I was just saying that there are tradeoffs. You don’t think there are, and that’s fine. I can see them and I make my choices accordingly.

I never said there weren't tradeoffs, just that RSCs enable greater functionality than before, such that one can "have their cake and eat it too," but it's not meant to mean that there are only two cakes in this entire analogical universe. Other frameworks (ie, cakes) have their own tradeoffs.

Re: If not React, then what?

#449

Post by crabmusket »

dcre wrote: post #416
crabmusket wrote: post #376

Earlier quoted context omitted.

I think most responses to his posts are missing that this is the most important part: > In practice, the only thing that makes web experiences good is caring about the user experience — specifically, the experience of folks at the margins. Technologies come and go, but what always makes the difference is giving a toss about the user. > In less vulgar terms, the struggle is to convince managers and tech leads that the…

The problem is that this fundamental claim undermines the entirety of the argument. You can build a good web experience in React if you care about the user experience.

I don't find the argument to be undermined by this. From my perspective, his strong statements against React read as deliberately lacking in nuance just like the conventional wisdom of "just use React and don't think too hard about it". It's a deliberate overvorrection away from the status quo. There can be room for nuance once the default assumption has been shaken.

I get why people are offended or find it unhelpful. If you read through his Reckoning series, I hope you'll understand some of the righteous anger he has for organisations that fail to serve the user, even when public service is their explicit purpose.

Blaming it on React may not be the most effective strategy. Who knows. But I still find value in the message.

Re: If not React, then what?

#450

Post by peutetre »

oefrha wrote: post #447
peutetre wrote: post #365

Earlier quoted context omitted.

> React will be unseated like jQuery got unseated when someone makes something that looks nicer. The solution is WebAssembly. Make your code look as nice as you want, as readable as you want, in whatever language you want. No more JavaScript limitations.

Sure, I wrote nice code in Go, the language I want, and compiled to wasm. The most simple apps were 2MB+ of wasm compressed, browsers won’t even reliably cache blobs that large, got evicted all the time. And 100KB of react is bloated? Lol wtf. Don’t tell me “whatever language you want” means “whatever language named Rust you want”, thank you.

Ah, so you want to use TinyGo. Makes smaller binaries:

https://tinygo.org/

Post reply on HN