Garann Means

What happened to my JavaScript phone?

Not long ago, it seemed like JavaScript devices were going to free JS developers from the constraints of the browser and let us control every aspect of our lives as easily as we once controlled hover menus. Though nodebots were captivating, many of us were anxious for the JS device revolution to reach a more mundane destination: our phones. And yet today the constraints of the mobile landscape look not much different from several years ago. We have the same two operating systems, the same two app stores, and same option to write a native app or push people to save what is still mostly a bookmark. How did we cover so little distance, given the enthusiasm, resources, and potential that appeared to exist, and more importantly, how close can we come to a JavaScript phone today?

Portrait photo of Garann Means

Transcript

>> All right, hi. My name's Garann, and I would like to talk today what happened to our JavaScript phones? I want to start off with a hypothesis which is that nobody in this room actually has a hacker phone. About five to six years ago, I feel like I could have asked you all this kind of conference if you had some kind of experimental advice running Firefox OS, Ubuntu on your person right now, and there would be a fair amount of hands in the air given the demographic of this conference. Today, I doubt there are any of those devices here in the room, unless you brought them here specifically to troll me? Am I right? I'm assuming that I am! So I think it's fair to say that hacker phones as a concept kind of disappeared.

We just gave up, and we went back to our iPhones and our Androids. It wasn't for no reason.

We got better cameras, faster modems, and greater stability. These phones seemed to get more and more expensive. I can't even fathom how I would have justified paying nearly a grand for my first Nokia, but they also become more impressive and able to replace our real computers. So you could say that they cost more, because they help us accomplish for. They go far beyond what we could have done with hacker phones.

Except they don't work like real computers. We're locked into somebody else's vision of this sort of like Ikea office computer that looks pretty convincing, but it's actually quite limited. If you don't like the vision that you're offered, you have at maximum one alternative option. So maybe that's why I'm up here today wondering what happened to JavaScript phones which would blow up this field and put the future of these computers back into the hands of your average JavaScript developer, the way we grabbed the web back from IE5 and Flash.

Interestingly, what happened involves a bit of all the things I just mentioned. The stunning cameras, the connection speeds, the stability of the firmware.

And it might seem superficially like this is triumph of the free market where the products that won do so because they were simply better products. It's actually more of a triumph of old boys' network, monopolies, the obtuseness of infrastructure, and fashion having lots and lots of capital to throw at something so that nobody else can compete on your level. It's not a story of the natural even Lukes of products to become better, it's the story of capitalism rewarding capitalism. Let's go back five or six years when some of us thought it might play out differently.

There are a few things relevant to examine from that time that should have culminated in a great JavaScript phone - the interest in Cordova and the tools, the exponential adoption of Node, and Node bots being like artisan coffee brewing, or bread-making or knitting, whatever you're into these days, of the day. People searching for ways of web skills on their phones, putting Node where they could think of and everybody seemed to have a soldiering iron. If that is not a recipe for a JavaScript phone, I don't know what is. Some of your babies, you will remember that time, so let's talk about the details.

First, the state of mobile development was really unresolved. People were already developing native apps, and they were making quite decent money off them because there wasn't as much competition.

So, naturally, developers who didn't work in the native languages of the platforms wanted a piece of that too or their employers or client did, and from there, we got things like phone gap. Phone gap was bought by Adobe and became Cordova, a tool to allow JavaScript developers to write a JavaScript application and compile it to native code. There was a lot of focus on making normal hosted web apps and websites mobile-friendly. There are tool kits such as emulators, and intensive theorising about responsive design that started appearing out of nowhere to meet the needs of smartphones.

You could compare it to the current consensus we should be producing accessibility websites, but in this case, we actually went and did something about it. At this point, testing cross-browser had been a significant and limiting piece of work recently. Adding mobile browsers generated mobile apps to the list of things to check felt pretty natural, and everybody wanted to be on the everybody's phone and we all just did it. That's the front-end. On the back-end, you have Node, which at this point is still fairly new, or at least is still being treated that way.

It's gone through a few years of people insisting it's merely a novelty, and people insisting it will never have the robustness of Engine X, or Ruby, or the corporate assured reliability of .NET. Express has existed a few minutes after Node was released so people have been using Node as a web server all this time. Even the Node community itself has been trying to distance Node from being a web server. I always read it as an unfortunate giving into pressure from hacker news-type people to be more serious.

There is nothing more serious than hardware. At this time, you can assume that you will see people playing with circuit boards with lights on them, and somebody's nocopter will be sitting on the ground, gathering speculation about what actually needs to be fixed, and how sweet it's going to be when it actually runs. The hardware is just marketing being useful things to do with JavaScript, not necessarily ma'am-up and not individual interfaces. Why not? Scripting languages are lovely to work with if introducing the additional layer of abstraction doesn't slow things down massively.

JavaScript has been getting faster, more powerful for years at this point, so that easier adoption makes it a very attractive interface to code against. There's one more big things that is happening at this point in time, which is that there is a JavaScript phone, and at a conference like this, a bunch of people would have had one.

We talked a little bit about - we will talk about Firefox OS in a second. You may or may not have noticed there's an elephant in this room. Maybe it's more clear when it seemed like we could have a JavaScript phone, but what made us think if we should? If you're thinking that was a really good idea, why didn't that happen? Why do you think that? Personally, I wondered if today it's too late? I don't know if people still feel this way, or if the ship has sailed? Several years ago, though, it was too early to wonder that. Another advantage for Apple and Google sharing the smartphone monopoly is they have had the privilege of training us all to use their products. If you think back, though, people used to have tons of complaints about the phone interfaces.

But if your echo chamber is like mine, that sort of grumbling has died down over the recent years, and if anything, you're left with a sniping back and forth about whether Android or iOS is better. Probably not even that, though. Because we have no or limited opportunity for personalisation, and for deviation from this sort of single-sanction set of use cases, there's nothing on our smartphones really to get invested in now. That didn't used to be true. There are probably even now things on your phone that kind of annoy you, but you found workarounds for them.

Like maybe the mail client isn't full-featured enough, or the maps give bad directions, the system preferences seem intentionally hard to set and confusing. I think the big reason that people wanted a JavaScript phone is because several years ago, the most serious JavaScript developers still have experience writing interfaces. Even if we weren't designers per se, we felt we could do better. Because phones at that point were like this trash heap of badly functioning operating system and carrier-installed apps and the third-party apps that might have improved that situation were treated and super sketchy.

I believe people wanted JavaScript phones because they wanted to make the software on their phones live up to the promise of the hardware. So you've been very patient waiting for me to say something about Firefox OS, and now I'm going to say something about Firefox OS. Mozilla had a project called Boot to Gecko that was meant to give us JavaScript phones. Mozilla was probably the only company that could have pulled this off, being a huge company that nonetheless maintained an open back-and-forth with the web community as a whole and isn't the growth diabetic focused business the same as Apple and Google were.

The idea was to bring a smartphone to everybody by using the power of web technologies. That's clearly not happened.

To understand why, we need to talk a bit about hardware and what goes on inside these little machines. Your phone is a tiny little computer, but it's also kind of not. It contains a lot of the same pieces as the computers that you work with, the processor, modem, sound, and graphics cards. They're in a different format.

In the old days, personal computers were hobbyist devices, and you could build it yourself to has your own machine. Even big-brand desktop machines as recently as the dawn of wildly available cell phones were the things that you expected to customise, but that's never been the case with phones. Handheld devices have always been largely single units that weren't intended to be customised, let alone built from spare parts. Today, you can still get a GSM shield, and you can make something similar to a phone but a long way from from the definition of mobile phone. Similarly, you can sit at your computer and do pretty much everything your phone does, just using different networks, but we still don't recognise your computer as a phone.

The size is a big part of what makes a phone a phone, but the size is only important because it offers portability. And portability is only useful if you can connect at that cell network. This the - the protocol is needed to negotiate a negotiation with a cellphone tower are only licensed to carriers. It's not quite as exclusive as it might sound.

Even the carriers who have their own communications infrastructure will regularly rent space on other networks for the client's communications. But it's another hurdle for anyone who wants to start making phones. This hardware needs to be certified by the individual carriers that it's going to connect to, and then it also needs to be approved by the relevant governing bodies in whatever countries it will be used in, for example, the FCC in the United States. And none of the hardware in the phone exists in isolation, so, if you love writing integration tests and stress tests, you will probably spend a lifetime being entertained by getting the hardware certified.

On the other hand, if you have some different agenda by actually releasing something, just passing tests and getting certifications could kind of end up being a lot. This is where, as JavaScript developers who, as likely as not have a front-end and web background when on unfamiliar territory may seem hostile, because the regulation the around telecommunications are strict.

If connection drops because it's something to do with hardware that you're trying to distribute, you can't just like throw up an error page with a cheeky gif as ask people to reload. Like who would you ask? The modem, the operating system? The phone's tight integration means if your hardware fucks up, you have to notify every component involved. If your hardware is fucking up and makes your component look bad, there goes your certification from that manufacturer. Say you're building a cellphone and consider writing an application with a bunch of micro frameworks or using an all-in-one framework that makes every decision for you. You might be attracted to using micro frameworks because you can get the best tool for every job and nothing you don't need, but there is overhead associated with making sure that all of the micro frameworks co-operate together, eventually, if every micro framework you npm install require you to pay fees and be certified, you may say fuck it and use a monolith.

Your phone is a chip with a big high-resolution screen on the other. Everything it does is the same bit of hardware. Even the antenna is designed to meander through the phone's guts and takes up all the available space left by the geography of the chip. There's no market where you can go and buy the most high-end pieces of the system on a chip of your phone. The iPhone's chip is designed by specifically Apple and produced exclusively for them.

You can't get those parts. Fairphone couldn't get those parts and Mozilla can't get those parts. When a company produces a phone, it produces the whole. Anyone who wants to come along and make a JavaScript phone would have to have the same variety of skills and large piles of currency and Apple and Google have at their disposal to make something comparable to an iPhone or a Android.

No everyone gives the a shit about having the fastest camera or modem. Some feature phones using KOS which is based on Firefox OS, and some like the Nokia we boots using old-school operating systems. If lots of people can come and build a feature phone, how come Mozilla couldn't build a $25 smartphone with a slightly shittier camera? The answer, which you probably already knew is they could have. Mozilla could have bet the whole company on becoming a carrier producing hardware giving people lovely $25 JavaScript phones.

According to people who worked on the project, they nearly did that anyway, rather than throw behind becoming a carrier, they looked for carriers who would become a partner. Becoming a carrier is time-consuming and expensive, so those partners wanted to ensure there would be lots of profits in it for them, load the phone down with their apps and get various marketing managers.

If you're a web standards - if you want to give the world $25 phones, that's not what you're about. Are there companies that could have acted as the carrier needed by Mozilla? Yes. Do such people benefit from such a phone give the same carriers many thousands of dollars out of a sense of profession that requires them to earn the latest tech? Definitely. Is there incentive for those carriers to back a competitor who break up their monopolies? No.

That's business, and that is what happened to your JavaScript phone. Sorry to be depressing. Now what? You're still sitting here desperately wishing you had a JavaScript phone, there are a few things you could do. Which you would choose depends on what a phone actually is to you. For example, most people probably define as a phone as something you make and receive calls on, right? Who uses up all their voice minutes every month? I don't think a lot in the people do.

So you could build your own voice and SMS phone with hobby I have the hardware. You could wipe the firmware on your smartphone and put a more hackable operating system on it. You could work through approved channels and JavaScript apps that improve on the things you don't like, our you could rebel. To be honest, I avoid working with hardware because it's a little fiddly for me, but I've spoken to colleagues and peers about this, and it turns out there are a few little chips that you can use to do traditional phone stuff, and an interface you can control it JavaScript.

I work with Nexmo that provides an API to do this kind of communications development, so I feel pretty confident it's possible. You could also just put together a piece of hardware that works like a My-Fi, and use an API like Nexmo's voice over IP, not worrying about carriers, cellphone towers, and all of that, and in theory weep going. You could add a nice screen, a graphics chip, an antenna, and you would end up with a large thing, not one that matched the power, quality, or size of commercial smartphones. You could tick all the boxes.

Then you would only have to write the firmware for that, so that it functioned together seamlessly and automatically, and you didn't have to start an app and click a button to connect to the near est cellphone tower. Your grandchildren might be able to finish the work you started.

So is that the real way forward? Maybe. There are projects like the Light Phone that make for an interesting argument that the ability to have appealing hardware once you scale back functionality is a good trade-off. Maybe a community-driven JavaScript phone starts somewhere simple like that, rather than trying to compete with smartphones out of the gate, and it builds on the hardware and firmware iteratively. Developers as a whole don't have a great patience for patience, and team work so don't hold your breath. You might not have a lot of friends running custom firmware on their custom hardware these days but the projects still exist.

If you have different versions of Android, you can replace the operating system you like better. This is another option I can't speak to you from personal experience, like many people I experimented with Linux in college, and it's interesting that the hellscape of finding drivers for the perfectly nice hardware I already owned and were in my operating system then to use then is the same one I would find myself in if I installed a version of Linux on my nice modern Android and gave up on using the camera or maps ever again. The risk in flashing your phone is that the very nice hardware that lets the manufacturer maybe taken their monopoly is operated by a nice proprietary driver, and any operating system under the sun could use those drivers and would end up a pretty shit monopoly. Things in your phone that have access to the system typically get signed by code that lives in a special secure area of the phone, which has its own processor and memory sealed off from the rest of the phone. If you wipe your phone, you lose access to that area, which you could see at a helpful way of stopping ne'er do wells from taking over your - or a cynical way of protecting intellectual property.

Probably, it's both. Whether good, bad, or neutral, though, the security is going to fuck up your phone if you flash it, and a lot of people learned that the hard way a few years ago, and that's probably why people don't do it as much any more. There are probably plenty of people in this room who I've barely addressed you at all, that means those who write apps intended to be on smartphones. To be clear, there's obviously nothing wrong with that.

Does it accomplish the goal of providing nicer alternatives to the apps that the phone comes with? It absolutely does. You can make - you can't make those apps automatic, and, in some cases get people to move your client but move the default to a back screen somewhere so they don't click on it. If you can create compelling software, it works. If you want JavaScript functionality on your phone, the least risky most effective route by far is to write apps.

It doesn't look like the revolution we were promised, though, does it? I have to ask you to indulge my nostalgia as we go back 15 to 20 years. This around the time of the web standards movement which you may remember a lot of arguing about CSS versus tables, or something to do with XHTML.

If you were doing much web development around that time, there was a period when developers like us argued over and over for taking the more difficult, more expensive, and less reliable path of throwing out perfectly good existing product to sign on to still very theoretical standards and turn our backs on the powerful, established proprietary languages like Action Script that worked great. Every day folks using the web weren't clamouring for us to break their fucking web pages. That push came from developers like us. I kind of think much of the evidence suggests that it will never happen, that a similar rebellion is coming for mobile phones.

I don't know exactly what that would look like, and if it has anything to do with JavaScript, but I it has something to do with the fatigue expressed by people intentionally trading in their smartphones for feature phones. If the world is deciding this they don't literally need a thousand other smart phones in their pocket, just to take pictures and send the occasional text, maybe it's really open alternative has a chance to compete. If people switch to feature phones and don't use as much data and do their texting via T9, maybe they don't want to pay for below-the-pack age contracts with the carriers, and so the carriers' power comes to a threat, and hardware companies fragment and they seek to serve a wider variety of interest. It's a lot of maybes. Even the tools that are closed and locked in now began with people working together on protocols, electronics, and computer science in public.

If you lock people into a mono culture where the most exciting innovation you can offer them is removing their head phone jacks, they will start moving in other directions to find a way out of it. I think a JavaScript phone might still be out there. Thanks! [Cheering and applause].