JavaScript for Line of Business Applications

As you might now react.js is a framework to create user interfaces in a web context. What is special about this? Is amazingly fast! (and supports server-side rendering) But has a downside, which requires you to change the way you think about web interfaces (see above).

There are a lot of tutorials about react.js but almost none, or very hard to find, in pure JavaScript. They all use the react.js special syntax. But I don't want to have another javascript pre-processor between each code change so this is the main reason.

The most complicated part of understanding react.js was how exatly the arguments passed in the components, and which ones can change and which can't...

Over the holidays I have discovered Facebook’s React, an interesting library for generating reactive user interfaces. I wanted to try it out in a real-world application, which reminded of one I still had running as a demo: sse-chat, a little chat application I wrote last summer for learning how to make Play Framework and AngularJS cooperate in a very basic way. So I thought, why not rewrite the client side using React, offering the exact same functionality as the AngularJS version. Both are available at the same time in the new version, with no changes to the backend code, except for the added route as both versions can be accessed in parallel.

The contraint of making it behave exactly like the AngularJS version was a great exercise and it really only took an afternoon to complete. Touching the existing demo version also had me notice that the live version of it had been up for like 4 months or so, without any trouble. I have the same experience with my BirdWatch application. Kudos to the Play Framework developers for that, and same for Akka, which provides the supervised Actor architecture presumably enabling such reliable server systems.

React has sparked a lot of interest in the Clojure community lately (and perhaps, hopefully the other way around as well), and for good reasons. At the very core, React lets you build up your DOM representation in a functional fashion by composing pure functions and you have a simple building block for everything: React components.

The core idea in Om is to simplify idiomatic state management with Clojurescript’s immutable datastructures, while still getting all the performance (and more), as well as adding some syntactic sugar.

I going to take a piece of the React tutorial and present in first Javascript, then Clojurescript and lastly using Om. Hopefully this will let us discover how plain Clojurescript interacts with React and inform us on some of the design decisions in Om.

So you know about React and how to build your own components. And you know you can run JavaScript inside PHP scripts, thanks to v8js. So nothing can stop you from rendering React components on the server side in PHP. Which means you send the first view from the server and then continue from there.

Part 1 ended with todos. The first one was to couple the server-side generated code with the client-side React, so that any updates past the initial page load will be handled by React's client JS, which is where React shines. Let's see how you can do just that.

One of the libraries gaining interest at the moment is Facebook's React JS library. It mainly concerns itself with "the V in MVC" and encourages developers to break their app into resuable, modular components. The Virtual DOM is a great feature on its own, and I encourage you to investigate React if you haven't yet.

In this post I'll be explaining how your React components can be used as CommonJS modules and then made browser friendly via Grunt. Using React this way (as opposed to Bower, or just downloading the files manually) allows easy re-use of components on the server as well as all the benefits of modularising your code.

We've known this for some time over here in the ClojureScript corner of the world - all of our collections are immutable and modeled directly on the original Clojure versions written in Java. Modern JavaScript engines have now been tuned to the point that it's no longer uncommon to see collection performance within 2.5X of the Java Virtual Machine.

Wait, wait, wait. What does the performance of persistent data structures have to do with the future of JavaScript MVCs?

A whole lot.

In today’s world of Javascript Application frameworks, design philosophy is the key differentiating factor. If you compare the popular JS frameworks, such as EmberJS, AngularJS, Backbone, Knockout, etc. you are sure to find differences in their abstractions, thinking models, and of course the terminology. This is a direct consequence of the underlying design philosophy. But, in principle, they all do one thing, which is to abstract out the DOM in such a way that you don’t deal directly with HTML Elements.

I personally think that a framework becomes interesting when it provides a set of abstractions that enable a different mode of thinking. In this aspect, react, the new JS framework from the folks at Facebook, will force you to rethink (to some extent) how you decompose the UI and interactions of your application. Having reached version 0.4.1 (as of this writing), React provides a surprisingly simple, yet effective model for building JS apps that mixes a delightful cocktail of a different kind.

In this article, we’ll explore the building blocks of React and embrace a style of thinking that may seem counter-intuitive on the first go. But, as the React docs say: “Give it Five Minutes” and then you will see how this approach will become more natural.