Home Facebook’s Charles Jolley: Moving HTML5 Forward, This Time With Help

Facebook’s Charles Jolley: Moving HTML5 Forward, This Time With Help

One of the early promises of HTML5 was that it would become an enabler, giving smaller developers some of the power they needed to produce bigger tools on a broader platform. In recent months, however, it’s become a common channel for driving developers and users towards native platforms. Whereas last year, developers criticized Microsoft for invoking the phrase “native HTML5” with respect to Internet Explorer, today you can’t look anywhere in the HTML5 landscape without seeing some major provider’s native interests looming on the horizon.

And Facebook is among those with an interest in HTML5. Last week, Charles Jolley, a popular developer whose dream since his time at Apple was for a JavaScript library called Strobe.js to enable and then to distribute cross-platform apps, found himself and his colleagues working for Facebook. It’s difficult for anyone, including Jolley, to say exactly whether Facebook will be able to advance his original dream. But there were some things Jolley did want to say for the record, as soon as he was permitted to, and so he found himself speaking to ReadWriteWeb.

ReadWriteWeb: I am concerned about the fate of all the good work you’ve done up to now, and our readers will also be wondering, what happens to Strobe from here? Does it become a Facebook project? Does someone else take it over?

Charles Jolley, HTML5 engineer, Facebook: The short answer, Facebook is not taking on Strobe itself. [Strobe] is going to operate as an independent… to the extent that it continues. We are looking at different ways that we can keep the Strobe platform itself going, and that may or may not happen. Frankly, it’s a little bit up in the air as far as Strobe itself goes.

That being said, we think it’s worth pointing out: I started Strobe because I had this vision for delivering apps that work everywhere. I think it drives a lot of benefits for consumers. And that vision is something that’s very much shared by Facebook, and it’s a very big vision. Something I discovered over the last year at Strobe is how big that is, and how many resources will be needed to make it happen. So for me, one of the big reasons to make the decision to go forward with the team at Facebook was that they think Strobe is great as it is. It would have been difficult, with the structure that we had, to get [Strobe] to where we really needed it to go to achieve that big vision.

I see what I’m going to do at Facebook as a continuation of Strobe. The technology itself may or may not make that leap, but probably won’t to Facebook. It could go somewhere else, though. We’re not shutting it down right away.

RWW: But the objective that you started to achieve, even while you were at Apple, you see yourself being able to do that at Facebook even if you have to change your toolset to do it?

CJ: Yea. Here’s the thing: We’re very early in this space. The Web is extremely early, on mobile in particular, and all the toolsets out there are extremely young and immature. So in my mind, it’s not really so much about a specific toolset that will determine who wins. It’s going to be about who’s able to deliver momentum… and who’s able to deliver new, interesting features to consumers. When you look at a lot of different companies in the Web space, the HTML5 space, they’re primarily focused on making it easy for developers to build apps for lots of different platforms. Which is important, because that provides more choice to consumers. But other than that, it’s really like an alternate way of doing something that you’d already do. And while that’s interesting, I think what’s really more interesting is taking advantage of the unique things that only the Web can provide the consumer: the fact that you can discover an app and use it without having to install it, for example, is a really big deal. Apps can be very helpful when you’re out around town shopping, or just going about your daily activities, but if you haven’t installed them first, you’ll never know about them.

I don’t think we’re at the state yet where switching to a different toolset means the difference between success and failure. What really matters is who’s able to deliver on those features that, frankly, don’t exist yet.

RWW: We’ve seen the various stakeholders in the HTML5 space, and there are a lot of them, utilize HTML5 as leverage for their own technologies – certainly Microsoft, Apple (your former employer), Adobe (if not for Mobile Flash than for something). People perceive Facebook as right in that line, because Facebook Platform has its own toolset and methodology. Certainly it employs standards, but standards as a means to Facebook’s own ends. It’s easy to imagine the set of all HTML5 applications available through a Facebook mobile platform as something less than the set of all applications for a broader HTML5 platform. Is that the wrong point of view?

CJ: Yea, I think so. I do think that it’s pretty obvious, even from the announcements that Facebook made at F8 around OpenGraph, [such as] allowing you to [exchange] a lot more things than just “Like’s,” that they’re very interested in becoming a kind of fabric for the Internet, a useful service. And it’s not just about opting into the full Facebook stack, as it were.

When we were just talking initially, before I joined Facebook, my perspective was that Facebook has an incentive to be open compared to the other guys. Which is not really what most people think of at first, but that’s how I see it. If you look at their actual actions, it really backs that up.

RWW: Give me an example. What’s an example of Facebook having the incentive to be more open than, say, MobiUs or, for that matter, Apple’s App Store?

CJ: Third-party companies like MobiUs have no other incentive. But fundamentally, the thing is, platforms are all about adoption by end consumers, frankly. That’s what really matters. It’s not, the toolset being interesting; what really drives platforms is actual usage by consumers. So I see the third-party guys at Strobe as part of this. The reason we would all end up focusing on the developer was because those were the people we could reach. But the fact is, if we don’t have consumers that are going to consume apps that we build, it’s really an uphill battle. You end up focusing on making it easier for developers, which I think is way less interesting.

I think among the companies that do have access to a lot of consumers, their incentives are pretty clear. For Apple, it’s about selling you their hardware. They really want to keep you locked into that system. For Google, it’s somewhat about selling their hardware and additional services. Facebook does not have as many different interests. In fact, Facebook plays well with a lot of different services. A big chunk of everything Facebook talks about at an F8 conference is about being more open than investing in their platform. So my impression is that Facebook wants to be open about stuff.

RWW: Is there anything that a loyal Strobe.js developer should stop doing today, in light of the changes that will happen?

CJ: I think the big thing is that Strobe is a beta format, and it continues to operate in a beta mode. We don’t recommend, necessarily, that people go to production with this right now until Strobe has made it clear that they’re ready to support that. We’re going to keep the service up for a little while, but at this point, we’re trying to decide the best thing to do with it. If you’re an existing customer, play with it, you can still use it. The big thing is, it’s a new service, so one of the reasons that we went ahead and made this move to Facebook now is because we were actually getting pretty decent uptake with developers. But nobody had gone to production yet with anything. We didn’t want to have people depending on Strobe for their businesses, and then make a decision like this, because that would have a bigger impact on everybody. That’s one of the reasons we did this now; we wanted to be able to make whatever changes we have to make before people are running production software on it.

About ReadWrite’s Editorial Process

The ReadWrite Editorial policy involves closely monitoring the tech industry for major developments, new product launches, AI breakthroughs, video game releases and other newsworthy events. Editors assign relevant stories to staff writers or freelance contributors with expertise in each particular topic area. Before publication, articles go through a rigorous round of editing for accuracy, clarity, and to ensure adherence to ReadWrite's style guidelines.

Get the biggest tech headlines of the day delivered to your inbox

    By signing up, you agree to our Terms and Privacy Policy. Unsubscribe anytime.

    Tech News

    Explore the latest in tech with our Tech News. We cut through the noise for concise, relevant updates, keeping you informed about the rapidly evolving tech landscape with curated content that separates signal from noise.

    In-Depth Tech Stories

    Explore tech impact in In-Depth Stories. Narrative data journalism offers comprehensive analyses, revealing stories behind data. Understand industry trends for a deeper perspective on tech's intricate relationships with society.

    Expert Reviews

    Empower decisions with Expert Reviews, merging industry expertise and insightful analysis. Delve into tech intricacies, get the best deals, and stay ahead with our trustworthy guide to navigating the ever-changing tech market.