During the past few months, I’ve been experimenting with a lot of new JavaScript libraries and frameworks. I have found it impossible to keep up with majority of developments in JavaScript, and the best tools coming out solve the problems they aim to solve but also have their downsides as any other tool.
ReactJS
ReactJS is great, it thinks outside the box and distinguishes itself from other libraries and frameworks very well. This isn’t just hype – it actually does what it says it wants to do – which is never having to touch the DOM – keeping your application simple and DOM seemingly stateless by abstracting this problem away – this is done by using a diff algorithm against a snapshot of the previous DOM. This keeps your application very simple to maintain if you follow some strict structure or use a framework that helps you with the structure.
The only concern I have is what if you actually want to maintain the state of certain elements yourself and they are within the child view of another React component? What about shapes? svg? canvas? style? does that mean we have to re-render the entire canvas every time state changes? how does this impact our application? If we change the way ReactJS handles this, then aren’t we using a tool not quite right for the job? I wondered about these due to my recent high usage of RaphaelJS where it would be very expensive to do a complete re-render.
AngularJS
AngularJS is very well designed, keeping different concerns of your code separate, I like the fact that they added dependency injection as one of the main parts of Angular.
The only real concern I have with AngularJS is performance, I am not a big fan of the dirty checking solution for web applications, it will just never perform as well as games due to the simple fact that we are not running our code natively on the OS. I consider performance to be a must feature for any type of application, and if that means I have to find a lot of hacky solutions later down the line to get the performance I so desperately need, then that is a huge deal breaker for me. This performance issue may be fixed with the introduction of Object.observe – which makes me wonder if AngularJS is trying to think too ahead of time.
I am also concerned with the way 2-way data-binding works, sure it has it’s merits, such as not ever having to worry that your model is out-of-sync with the view, but in practice, it’s not very often that you actually need to know what the user is doing in real-time. The bindonce solution is a good solution for this problem, but what about a different use case? what if I want to to only capture the data when the user clicks a button? What if you don’t want to waste precious cpu cycles just to update the model to reflect the real-state of the view?
I’m not too certain of AngularJS 2.0 – if it is going to be indeed 100% modular, I hope that they focus on actual end-user in mind first before anything else. Testability and Modularity should never be the primary goal of any project.
Flux
Excited about the move to Flux – granted, it’s not a completely a new concept. But I am convinced of the benefits after trying it out. The problem that it tries to solve is architectural and it succeeds in making your application scalable by making each UI component decoupled from the rest of the system and keeping event and data flow simple – it’s like HMVC on steroids for single-page web applications. I do however think that writing code in the “flux” way makes your code slightly more verbose – but the benefits make this an insignificant trade-off. I also have some concerns with performance considering that all events are passed down to all the stores, and that being passed further down to components – this is something I may have have to look at some time in the future.
Moving forward
JavaScript is in an exciting phase – it is definitely heading the right direction, learning from the mistakes from the last tools and patterns and improving from it.
Would I ever consider using Node.js as my primary back-end solution? No, ASP.NET MVC is as close to perfect for me as it is – it’s flexible, it’s mature and well supported. With the current addition of async with C# 5.0 along with SingalR, it is a very complete solution. Although I definitely prefer the way you do async operations with node.js, simply because of async being supported from day one – everything is built to support async, it’s not quite the same with C# yet – I would definitely consider node.js for heavy I/O and real-time applications. I also prefer the simplicity and async model of node.js.
I feel that over the last couple of months, trying to keep up with how JavaScript is moving forward, the tools, libraries, frameworks, ES6 – it all seems to be moving faster than I have time to spare.
New toys are fun, but we, as developers should be more focused on solving problems that impact the actual application at hand that we are building rather than trying to figure out how to do x, y, z which can slow down production, so think very carefully before using any of new frameworks or libraries for production – do experiment with them whenever you want to have a bit of fun – I myself have been using all of these during my spare time just to try them out for different use cases.
