Am I wrong in hating React JS?
medium.com
medium.com
> I hate html in javascript. I hate JSX.
At least it's just HTML and JavaScript.
In my opinion it's better than learning a new messy templating DSL, i.e.
<ul ng-if="::vm.items.length">
<li ng-class="::{ 'active': item.active }" ng-repeat="item in ::vm.items | orderBy: 'id' as ordered track by item.id" ng-click="item.active = !item.active">
{{::item.name}}
</li>
</ul>
<select ng-options="item.subItem as item.label for item in ::vm.items2 track by item.id" ng-model="selected"></select>
<div ng-include="selected.template.url" />
You can use the official Create React App CLI [1].
> I hate the sheer amount of boilerplate code and the verbosity.
How do you recreate the following component in Ember/Angular/Backbone/jQuery/FoobarJs with less boilerplate and verbosity?
Header.js:
import React from 'react';
import Icon from './Icon';
export default ({ icon, title, subTitle }) => (
<header>
<h1><Icon name={icon} /> {title}</h1>
<p>{subTitle}</p>
</header>
);
React is just a library to build views, so there is not a single way to build your app in the React world. You can use Redux, MobX, Flux or whatever you want to manage your data. You can even do it in 100% raw vanilla JS. I think it's great.
---
I would also add that for any web app truly utilizing these libraries, you're going to have to know how they get compiled and where your data is coming from. With Angular you have to learn about scopes, digesting, linking/compiling, etc.
Two-way binding was amazing to me when I first took up Angular, it made common tasks so easy but on an enterprise-level application it's a nightmare because you're quickly dealing with digest/event cycle issues, especially during automated testing. The control over data flow that React prefers makes the easy, common tasks more time consuming, but overall saves a massive amount of complexity.
https://developer.mozilla.org/en-US/docs/Web/API/Element/cla...
While I prefer JSX now, mainly because it is just html/javascript, I sometimes feel that inline conditions/loops like `ng-if` are cleaner - I don't need yet another several lines of a `var` definition, condition, and assignment.
My biggest struggle with React was due to the fact it's a view-only library. Coming from Angular or similar projects you're suddenly in the dark on how best to manage ajax, forms, etc - yet when you power through, you realize it's actually freedom to do whatever you want. Done correctly, that's way more powerful.
Yes.
Is it here to stay?
Yes.
Should I get into it?
Depends on what you need. If you are building a web application with complicated UX needs (protip: you probably aren't) and/or the team insists on React, you probably need React. If you want an easy time getting a job in the Bay Area right now, you probably need React. If you want to avoid having your comments downvoted on HN, you probably need React.
So, it depends.
lol :)
Citation needed. HN has this really strange assumption that everyone who talks about web technology is working on Wordpress sites or implements TodoMVC for a living.
I think the assumption that everyone does a 'Todo' is definitely a poor one, but I feel like 90% of the React articles are by people that have used it for 6 months at most, company blogs included. Glancing at the angular builtwith stats[1], they had 600/10k within 4 years. 3.5 years into React and it hasn't broken 100. While these numbers don't directly translate into "complex UI", they are still indicative of long term usage, going back to my hand-on-stove comment.
There were people who programmed in assembly and hated compilers and C. There were people who programmed in C and hated Perl. There were people who programmed in Perl and hated PHP. There were people who programmed in PHP and hated Ruby. There were people who programmed in Ruby and hated that JavaScript suddenly was a "real" programming language.
You'll probably be able to find work in your language/framework of choice for a long time, although as time progresses it will be less "hip startup" and more "enterprise" (look at C#/ASP.NET) and "banks" (look at COBOL).
I disagree with that. It's not about age, it's about experience. React is essentially reimplementing ideas from the past on a new platform. I think it's more skepticism that React is 'it' as the next big UI view layer. The tolerance for bull goes down as you age, and sometimes the next big thing is just a different way of polishing the same ideas from 20 or 30 years ago.
- jQuery
- Coffeescript
- Backbone
at the time, if I had asked you if those were a fad, you'd think I was crazy. And yet, because of native language enhancements, none of those frameworks are really needed anymore. And I'm sure in 5 years React, Angular, Vue, Ember...you name it, will also likely be a thing of the past.
The important thing that I've learned in my (so far very short) career is that it's always best to know the language first, and the framework second. Frameworks come and go, but the language is permanent. By knowing the language really well, it's strengths and weaknesses, it enables you to determine when a framework is helpful...and more importantly, when a framework is a hindrance.
As an anecdotal example, I had a client that was using a React boilerplate on NPM to do a Foursquare API request. React is like, 50k lines uncompressed? To do that? I was able to replace it with 22 lines of vanilla JS. If you don't know the base language, it's often easier to simply think in the framework and create a bloated environment for very basic things rather than just use what the language gives you. It's faster, it's cleaner, it's more widely supported in browsers, has a larger community, and is more defensible to use the base language than a framework, until the framework does more work to help you than harm you.
So my advice would be, if you're thinking about using React or Angular, think about why you need it. Are you doing heavy lifting on the front-end, like interactive graphics or a dashboard? Sure, those are probably pretty good choices. If not, and you're simply trying to make the front-end more RESTful, with some easier reasoning about your applications, you could probably get away with a lighter framework like Mithril, Elm, or another lightweight framework.
I still wouldn't call jquery a fad, just obsolete
1. Get and manipulate dom elements. 2. Register simple event handlers 3. Ajax calls that are simple (frankly all other ajax-ish APIs I've ever seen pretty much copy the design and approach of the JQuery one).
Also a pretty big ecosystem of simple highly focused add-ons. You (still) can get a long way with just JQuery
1. `document.querySelector()` and then just modify the DOM however you want.
2. `node.addEventListener()`
3. `fetch()`
There are still things that jQuery provides that aren't as simple to do with the built in functionality, but in most cases, you can get by just fine without pulling in all of jQuery. And in those cases where you can't, there are more focused libraries available for those specific use-cases.
It took a while for React to "click" for me, but that was mostly because of transitioning from MVC to Redux. I highly recommend learning pure React first. Build a project with that first, even if it seems like you're writing a lot of code.
Seems like you're already obstinant and opposed to tech from it's perceived novelty and new age, rather than trying to understand the problems its trying to solve.
It's not hate. It's definitely not hate. You don't like React, and that's perfectly fine. "Hate" has some very specific, very negative connotations that make almost impossible to have a regular conversation. One of my mentors uses the term "stop words". Hate is on that list of words that, when used, stop the conversation in its tracks.
It's ok to not like things. It's perfectly OK to not like Javascript frameworks. There's a ton of them, or you can write your own if you feel that's necessary.
But please, can we stop throwing around the word "hate"? It does nobody any good and only furthers the problems of ego and exclusivity prevalent in our industry.
- forces you into an object oriented paradigm with constructors/destructors
- mutation from external sources and internal sources results in a single function being run to refresh the output.
- inline html/xml is your freind. You can see easily how a ui is structured rather than parsing a 300 line file to see what gets created, destroyed, appended, prepended anD etc
- all jsx results in is a "patch". This "patch" is then compiled into components (which also result in a "patch") or html elements/text/null values. This makes reasoning about the application simpler since a "controller" component may not care about updating canvas info. But the "canvas" component certainly does
There is no inline XML, and I'm not aware of any other popular (or otherwise) React alternatives where you use long files which create, destroy, append and prepend DOM elements?
I'm also not sure what you mean by patch, or what the specific benefit you're highlighting here is - just modularity? You can do that with any framework, it doesn't seem unique to React - at all?
Polymorphism and inheritance can be implemented if you wanted. Mixins were used for a while.
Xml is react native and all other alternative rendering that use jsx syntax and a form of react
React alternatives where you create/destroy/append/prepend would be the DOM.
Patching is interesting in that the inline html isnt actually html until the end of the render loop. I dont remember seeing that anywhere else to be honest. It seems more similar to transforms like in node streams.
How about hyperscript? Functionally equivalent to JSX but it's pure JS, with no XML syntax.
header(
h1(Icon({name: icon}, [title]),
p(subTitle)
)
Today UI elements are dynamic things and the code that drives the dynamics should be kept close to the static representation of a given view state.
React actually separates UI code and interaction logic, as it should, by hosting the static part in the render function and the dynamic part in event handlers defined on the component. This is in my opinion a great balance of SoC / cohesion as it allows proper scoping of a UI unit and fosters controlled reuse.
I don't want to sound rude but we've had enough of this MVC fanatism that completely disabled many developer's creativity and took a lot of courage and energy to the React team, among others, to challenge.
Tying view logic (and only view logic) to static UI code is probably the only way to go on the path to proper UI component sharing and reuse. Whether we like it or not, whether we put the code in separate files or use any other artifice we're bound to make these two walk hand in hand. The last bastion being style. Which the React community tried to address, too.
At the risk of saying something obvious, I think we shouldn't reason on principles and habits. Progress can't be, and never is, driven by such forces.
It might be worth giving React that 3rd try.
For one thing, I haven't been to a single React site that isn't an absolute CPU hog. Facebook is the worst for this.
Besides that though, I feel like it's still some intermediate step before we have something better.
I'm bullish on Elm though. For now, plain vanilla (but mostly functional) JS works fine for me and occasionally I'll throw in Backbone/Marionette where appropriate. Maybe that's too boring for people, but I'm too busy being happy with a stable stack and making money to care.