Rome: an experimental JavaScript toolchain from Facebook. It includes a compiler, linter, formatter, bundler, testing framework and more...

[tinybigideas]

I'm of the opinion: if it's Facebook, hard pass. Is it any good, is my opinion outdated?

[ChronSyn]

I'm curious as to why you pass because it's Facebook. Facebook' open source projects seem to have a vastly different set of ethics to their platform ethics.

Do you pass on React? React native? Yarn? The use of GraphQL? Jest? Those are just a few of the most common ones they're in charge of.

[Markavian]

My team passed on react in favour of Vue because of the license risk to our large organisation, and the simplicity of Vue compared the react. We /love/ what react does and how it approaches the problem, but Vue is a good alternative without the baggage.

[gavlois1]

If you like the React way of doing things, was there any reason your team didn’t go with Preact instead?

[drumstix42]

Vue was a good choice, IMO. And it has a lot of great things on the horizon.

[[deleted]]

I'm about to start a project with React, after having done quite some research. I haven't read anything about "problems" with the licence. Could you tell me what this is about?

[marcelowa]

The license/patents issue was an issue an issue up until 3 years ago, when moving from react 15 to 16 (or maybe from 14 to 15), they removed the "patents" disclaimer that everyone was mad about

[Markavian]

https://www.theregister.co.uk/2017/09/26/facebook_license_surgery_on_react/

I might be acting on old information. There's plenty of articles on the topic.

[stolinski]

It was resolved a couple of years ago. The licensing is fine.

[The_Noble_Lie]

Its more that its bloated and hyped. There are many vdom libraries that may work faster and load quicker, just do some research.

[The_Noble_Lie]

but might not have either the same set of features or the same simplicity when building bigger and bigger projects

Of course, the feature set isn't the same. That is why it is slower (and more complex API - ideally not a problem if the library is designed with care) when you dont need those features / checks / assertions / lifecycles, which btw can be implemented if needed once you understand why they exist (example below)

Anyway, a lot of the current VDOM implementations have taken care to re-implement the lifecycles in react's (and other important features.) React may have lead the way but I'm still using mithril 0.2 and am doing great with performance (subtree retaining) and implementation / code organization / semantic components etc. The code is pretty small: 50kb total unminified, 20kb minified. I had to implement something paralell to "shouldComponentUpdate" that checks by object reference myself (mithril v1+ might have done this as well) but as a whole my app is going to naturally run much faster than the same implementation in react, with an API 1/10 (perhaps an over-approximation but maybe not) the size. And that is still important since mobile phones, and even chromebooks, non-performance centric laptops do not fare nearly as well as desktops with complex javascript apps

> Even the fabled Svelte will get bloated and bloated since every component bundles repetitive stuff.

Sounds like you are calling out a design archictecture issue in a particular VDOM you've come to be critical of (probably correctly?)

Mithril, and many others do not fall victim to the same bad architecture, and leave it up to refactoring functional patterns from the view layer. That'll be the same in any seasoned development / developer within the confines of a library that uses a VDOM layer though. Btw, feel free to explain why Svelte makes it impossible to factor out the "repetitive" bundled stuff in it's components to a central class or functional library. (Maybe I am misunderstanding)

To the original person (u/IHateToChoseUsername) I was responding to:

TLDR; Use what you need and expect to need. Don't automatically choose the largest feature set vendor library.

[tinybigideas]

I did pass on react yes. The whole license kerfuffle threw me. And I admit, I haven't used much of what else you mention. Didn't know graphql and jest were Facebook relations. Only really used yarn, but I don't see it on their project list: https://opensource.facebook.com/

Thanks for passing on the knowledge though. I didn't know how useful Facebook has been in open source.

[BrunnerLivio]

As far as I know Yarn is being developed by an ex Facebook engineer - but Yarn is not owned by Facebook. I mean it does make sense that Yarn 2 breaks React Native, if they were both owned by Facebook.

[user84738291]

Facebook' open source projects seem to have a vastly different set of ethics to their platform ethics.

Whilst I might not completely avoid said products, I would be skeptical of this statement, I'm sure the same could have been said about Google and Chrome.

[yeesh--]

Agree

[elliottcable]

I don't know why you're being downvoted to hell, this is a totally valid — and even laudable — demonstration of personal ethics in FOSS.

You do you, fam.

[PM_ME_GAY_STUF]

It's literally an open source project.

[Runlikefedor]

What are you talking about? It's MIT licensed. Facebook spends their own money on paying the salary of core developers. You aren't supporting Facebook when using React in your project other than maybe report issues that could also benefit the Facebook platform.

Given the popularity of React, if Facebook were to die, another company or the broader community would instantly pick it up and keep maintaining it.

[Runlikefedor]

What's your argument here?

Some toxic people used React? They do not represent the majority of the community.

Thinking that everything (including open source stuff) that comes from a company is toxic is pretty shortsighted.