Follow-up to Why I’m Leaving React Behind

On Sunday, I posted what I thought was a fairly innocuous post about my decision to move away from React. Wow, I had no idea I was an influential writer. The storm (at least relative to my normal state of being) was impressive. I did want to clarify some things and answer some of the questions I got posed. Unfortunately, Twitter isn’t a good medium to have that sort of discourse.

Firstly, I have nothing but respect for React as a technology. More than that, the React team has changed the conversation when it comes to dynamic web properties that can scale. That is a testament not only to the React team for the awesome technical work, but also to Facebook for funding it and allowing it to be published on GitHub. Dan Abramov (@dan_abramov) is just one of the team members who is active in the community.  If I just cared about technology, this wouldn’t even be a discussion.

My problem is only with the license.  There are two parts.  Firstly, I feel the patent clause is overly broad.  Secondly, I feel the patent clause should be where everyone looks at the license – in the license file.

I have been asked more than once if I consulted a lawyer to get a legal opinion.

No I didn’t.  More than that, if I have to get a legal opinion as an individual developer on every license for every piece of open source technology I use, my coffers will drain pretty quickly.  Lawyers are expensive.  I look for nice normal standard licenses – licenses like the MIT license.  I understand those licenses and they have a lot of legal opinion (even if they don’t have a lot of legal tests in the courts).  If I need legal advice on whether I can use a license or not, I’m not going to use the software.

I have owned a small business.  Businesses can and should protect themselves from patent trolls and bad licenses.  If you are a business owner, you should get your own legal opinion on whether the PATENT clause is good for your business or a problem for your business.

Facebook is not (currently) evil, and I don’t expect them to become evil overnight.  I have not heard of Facebook going on the offensive with their patent portfolio and only they can comment on why they felt the need to add the patent clause (although I can guess it has more to do with patent trolls).   However, the fact remains that companies are different from individuals.  Company policy changes and there are any number of examples of patent litigation in the technology sector.

Personally, I think Facebook screwed up here.  More than that, I think the entire legal licensing community has screwed up.  They have screwed up by not providing appropriate licenses that are readable by non-legals, protect the companies that support open source, yet give other companies the freedom to use the technology.

It also goes further than that.  The US patent system is broken and severely needs an overhaul to ensure continuing investment in software technologies that benefit all.  Our software development community is vibrant and full of people who genuinely want to help.  We should be working towards protecting that community.

You should come to your own conclusion.  If you need a legal opinion on whether it is safe for your company to be using React, go seek one and let us know what you find out.


Why I’m leaving React behind

In the recent past, I’ve worked rather extensively on learning React and its ecosystem. It fits with my world view of things. I’m not a great programmer. I’m not going to learn five different frameworks in order to work. However, I’m leaving React behind and learning another framework now.

Why? Well, it has to do with licensing.

As an individual developer, you might think “wait, React is open source, so what?” Well, it isn’t my definition of open source. Facebook slipped a fairly broad patent protection into the license agreement. Put on basic terms, if I sue Facebook, my license to use React is terminated. The actual wording is as follows:

The license granted hereunder will terminate, automatically and without notice, if you (or any of your subsidiaries, corporate affiliates or agents) initiate directly or indirectly, or take a direct financial interest in, any Patent Assertion: (i) against Facebook or any of its subsidiaries or corporate affiliates

But I’m just an individual developer. I’m highly unlikely to sue anyone, much less Facebook.  Except that I am then rewarding Facebook for being a bully. Let’s say I’m not an individual developer. I’m a small business. Facebook uses my technology without permission. I can sue them for that and would likely win. However, my right to use React has just terminated. I might have won the battle, but if I based my business on a React platform, I’ve just lost the war. My company is shuttered.

The React license is what I would call encumbered. It has provisions that would give most legal people fits. Sneakily, they have not placed this information in the handy LICENSE file. Instead, they have placed it in a PATENTS file.

I’m an individual developer. My non-use of React will not persuade Facebook to remove that patent claim. But I can express my displeasure with my feet. If
Facebook wants to do this here, how long before the use of Facebook login and social features has the same restrictions? I don’t care to find out. I’ll reorganize my side projects around companies that work with developers.

So, what frameworks will I look at? The world has moved on since I last looked at frameworks. Fortunately, most of the frameworks I am going to look at have a nice friendly MIT-like license. Angular 2, Ember and Aurelia all are looking good. A bonus is that they inevitably support ES2015, which I now see as a requirement. Polymer isn’t quite a full framework, but has a nice friendly BSD-style license. None of these have a patent clause.

Are there others I should be looking at?  Let me know in the comments.

What do I use to write a Mobile App?

I’m at Dreamforce this week, manning the Microsoft Azure booth in the Developer Zone. It’s been a really fun and busy week explaining all the things that can be done. This post isn’t about that. It’s about a question I got on the first day of the conference – what do you write mobile apps in? The answer – it depends. It depends on a lot of factors, but only a couple matter and they are in this post.

What sort of App are you writing?

In my mind, there are three types of app. We are all familiar with Consumer Apps. Facebook and Twitter fall into this category as do the vast majority of games. In Consumer Apps you are targeting the individual with your service. The service and your app are central to the product you are offering. In this case you are interested in engagement and getting users to use your app. Business Apps are used by businesses to allow consumers to access their services. The major difference is what is the service? Is the app just one method of accessing the service or are there other methods. The canonical example of the Business App is a banking app. The bank offers you a service (money management) and you just so happen to have an app for that. You could just as easily forego the app and access the money management features via a web site, ATM or at the bank branch. Many shopping apps appear here.

Random thought: Is Amazon a Consumer App or a Business App? I tend to think of it as a business app because the core thing that Amazon is selling is not the app – it’s the products you buy.

The final category is Enterprise Apps. These are produced by enterprises for their employees. Your friendly cable technician may have an app on an iPad that tells him all about your service details. That app will never appear on the device App Store – it is distributed via a private enterprise store or via an enterprise mobile device management platform like InTune or MobileIron.

So, what’s the big deal as to the type? In the case of the Consumer App you want the app to follow all the magical guidelines that the device manufacturers put forth for app designs for the platform. You want the customer to be comfortable with the app and that means making it act like all the other apps on the phone. With a Business App, the design is secondary to the brand that is being pushed. All Amazon apps look similar and act similar, irrespective of the platform that is running on them. Finally, Enterprise Apps are more concerned with functionality than a particular design. Design rules can be broken easily. This design stuff feeds into an interesting decision later on.

What sort of Developers do you have?

I was talking to a development manager, so this was particularly relevant to him. However, even if you are an individual developer, you still have your own strengths and weaknesses. There are basically three camps:

  1. Native Apps are written in Objective-C or Swift (for iOS), Java (for Android) or C#.NET (for Windows Phone).
  2. Cross-Platform Native Apps are written in C#.NET generally (although C++ is available too), with the assistance of Xamarin and use a compilation step to compile to native.
  3. Hybrid Apps are written in HTML5, CSS and JavaScript (or TypeScript) via Apache Cordova (or PhoneGap) and then wrapped in a WebView to display the UI.

Native Apps should always look like the native platform, but you have to write the code two or three times – once for iOS, once for Android and once for Windows. Cross Platform Native Apps allow you to write a single code-base for all your business logic – probably about 90% of the app – and then adjust the UI according to design rules for the other 10%. You still have to write a bunch of code for each platform, but the bulk of it is common. The result is a set of native apps each with their own look and feel.

Hybrid Apps are rendered in a WebView (which is a restricted sandbox) so you can use pretty much the same code for a website as for Cordova. However, they suffer from the same code base being used for everything. That means Android and iOS apps look identical. Realistically, this means you are going to write the code like you do a cross-platform app – with a central project for the common code and then a UI-specific piece for each device. Even then, you are likely to be disappointed with the “native look” because there really aren’t any standardized controls to just drop in. You also have to be careful about hardware device support – not all devices can handle all hardware compoenents. If you want to support Touch ID (on iPhone), you are likely to be doing some special code for that or moving to a cross-platform native app.

Bringing it Together

If you are producing a consumer app, then you probably want the closest and best native performance and design paradigm – that means Objective-C or Swift for iOS, and Java for Android and C#.NET for Windows Phone.
If you are producing a business app, then you probably want the widest coverage while still getting the performance – that means Cross-Platform Native Apps, or treating the project like a consumer app.
If you are producing an enterprise app, then you probably want common functionality across all platforms – that means Hybrid or Cross-Platform Native Apps.

Now that you have decided what skillsets you need, you can narrow down by my final criteria:

Write the app in what you know

If you know C#.NET and don’t know Objective-C, why are you trying to write a native iOS app? Just get Xamarin and build the app using C#.NET. Similarly, if all you have are JavaScript skills, go with a Hybrid App. Unless there is a specific (commercial or personal) reason to learn a new language or develop a new skill set, just go with what you know. It’s enough work to learn a new framework – you probably don’t want to be learning a new language at the same time.

Moving to

I’ve run my blog on a self-hosted WordPress install on Microsoft Azure. For reference, I’m running it as a Website with a small Basic instance. It’s worked thus far but it costs me about $30 a month to run it. That’s over $300 a year, which – for my small blog, is more than I’m willing to spend. In addition, I’ve had several outages of my linked MySQL database on Azure where I’ve had zero visibility into why it was down and no service messages to show that it was anything but a fault.

So, expensive and unreliable don’t mix. Goodbye Microsoft Azure! I’m sure your larger offerings are good, but for a personal blog, it’s just too much. Hello, which – for what I want – is $99/year. I could probably get away with the free blog (3Gb and styling), but I want my own domain name and you shouldn’t have to watch ads to read my thoughts.

What do I lose from all this? Well, plugins. comes with a series of plugins, but I had my own set. Specifically, I had syntax highlighting as a plugin. Fortunately, has a solution for that.

I hope you enjoy the updated site and join me every other day as I discuss something.

A side note: As part of the set up for my blog, I had to contact support. I think you don’t really know a company until you contact support. Then you know just about everything that a company stands for. It took 24 hours to handle my request (but it was a Sunday!), but their support group was awesome. The domain change is in my court now.

Update on the transition: There were two issues that I had to work through. The first is source code. Under my self-hosted version of WordPress, I used pre tags and a plugin to do line numbers and syntax highlighting. Under, one uses short codes for syntax highlighting. So I have to go through all my posts (there are 80 of them) and convert the tags to short codes. Secondly, the links to my own posts (when I refer to previous posts) didn’t get converted. Hence I have to convert them all myself – I’m doing that at the same time I do the code tagging. As a result, the older posts will take a while to have readable source code. I hope you be patient with me while I do the conversion.

Now, back to our regularly scheduled discussion.