My ReactJS Thoughts

One of the pleasures of being a professional software developer is the never ending learning of new technologies and concepts.

The software development landscape is truly moving at a breakneck pace. When I first began my professional software developer career, it didn’t seem so fast paced.

Now with the advent of the internet, things just seem to move at the speed of light. Every day, I seem to read about a new programming language, or development tool or new framework.

One of the hot new frameworks that seems to be making waves is Facebook’s ReactJS.

It’s a Javascript framework library that helps developers create very fast and responsive HTML applications.

It’s so fast and responsive that Netflix uses React as it’s primary UI framework for their main TV interface. I’m a big fan and user of Netflix, and whether I’m on my tablet, my smartphone, my laptop or on an actual TV screen, the interface always seems fluid and fast.

So fast, it feels like a native software application, but of course, we know it’s a plain old HTML application powered by the power of the React libraries.

The problem that still exists today with building HTML software applications, is the time it takes for a web browser to translate allrelated tags from a web page, into the actual visible website we see inside a web browser.

This process of translating HTML code to the actual visible page is called ‘rendering the DOM’.

The DOM, or Document Object Model, is an object graph representation of each of the HTML elements of a page.

While you may see a website as a bunch of text, images, hyperlinks and other visual elements, a web browser sees the page as a bunch of object representations of each of those visual elements.

-html
-header
-body
-header
-paragraph
-image
-hyperlink

Everytime the page needs to refresh itself, whether you manually refresh the page yourself, or you submit a form or click a hyperlink to a different page, the web browser needs to make a brand new request to the web server, which re-downloads all the html, css, and javascript related files for the page, down to the client.

Once downloaded, the web browser needs to retranslate, or RENDER the HTML’s Document Object Model to their corresponding visible HTML elements.

The rendering process was and always has been the time consuming and resource intensive process for a web browser loading a page.

During the early years of web browsers and the internet, there was simply no way to get around this.

It wasn’t until the advent of AJAX (asynchronous Javascript and XML) that other ways were invented to get around this long and resource intensive process of rerendering a web page.

AJAX got around the long process of rerendering by only refreshing a PORTION of a web page’s DOM, and avoiding a full new roundtrip to a web server to redownload the HTML, CSS and Javascript files for a page.

Web applications like Gmail and Google Maps heavily use AJAX technology. If you watch closely, when you move around in Google Maps, you’ll see that the web browser never completely “refreshes” itself. Whenever you scroll around in a Google map, behind the scenes, AJAX only refreshes the pieces of the map that actually need to change.

The same sort of behavior happens with Google’s gmail application. You’ll never see any full page refreshes, after the initial page load into your browser.

It FEELS like a traditional client desktop application like Microsoft Word or Excel.

While AJAX works very well, it’s really a workaround for dealing with the problem of rendering a full web page.

This is how ReactJS came into existence.

Instead of bypassing a full page render, the way AJAX technology does, the React framework tackles it head on.

In fact, the most important method inside the ReactJS framework is called, surprise surprise! render()

ReactDOM.render(

Hello, world!

,
document.getElementById(‘root’)
);

What this simple hello world example is doing, is inserting a header tag into the DOM div element named ‘root’.

Behind the scenes, ReactJS builds what is called a “virtual DOM”….it’s a mirrored copy of the real DOM of a web page, but in memory.

When a web browser encounters a ReactJS powered page, the React framework compares the virtual DOM to the actual DOM of a web page.

It then compares the differences between what may have changed between the virtual DOM and the real DOM, whenever something changes on the page…say you enter some data in an html

… then the React framework will detect that something changed between the virtual and real DOM objects, calculate the smallest diff changes between the two DOM objects, and then based off those diff changes, update the real DOM, and refresh and rerender the page.

Because the web browser is only updating the DOM elements that have changed and not the entire DOM, the rendering process is much more efficient and quicker than a regular browser render process.

This results in page changes that feel almost instantaneous. Other UI frameworks like AngularJS handle UI rendering by needing to refresh the entire DOM, and thus cause slower render times.

This is precisely why companies such as Netflix and Facebook, which need to build HTML user interfaces, have chosen React … the UI is rendered much more quickly compared to other UI frameworks like AngularJS.

In fact, ReactJS is so efficient that Facebook has created an offshoot for ReactJS called “React Native”, which allows you to develop cross platform smartphone and tablet mobile applications, using only HTML and the ReactJS framework, to create the user interface layer.

It saves the developer time from having to create separate UI screens for Android, iOS and Windows mobile devices.

I’ve started to tinker with ReactJS in my spare time. It took me a little while to feel comfortable with it, as it handles UI rendering quite differently than AngularJS, which is the other popular Javascript based UI framework that many web developers are using today.

But after awhile, it started to make sense to me. The nice thing about using React, is you can create custom React components that are very modular. You could create custom React components to represent special textboxes, radio buttons and dropdown controls, and then combine those individual components into larger aggregate components.

In ReactJS code, the HTML and Javascript used to render a page is combined together into a single codebase. It makes it extremely easy to figure out, at a glance, what exactly the React code is doing.

In other UI frameworks, the HTML and Javascript is usually separated into separate files, and it takes more effort to mentally keep track of the interaction between the HTML elements and the javascript code that interacts with the HTML.

Undoubtedly, some developers are turned off by the combining of HTML and Javascript in the same code file…it can be argued that this violates the software design principle of the “single responsibility” pattern. It’s the reason why Javascript code is traditionally kept completely separate from HTML files, so that the HTML view is completely independent from any associated Javascript files.

While I can understand why some developers may be turned off by this melding of HTML and Javascript in a React code file, I think the tradeoff is worth the violation.

When I debug a ReactJS application in my browser developer tools in Chrome or Firefox, I can know exactly how any ReactJS component will ultimately look like in the final rendered web page, as well as any associated data that binds to any of the React components.

There are some caveats to using React over other competing UI frameworks like AngularJS.

React is a UI framework only. It’s only job is to render HTML to the browser in the most efficient way possible.

However it cannot handle other UI related functionality such as making server side calls to middle tier endpoints like Angular can. AngularJS is more of a full featured UI framework.

But that doesn’t mean you can’t accomplish the same things in React…they just won’t be bundled in the same framework as AngularJS is.

ReactJS and AngularJS seem to be the two most popular Javascript UI frameworks in use today.

As usual with competing technologies, there will always be raised the question of which framework is better and/or which one will ultimately dominate software development.

I won’t try to pretend to be an oracle and prophecy which one will end up on top.

As a developer, we should always expect the only constant in software development is CHANGE.

I’m sure some new framework is just around the corner, to address perceived shortcomings that developers find in React and Angular.

But I find it’s never a waste of time learning and trying new things. Even when computer languages and frameworks go out of style and eventually into obsoleteness, the knowledge and experience gained from learning those technologies never goes away and I find knowledge builds upon previous knowledge.

I believe it’s well worth a developer’s time to look into the React framework … it could end up being a valuable new tool in a developer’s software development toolbox.

← The Power of the Tech Stack Ecosystem My Ideal Work Computer →