Goatstone

Angular Vs React TODO

July 2017

For many years I used jQuery and Backbone in order to develop web applications. I always knew there was something better on the horizon. Currently that horizon offers two prominent strategies for building web applications: React and Angular. My objective is to compare React and Angular by creating Todo applications with both libraries. These two applications can be found at their respective Git repositories:


https://github.com/goatstone/react-rx-todo


https://github.com/goatstone/angular-rx-todo

There are a number of distinctions between the two frameworks, I will focus on what I think are some, but not all, of the key differences: inter component communication, templates vs. JSX, TypeScript Vs. JavaScript and the file system.

Inter Component Communication

A key aspect of these Todo applications is the inter component communication.

In the case of the React application I am using 4 distinct streams. In the case of the Angular application I am using @ngrx/store. The React application does not attempt to store state, data flows from the backend into the application. In this case the ‘store’ can be thought of as what resides on the server in a database or produced by a web API. This is an old school way of thinking about it, however, in some use cases I think this simplified approach could work fine. I came upon a custom Rx solution and although this works, it is not a standard framework.

For the Angular Todo, I have used @ngrx/store. The notion of sticking to something like @ngx/store rather than my own solution means I could hand over the code to another and there exists 3rd party documentation and examples to guide their understanding. In addition to this @ngrx/store has solved the problem of storing the data on the client for me. So far @ngrx/store has been great and I plan to use on any future projects over a custom solution.

Angular Templates vs. JSX

One big difference between the two frameworks is the way templates are handled. React uses JSX, something that is not even a template, it is a form of XML that is a special JavaScript syntax. Why this may be important is a question I will not try to answer except to say if you are going to use it you need to understand what you are buying into, foregoing JavaScript syntax for JSX. On the other hand Angular offers the more traditional template. These templates attempt to be nothing more than templates and are really just HTML.

File System

I think it is important to be able to use absolute paths when referring to other modules in JavaScript. In the case of modules in the Todo applications I have lines like this

goatstone/todo/header/component.ts
goatstone/todo/header/style.ts

The entire path indicates what the thing is supposed to be. In the case of the React application I am relying on a standard sym-link (A solution that is too based on the operating system being used). In the case of the Angular application I can use the .tsconfig file and set the "baseUrl" to the root of the repository. That the framework provides a solution for using absolute paths is very helpful and I can avoid using the sym-link or searching for a solution from the variety of solutions offered.

In the Angular documentation there exists guidelines for style, some of which refer to how to set up the file system. This is the point in which I differ most with the established documentation. I think of files systems being component oriented. All style and template information should reside in the same folder that is marked simply with the name of the component or functionality.

TypeScript Vs. JavaScript

At first I did not like the way Angular 2 seemed to impose TypeScript onto Angular. The documentation was written with TypeScript, not JavaScript. However TypeScript is simply a superset of JavaScript and as I worked with it I began to appreciate this and really like TypeScript. The superset is nothing more than tried and true Object Oriented concepts. Information for these concepts is readily available in standard OO documentation.

How the new JavaScript should be written is not always clear. As much as ever there are distinct opinions about how this should be done. TypeScript provides a standard for writing JavaScript that is not 1.5.

Conclusion

These are just some of the differences between Angular 2 and React.

You will see as you continue your exploration of client side development strategies that there are many tradeoffs between React and Angular. The tradeoffs you need to make will depend on your particular problem space and your personal preferences.

The full framework of Angular over the view only strategy, answers many of the questions I find that I must answer over and over again. However the broad usage of React ensures that there is, publicly available documentation about how to approach given issues with React The super-set of JavaScript that is TypeScript for me, is a great way to get beyond JavaScript 1.5 and you can use it with React as well?

There is a lot to explore and compare in the two frameworks, don’t just take my word for it. I think making an application like the Todo application can get you far in understanding what a development strategy offers.

Jose Collas, July 2017