JavaScript has already emerged as the backbone of the fast-growing world of the Web. But how is open source enabling JavaScript to power advanced Web developments? Brendan Eich, the creator of JavaScript, spoke to Jagmeet Singh of OSFY to reveal the secrets of the open source framework. Eich also talked of how he enhanced the Web with Mozilla and the work he is doing now at Brave Software.
Q What was the foremost aim of developing JavaScript?
I joined Netscape to ‘do Scheme’ in the browser. But on my first day at work, I learned that Sun and Netscape were working on a Java integration deal. So, with Marc Andreessen directly, and Bill Joy at Sun supporting me, I came up with a plan to make a dynamic language with Java (or the C family) syntax, which people who were not professional programmers could write directly in the HTML Web page source. We wanted a scripting language to complement Java, akin to Visual Basic for Visual C++ in Microsoft’s Windows platform. This would empower more people to start programming, by gluing components together with a little script in the page. The components were projected to be either built-in (the ‘DOM level 0’ which I implemented along with JavaScript for Netscape 2), or we hoped they could be written in Java by higher-priced programmers.
Q JavaScript is presently ubiquitous in the world of the Web. What is the reason behind its success?
There are three reasons that I see as critical and related. JavaScript itself is certainly the first and foremost reason behind its success. The second reason is its enough powerful basic features. And the third one is the ease in extending the framework and patching (so-called ‘monkey-patching’ and ‘object detection’. All this enabled Web developers to compensate for version differences and even extend old or incompatible browsers to resemble newer or different ones.
Q How has the open source community helped in making JavaScript the star of the Web world?
Even before Mozilla or an open source implementation of JavaScript, I used all the early adopter support techniques and energy that I had acquired over the years in software, going back to Silicon Graphics. I helped developers find workarounds and reduce test cases. I answered questions promptly. Also, I groomed helpful second and third (virtual or even real) team-mates. Netscape eventually allocated and hired more people to work on JavaScript in late 1996. Before that I had important volunteer help.
Q Do you consider JavaScript as a dominant factor in new, emerging technologies like IoT and wearables?
Thanks to Node.js and the module ecosystem it spawned, JavaScript has moved strongly into servers and IoT devices. People are now even doing machine learning in JavaScript. Early hobbyist-level work such as Johnny Five endures and grows. I expect these trends will continue over time.
Q When can we see the much anticipated JavaScript 2.0? Could we say that for Web developers, this new version will be worth waiting for?
We had already kind of created what JavaScript 2 eventually became, which was ES4. It just had to be abandoned as that fourth edition, and its best parts carried forward into ES6, now called ES2015. The ECMA-262 standard has now moved to an yearly release cadence, so there’s no need to await a ‘big bang’ 2.0 that might not ever have come out under such an ‘all-or-nothing’ approach. This more closely matches how software is developed and tested at scale.
Q A year back, there was an announcement on WebAssembly, which you had also called a ‘game-changer’. Can you tell us about the status of the project and the support from browser vendors?
I helped announce WebAssembly, which is directly descended from asm.js, the statically typed subset of JavaScript that can be optimised to near-native code speed on par with Google’s Portable Native Client (PNaCl) and other such predecessors. Since then, all four top browser vendors have moved forward with WebAssembly, and just the other week, three of them announced their plans to release WebAssembly support, which is likely to go live in the first quarter of 2017.
Q The ECMA TC39 committee that develops and standardises the ECMAScript (JavaScript) has recently become open to community contributions. Can organisations from India join and contribute towards language specifications by leveraging this latest development?
ECMA still requires people to agree to give up ownership of intellectual property according to its ‘Code of Conduct in Patent Matters’, which has language for ECMA members and non-members alike. Still, having worked in TC39 for over a decade since helping reform it once Firefox had restarted the browser market, I think it always helps to have a corporate or not-for-profit organisation that can join ECMA.
Q Years after introducing the world to JavaScript, you co-founded the Mozilla project. Why was there a need for launching Mozilla?
I had finished JavaScript 1.0 and standardised it with excellent colleagues from IBM, Microsoft, Sun and other companies, as ECMA-262 Edition 1. Netscape had finally invested in a JavaScript team, led by Clayton Lewis, with outstanding programmers who could carry on the work both in the engine I had rewritten (SpiderMonkey; the first engine was called Mocha), and in ECMA TC39. I was ready for something new.
Because Netscape was being driven out of business due to Microsoft’s abuse of its Windows OS monopoly on personal computers, Netscape’s executives and top engineers were warm to the idea of releasing the Netscape code as open source. This was a daunting task (free the lizard!) and the first big commercial, closed-source conversion to open source.
Moreover, the chance to be the chief architect of the mozilla.org project—to work from the start on an ‘escape pod’ for the browser, was one I could not pass up. It is hard to remember how unlikely the later success of Firefox seemed. But even in 1998, some of us believed that Mozilla could bring back the browser market from its then-impending inevitable monopolisation by Internet Explorer.
Q The original Mozilla project brought in Mozilla Corporation as a for-profit arm to support the Mozilla Foundation. Is it easy to garner profits with open source developments?
Initially, mozilla.org had no legal structure. It was a ‘virtual organisation’ inside Netscape, soon bought by AOL. But in 2003, we spun Mozilla out from AOL as a non-profit, the Mozilla Foundation, with no for-profit subsidiary. After some promises from the US IRS were broken, we ended up creating the Mozilla Corporation as a wholly-owned subsidiary of the Mozilla Foundation.
I cannot say this model is easy to transfer to other open source projects. It is hard, perhaps even impossible, as Mozilla Firefox was sui generis (unique). What I have seen work for other open source projects ranges from commercial dual-licence to indie-developed or consulting-funded and to SaaS subscriptions. No one has cracked the code on how to make predictable money from open source. We do know that creating great software can create even greater value through ecosystem effects such as easier integration, community- and partner-built extensions and standards for interoperation.
Q How is the Indian developer base contributing to Mozilla’s open source solutions?
I am no longer at Mozilla and cannot say much on that topic, since I am busy with Brave, which is doing well around the world, including in India. We already have several volunteer Brave Squads around the country. Some of them are from Lucknow, Hyderabad and even Jaipur. They are active in fixing bugs for Brave as well as in localisation efforts (adding Hindi and Bengali). Developers can get involved via the official Brave repository on GitHub or by joining us @BeBraveIndia on Twitter, as well as following the Facebook group.
Q Unlike its progress with a Web browser and email client, Mozilla had a brief stint in the operating system space with its Firefox OS. What reason do you ascribe to its failure in the market?
Firstly, although I was an executive sponsor of Firefox OS (codenamed B2G, at first) along with Mike Shaver, we did not get the CEO or other executives fully on board in 2011 when we started. While there was a bigger opportunity in the still-immature Android market, it took us till 2013 to really get to market and, at that point, the window of opportunity was closing due to Google’s lead and scale advantages.
Second, even if we had started with full force in 2011, we might have failed, again because of Android’s scale and lead-time. A mobile OS requires commodity-scale hardware, deep software integration and, in many parts of the world, a distribution system that has gatekeepers to be paid. It is therefore quite hard for anyone, never mind Mozilla, to do a ‘third OS’ now. Some say it’s impossible, but of course, there are viable Android forks and mods in Asia.
Some day, perhaps, on a device as different from today’s smartphones as the first iPhone was from feature phones, there will be a new OS. It certainly needs to be open source for best testing, recruiting and developer ecosystem effects.
Q After JavaScript and Mozilla, you recently expanded your presence in the Web world with Brave Software. Why did you feel the need for a separate Internet security company?
All of the big browser vendors are more or less captured by today’s ad-based ecosystem for funding free websites. Apple is the least captured as it walked away from ads as a business (twice, I believe), and so you have seen it add content blockers as an app-install model for extending Safari with ad blocking, starting last fall in iOS 9. But none of the big browsers will block third party trackers and ads, by default. Google would be cutting off its main revenue source if it blocked ads, by default.
Meanwhile, malware in ads (so-called ‘malvertising’) is coming in through third party ad exchanges. This is just the worst threat, among many—from slow page loads, to drained batteries due to the radio running too much when loading ad-tech scripts and ads or videos. The threats include users being bothered by ‘retargeting’, overt privacy concerns, and data theft that is legal and does not quite rise to the level of malware. These threats drive users to adopt ad-blockers, which, in the best cases, eliminate bad ads but in general, also deprive websites of revenue from ads.
Brave proposes to fix this broken ecosystem by blocking trackers and ads, by default. It offers users a wallet in the browser, with which to anonymously and effortlessly pay their top sites, and we hope (this is still in the future) even pay users properly for their attention.
We are working now with many small publishers and (soon) with a few large ones to find better ways than ads. Brave cuts out the middle players and proposes several ways for marketers and users to support publishers. Given all the threats and inefficiencies of online advertising and the downward trends, we believe the Web is ready for a new set of standards for anonymous and private ads and micropayments.
Our long term value is not in how we innovate to create just some future standards, rather it is our users’ trust in us putting them first, always giving them the same or even larger cut of any revenue based on their attention, and never holding our users’ data in the clear off of each user’s devices. All this means we never hold cleartext user browsing data on our or anyone else’s servers.
Q How is the Brave browser different from Firefox, despite both being open source offerings?
Brave blocks third-party ads and trackers, by default, and works hard for user privacy in other ways (HTTPS everywhere activated, by default, and fingerprinting protection). Other browsers, including Firefox, do not block adverts by default, because they do not want to rock the boat.
Brave also differs by being based on Electron and (same as Chrome’s engine) Chromium. This gives us the market-designated best engine with the most widely used extensions, but not any of the Google accounts or other service integrations, nor the front-end features of Chrome, which we do not want. Brave has its own user interface, built via Electron using React.js, HTML, CSS, SVG and images.
For users, particularly mobile users, the speed with which Brave loads Web pages directly translates into benefits. For instance, Brave Android users will see a 2x to 4x speed increase, which correlates with battery and data plan optimisation.
Q Lastly, how do you see the parallel journeys of open source and the Web?
Canadian science-fiction author Cory Doctorow in his recent talk on the darker view of things notes that while open source has won, the Web is in trouble due to closed source and worse threats such as DRM and the laws enforcing it. I believe, open source, which goes back a long way to when IBM released its Fortran, is inevitable in any broad, commercial-in-part ecosystem that has stable kernels across evolutionary time, transforming from UNIX to Linux, TCP/IP, HTML and JavaScript. These kernels and analogues of them in other layers of the ecosystem’s ‘stack’ become the cost rather than profit centres, over time. The Web now has over three giant open source engines backed by multi-million LOC (lines of code) projects, namely Mozilla’s Gecko, the Apple-led WebKit and the Google-led Chromium. Microsoft has even recently open-sourced its new ChakraCore JavaScript engine.
However, I see not so much a parallel as a symbiosis. The Web is big enough and commercialised now, so inevitably its evolutionary kernels will only be open-sourced for best peer-review effects such as development, QA and evangelism. Open source, in turn, symbiotically promotes open standards by providing reference implementations an A/B whitebox testing which is better than any closed-source approach that feeds into standards.
