Is it just me or are browsers fun again?
Who would have believed? Microsoft releasing their JavaScript engine as open source. And under a permissive MIT license.
While there are many browsers and vendors out there, there are probably only 4 that matter: Chrome (Google), Firefox (Mozilla), Edge (Microsoft) and Safari (Apple).
Who haven’t I included?
- Microsoft’s Internet Explorer. Microsoft is actively transitioning away from it to Edge
- The rest of the pack, as far as I can tell, are nice wrappers around Chromium – and are negligible in their market share anyway
What should we expect in 2016 from the browsers? A lot.
Google Chrome
For Google, Chrome is an important piece of the puzzle. It lives in the web and the more control points it has over access to information the better positioned it is.
The ongoing activity of Google in WebRTC is part of the picture, and probably not the biggest one.
Google is the company with the least amount of regard to legacy code that there is. When something requires fixing, Google developers are not afraid to rewrite and refactor large components, and management allows and probably even encourages this behavior – something I haven’t seen anywhere else.
A few examples for recent years:
- Google forked WebKit into Blink, essentially replacing the page rendering inside the browser. The first order of the day after the fork? Spring cleaning – removing code that isn’t necessary for Chrome
- Google switched EVERYTHING from OpenSSL to BoringSSL. OpenSSL seemed to have some vulnerabilities lately, so Googlers took the time to fork it, clean it up – and deploy the new project across Google
- Introducing SPDY and getting HTTP/2 out the door
That said, it seems that Google have been somewhat complacent in the area of speed and size with Chrome. I am sure the Chrome team is aware of it and working hard to fix it, but the results haven’t been encouraging enough. This will change – mostly because of the actions of the other browser vendors.
Mozilla Firefox
Mozilla is in transition. From relying on Google as its main benefactor to spreading the risks.
In the past few months though, Mozilla has started trimming down its projects:
- Mozilla plans on splitting Thunderbird, its email client, from Mozilla
- Mozilla stopped developing and selling Firefox OS smartphones – I wonder how will this affect its relationship with Telefonica, TokBox and the Hello project
These changes indicate that Mozilla understood it can’t just try and replicate every cool new Google project and open source it – it will now focus on making Firefox better. This is a much needed focus, with Firefox slipping in market share for quite some time now.
On the browser front, the notable changes Firefox is making are around privacy and the pornprivacy mode.
Microsoft Edge
Edge is new. It is a complete rewrite of what a browser is. It is speedy, clean and with huge potential. It has its own adoption challenges to overcome (mainly people comfortable enough with Chrome and not caring to try out Edge).
What to do? Microsoft just open sourced the JavaScript engine in Edge – Chakra. It shows some interesting performance results that seem to rival Chrome’s V8. The more interesting aspect of it, is the clear intent in getting Chakra into Node.js as a V8 alternative. I am not sure if it will work, but it does have merit. It shows to me that:
- A browser/webapp today is split into two – frontend and backend (we already knew that). More often than not, these days the backend is based on a Node.js framework. Microsoft wants to be a part of that backend, probably to end up licensing Windows 10 on servers
- JavaScript today is more than a browser scripting language. A JavaScript engine’s health/popularity/importance relies on the ecosystem around it – which is why Microsoft ended up open sourcing it
I am sure there’s an engineer at Google already tasked at reviewing the code of Chakra once it gets a public git repository.
Edge is trying to move the envelope. This will challenge Google further with Chrome – always a good thing.
Apple Safari
Safari seems second place at Apple. It is working, but not much is said or done about it.
We hear a lot of rumblings about WebRTC in Safari lately. How will this shape into Safari, iOS and Mac is anyone’s guess. The bigger question is will this be the only significant browser change to be introduced by Apple or part of a larger overhaul?
Why is this important?
The web isn’t standing still. It is evolving and changing. Earlier this year, WebAssembly was announced – an effort to speed up the interactive web.
While many believe that apps have won over the web when it comes to development, we need to remember two things:
- There are times when an app won’t do – as Benedict Evans phrases it well in Apps versus to web: “Do people want to put your icon on their home screen?” – and sometimes they just don’t
- Apps are sometimes built using HTML5 – usually because a developer wants a single code base for all platforms or just needs easier access for his service from a browser and mobile apps at the same time
An interesting road ahead of us.
Nice review of what’s going on in the web world…
thanks Jeff
Thanks for an interesting status update on browser antics. However this all remains complex and difficult for WebRTC developers so I am struggling to find the “fun” you claim is hidden in here…
Lawrence, our definition of “fun” is definitely different.
For someone who loves technology and how it fits into the business riding on top of it, such times means chaos, and chaos means opportunities. Being able to watch, interpret and leverage these change is what makes it all fun. At least for me 🙂
“or just needs easier access for his service from a browser and mobile apps at the same time”
I fail to see how needing access to a service would result in choosing HTML for an app. Could you explain?
Tim,
If you need to get information from your server to populate the view for example, and you need to do this for people who browse to your website or open your app – what will you use to serve that information? The choice today would mostly be REST, which ends up being HTML. If the service is chatty, or interactive, then you’ll end up using WebSocket for the website – but what for the app? TCP with something proprietary on top or the same mechanism you already have in place in the form of Websocket?
Would you write the code twice (or 3 times – web, iOS, Android) to access the REST or Websocket backend, along with your service logic, or would you prefer writing it once and wrapping it as an app? I don’t think there’s a clear answer today, and it will greatly depend on the use case.
Hi Tsahi
What are your thoughts on the various Chinese browsers like Qihoo & UC? I’m not aware that any of them support WebRTC, but account for 100’s of millions of users, apparently…
Dean – great question
From searching a bit on the internet, and from what I’d do if I had to create a browser any time after 2010, they use one of the open source rendering engines out there. Both Qihoo and UC seem to use Webkit in one form or another.
You could say that browser wars happen between players who own/control/maintain a rendering engine. In that sense, these browsers are immaterial in determining the future of HTML (I am cautious not to define it as Internet and web).
Some sites like Vizzed Retro Video Game Room will ONLY work on FireFox (to have the plugin that plays the actual games) and not work on Chrome.
Some sites like Debate.org ONLY work on IE or it will show but not load correctly.
Anybody who says the browser wars are over are smartphone idiots who only do social functions. If you do only those things then YES the browser wars are done. They never were there to begin with.