字幕表 動画を再生する
>> 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].