Glad to see people implementing similar projects in both frameworks so everyone can evaluate their needs.
Though, comparing code snippets to a lengthy tutorial kind of misrepresents the verbosity of React. I think we forgot to put the completed tutorial on GitHub, so here it is for an easier comparison:
The difficulty is when the Todo MVC does not represent a framework's advantages. In the main react thread, peter's comments suggest that React shines in an environment with many, complex interacting UI components.
This is exactly why we're working on TasteApp[0] which is going to give frameworks a better chance to show of their strengths in medium-sized projects.
Well, I think most would agree that AngularJS has better readability and is more concise but a disclaimer would be that I've been looking at Angular's syntax for quite some time and reactjs is a new framework...Instagram's website is nice by the way, simple, clean UI.
The "Load More" Button on the site is probably powered by reactjs? @peterhunt
> For our comment box example, we'll have the following component structure:
>- CommentBox
> - CommentList
> - Comment
> - CommentForm
Yet the AngularJS solution simplifies this down to one component.
If we presume React could simplify down to a single component too, then the AngularJS solution is would only be fair if it keeps the artificial constraint of having four component classes.
There's a decent amount in there. We have client-side URL routing/transitions (thanks, Backbone) and the entire profile and feed pages are just big React components. There are also photo modals, login modals, and a full layer/tooltip system which is non-trivial to get right.
I am relatively new to Angular, but wouldn't you want to have the comments be a Factory using ngResource? If the comments are restful then it seems much easier.
Theoretically yes, but ngResource is kind of the achilles' heel of AngularJS right now. You're often better off using a different library or making your own class with $http requests.
I'm using AngularJS 1.1.5 and ngResource in my project and it works quite nice. I wouldn't discourage people from learning the hard way. However, +1 for Restangular.
React's model is a bit interesting- it inverts the relationship between markup and code with the code containing the markup (without odd escaping). Not quite sure how well it really works without using it in a large app, but it is intriguing.
I do think that components which consist entirely of JS are convenient (self-contained w/ no ancillary HTML assets). Not sure it's enough to justify the framework, but has some potential.
I would like to see a similar tutorial which also covers authentication and how to add security to your app. There are a few but I want to see a really simple one.
What I don't understand is how you add login while keeping your REST backend stateless. How do you validate the request and make sure that it comes from the correct user and not just someone who forges the request without keeping a state on the server-side? Normally you just add a session.
There's a bunch of different ways to do this. For Instagram we use Django's normal login mechanisms which add a session cookie. Our calls to the REST backend include this cookie. It works pretty well for us.
Our web application / REST API actually uses two systems; for employees, it uses HTTP basic authentication, which is validated to LDAP via Spring Security. For customers, there's a security proxy in between the front-end and our API (IBM's WebSeal), so authentication's handled completely outside of our REST API.
I agree, within the first few days of using AngularJS I immediately felt the benefits more than I did trying any of the other more popular JS MVC frameworks. I've gone as far as going back into other parts of apps I'm making and rewriting them using AngularJS from it originally just being some jQuery functions.
Neat, although I'm more interested in when you plan on having this book out... Angular is incredibly powerful but it really could use with some more resources for those who are picking it up.
I can't quite recommend that book. A lot of the code examples contain errors and, worse, some of them are subtle errors in nomenclature (the text refers to the "myService" service but the code declares it as "service" in one place and then "myService" in another) and not jsut typos.
That's probably a fair assessment. I don't really read books like this for the code precision (heck even sample repos on github don't survive working over much time). I look more at the high-level gist of concepts, so for that it's good, and then I know what to Google next...
I wouldn't even be surprised if the book is totally out of date in a few months.
I think knockout is a fairer comparison than angular. KO is not at all prescriptive, just one piece in the puzzle which you combine with other things, much like React professes to be.
The controller directive is necessary to determine the scope of the variables/functions embedded in the view.
But I do agree on the point that designers would certainly gag when seeing this... A developer would need to go though the deign and insert all the hooks. This step is unavoidable with any web application framework.
That being said, I think a designer would puke if they were required to write React components.
The controller is in fact separated. The "ngController" you see referenced in the markup is the link between the view and the separate controller. Any MVC framework you could hold up as an example of proper "separation of concerns" will necessarily have the same link, even if it's implicit. Sometimes it's defined in the controller, sometimes the link is defined in the view, and sometimes you don't see it defined, but it's still there. (of course, we all know explicit is better than implicit)
Right, but doing it this way means both the view and the controller know too much. Why should a view know about how it is going to be used? Also, I'm guessing if you give this to a designer his/her eyes are going to glaze over.
No, the link here is only in the view. The controller doesn't "know" about the view. This is opposite but functionally equivalent to have traditional server-side MVC frameworks handle this, which is to declare the view in the controller or the routing (which you can also do in AngularJS, you actually typically declare both the view and controller in the routing). But the point is, you have to declare the link somewhere. Declaring it in the view is no less proper than declaring it in the controller.
Having said all that, I'm really impressed with React and look forward to checking it out and using it in combination with Backbone. AngularJS definitely has its share of pain points. It's just that where the controller is linked to the view is not one of them.
(By the way, I'm upvoting you since I don't see anything particularly offensive or improper about your comment. We're just disagreeing. Not sure why you're being downvoted. )
You don't actually ever need to explicitly specify the controller in Angular views. Usually in angular apps, the controller is specified by the routing provider (in JS), along with the view (template path).
In small examples (ie when not using angular routes) it is easier to explicitly specify the controller.
you should learn about the angular concept of scope before gagging on this. its actually a very elegant mechanism for letting you treat a segment of the document as lexically scoped data within your Javascript.
I think he/she's going after the idea of polluting one's view with all sorts of non-standard markup invokes a gag reflex. I'm amazed that Google chose to adopt such an ugly non-standard idea. HTML5 does allow for data attributes, why on earth did Angular choose to ignore those? "ng-repeat", "ng-pooponastick" etc??? Most templating languages to not violate the actual HTML attributes to exploit their purposes. I'm not hating on Angular.js yet as I've yet to use it in a real project. But I'd hate to have to migrate a project from Angular to a more pure template.
You can use data-* attributes in angular if you're not keen on invalid attributes e.g. data-ng-repeat. It used to be slightly broken, but I've been led to believe this is no longer the case.
As for making up your own elements as angular allows you to do, I think this is actually quite forward thinking. This is basically what the ShadowDOM[0] is all about, and when becomes common place you won't bat an eyelid seeing <NoBleachsSuperTag> in HTML.
angular allows you to prefix any html directive with "data-" to make it fully compliant with the html5 spec.
you can certainly use <li class="some_style_class" data-ng-repeat="comment in comments"> in your angular templates and have it pass a validator for html5 and still work with angular.
This is a great example of where Angular shines compared to jQuery. Yes, you can do this with just jQuery but it won't be as well modeled or as easy to test.
Though, comparing code snippets to a lengthy tutorial kind of misrepresents the verbosity of React. I think we forgot to put the completed tutorial on GitHub, so here it is for an easier comparison:
https://github.com/petehunt/react-tutorial/blob/master/scrip...
Outside of standard HTML boilerplate our entire application is pretty small I think.