Skip to main content

I'm Really Excited About ReactJS

I’m really excited about ReactJS.
I’ve let my tentative excitement grow for a while now, with a few experiments and tutorials and lots of reading. There is a strong habit of Shiny New Thing syndrome in the web world, and I’m as guilty of it as anyone else, so a lot of effort was made to avoid jumping on the bandwagon too soon. After building my first simple but complete application with ReactJS (and Flux) I’m absolutely convinced it is the best option for me to build web interfaces going forward.
To share my excitement and to preserve my thinking, in case I come back in a couple years wondering how I got started with ReactJS, I’m going to outline all the reasons I’m so excited about ReactJS.

ReactJS is Fast in Every Way That Matters

Saying a software library is “fast” is often a red flag for not having a holistic view of the trade offs. Faster than what? Fast by what measurements and under which conditions? I can say that ReactJS is fast because I’m not saying one vague thing, but saying ReactJS is fast in all of the ways that it needs to be fast. It isn’t just fast as software executing on a machine, but as a tool for humans completing tasks.
ReactJS is Fast in the following ways.
  • It doesn’t take long to get started with ReactJS. You can learn the basics to get started actually using it productively very quickly, without a lot of upfront costs or cutting corners that you wouldn’t in production usage. Learning has a very forgiving slope compared to some of the more complicated Javascript UI layers available to choose from these days.
  • Owing largely to the simplicities that make learning ReactJS so fast and easy is the amazing swiftness with which you can actually develop within an application built with it. Refactoring that would take a day can be done in less than half an hour. Building new large components can be accomplished before you finish your cup of coffee. All the common development tasks around using ReactJS are just wonderfully streamlined. I think, more than most libraries, ReactJS was really able to consider its use by developers as a form of User Experience and optimized those experiences impressively.
  • It is fast in the usual way people mean when they talk about software: the things it is built to do it does very quickly. It is largely defined by how amazingly it outperforms other DOM rendering options, owed in large part to its use of a virtual DOM layer.
  • It doesn’t have a huge impact on page load sizes. Other options can add enormous costs to your page load, and while ReactJS isn’t necessary tiny it is one of the smallest libraries among those it would compete against in the same space. What’s more, if you need to make it even smaller you can try React Lite, a stripped down implementation of React that removes the server-side rendering most of us don’t use and comes in around 20k minimized with full API compatibility to drop in as a replacement for the full React. This is an amazing cost savings.
This library is fast to learn, fast to build with, fast at rendering your UI, and fast to get to the user.

ReactJS can be a Small or Big Part of Your Project

There are two sides to a spectrum, in my opinion, to the way a library or framework: either a library is a dependency with relatively little weight compared to your own project or it is a larger thing within which your project feels to simply “fit into”. This is the library versus framework debate, and it took me a while to get a handle on where ReactJS sits on this spectrum. It gets compared to Angular a lot and compared among other Javascript frameworks, and for good reason as it solves so many of the same problems and enjoys as vibrant an ecosystem around it. But ReactJS’s own webpage describes it as a library and, I think, deliberately.
What I’ve come to realize about ReactJS is that it has managed to be both. It is easy and light enough to be included as a dependency in a project even if you only needed it for a single component, either one you needed to create in one isolated part of your application or even if you included React as only a secondary dependency of an off-the-shelf widget you found and wanted to drop into your project. In this way it almost feels like jQuery’s lightness, only there because its the glue so many plugins depend on. At the same time, ReactJS and its Flux implementations can serve as wider role in organizing a project and act as a foundation upon with a huge ecosystem of helpers, tooling, and components are blossoming faster than anyone can keep up with.
Simply put, ReactJS is the only option I’ve found that feels it can work equally well as either a small or large part of your project. This is very important to me, because I have needs on both sides of that spectrum and I hate the idea of needing to invest my time in so many different options for so many different situations. I want to hold fewer things in my head and narrow my focus. Generalization is nice and still important, but there is a growing need for a specialization that is hard to achieve with a constantly changing set of projects in my work.

ReactJS has Great Support

Finally, it is really important to look at a non- technical aspect of a dependency before you depend on it very deeply. There are many projects out there that fill the same shoes as ReactJS, and some of them even have impressive accomplishments that objectively set them apart from it! Elm and Mercury and Riot are great contenders beside React, each with their own very positive attributes that set them apart and make them absolutely great options.
Community and backing is as important as technical considerations for many of us and in many situations. In many cases, these are easily outweigh the technical considerations. We need to depend on ecosystems within which we can rely on the backing (Facebook in this case) and the community (React is going to naturally attract more people than the clones it inspires) and for my situations these aspects outweigh the many great reasons I might otherwise have picked something a little more technically exciting.
I’ve recently been looking into Redux, which sits beside ReactJS and fills the Flux prescription Facebook is encouraging everyone in the community towards. What really struck me as amazing is how huge the ecosystem within just this one subset of React is and that realization is what finally sold me.


So, for the foreseeable future my personal focus as a web developer is with feet firmly planted in growing my understanding and experience with ReactJS. I’m going to be building more small web apps to practice this craft, using them as testbeds for learning new pieces of the ReactJS landscape. I’m going to be building some of my own libraries and components, sharing them with the community and writing about them here.
I’m really excited about ReactJS.


Popular posts from this blog

CARDIAC: The Cardboard Computer

I am just so excited about this. CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer.  One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC? It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on

Statement Functions

At a small suggestion in #python, I wrote up a simple module that allows the use of many python statements in places requiring statements. This post serves as the announcement and documentation. You can find the release here . The pattern is the statement's keyword appended with a single underscore, so the first, of course, is print_. The example writes 'some+text' to an IOString for a URL query string. This mostly follows what it seems the print function will be in py3k. print_("some", "text", outfile=query_iostring, sep="+", end="") An obvious second choice was to wrap if statements. They take a condition value, and expect a truth value or callback an an optional else value or callback. Values and callbacks are named if_true, cb_true, if_false, and cb_false. if_(raw_input("Continue?")=="Y", cb_true=play_game, cb_false=quit) Of course, often your else might be an error case, so raising an exception could be useful

How To Teach Software Development

How To Teach Software Development Introduction Developers Quality Control Motivation Execution Businesses Students Schools Education is broken. Education about software development is even more broken. It is a sad observation of the industry from my eyes. I come to see good developers from what should be great educations as survivors, more than anything. Do they get a headstart from their education or do they overcome it? This is the first part in a series on software education. I want to open a discussion here. Please comment if you have thoughts. Blog about it, yourself. Write about how you disagree with me. Write more if you don't. We have a troubled industry. We care enough to do something about it. We hark on the bad developers the way people used to point at freak shows, but we only hurt ourselves but not improving the situation. We have to deal with their bad code. We are the twenty percent and we can't talk to the eighty percent, by definition, so we need to impro