Go to the profile of Edoardo Paolo Scalafiotti
Edoardo Paolo Scalafiotti
#golang, #IoT and speed. Fascinated by nature - and bees. Also, dark chocolate.

Go Angular or React to Node

Or why you should use Go with Angular and Node with React

The two real protagonists of 2016’s SPA scene are probably going to be Facebook’s React and Google’s Angular2. Here’s why I think that they are not just two equivalent choices or “sides” to pick, but instead two different approaches to different problems. React:

[…] makes no assumptions about the rest of your technology stack, it’s easy to try it out on a small feature in an existing project.

while Angular is just:

One [as in: A BIG ONE] framework. Mobile and desktop.

To summarize, React is more focused on the “View” part of your stack: making no assumptions about the rest means that it can be plug-and-play into an existing solution. You could use it as a view component in Node.js (which actually makes a lot of sense) or in any other framework, be Ruby-on-Rails, Django, Laravel, Yii and so on.

Since React uses JSX and is written in vanilla JavaScript, it makes a lot of sense as a plug-and-play solution to a Node.js backend.

React is at its best when coupled with Node.js on the server

Moreover, since separation of concerns is not really the priority in React because of its inlining CSS style and, again, its JSX syntax, it makes sense to use React in one of these situations :

  • You have an existing project and want to upgrade the View framework.
  • You are in a small team or startup and want to have a code-once, run-everywhere programming language, using Node.js on the server.
  • You want to build a single application where server side and client side are strongly related to each other.

It’s possible to use Angular for the same reasons, but React makes for a stronger case here. Angular uses JS too but it’s no secret that it encourages developers to adopt TypeScript, which is a far better solution for bigger teams:

Types enable TypeScript developers to use highly-productive development tools and practices: static checking, symbol-based navigation, statement completion, and code refactoring.
[…] These features are available at development time for high-confidence application development, but are compiled into simple JavaScript.
 — from typescriptlang.org

As a side note, this is also why I think that Meteor has failed so far in attracting enterprise users (big kahunas are clearly the target for their Galaxy solution: small developers ain’t gonna repay $20mil of investments). Meteor lacks structure, a problem that Sacha Greif (the author of the “Discover Meteor” book-tutorial) addressed in a series of blog posts:

From the start, the Meteor Development Group has viewed Meteor as a platform: they’d give developers a toolbox, some screws, and a bunch of wooden boards, and developers would then use these tools to build whatever they wanted, however they wanted.
[However,] many community members (myself included) have asked all along for a real framework. One that would make choices for you, and give you easy blueprints to quickly build apps. In other words, not just a few two-by-fours, but an actual IKEA kit.

Back to Angular. Angular is *very* opinionated and has a different approach from that of React: it is a complete framework packed with routers, its own models, forms and so on.

By using TypeScript, Angular is a stand-alone framework that provides a full-fledged solution to an SPA . However, Angular follows the notorious Angular way, which might not be as bad as someone points out. Let me explain. Google’s support and Misko Hevery’s team provide a rock-solid foundation: personally, I cannot see how myself or some other small team can do a better job (especially since we’re application and not system developers). We can of course learn by example and maybe drive some new feature inspired by use-cases, but when you put together the minds of the teams at Microsoft (TypeScript), Google (Angular), Netflix (RxJS) and basically every single web-giant on the planet, I think that at least we must pay attention to the way that they do things. And if it’s a very opinionated way, then we should pay more attention to that opinion.

So, since Angular2 is at its best — and far more documented — when used in full-TypeScript, it answers to a different use-case than React’s. Since we’re not talking anymore about code-once, run everywhere because of TypeScript, I actually think that Angular will make far more sense if coupled with Go on the server.

Angular will make far more sense if coupled with Go on the server

Let me explain. Go is a strongly-typed programming language and it has the same benefits of Node.js in the non-blocking I/O — concurrency “department”:

Concurrency is a way to build things: its a composition of independently executing “things”, typically functions, but they don’t have to be. It’s the composition of independently executing processes (not in a Unix way, but in the more abstract way possible).
 — Rob Pike, Concurrency and Parallelism

And about Node.js:

Node is still a nice tool and if it’s working for you then you have nothing to worry about […] 
I’m not saying Go is the absolute best language out there and that you must use it, but it’s very mature and robust for its age (roughly the same age as Node), refactoring with types is pleasant and simple, the tooling Go provides for profiling and debugging is great, and the community has very strong conventions regarding documentation, formatting, benchmarking, and API design.
 — TJ Holowaychuk, Farewell Node.js

But Go can be the best solution for a fast and distributed RESTful API, especially when performing CPU-intensive jobs and not just data-delivery. For everything client-side related, the full structure of Angular2 will take care of the rest. Moreover, a big team can take full advantage of Go’s and TypeScript’s mature structure. So, Angular2 will make more sense when used in one of these situations:

  • You are building everything from scratch and have developers in your team that have prior experience (or are more comfortable) in using Java, Python or even PHP OOP
  • You are building multiple applications out of a single API (es: public API, mobile app, desktop app and so on…)
  • You are in a big team where separation of concerns is a requirement (especially for the design team)

In conclusion, if I had to start from scratch a startup in 2016, and depending on the project, I’d definitely choose between:

  • React AND Node.js, or
  • Angular AND Go