4 ms·
> Vue is like 10x better imo That's very much here and there, and ridiculous. Vue offers an interface that is extremely heavily transpiled and modified before
by nawgz 4y ago
> Vue is like 10x better imo
That's very much here and there, and ridiculous. 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, making performance analysis quite difficult. React offers a thin layer on top of JavaScript - look up what JSX actually does if you feel the need to contest this - and offers clear semantics on how a component will evolve over its lifecycle. Plus the TypeScript integration is way better.
So now back to your point: what are you criticizing about React? That you want the batteries included? That you think the vDOM is too heavy? If you're praising vue, I can't imagine you have a single legit criticism
> too many folks' livelihoods is directly tied to React for a serious critique of the monstrosity it turned into
If other libraries were actually as good, they would take over developer mindshare. They're too thick and with too much magic you can't control, React is on the exact opposite end of that spectrum with being thin and unopinionated outside of its core semantics. Which is the right end to be on, and the reason it is winning the developer mindshare war. Not because of sunk cost fallacy.
- dvt 4y agoI 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.
- nawgz 4y ago> 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?
- dvt 4y ago> 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.
- nawgz 4y agoI’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.
- aabbcc1241 4y agoI 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.
- nawgz 4y agoThere 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
- robertlagrant 4y agoI would walk it back because we're talking about JavaScript, not anything important enough to get worked up about with someone.
- oorza 4y ago> 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.
- acemarke 4y agoFWIW, 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.
- irrational 4y ago> 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.
- Shared404 4y agoCries in plan9
- spartanatreyu 4y ago> 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.
- girvo 4y ago> 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.
- nawgz 4y agoOh 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.
- spartanatreyu 4y ago> 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.
- ROARosen 4y ago> 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 https://vuejs.org/guide/extras/render-function.html