I’m coming up on my first year with RedMonk, which will also mark my first year as an analyst and my first year in the tech industry. Needless to say, it’s been a firehose. While I’ve made a lot of progress coming up to speed, I am constantly awed by the insights of people around me who are working with a deeper knowledge base and more historical context.
I’ve been making an explicit effort to learn more about where we’ve been as an industry. My new approach to these tech history lessons is inspired by Bryan Cantrill’s amazing Monktoberfest talk Oral Tradition in Software Engineering; rather than simply learning via research, I am tapping RedMonk’s network of awesome people to talk more about their areas of expertise. In an effort to make these lessons a bit more scalable than a 1:1 discussion (and to justify these dinners on my expense reports), I’m documenting the conversations and sharing what I learn along the way.
A few disclaimers before we start:
– This is not intended to be a comprehensive history; this is a recap of a discussion.
– I’m not asserting this knowledge exists exclusively as an oral history. I have linked to additional resources for those that want to learn more.
– By virtue of the fact that this stems from a Q&A session with me, this content is aimed towards people who are newer to the industry (or people who want to reminisce.)
We at RedMonk are fortunate to know some really talented individuals. The first of these individuals to kindly volunteer to share their knowledge is Joe Hildebrand. Joe is currently a Director of Engineering at Mozilla, and prior to that he was a Distinguished Engineer at Cisco and the CTO of Jabber. Outside of work, Joe helps various open source projects and committees make the internet a better and more secure place. Joe is also a long-time personal friend and a standup individual.
Joe and I had a fantastic conversation that started as the history of JavaScript that morphed into a larger discussion about programming languages.
A Brief History of JavaScript
In the olden days (aka the early 1990s) the internet was a very different place. At the time browsers were relatively simple, and websites had to be correspondingly simple to work. Websites were mostly textual without fonts, and images in any form were a big deal. In this text-driven world, it was not clear why a developer cared about using HTML over Gopher or WAIS. Images changed that, and the Mosaic browser in particular was instrumental in shaping how images were used in HTML.
Aside for a quick Mosaic history: the Mosaic browser was developed in 1993 at the University of Illinois Urbana-Champaign, and several of its original developers (Marc Andreessen among them) then developed a competitive browser at Netscape. The browser was ultimately open sourced under the name Mozilla before Netscape was acquired by AOL in 1998.
With the goal of allowing webpages to move and not be so static came the need to embed a programming language into the browser. Sun’s Java was a complicated language that needed to be compiled; Netscape wanted to build a lighter weight interpreted language to run in the browser and interact with HTML. With this in mind, Brendan Eich set out to write JavaScript. Lore was he wrote the language over a weekend, but the official version says it took ten days; either way, the language came together impressively quickly.
JavaScript became quickly and firmly cemented as a frequently used programming language. Decades later, it’s still one of the top programming languages in the RedMonk rankings.
However, this definitely doesn’t mean there are no complaints about JavaScript. It was “horrifically slow” originally, though that has improved over time. There are also complaints about the inconsistencies in the language’s design aesthetic; said inconsistencies can make it difficult to learn and master the language.
JavaScript and Node.js
Once JavaScript became a default language running in the browser, there became momentum to also use it as a language on the backend. After all, once you’ve overcome the challenges of learning JavaScript to program the browser, it would be a shame to have to learn a different language to write your server, right?
What wasn’t originally obvious was whether JavaScript could be fast enough to run the server. The Node.js runtime changed that with a couple of key features.
- Node.js is surprisingly single-threaded for a server-side programming environment. People had previously assumed you needed all your CPU cores running threads at the same time to be fast, but to do that requires “a shocking amount of skill and adds a lot of complexity. Debugging those programs is a nightmare.” Node.js simplifies this by having one process running through one core.
- Node.js is event-driven. (Confession: this is one of the phrases I encounter frequently but didn’t really understand until Joe explained it to me. If you are also in that boat, here you go.)
Example: I want to do something at 6:05, but I don’t have a watch so I need to rely on Joe to let me know the time. One possible approach is for me to ask Joe for the time. I then have to pause what I’m doing to wait for Joe to answer me, and we have to repeat the process until it’s 6:05. The other way I can do this is to say, “Joe, please tell me when it’s 6:05.” Joe and I then have the bandwidth to do whatever we want until Joe lets me know it’s 6:05.
In this example, the second method would be considered ‘event-driven’ where the event in this case is that the time changes 6:05. This event-driven method of asking for the time improves our collective resource utilization.
Node.js created an environment that was fast enough to run JavaScript on a server by decreasing complexity with single-threading and using an event-driven architecture.
More Generally: Why Write a New Programming Language?
This discussion led to a more abstract conversation about why developers choose to write a new programming language in the first place. According to Joe, here are some typical reasons developers choose to write a programming language. (Note these are not ranked in any particular order, and he does not consider this to be comprehensive.)
- license compatibility
- performance reasons (i.e. the problem they’re solving doesn’t map well to the existing language)
- different preferences for aesthetics and syntax
- trying to change the learning curve (i.e. want people to learn something more quickly by improving the syntax)
- writing something that is easier to secure
- the human tendency where people don’t like one piece of a thing, but instead of making that individual piece better they decide to completely re-write a new thing
- the language’s standard library is not good enough (“This is a stupid reason, but it happens.”)
Wrap Up
Many thanks to Joe for helping get this series off the ground. I learned so much from our conversation, and I really appreciate you sharing your time and wisdom!
Recruiting future interview subjects: If you ever want to grab a drink/coffee/lunch (my treat) and share the story behind something you’re interested in, hit me up. So far 100%* of these conversations have been a lot of fun, and I would love to chat with you!
* I’m admittedly working with a problematically small sample size, but I fully expect the results to hold as we scale.
No Comments