Hacker News new | ask | show | jobs
by Bahamut 4253 days ago
I disagree (about never going back) - I spent some time playing around with React (I authored https://github.com/wesleycho/angular-react ), and I found the lack of a framework for application development to be a massive void. Code organization and modularity is becoming an increasingly important problem with JS as more logic is happening in the client and more components need to be modular for fast changing requirements. Neither Angular or Flux quite solves this, but Angular provides more useful tools for managing an application.

Angular has a void with the lack of a useful enough eventing solution - $scope eventing has specific use cases, but you don't want to use it as a general event bus, mainly due to performance. This is important for Angular since you don't want to couple modules together with hardcoded state keys that you may want to alter in different applications.

Flux does offer a way around the eventing problem at a lower level within React components, but on a higher level, there is no application level of control - you have to construct exactly the control you want, which while liberating, also is an easy way to create a hole in architecture when designing an application if you're not careful. Angular exposes that problem directly in many ways (for example handling transitions between two urls in the application), as well as forces thinking about module dependencies with dependency injection.

HTML mixed in with JS via JSX is also an abomination, that originally made me want to run far away from React when I first looked at it. I'm not a huge fan of it still, but it's not an extremely terrible thing as long as you keep higher level templates slim, which React forces you to do in order not to have huge chunks of HTML mixed in with complex JS...although I'm sure there are developers out there who do it anyway (just like there are plenty of Angular developers who will toss plenty of jQuery in an Angular controller).

4 comments

> Angular has a void with the lack of a useful enough eventing solution - $scope eventing ...

I've found that using a publish/subscribe system for communicating between components makes them more loosely coupled and modular. In most cases, the components I've written are naturally somewhat slightly coupled so I just pass around functions as props from parent to child components.

> HTML mixed in with JS via JSX is also an abomination ...

Totally agree. I use the default React.DOM elements instead. I find them more transparent and easy to read, and manipulation of these are much easier using the map, filter, folds etc.

> I've found that using a publish/subscribe system for communicating between components makes them more loosely coupled and modular. In most cases, the components I've written are naturally somewhat slightly coupled so I just pass around functions as props from parent to child components.

I agree - my company is going to open source an event machine for Angular sometime in the next couple of months which should address this hole.

> Totally agree. I use the default React.DOM elements instead. I find them more transparent and easy to read, and manipulation of these are much easier using the map, filter, folds etc.

Unfortunately it doesn't seem like React documented React.DOM :( . I would rather just use HTML, but I would rather have it in a separate file. Perhaps a build tool for grunt/gulp where you can register keys with the path to the template being the value, and the tool converts the value into the React.DOM elements would be a good idea.

> Unfortunately it doesn't seem like React documented React.DOM :(

React.DOM.div(), etc. are part of React's public API -- if we didn't document them, that's a mistake.

At the least, I cannot find any mention of the specifics anywhere on the main GitHub page - this is the best that I can tell: http://facebook.github.io/react/docs/top-level-api.html#reac... . I do know the recommendation is to use JSX, and I can see why, but more visibility of the API would be better.

Edit: As a note, I did find out how it worked by doing source code diving two months ago.

I think there's a page or two that describes what the jsx transformer does(which is it converts them to React.DOM elements IIRC). I think that's where I learnt that you could use raw JS functions instead of jsx, even though it said that jsx should be preferred or something to that effect.
"HTML mixed in with JS via JSX is also an abomination"

Why?

> HTML mixed in with JS via JSX is also an abomination,

Ha! It made sense to me. It was very easy to explain its purpose and it is entirely optional.

You can reinvent Angular concepts in ReactJS using RxJS. If you do that, the code to do so is very small and is much more logical that AngularJS nonsense.