React is a good library. The component paradigm for building complex interfaces is nice. Tried React for a while and it gets things organized…
But it’s not the only tech that offers that feature and something did not feel right.
There were many good discussions about the pros and cons, so I will skip that.
Angular 2… well I tried It, liked some if it parts, other parts not so much.
It needs a lot of configuration and framework specific explicitness. Developer writing a production app rarely appriciates all the extra typing.
It can have that React feeling if it is up to preference, thanks to ES2015 template strings
And the main issue, what is the status of the project? As far as I know, nobody knows.
The main thing that does not get mentioned is, what does React do for the the developers in the long run and what does it do for the evolution of the native web?
Here is a excellent point in that regard by Rob Eisenberg:
"Clearly I am biased, but let’s think about this. (creator of the Aurelia framework)
For years we have been saying that it’s a bad practice to put JavaScript code in your HTML. But Facebook comes along and tells you that you must put HTML in your JavaScript code and we just accept that as ok? Clearly this breaks separation of concerns, makes it harder to work with a designer, destroys the declarative nature of HTML and forces you to work with a non-standard language: JSX.
The big problem with React is that it encourages developers to abandon web standards. First off, you aren’t using JavaScript, you are using JSX. Second, instead of learning the real DOM APIs you are working with their virtual DOM, which is different. You can even see that events and properties are named different sometimes. Next, you are asking developers not to invest in upcoming standards like Web Components, which actually solve the problems that React is trying to solve. Also, don’t use CSS, use a non-standard JavaScript API…never-mind that there are browser standards being worked on (such as ShadowDOM and Scope Styles) that allow you to do the same things, but without the non-standard library.
In recent years the community has developed a solid way to address browser issues. You work based on web standards. When the standard isn’t implemented, you use a polyfill. Any library or framework for developing apps should be built on top of that approach. We should not adopt libraries or frameworks that advocate, either explicitly or implicitly, circumventing web standards or throwing them out entirely. We should endeavor to progress the native web.
As web developers, we need to think very carefully about the consequences of adopting various libraries or frameworks. We should adopt those which are based on standards and committed to them.
Recently, I’ve had conversations with developers who work on IE and Firefox. Both seemed to indicate that React was actually thwarting them as browser developers by taking developer focus off of the standards-based solutions which were in development. They indicated that the delay in bringing Web Components to the browser was actually linked to React’s disengaging web developers from the standards and focusing them on React’s components instead. That’s bad for all of us."
There are more point’s on the comment’s section CodeChat 036 - Colin Megill Brings Up Strong Reasons to Use React.js | Microsoft Learn
As a relative newcomer to Meteor community, I came to it because of the accessibility Meteor offers and elegantly designed reactive fullstack platform.
And as a relative newcomer, I do not see comfort in the client side of React or Angular 2. Opinion comes from a standpoint of someone who is not already business wise invested in the previously mentioned tech, and there are many, many other newcomers to Meteor with similar dilemma. I honestly believe there is a better option for someone who is starting “today”, with a brighter future.
A tech that has the accessibility in the spirit of Meteor, but the possibility to use the same superior client side that:
- is from the inception architected with ES2015/ES2016
- strives for clean code
- strives for developer experience
- does minimally intrude,
- it is available today,
and to also apply it for scenarios where Meteor cannot be used, as it gets demanded from the clients and the constraints of the existing infrastructure they have. Lastly, as a “side effect” of it’s usage, elevating and evolving our industrys best practices and standards.
What is your opinion?