React.js is a technology which had my interest since I first saw the concept of components and keeping together presentation and behavior. It’s something that clicks for me because it was very similar to the way we built our WinForms enterprise application. WinForms is something that we settled on when we tried to enforce a proper MVP (Model-View-Presenter) architecture, as a good compromise. We ended up with components. It’s very fast to develop, it’s powerful and flexible, and not easy to understand.

(for a good intro to React please checkout this post: (http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome)

I am also quite familiar with complexities of a good presentation layer architecture, the advantages and pitfalls of 2-way binding, the observable object pattern, the component encapsulation problems, styling and tricky separation of concerns through my experience with XAML.

XAML for instance is very powerful, it’s extremely flexible and, I would say, very purist. You have your models, viewmodels, views, components, templates, behaviors, your Visual tree and all sorts of scopes. You have great frameworks for building UIs (Caliburn.Micro), with great features out-of-box. When I took it for a spin I decided to make an invoicing app in Silverlight (which I still actually use). The pickup of all these concepts really took a while and it was, I must admit, at times daunting and hard to grasp. But at the end I was very happy with what I learned about XAML because it seemed to solve all of these “architectural impurities” I had with the WinForms enterprise app that was built like that only because it was the most reliable and predictable tech at the time (that was cca 5 years ago). XAML was something of an engineers dream, a well thought-out tool for building great UIs, with all the bells and whistles out-of-box, fantastic binding capabilities, thought-out best practices and patterns, static language. And it was pretty complex, and sometimes slow.

Don’t get me wrong, most of the stuff worked great, but there were some stuff (like running a big grid over 24” screen and stuttering while scrolling) that you as a developer notice, especially if you’re building an app on Winforms on the side which regularly chews that sort of grids like it was nothing. It gets you worried a bit, but you could always use a few tricks like recycling visual tree or something like that. Admittedly, you can get XAML extremely optimized (ie. Latest Visual studio)

I always wanted something similar to XAML concept on the web. And wouldn’t you know it, Knockout.js came to be, then bunch of other frameworks, and finally Angular. Angular looked very good – scopes, directives, converters, 2-way binding. All great!

Angular felt right at home, lots of familiar concepts. But also bad performance, visual trees, scopes,, special syntax for binding, hacking for performance gains and just like that, I was feeling like coding in XAML, only slightly worse:). After a short while I started thinking that it would be great to have something that was just a bit simpler, easier to follow and less of a hog, something more like my Winforms stuff. Enter React.

So I’d say it’s a full circle: React to Angular is pretty much like WinForms to XAML: performant, code-first approach (instead of templates), componentized, easy to debug. Sure, there’s always a tradeoff and that is something I wanted to explore.

In the series of posts I will go through my experience of building a sample app in React, the tools and libraries I used for development, and the suggested workflow.

And if you want to have a look at the app yourself check out the following link:

https://github.com/brunoAltinet/ReactAspNetCrudExample