Reflections On React

June 27, 2017 0 Comments

Reflections On React

 

 

I’ve been digging back into React lately after being absent from the scene for some time. The last time that I worked with React, React.createClass was how you created components, React Router was at version 2 and JSX was something that people used, but they didn’t necessarily feel good about it. Now that I’m back like Slim Shady, I took a bit of time to bring myself up to speed on what’s changed and where we are now.

Keep in mind that I am the new kid. None of what you are going to read here is news. These are just my musings as a “the last guy to know”.

The first thing that stood out to me is how well React has withstood the test of time.

Like a Giant Sequoia, React has proven to be an immutable (get it?) object.

Creative Commons Base of General Sherman” by oliveoligarchy is licensed under CC BY 2.0

The JavaScript world is a ruthless place. Nobody will hesitate to call your framework ugly, talk about how it has ruined JavaScript or write diatribes on why it’s the reason the entire web is slow. Once a weakness in your pattern, architecture or implementation is identified, the community can turn like a pack of wolves and said framework turns into an anti-pattern overnight.

Not so for React. If anything, the level with which people appreciate React seems to only increase on the daily.

React has effortlessly weathered the brutal JavaScript landscape. The biggest testament to this is the list of notable companies who are using it in the highly competitive consumer space. These include web behemoths like Netflix, AirBnB, Pinterest and countless others.

It has also managed to survive the past 5 years without a post on how it has ruined everything or has some huge glaring drawback that nobody can see until it’s too late. That’s an astounding feat. Rarely do we get libraries that are so well designed and written that they seem to sit as closely to the cusp of perfection.

One of the more curious things is how much developers love React. It seems to endear itself to developers the more they use it. Instead of getting frustrated with React as their projects get larger, it appears that it’s really only then that they appreciate its real value.

That’s an important side-effect of projects that are born out of necessity vs simply trying to create another JavaScript framework. I was at a certain JavaScript framework conference once and someone asked a question about how to build a large applications. The answer they got from the creator was “We were kind of hoping you would tell us”.

React has already been down the path of an enormous application. Any frustrations that developers are going to find as applications scale have likely already been discovered. The intrinsic value of systems that were forged in the fire of real life cannot be measured.

All of this success for React is remarkable when you consider that it asks developers to put XML inside of their JavaScript; a concept that seems like it was born out of the worst ideas.

JSX is like the movie Thor: it looks terrible on paper, but in actuality it’s a shockingly good experience.

I still remember reading the docs for React about 5 years ago and thinking, WTAF. You want me to put XML in JavaScript? Is there a hidden camera in here somewhere?

Nobody could have predicted how well this would work. As it turns out, JSX in JavaScript is a great idea because the only other option in template literals. Not that those are so terrible, but simply because JSX offers you more. Take for instance the syntax highlighting that is available in tools like Visual Studio Code…

That’s using Emmet INSIDE of a JavaScript file in Visual Studio Code. Note that this also works with template literals, but you don’t get the nice syntax highlighting for your markup the way that you do with JSX.

JSX also prevents the munging of logic into HTML attributes — well almost. We’ll get to that in a minute. But for the most part, we can just write JavaScript, which is what we really want to do. I still have a hard time with looping constructs that are born of attributes. It’s something that you get used to, but it doesn’t feel as natural as just writing, well, a loop.

React has also moved considerably in the direction of using plain JavaScript constructs as much as possible. Some of them are GREAT! and others are kind of weird. Not bad, just weird.

I love how React has dropped createClass in favor of extend Component. Using ES6 classes just feels right, and frankly, I would rather write myFunc() {} over function myFunc. I know that’s a small thing, but I just feel so much better doing it.

I have since been informed by cody lindley that the goal in react is to use simple function components when at all possible in favor of classes. So I suppose one won’t find themselves in class components too often, but when you do, there is a bit of weirdness that comes along for the ride.

This one is weird for me. According to the docs, string refs have “some issues”, but darn if they weren’t easy to use. Just ref="someRef" and then this.refs.someRef. Easy. Intuitive.

Now we’re using object refs and the syntax feels a bit awkward to me. Not bad awkward, just like, “Middle School Sadie Hawkins Dance” awkward.

<input ref={(input) => { myInput = input }}

Does that not feel a bit heavy to anyone else? The answer that I commonly hear on these things is “React was made by smart folks. They know what they are doing”. I am not debating that fact, but ignorance is my mutant power. Stand back while I use it.

It just seems like if you have a lot of element refs and looping in your code, the JSX could get soupy in a hurry.

The other thing that I find weird is the new binding syntax for attaching the your classes scope to methods.

this.myFunc = this.myFunc.bind(this);

Frankly, that seems opposite of how functions on a class should work. Yes, I am aware that it is a limitation of JavaScript, but then a pre-processor like TypeScript would fit this bill nicely. I realize Flow is Facebook’s jam, but TypeScript is everyone else’s, so I would like to see React at that party.

Thanks to Atanas Korchev who pointed out that I can just use a Lambda instead because Babel supports that…

myFunc = () => {
this.setState...
}

…which is exactly what I want to do, so I guess strike that one from the weird list.

The last thing that I looked at is the state of React UI libraries in 2017.

It all started with this tweet here…

I got a lot of different replies. A lot of people said “Roll your own”! I was also introduced to some very interesting ones like Bulma and Tachyons. While there are some great CSS library choices out there, I was referring more to the super complex widgets like grids with grouping, sorting, drag and drop, frozen columns, editing, virtualized scrolling — when I say “UI Library”, I mean the kind of components nobody wants to build.

I heard some folks even say “I don’t use React that way”. I don’t entirely understand that sentiment other than maybe they are saying they don’t build complex UIs? That’s a notion I tend to agree with, but the fact of the matter is that the bulk of developers out there are building forms over data applications with requirements like “display this data in this browser app with a Gantt chart”. Nobody wants to build a Gantt chart. If that’s the requirement, I need to know where I can download a Gantt chart for React and move on with my life as quickly as at all possible.

Here are some of the options that we have right now…

Lot’s of choices, but none of them are going to give you a Pivot Grid or a Scheduler. For that you are going to need something like Kendo UI or Sencha. Those are both comprehensive, but neither offers a set of native React Components yet. What you’ll get are their standard components wrapped with React.

There are a lot of smaller 1-off packages out there that do a fantastic job of supplying these more complex widgets. I suppose my point is that there is no comprehensive library that contains the kitchen sink. It reminds me a lot of the old jQuery days.

I remember saying several years ago that I thought that React could be the new jQuery, and I think that’s absolutely true. It’s mature, it’s proven and it’s universally adored. React is going to be the standard by which we measure all others until someone else comes up with an entirely different way of building web sites and we get to learn everything all over again.

Until then…


Tag cloud