> I hate the lack of conventions — every project I look at looks different, every blog post looks different.
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.
JSX can also be a hard sell for seasoned developers because they've been taught to avoid combining HTML and JS for so long. I initially disliked the Angular templating system because it felt like I was regressing to `on-click="javascript()` code.
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.
You definitely have to learn a DSL - in JSX you have to use className instead of class for the HTML tag property. There are a few other examples of this, but the point is the argument doesn't hold water against Angular's templating language.
Learning a few differences for attributes names isn't nearly as involved as learning angular's entire custom attribute and syntax support though.
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.
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.
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.
It's a 3.5 year old framework. Unless your career is "technical cofounder" with 6 month intervals, you probably don't get to pick your stack. People that have up and chosen React for their professional platform and have their company succeed aren't going to be all that common[0]. Within those that have, people who have used it for long enough (and large enough) to burn their hand on the stove are few and far between. Remember when Angular was the golden child and could do no wrong? It's 6 years old now, and took a while before the fandom died down and you could actually find the practical criticism.
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.
Whats the threshold for "complicated UX needs"? I'd think for all but the very most basic bootstrap landing page (IE, if any of the value of your business other than a sales sheet is in your webapp) you'd want to use decent tools.
I have a lot to say on this topic, but suffice to say I think the decent tools being used today are far more complex than is necessary for building most web UIs that I deal with.
You are probably just experiencing change aversion, also known as "getting older". It's normal to have these feelings.
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.
You're not wrong in hating React, but it is a fad as much as no one wants to believe it. The reason I believe is because no matter how strong the framework, eventually it will be adopted (to some extent) into the native language (which is a good thing). Think about these frameworks:
- 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.
Are you perhaps thinking of JQuery UI? The core JQuery lib is still used. And for basic front end dev it really does offer most of the utility you'll look for in other libs.
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
You can, but it pretty much is obsolete at this point.
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.
I wasn't a huge fan of JSX until I saw the template errors in Angular 2. Not trying to bash on the rest of Angular 2, but it really made me appreciate how JSX points out the exact syntax error at compile time. Pretty much all template based frameworks have the same problem.
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.
I recall a few years back I hated Ember JS and kept trying to get into it and hating it then for some reason the 3rd time I did, it stuck and I LOVED IT.
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.
What may help is to change your perspective, and to change your word choice.
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.
Thank for the feedback. It might have not been obvious in my article but I am definitely open to changing my mind about stuff and I gave 2 examples: Ember & VIM. So just because I hate React now doesn't mean I will not be a fan later.
- 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
I respectfully disagree. You don't need constructors and certainly not destructors (really not sure what you mean by this in the context of React, can you elaborate) and these are not really the main OO concepts. Polymorphism, inheritance are, but you don't refer to these?
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?
Component will mount/component did mount is effectively construction. Component will unmount is effectively destruction. Apparently them changing the names makes you believe thats not what it is
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.
If anything it forces you into it is functional paradigm (especially if you use flux/redux) with every component beeing a function of state. You mentioned it yourself in second point. To me react does not seem object oriented at all, at least in traditional way.
I don't think you can make an argument against building the DOM in JS (instead of using some random DSL to parse HTML template strings) without falling into the fallacy that JS === logic and HTML === presentation. But, you don't seem to be making arguments.
Then don't use it, imho Elm is way better, and the way they write html in elm is a lot more pleasing and less ugly than jsx. I'd recommend taking a look. It also compiles to js and has better performance.
I love Elm too, but Elm's biggest problem is Elm. It's hard to justify picking anything other than Javascript if other people are going to be touching the codebase.
I'm with you on the embedded HTML in JavaScript files. There's a reason everyone went nuts for MVC, the seperation of UI code (in my opinion) just makes your life as a developer easier.
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.
I kind of feel this way about React, but I feel even more strongly this way about Ember.
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.
> 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.
> I hate the lack of CLI. I hate the ridiculous amount of shit I have to do to simply get a project started.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?
> I hate the lack of conventions — every project I look at looks different, every blog post looks different.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.
---
[1] https://github.com/facebookincubator/create-react-app