Mobile Web Performance and the Hardware Revolution
Last month I argued that the return to Native Apps was killing the potential of the coming hardware revolution. In it, I discuss how the platform fragmentation that we are seeing as a natural result of software coming to an increasing number of devices.
There can be good reasons for software fragmentation: the use cases and capabilities of a refrigerator, a TV, and mobile phone are all very different. However, fragmentation within a category, and even across similar categories, is superfluous and was, prior to the introduction of mobile, a solved problem thanks to web apps.
Speed is the other big issue when it comes to the new wave of devices around us. As discussed at length in his excellent article on the topic (which should be required reading for anyone participating in the native vs. mobile web debate), Drew Crawford points out that there are serious performance issues on mobile that you don’t see on the desktop which cripple mobile web’s performance capabilities. As illustrated in Crawford’s chart below, the iPhone 4S has browser performance that edges out IE8 in 2010, and doesn’t come close to the fast browsers available at the time.
I can’t argue with Crawford’s numbers - mobile web is too slow for serious web apps today. Facebook’s HTML5 reversal should be evidence enough of that. However, as Crawford pointed out, the iPhone 4S (released in late 2011) is comparable to a slow browser in 2010, so we should expect phones released this year, like the iPhone 5S/6, to have performance near slow browsers in 2012, which is not bad when it comes to web app development. Even if hardware gains are all that we have to look forward to in mobile, it would be a mistake to bet against Moore’s law when it comes to more powerful computing making its way to phones and other devices.
While mobile devices will always lag behind their desktop peers, they will soon be “good enough” for most applications that matter to most users. Facebook’s experiment with mobile web was a failure, but as with many things in technology, it was a failure because it was before its time - in a few years (or sooner), a mobile web Facebook experience will be near native, and close enough to make the development and deployment benefits outweigh the performance costs.
Performance is an issue that time and Moore’s law will solve, but platform fragmentation is a drag on innovation that the march of technology can’t fix.
Facebook Should Buy Stripe
Facebook recently released a “Payments Test” that allowed users at certain e-commerce websites to autofill their billing info as it’s stored on Facebook’s website (from previous Facebook purchases). There was some speculation that this was an attempt to compete with the likes of PayPal as a full-fledged payment processor, but it has since been confirmed that this is more akin to Chrome saving form details, and therefore not a threat to processors.
According to TechCrunch, the strategy behind the autofill feature is to be able to track the ROI of ad placements on Facebook — they are tracking similar metrics with Datalogix in physical stores. The hope of course is that if Facebook can prove the effectiveness of their ads (which has been disputed in the past) they can win more advertising dollars.
Facebook is (was?) in an extraordinarily unique position of being a nearly universal identity provider on the web. In the early days of Facebook Platform it seemed as though “Connect with Facebook” was going to obliterate home-grown authentication systems. While the expectations are much lower now, Facebook Connect is still an incredibly popular choice, especially for the average internet user.
Ads are not the only way to monetize their position as an identity provider. In fact, they may be the least interesting way. Google revolutionized advertising, and has able to make killing on it, but that doesn’t mean that ads are the only way forward.
While there are tons of ways to take advantage of being an identity provider, payments is an absolute slam dunk. Payments online are still roughly the same as they were 10 years ago, and there is still a lot of FUD regarding the process for end users. Having a single provider that people trust, and that has their billing information on file, would be a game changer for online commerce.
In the same way that Apple has created an environment in the App Store and iTunes Store that leads to easy, nearly thoughtless purchases, so could Facebook create a safe, simple environment for every single transaction that happens online.
Were Facebook to tackle such a huge opportunity, they would need to ask themselves whether to build or buy a solution.
While they have an enormous amount of technical talent, the regulatory hurdles involved with payments makes an acquisition much more attractive, and who better than Stripe, a developer-friendly processor that is rapidly gaining marketshare on the simple premise that accepting credit cards should be easy for the people who build websites.
Stripe could continue building an amazing product, evangelizing more and more developers to switch from something like PayPal, with the added benefit that with the flip of a switch, they could enable “Pay with Facebook” - a seamless way for users that already have payment data stored to check out in seconds.
The boost in conversions that developers would see would do the marketing for the “Pay with Facebook” option itself, and if Stripe allowed customers to save billing information with Facebook after every purchase, Pay with Facebook could rapidly become a contender in payment processing, even alongside such behemoths as Braintree, PayPal, and Square .
There are good reasons why Facebook shouldn’t pursue payments, of course. It takes away from their core focus, and they would be competing in a space with well-established competitors (and possibly their customers).
The reality is, however, that Facebook’s current business focus is advertising, and taking focus away from that to work on payments seems like a prudent choice. In addition, Facebook Payments would compliment advertising - imagine an ad that allowed users to make a purchase with a single click, and all without leaving Facebook.
There is very well-established competition in this space, but none of the big competitors have addressed the social aspect of commerce, or established themselves as anything close to a universal identity provider, both of which could be critical for the future of e-commerce.
It seems (and this is mostly anecdotal) that Facebook’s social product is losing steam, and they might not have this opportunity for long. Building Facebook Payments would solidify their position as necessary infrastructure for the next wave of innovation, regardless of whether the social product continues to be as successful as it has been.
The looming question in my mind is why this strategy didn’t work for Google. A huge percentage of the internet population has a Google account, and Google has a good reputation with the public and with developers. They created Google Checkout to compete with PayPal, but are retiring it this year to focus on Google Wallet, a mobile payments play. With Stripe’s success, it seems that getting merchants to switch processors isn’t impossible, so perhaps Google’s execution was simply lacking.
I still think $FB is a buy, but only if they take advantage of the opportunity that they have by making a play into an open space, like payments with Stripe. They may not have an unlimited amount of time to convert their popularity into a long-lasting business.
 - Google is a player in this space too, but they are now focusing on mobile with Google Wallet. PayPal and Square are also heavily involved in mobile. Facebook going after traditional e-commerce might seem like skating to where the puck is, but I think that having customers accustomed to “paying with Facebook,” having their billing information on file, and having a large installed base on mobile would go a long way towards whatever happens with mobile payments.
Filequeue supports Streams
Filequeue, the module I wrote to fix an issue I was having while trying to open too many files at once in Node.js, now supports Node 0.10.x, and has support for the new
WriteStream methods that were included with the 0.10.x release.
Adding streams support required that I rewrite most of the module to be more flexible in terms of method signatures allowed (previously, a callback as the final argument was required for the module to function properly).
While doing the rewrite, I also changed the way new methods were added to pass the Grep Test. The actual logic of what’s happening when the methods are called is much clearer now, which should make maintenance and extension much easier, both for myself and other contributors.
Filequeue is available on NPM.