Menu

Colin Devroe

Reverse Engineer. Blogger.

Like? Subscribe.

React is an ecosystem

Jonathan Snook, on his learning curve when joining a new organization that uses React:

When people talk about learning React, I think that React, in and of itself, is relatively easy to understand. At least, I felt it was. I have components. I have JSX. I hit some hiccups with required keys or making sure I was wrapping child elements properly. But overall, I felt like I grasped it well enough.

Throw in everything else at the same time, though, and things get confusing because it’s hard at first to recognize what belongs to what. “Oh, this is Redux. That is React. That other thing is lodash. Got it.”

Most of the time React is merely a piece of an app’s overall puzzle. There are so many other pieces that make up the entire thing it can be an overwhelming experience.

I’m not new to building apps. In fact, the vast majority of my life I’ve been building apps. But learning React this year has been one of the more haphazard experiences of my career. It is not straightforward.

It isn’t that I think React itself is poorly made or documented. In fact, out of the box you can spin up a simple Hello World React app about as quickly as any other technology. But, as my boy Snook points out, it never ends there. Any somewhat mature app built on React has many, many other parts to learn.

He points most of them out in his blog post but I’ll reiterate here some of the things I personally see that could be overwhelming to people jumping in…

  • Build routines
  • Servers
  • State managers
  • Component hierarchies
  • JavaScript specifications
  • Myriad JavaScript packages (such as design libraries)
  • JavaScript style guides (naming and positioning of things)
  • CSS pre-processors (like SASS)

Any one or all of these things could potentially be new to a web developer coming into React. And, equally so, an app developer.

The only way to avoid being overwhelmed would be to take one bit at a time. Understand that what you’re looking at isn’t a single thing but a collection of many new things and that each of them will become natural to you over time. If your team is large enough, perhaps there are pieces you won’t need to worry too much about. But if not, you’re essentially diving into the “full stack” and will eventually become familiar with that entire thing.

I will say, lastly, that it has been very fun. React sort of combines the things I like about building apps with, say, Swift (typing, “stricter” rules, reusable bits) and the things I like about building things for the web (HTML, CSS, app runs on literally everything).

The Swift Era begins

Brent Simmons:

Though I don’t discount Catalyst’s usefulness — we will get lots of apps new to the Mac — the real news this week was about SwiftUI and the Combine framework. This, finally, is a new way of writing apps, and it’s based on Swift and not on Objective-C. It’s very much not from NeXT.

We were all biting our lip waiting for Marzipan/Catalyst to not suck and Apple was busy building an all-new way to create interactive UIs for their entire line-up of devices.

I’ve watched some of the SwiftUI sessions already. It looks very impressive. It has definitely taken cues from declarative web frameworks (in the best way possible) and brought those lessons into the more structured native app world*.

If I were rebuilding Summit, my never released iOS app, I’d throw out my entire UI layer and use SwiftUI without even thinking about it. As Brent wrote, SwiftUI is the future of UI development on all Apple platforms – both released and as-yet-unreleased – for the next few decades.

* It may be because I’m currently writing a React app, but I can’t help but notice the similarities between it and SwiftUI. To have a framework that manages state and updates the UI according to that state is such a powerful way to build modern UIs. Where SwiftUI keeps a “source of truth” about a view’s state, React keeps a “virtual DOM”. Great tools and each have their place.

Xamarin.Forms 3.1

David Ortinau on the Xamarin Blog:

Earlier this year, we surveyed Xamarin.Forms developers about the kinds of custom controls and extra platform code being written repeatedly that should be considered for support “in the box”. From these conversations, we created an initiative to deliver as many as we could in the next several releases. Just six weeks after shipping Xamarin.Forms 3.0 at Build 2018, we are excited to introduce Xamarin.Forms 3.1 with a batch of those enhancements to make your lives easier.

I shipped a Xamarin.Forms app on iOS and Android in 2017. I thoroughly enjoyed exploring and using Xamarin and in some circumstances, for some teams (especially those with deep C# experience) I’d wholeheartedly recommend Xamarin. The Xamarin team continues to keep on top of the latest OS/SDK/API releases as well as making it very easy for developers to ship cross platform applications.

Hopefully by the end of this year I’ll be able to say the same about React/React Native. I’m looking forward to exploring this deeper than I have in the past. I like to use different things so that I know what the best tool for each job is – rather than using the same tool for every project.

Facebook will drop the patent clause for React license

Matt Mullenweg:

I am surprised and excited to see the news that Facebook is going to drop the patent clause that I wrote about last week. They’ve announced that with React 16 the license will just be regular MIT with no patent addition. I applaud Facebook for making this move, and I hope that patent clause use is re-examined across all their open source projects.

Interesting outcome. Here is more context.

Matt Mullenweg on Automattic’s use of React

Matt Mullenweg:

I’m here to say that the Gutenberg team is going to take a step back and rewrite Gutenberg using a different library. It will likely delay Gutenberg at least a few weeks, and may push the release into next year.

Automattic will also use whatever we choose for Gutenberg to rewrite Calypso — that will take a lot longer, and Automattic still has no issue with the patents clause, but the long-term consistency with core is worth more than a short-term hit to Automattic’s business from a rewrite.

This is a big blow to React. The framework will still be massively popular and adopted but the number of developers in a thriving ecosystem like Automattic’s products – like WordPress – that now have to move onto something else is a big blow. Automattic’s continued use of React would have meant thousands of jobs for a long number of years.

As usual, Mullenweg sees the longterm angle, and weighs that against the core principles upon which his company was founded, and I believe he’s taking the right path.

Side note: I still see so many developers that deal with WordPress day-to-day that haven’t yet started learning JavaScript in earnest. Mullenweg himself has urged the WordPress community for the last several years to invest in learning JavaScript. So, if you haven’t already… jump in.