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.

I’ve spent most of the day writing JavaScript (fun!) which was an opportunity to try out ES 2018, the MDN docs, and laugh while reading Eevee’s take on the latest JavaScript spec updates.

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.

Den Temple attends NativeScript Developer Day[s]

Den Temple, fellow NEPA.js attendee, hopped a bus to New York City for a developer conference:

A three-hour bus ride and one sleepless night in a hostel later, I find myself attending NativeScript Developer Day in NYC.

Glad he shared his notes.

Reminder: attend meetups!

Attending September’s NEPA.js meetup

On September 12th, NEPA.js held its September meetup. Anthony Altieri presented on beacons – the typically small Bluetooth devices that “chirp” some very basic information multiple times per second allowing app developers to understand the proximity of a user. This allows for things like understanding where a shopper is in a retail space.

His overview of the devices, the spec, some of the software, and the differences between iOS and Android, and iBeacon and Eddystone – was a really nice introduction into the space. He did a great job.

I learned a lot during his presentation. Thanks to him for putting it together.

If you haven’t yet been to a NEPA.js and you live in our area – I implore you to check one out. It is consistently attended, always fun, and isn’t always focused solely on JavaScript. But even if it was, it is worth your time.

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.

Tom Dale: “Compilers are the new frameworks”

Tom Dale, Senior Staff Software Engineer at LinkedIn and co-creator of Ember.js, in a post where he argues that compilers are the new web frameworks:

Native code tends to have the luxury of not really caring about file size—a small 40MB iOS app would get you laughed out of the room on the web. And AAA game titles accept minutes-long load times in exchange for consistent 60fps performance, but I shudder to think what a 30 second load time would do to the conversion rate of your e-commerce site, 60fps or not.

While I agree with most of his post, that compilers are becoming increasingly more a part of a web developers workflow and thus becoming very important to learn, this particular bit isn’t a fair one-to-one comparison in my opinion.

Web apps do not need to pre-load every single asset onto the device prior to running. If you were to weigh a fully native app next to its counterpart web app* you’d likely get a very similar result. It is just that a native app is downloaded mostly all at once and a web app can be loaded as needed.

But his point remains, more and more web apps are looking more like native apps. They are compiled, loaded, and completely obfuscated from the source code they originally started out at. I’m not sure if I feel this is good or bad for the web. But I do know that the barrier to entry in web development is higher than ever.

* Most web apps that have a direct counterpart on a mobile platform share lots, if not all, code these days so these comparisons are getting tougher and tougher to do fairly.

A unique color for every address in the world

A recent, yet-to-be-announced client project had me designing a mobile app interface that dealt a lot with showing locations and events that are happening at certain locations (how is that for vague? sorry).

While I utilized the brand’s colors to represent certain sections of the app I wanted the app to have tons of colors in order to portray a sense of fun throughout the app. But how could I incorporate pinks and yellows and bright greens without the overall brand disappearing?

After toying with a few design ideas I had an idea to create a unique color for every address in the world. This would result in two benefits; first, each location was then branded as a color, and second, every user would see that location as the same color. If I were a user of the app here in the US and I flew to Spain and looked at a location for an event  there, I would see the same exact colors representing that address as the person that lived in Spain and created that event.

Since I wasn’t to be the developer of the mobile application I wanted to avoid the possible pushback this idea might receive from that team. I didn’t want to add burden to the other people on the project by showing a design mockup and a set of requirements and then walking away. I wanted it to have zero overhead for the developers.

One of the solutions I discarded was generating a random color each time an event location was added to the service and then store the color for that address in a database. While this solution is relatively simple to implement it was no good. It adds more work for the developers and they have to maintain the datastore indefinitely. Several other ideas with the same caveats came to mind and I quickly tossed them into the bin.

Once I eliminated all of the ways I didn’t want to solve this problem – the solution came pretty quickly.

Since every address is already unique, I just needed to find a way to represent an address that could be turned into a color. In other words, I wanted the address itself to represent a unique color. And I wanted to do it in realtime as the application’s UI loaded.

So I jumped into JavaScript and began working it out. Here is what I settled on:

This solution allows for just over 16.5 million colors. Far more than this app will likely require during its lifespan.

Here is a demo of the process and if you view the source you can see the code at work. It is fairly simple to follow.

Oh, there was an issue that I ran into with this solution that was fun to solve. If the background color that was generated was too dark the text became hard to read. So digging around I found a way to determine the luminosity of the background color and thus change the text to something a bit lighter in those instances. That too is shown in the demo.

I was then able to repurpose this demo code and give production-ready code to the developer that is going to ship in the app. When that ships I’ll write more about it.