Hmm. So, the complaints about React are "no convention over configuration", "we didn't like JSX", "event handlers require binding for `this`", and "trouble finding a correct source of truth" for articles and such.
The first two are pretty common. Some people _love_ that React lets you pick and choose the other pieces that you need for your own application, while others hate that React isn't a kitchen-sink-provided framework like Angular. (Relevant HN comment from a while back on "frameworks vs libs": https://news.ycombinator.com/item?id=10969819 ). Ditto with JSX - some people love that it's almost exactly the same syntax as HTML, while others hate the idea of having anything HTML-like in their components or dislike that it does have a few minor differences from actual HTML syntax.
The event handler complaint I find a bit more odd. Admittedly, I never got too deep into "vanilla JS" or jQuery, so I haven't spent too much time writing non-React event handlers, but having to bind methods is very much an artifact of how `this` works in Javascript (especially with classes) and not specific to React.
As for a "correct source of truth", well, I have that covered :) I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics.
React is a tool like any other. If someone argues for or against the use of React based on anything other then the actual design / API / implementation / results of the framework its just a bad argument.
Well, this is just my (and partially of my colleague) subjective opinion after spending a month working with it. Of course, that's due to change once I get enough mileage with it.
For myself, I still have not decided whether I like JSX or not :) My colleague finds it great, and I like the declarative nature of it, just need to persuade myself to accept it mixed in JS file.
Yes on .bind, but I got used to not having to care about it in Aurelia (and Angular also). Got my fair share of `this` handling in pre-ES6.
And of course, thank you for the links. Bookmarked! :)
Are you using arrow functions? I find that using es2015 arrow functions for class methods takes care of most of the problems around this and react.
The only annoyance is dealing with binding event handlers to items/components in a list. Generally you need to abstract the list item into it's own component and do the event handler binding there.
Yep, we are using arrow functions and other ES2015+ goodies, but they don't help with event handlers. In fact, I believe class property syntax helps with that, but we only figured it out after we built these few pages and components necessary for the web app part.
Sorry, I didn't think about the arrow functions being used in class property syntax too. :) So yes, they do help with event handlers, I stand corrected.
One note: From what I've read, using arrow functions as props in a render method of a component will create new functions each render, so you might end up with a good bit more GC than normal. There are some nice little mix-ins that will autobind to remove the need to remember to .bind everything.
Try react-native, react-gl or something with different render target than the web platform. It makes perfect sense to you then.
The SGML syntax is just perfect for composing and nesting components. So does HTML, XML etc. You just have to get your head around the idea that you´r writing HTML, because your´re not.
> just need to persuade myself to accept it mixed in JS file
Why is this a bad thing? The most important thing about JSX is that it's a single source of truth -- you never have to wonder if data is processed in the JS or in the template. I really think everything in one file is the ideal, we've even started moving the styles inline via styled-components.
Not a bad thing. Just a personal preference of trying to separate views and view models for a long time. I believe it just needs some time to get used to it. As I said, I really do like declarative nature of JSX, knowing that it's just compiled to a regular JS/DOM code.
I've found that the best way to make event handlers is instead of doing
class Blah {
private handleThing(...) {}
}
to instead do this
class Blah {
private handlething = (...) => {}
}
this means that it is created only once, at instantiation of the component, so it is fast, looks decent, and has access to `this` as it's technically a method on the object, not the class.
Also, if you're coming from C# land, head straight to TypeScript 2.3 - it's lush and handles the latest ECMAScript stuff wonderfully, and you get static type checking, interfaces, union types, etcetera. The only issue is when a package has no type definitions or no supplementary @types package, which sucks but they exist for most popular packages. Also VS Code is built with it in mind and brilliant to work with.
As for stacks, I'm currently really enjoying redux/redux-observable and my helper lib redux-rx-http (for API), I find harnessing the power of RxJS to manage side-effects through "epics" is a really elegant and decoupled way to chain a bunch of things that you want happen together.
Yep, the class property syntax helps with event handlers.
As for C# and TypeScript, we also have a very strong JavaScript background, from vanilla pre-ES6 to the latest ES2017+. We still prefer JavaScript to TypeScript, although out of languages that compile to JS, TypeScript is the best in our opinion.
One problem with using fat arrow syntax like this is the method is no longer attached to the prototype so it's not shared across all instances and is less memory efficient. It also doesn't work well with React HMR if you're using that. If you can use decorators I highly recommend autobind-decorator: https://github.com/andreypopp/autobind-decorator
Also I think you're using a TypeScript-specific `private` syntax there which likely changes the runtime semantics so my comment really only applies if you don't use that.
If they want to use their own function for that... they can, but JSX is a trivially easy way to describe nested components (which can get verbose with the above).
A nice bonus of JSX is that it also means your components and render templates are not tied to React at all (if you're using stateless functions anyhow). You can switch the React.Component part trivially with babel to anything else (like deku, yolk, a custom one, whatever).
I find it a bit odd that both you and the parent commenter (acemarke) seemed to have interpreted the post in a completely different tone than I did.
I didn't find anything in the original blog post in the tone of a "complaint". If anything, they were merely pointing out what kind of things they run into and their thoughts, while transitioning from an ASP.NET background.
It's actually a really helpful read if you also happen to come from ASP.NET and are looking to pick up the Node/React stack. I personally also came from a different stack only recently (not ASP.NET) and dove into Node/React a few months ago, and found the way he expressed his views helpful for myself to align my thoughts.
Yeah, re-reading it, the tone was a bit more "things we ran into" then "stuff we hated". That said, the items listed are definitely common complaints or points of argument about React that I've seen numerous times, so I was coming at it from more of that reaction.
> I didn't find anything in the original blog post in the tone of a "complaint". If anything, they were merely pointing out what kind of things they run into and their thoughts, while transitioning from an ASP.NET background.
Yes, exactly this! There's nothing to hate really. It's more of a complaint against our inability to quickly grasp new concepts than trying to throw some stones over to React.
If your team is from a .NET background, you may be better off using something with first class Typescript support.
I have been working on a boilerplate that uses VueJS with typescript. It is still reactive. I setup the UI to closely mirror the structure of a .NET MVC app. It is much more intuitive to me coming from a strongly typed OO background.
There are a lot of people using Typescript with React... it's not so bad, I don't see the point nearly as much as some, but it's definitely there, and pretty well supported.
I tried typescript with react, but found that I was constantly adding `: any` when dealing with `props` and `dispatch`. It felt like it was getting in the way more than it was helping.
I never use 'this', 'bind', 'apply', 'call', 'class', and only use 'new' to create React components. I find it much easier and more fun to work with React as a result. I hope other people would give it a try.
Pretty interesting read. I have had pretty much the same experience with documentation around react, and although Angular 2/4 documentation can be confusing at times at least you know what you are reading isn't outdated. Also as far as their backend choices I'd like to know why they went with knex over sequelize.
41 comments
[ 4.3 ms ] story [ 81.6 ms ] threadThe first two are pretty common. Some people _love_ that React lets you pick and choose the other pieces that you need for your own application, while others hate that React isn't a kitchen-sink-provided framework like Angular. (Relevant HN comment from a while back on "frameworks vs libs": https://news.ycombinator.com/item?id=10969819 ). Ditto with JSX - some people love that it's almost exactly the same syntax as HTML, while others hate the idea of having anything HTML-like in their components or dislike that it does have a few minor differences from actual HTML syntax.
The event handler complaint I find a bit more odd. Admittedly, I never got too deep into "vanilla JS" or jQuery, so I haven't spent too much time writing non-React event handlers, but having to bind methods is very much an artifact of how `this` works in Javascript (especially with classes) and not specific to React.
As for a "correct source of truth", well, I have that covered :) I keep a big list of links to high-quality tutorials and articles on React, Redux, and related topics, at https://github.com/markerikson/react-redux-links . Specifically intended to be a great starting point for anyone trying to learn the ecosystem, as well as a solid source of good info on more advanced topics.
For myself, I still have not decided whether I like JSX or not :) My colleague finds it great, and I like the declarative nature of it, just need to persuade myself to accept it mixed in JS file.
Yes on .bind, but I got used to not having to care about it in Aurelia (and Angular also). Got my fair share of `this` handling in pre-ES6.
And of course, thank you for the links. Bookmarked! :)
The only annoyance is dealing with binding event handlers to items/components in a list. Generally you need to abstract the list item into it's own component and do the event handler binding there.
I don't use .bind() anywhere in my react code.
They do. Just do:
and you don't need to bind in the constructor anymore. You'll need to use Babel of course to transpile that.The SGML syntax is just perfect for composing and nesting components. So does HTML, XML etc. You just have to get your head around the idea that you´r writing HTML, because your´re not.
Why is this a bad thing? The most important thing about JSX is that it's a single source of truth -- you never have to wonder if data is processed in the JS or in the template. I really think everything in one file is the ideal, we've even started moving the styles inline via styled-components.
Also, if you're coming from C# land, head straight to TypeScript 2.3 - it's lush and handles the latest ECMAScript stuff wonderfully, and you get static type checking, interfaces, union types, etcetera. The only issue is when a package has no type definitions or no supplementary @types package, which sucks but they exist for most popular packages. Also VS Code is built with it in mind and brilliant to work with.
As for stacks, I'm currently really enjoying redux/redux-observable and my helper lib redux-rx-http (for API), I find harnessing the power of RxJS to manage side-effects through "epics" is a really elegant and decoupled way to chain a bunch of things that you want happen together.
As for C# and TypeScript, we also have a very strong JavaScript background, from vanilla pre-ES6 to the latest ES2017+. We still prefer JavaScript to TypeScript, although out of languages that compile to JS, TypeScript is the best in our opinion.
Also I think you're using a TypeScript-specific `private` syntax there which likely changes the runtime semantics so my comment really only applies if you don't use that.
JSX isn't even required either. It just desugars into:
If they want to use their own function for that... they can, but JSX is a trivially easy way to describe nested components (which can get verbose with the above).A nice bonus of JSX is that it also means your components and render templates are not tied to React at all (if you're using stateless functions anyhow). You can switch the React.Component part trivially with babel to anything else (like deku, yolk, a custom one, whatever).
So.. yeah, seems an odd complaint.
I didn't find anything in the original blog post in the tone of a "complaint". If anything, they were merely pointing out what kind of things they run into and their thoughts, while transitioning from an ASP.NET background.
It's actually a really helpful read if you also happen to come from ASP.NET and are looking to pick up the Node/React stack. I personally also came from a different stack only recently (not ASP.NET) and dove into Node/React a few months ago, and found the way he expressed his views helpful for myself to align my thoughts.
Yes, exactly this! There's nothing to hate really. It's more of a complaint against our inability to quickly grasp new concepts than trying to throw some stones over to React.
I have been working on a boilerplate that uses VueJS with typescript. It is still reactive. I setup the UI to closely mirror the structure of a .NET MVC app. It is much more intuitive to me coming from a strongly typed OO background.
The boilerplate is not fully done yet, but here is the UI portion if you'd like to browse the structure: https://github.com/caleblloyd/dotnet-core-boilerplate/tree/d...
Cool, nice idea for the project!
I never use 'this', 'bind', 'apply', 'call', 'class', and only use 'new' to create React components. I find it much easier and more fun to work with React as a result. I hope other people would give it a try.
not a huge fan of the `new` keyword in js; it's difficult to mock and there are better options (Object.create/freeze e.g.)