Development

Atlassian Rebuilds HipChat Using Facebook’s React and Idea of Web Reform

13 Feb 2015 12:03pm, by

“React,” in retrospect, may have been an ill-fitting name for Facebook’s innovative page rendering library. In just over one year’s time, it has proven to be the most pro-active addition to the Web developer’s arsenal, changing the way entire JavaScript projects are being considered and planned.

The latest sign of how React.JS (now generally known as just “React”) is redefining Web project development comes from Atlassian. It acquired the social collaboration app HipChat back in March 2012, and for most of that time since, had its developers concentrate on renovating its mobile apps. The Web version was languishing until just a few months ago, when the dev team realized React could enable them not only to start completely over, but to prototype a completely new Web app in just a few days.

“React is truly simple. The public API can be memorized in a day,” wrote Atlassian developer Rich Manalang on Tuesday, in a post for his company’s blog. “Once you’ve built your first component, it’s easy to build the next one with confidence that it’ll just work.”

A Change of View

When Facebook’s developers introduced the world last year to React.JS, right away they caught some flak from factions of the Web community. Some of it was for appearing to use HTML code as markup inside JavaScript, but much of it was for brazenly disobeying the principles of MVC architecture. If you change the data upon which a model is based, the naysayers said, you must dispatch a change to its corresponding view. The view must be kept up-to-date.

It’s a principle that makes perfect sense in a local application running on a server. But it doesn’t scale when it’s running on the Web.

React’s original goal was to overcome this scale issue, where a data model can effectively be mutated by tens of thousands of simultaneous inputs. Rather than generate the client-side AJAX code for re-rendering every little change in real-time, like other frameworks, React generates a layer of abstraction between the server’s rendering of a page and the client’s rendering. Changes to the model are reflected on the server side, but only the differences between the two renderings are sent to the client.

Facebook now says this abstraction reduced the computational complexity of Web rendering by two orders of magnitude, from that of a matrix multiplication problem O(n3) to that of an addition problem Θ(n). And like certain other innovations that emerged from Web service providers in recent years, developers are discovering React could actually resolve a much greater problem than it was originally designed for: the functional difference between a Web app and a native app.

The Declarative Imperative

Native apps are better apps. At least that’s the opinion of a growing number of mobile platform users who are using browsers less and less. Native apps simply flow better. They’re quicker to respond to user input. They contain visual elements that users can touch and manipulate like tangible objects. And users don’t have to navigate through those elements like an accounting application from the 1980s.

HipChat’s developers had known since the spring of 2012 they would have to incorporate their new parent company’s design directives. As Manalang tells the story, his team had examined the prospects of rewriting HipChat’s existing client-side code using jQuery, and concluded they ran the very serious risk of “making the existing Web client actually worse instead of better.”

What drew them to React, Manalang stated, is its server-side, internal rendering of the Document Object Model.

“The most expensive operation most Web apps suffer is mutating the DOM,” he writes. “React’s approach is to maintain a virtual representation of the DOM which allows it to calculate differences in the DOM so that it only mutates the part of the DOM that actually needs to be updated. This is a huge benefit!”

While Facebook early on pitched React’s adherence to JavaScript as a virtue , the truth is, it’s somewhat different. In fact, it incorporates a markup syntax called JSX (the part that opponents ridiculed earlier) that resembles a kind of embedded XML, but which actually recompiles to a purer, longer form of JavaScript.

The difference enables developers to implement declarative code — a style of programming that was more dominant prior to the advent of the Web, and which is more concurrent with building native code for mobile apps. A declarative style specifies what the changes are, and expects the underlying library to carry out that declaration. By comparison, with the imperative style that became common (some would say, colloquial) when the Web took root, the instructions for carrying out each alteration or “mutation” to the model is much more explicit and iterative; it’s not assumed that any interpreter or library knows how to do a task for itself.

“React’s declarative model means that we can always know the state of the UI given a specific set of data,” states Dave Elkan, a member of Atlassian’s development team, in an e-mail message to The New Stack. “Combine that with [Facebook’s] Flux pattern of unidirectional data flow, and we have the ability to create a component and update its UI by modifying the underlying data. React simply takes care of the rest.”

Imperative style may be easier for some to learn, and then to utilize, but it does not scale well at all. What’s more, the iOS, Android, and Web platforms would each expect a function to render elements and utilize resources differently, using explicitly stated directions specially crafted to each platform’s particular needs.

Abstracting the Web Along with Everyone Else

The declarative style is more implicit. That virtue opens up the possibility, said Manalang, for Atlassian to develop components that are more reusable across platforms. HipChat’s having been built on native platforms to begin with made its programming model more declarative from the beginning. As Atlassian’s Elkan tells us, that fact enabled his team to adopt React like a Web framework, without having to change the programming model created for native apps.

At an in-house developers’ conference last week, Facebook announced it is creating React Native, a set of libraries enabling code crafted for React on the Web to be more easily repurposed for Android and iOS. React Native may help other firms not in Atlassian’s position to adapt their existing Web platforms to a more declarative model that would be easier to apply to native apps also.

The long-term ramifications of Facebook’s latest announcement have yet to be considered. So far, Facebook has been far more successful than even its ardent supporters had hoped in building an open source platform for the distribution of apps in new and exciting contexts. But just four months after W3C declared HTML5 effectively done, an alternative and attractive mode of Web programming comes along that could push it aside: a methodology that’s both easier to implement and applicable to platforms outside the Web.

“Not only does [React] make our Web application more robust, but it also greatly increases code maintainability and testability, as changes only need to be made once and packaged in our native clients,” states Atlassian’s Dave Elkan. “We’re already embedding the messages panel into the next versions of our native Windows and Linux clients with an eye to expanding to other places in the future.”

That sounds much more like a plan than a reaction.

Feature image via Flickr Creative Commons.

A newsletter digest of the week’s most important stories & analyses.