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)
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 https://channel9.msdn.com/Shows/codechat/036?WT.mc_id=dlvr_twitter_ch9
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?