Hacker News Reader

> React offers a thin layer on top of JavaScript

I think you've completely missed how much "magic" react really does behind the scenes. I guess the most recent example being strict mode and confusion about why console logs are appearing twice in the console when a component only appears to have rendered once.

> If other libraries were actually as good, they would take over developer mindshare.

History shows us that out of two options, the early option usually trumps the more thought-out option.

> I think you've completely missed how much "magic" react really does behind the scenes. I guess the most recent example being strict mode and confusion about why console logs are appearing twice in the console when a component only appears to have rendered once.

Though that decision was wound back, as it was the wrong one to make. The idea of "modes" in general was wrong-headed, according to the React team themselves.

Oh no, they rendered your component twice to make sure it’s idempotent, how magical!

Tell me where react uses magic instead of well defined semantics and maybe I’ll agree

> the early option

Angular and React were around at virtually the same time. A million JSX using libraries promising performance or DX have tried and failed to gain meaningful traction. Early adoption has nothing to do with it - React is the right abstraction for UI dev and is more terse and easier to reason about than any other framework today.

> Oh no, they rendered your component twice to make sure it’s idempotent, how magical!

The problem with trying to check if the component is idempotent is that React can't actually verify that the component is idempotent.

It could have a simple inconsequential non-idempotency like a console.log statement, a larger non-idempotency like pushing a request, or a complete non-idempotency like relying on non-deterministic behaviour and just happening to get the same result during the idempotency check (what's worse is that sometimes this is caused by invisible data races leading to heisenbugs).

Trying to check for idempotency in a language that has no language features for verifying pure functions is bound to failure right from the start.

> Angular and React were around at virtually the same time. A million JSX using libraries promising performance or DX have tried and failed to gain meaningful traction. Early adoption has nothing to do with it

Angular does not use JSX. AngularJS lost because it fell out of support. Angular lost because only enterprise developers trusted Google after the burnt bridge of AngularJS. While I would agree that React is mostly better than Angular/AngularJS, it didn't become popular based purely on its quality relative to Angular/AngularJS.

> React is the right abstraction for UI dev and is more terse and easier to reason about than any other framework today.

Terseness does not equate to readability nor comprehensibility. Speaking of alternatives with better DX, Vue looked at the successes and failures of React's Hooks implementation and DX and improved on the model with it's own form of magic: Vue 3's Composition Api, meanwhile SolidJS removed the magic all together while making the code function how developers expected it to.

> If other libraries were actually as good, they would take over developer mindshare.

I don’t think that is true. We’ve seen plenty of examples of superior technologies not being adopted for various reasons.

Cries in plan9

> Vue offers an interface that is extremely heavily transpiled and modified before it actually resembles code that can run on the browser, and uses an entirely magic (read: opaque) rendering system

Not entirely true. If you're looking to code that "resembles code that can run in the browser" without that much "magic", Vue has an interface for directly declaring render functions, also for the possibility of using JSX.

See doc here: https://vuejs.org/guide/extras/render-function.html

I don't want to get in a whole Vue vs. React thing here, and I'm no megafan of Vue, either, but I just think it's a lot better designed than React. In fact, I mostly still use React because, hey, just about everyone knows it.

> If other libraries were actually as good, they would take over developer mindshare

This is incredibly naive. React's sole success relies on Facebook heavily pushing it in the conference circuit. "How React Saved my Life" was the go-to talk title in the 2010s.

> React's sole success relies on Facebook heavily pushing it in the conference circuit.

LOL, yes, I started using React because I spend all my time at conferences, just like 100% of the millions of people that develop in React. I'm the naive one, eh?

> LOL, yes, I started using React because I spend all my time at conferences, just like 100% of the millions of people that develop in React. I'm the naive one, eh?

You're using it because you probably Googled "good javascript library" and got sent to a blog, you saw it in a talk on YouTube, or because your coworkers/friends are using it. And React has a lot of content because it was heavily pushed in the conference circuit, where people live blogged, tweeted, and so on.

I don't even think my point is particularly controversial, companies literally do this all the time (Angular was pushed almost as hard). Facebook just happened to also be a very developer-friendly and hip company last decade, so folks really drank the Kool-Aid.

I’m in disbelief you think a decade of one front end framework dominating software engineering of all fields is due to advertising, and not because it presents an incredibly powerful abstraction with a terse interface requiring far less magic than any other major web front end library. Pure disbelief.

I think the OP means both quality and promotion are important to a frameworks adoption.

Promotion helps it to be known, tried, given feedback, improved and loop to grow.

There is no discussion of quality. The claim is nakedly that React isn’t at the top tier and it owes its success entirely to marketing and not at all to quality. Developers have been drinking koolaid for years.

Show me where they said otherwise and I’ll walk back my tone; I don’t expect to

I would walk it back because we're talking about JavaScript, not anything important enough to get worked up about with someone.

I will plainly speak however I wish to non web engineers telling me I drank koolaid in my selection of libraries, and that marketing is the only driver of the general decision making around such libraries

It’s just plainly absurd. In front end, it went from Java -> JS transpilers to vanilla JS and jQuery to ideas to Knockback and then finally to React and that generation of frameworks. Somewhere in here TS became non negotiable and so we write strictly typed front end code on top of high quality libraries.

Meanwhile, backend guys come in and act like they know about how this went, it was just Facebook and Koolaid - those web guys don’t think for themselves. They were dictated to.

What a joke.

> backend guys come in and act like they know about how this went

I'm getting the impression you think this is West Side Story: Software Edition, and that you think other people are aware of this. It's just some individuals talking about a very abstract topic. Nothing to get upset about.

I get very upset at the idea that Koolaid dictates front end development. It’s the same backwards superiority from backend devs as I saw a decade ago, except their languages and frameworks have barely meaningfully progressed and they still like to shit on UI dev, like their work is somehow more valuable than it.

> the same backwards superiority from backend devs as I saw a decade ago

Again, even from observing you in this thread you've decided one comment represents all backend developers. You probably made the same mistake a decade ago. It's not us vs them. It's just some individuals talking.

I actually have developed web UIs for 9 years professionally and remember evaluating Angular1 vs React. In angular I built an app with tons of great features, but React was far more terse and honest about how things work because there were not really big DSLs or magic features, instead you built trees of JS objects that used the pretty thin JSX syntax to accomplish this. I admit JSX was of course exactly a DSL in some small ways but primarily it was just more terse and semantic.

When you think about major UI frameworks, the fundamental concept of composition is clearly key. State is the other idea at play, and their interrelation needs to have obvious life cycles to be predictable. React accomplished this as well in a very intuitive fashion that is also exactly as performant as you can wire a VDOM based approach to be. The react team’s foresight and rule based approach continues to be cutting edge with hooks, as they are more honest and terse than class-based components.

Finally, wiring up my favorite state library mobx gave me free render optimization and incredibly smooth code authoring capabilities all for one. This was around long before hooks, but still remains top tier as well.

Kool aid is both a poor drink and a poor representation of why I chose React and continue to enjoy building applications with it.

You chose to evaluate Angular1 vs React. But the information about React came to you based on Facebook's marketing of React...

The man wrote that koolaid was the decision maker, but I had literally built a high quality SPA in its main competitor before evaluating it and seeing for myself it was better. The “marketing” was being done by others like me on sites like this who had made the same decision because it was a simpler, better conceptual mode than the other web frameworks offered. Can’t believe your takeaway from “I professionally evaluated it” was “the marketing got you”, but that’s shockingly the level non UI engineers talk at thru thinly veiled superiority on threads like this.

> This is incredibly naive. React's sole success relies on Facebook heavily pushing it in the conference circuit. "How React Saved my Life" was the go-to talk title in the 2010s.

I was around when React took off. People may have been aware of it because of marketing, but every web developer I know wanted to immediately switch to it, even before class components, because it represented a fundamental paradigm shift in how web applications would be built, and it was self-evidently better than anything else anyone had thought to suggest.

The was a popular talk because _it was true_. React changed frontend web development from a tedious chore offloaded to the junior-most members of your team and elevated it to something everyone takes seriously.

It was a very, very long time before there was anything useful competing with React. Nothing really started to compete with the sheer volume of people who wanted to work with it until JSX proliferated across the frameworks. Just JSX alone was enough to convince people to switch to React.

FWIW, my initial interest in React had _nothing_ to do with Facebook at all :)

My first web app was built with Google Web Toolkit (GWT) back in 2011-12. GWT was a Java->JS compiler framework, and I used an additional library called SmartGWT that provided desktop-style widgets. It all did work, and let me use my existing desktop dev skills to build a web app. But, it also had a lot of pain points.

From 2013-15, I built a JS app using Backbone. Backbone's flexibility was great. On the other hand, it _also_ had a lot of weaknesses that I ran into over time. Nesting child views was really hard. There were a dozen ways to trigger events. You could use plugins to add functionality, but many were incompatible with each other. It had no rendering capability out of the box - you usually had to use something like Handlebars to generate HTML from templates (although in my case I used an addon called Epoxy for data binding). It had no lifecycle methods built in, although Marionette added that.

I started looking at React in 2015 because I wanted to rewrite that GWT app's client (no one else on my team by then knew GWT). I heard about React, started going through the docs and some blog posts... and saw something that solved basically all the Backbone pain points I was experienced. Natural composition of any components by passing props to children, children notifying parents via callbacks, automatic UI updates just by re-rendering, lifecycle methods... it was clearly just an infinitely better UI development paradigm than Backbone or GWT, and switching was a blindingly obvious choice to make.

For me at least, Facebook never even entered into it.