Reaction Conf

Trek Glowacki
3 min readJan 30, 2015

--

In 2007 I started to hear development requests that sounded like this:

… and can you make it work like that thing on Facebook/Gmail/Google maps?

At the time I was writing mostly Ruby (and mostly Rails), which meant server rendered applications with very limited client side interactions. What people were asking for, by alluding to these applications, was experiences with a higher level of interactivity and reactivity than server rendered applications can deliver.

2007 customer demand sadly outstripped tooling supply. The JavaScript ecosystem wasn’t even in its present nascent form. So, this sent me on frantic goose chase that involved mustaches, jQuery, and even React-style templates (which are not a new idea… it’s been kicking around for a while).

Part of this quest led me to SproutCore. In hindsight, SproutCore is clearly not the answer to building browser applications but at the time there was a lot of potential. SproutCore wasn’t there yet, but with enough community person power I felt like it could get there. Like a good open source citizen, I chipped in.

Enter Apple, Inc.

In 2008 Apple purchased the company that created SproutCore and based their early browser application suite on the framework. “Great,” thought a much younger and more naive me “now that there’s a big contributor with big resources, the project should steam ahead!”

What actually happened was the project went dark. PRs kept pouring in, Issues kept being reported, but merges and fixes were rare.

Then, after months, a new SproutCore came out. Some of those Issues were resolved but most of those PRs were suddenly unmergable. Apple’s vision of open source was one where Apple makes decisions that benefit Apple, behind closed doors at Apple, and then pushes those downstream to you as a consumer. Your contributions? Not needed. Your feedback? Not important.

This was the first time I got burned by corporation style open source.

Enter Google.

The Apple/SproutCore event is a great example of the potential for cooperate OSS anti-pattern because it’s so egregiously awful, but even milder examples can still be painful.

When Angular’s popularity started to climb, I hesitated to recommend it. Not because I work on a “competing framework” (Angular 1.x wasn’t created for the same audience as Ember.js), but for the very reason many people picked it as a technology: it was backed by Google.

This felt insane. Google? Google, who have a long history of suddenly killing technologies because it eats into other products? Google, who maintain several similar projects?

“But,” a slightly younger, slightly more naive me thought, “Google probably knows better.”

Then the Angular 2.0 announcement came out and people were mad enough that articles were published reminding them to keep calm. Ultimately I think Angular 2.0 will be a better framework, but I sympathize with people who liked Angular 1.x and feel left out in the cold now.

Enter Facebook.

Just over a year ago, Facebook released their view-rendering library React. I like React. I like how clear its explicit data passing makes code. I even like its React.DOM/jsx templates (I’ve written apps in this style of templates as far back as 2010). In many ways, I think of React as an R&D department for Ember.

Yesterday at ReactConf Facebook announced React Native:

This is exactly the large, ambitious type of project that a community driven framework has difficulty doing. Something like this requires resources (time and money) that are hard to find outside a revenue generating organization. I’m excited to see it and want to dig into its internals.

But,

Corporate-style open source makes me very nervous. Very, very nervous.

--

--

Trek Glowacki

I helped start @workantile, coupon queen’d at @GrouponEng. Doing the startup thing at Flash Recruit. @emberjs core emeritu. @paul_irish once called me ‘a hero’