17 karma · joined November 19, 2015
I am not arguing about JSX syntax, but rather the principle behind it. How would I safely refactor a css class across hundreds of components in a safe way and not by find/replace? An IDE such as WebStorm actually tracks CSS classes by their reference in other HTML/CSS files and this includes CSS preprocessors. I know it's a safe bet to run the renaming, although I always preview the changes beforehand.
I'm a reasonable developer, but this is an anti-pattern that has been eschewed voraciously over the years. Your appeal to the intelligence of React's devs is an informal fallacy and doesn't change this fact.
I am not trying to be dogmatic here. Yes, breaking the 'rules' when it is warranted is perfectly fine. My argument here is that in this case, this anti-pattern isn't warranted and will be very expensive work with as the product grows. I am advocating standards and best practices. React sidesteps both for an unnecessary reason. It works, it's pretty awesome how fast it is, but it cannot scale with a product's lifecycle.
Web components keep the HTML in the DOM and are being officially adopted as a standard. They can be polyfilled with a lib from http://webcomponents.org/. Aurelia, although it is a framework, is extremely lightweight and greatly simplifies the use of web components. Polymer isn't as elegant, but it clearly demonstrates the idea of dynamic reuse. There are other alternative libs as well.
As an aside, ES6 is now standard and with Babel. Javascript is now closer to ECMA, as it was intended to be.
I think I've made my argument as clear as I can, thank you for a great (and polite) discussion. It has actually been helpful for me to voice my opinion and get a better understanding of the support behind React. Again, it's impressive how fast it is over other libs such as jQuery, but jQuery's always been bloated and is near the end of its usefulness. However that point doesn't detract from the very cool things that React can do in the right hands. I wish I could bet on it, but to me it's the wrong horse in the race.
This isn't the first time people have fallen prey to embedding HTML as a string into JS to write the DOM. 5/10/15 years ago, if we saw this, devs would just shake our heads. If anything React is an old hack, an anti-pattern brought forward again.
I misspoke about views in business logic, as you said, it is the controller logic, which should be decoupled from the view itself as well. The naive example of converting a webcomponent to a JSX component may look similar, but more complex components will only require greater complexity for the render() method to handle.
I understand your rationalization, but the crux of the arguments here are concerned with the anti-pattern React introduces and why developers who've come across this before have seen this as technical debt. The arguments for React are a matter of opinion, wherein the arguments against it are based on the practical principles for programming UIs, principles have been forged to be tried and true since the 70's.
I personally favor standards, such as webcomponents and OO programming for modules. I understand that this may not seem popular at this point and time, but 20 years of dev experience has taught me otherwise.
You'll also need to worry about how you run BDD tests for specifications and scenarios. How can this be achieved in React as you write test suites for user stories and non-UI acceptance tests? How will this impact your continuous delivery/integration systems as well? You'll have to rewrite all your test suites into Jest, right?
There are architectural trade-offs for sure. Can you definitely say you've performed a thorough analysis before making this decision? There's a difference between having a clear strategy to move from one tech to another and knowing that the migration will not just bury you into a deeper whole than the one you think you're escaping.
http://aurelia.io/ is based on webcomponents (MVVM), ES6, and current web standards. It's amazingly simple and good architects can use their own structural patterns to create code that can actually scale with the product. DDD and BDD methodologies mesh perfectly into the development workflow, especially with Agile product development.
I wish you well, but I really think React is a short sell with dire consequences.
Honorable mention for sophisticated animations: http://greensock.com/
And then there's the missing mentions about the plethora of mobile app bootstraps such as phonegap.
As complex as the frontend has become, C++ development requires a much more sophisticated set of skills and use of frameworks IMO. I do like that frontend work can require some decent engineering chops now, although it shrinks the talent pool considerably, for the present time at least. I personally look forward to the day jQuery DIAF now that much of the DOM API is standardized. Although it is extremely useful, it's a tight coupling that I'd rather do without.
It is very scary how naive and misinformed this article is coming from a .gov site. Given the misuse of terms and purely ridiculous suggestions, I wouldn't even show this to grade schooler.
http://disi.unal.edu.co/dacursci/sistemasycomputacion/docs/S...