开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《转职 new-grads-2020》
今日推荐英文原文：《How JavaScript Grew Up and Became a Real Language》

---

今日推荐开源项目：《转职 new-grads-2020》传送门：GitHub链接
推荐理由：不选择读研的毕业了应该下一步都是找工作吧，这个项目就是为 2020 年毕业生准备的职业列表——在毕业之前好好想想自己的技能适合什么职业还是很重要的，而且即使职业相同，具体的要求也可能存在差异，语言的使用，框架等等都可能成为不同公司相同职业里的差异点。在毕业之前了解一下自己可能遇上的职业要求来调整自己的技能树是个不错的选择。

---

今日推荐英文原文：《How JavaScript Grew Up and Became a Real Language》作者：Matthew MacDonald
原文链接：https://medium.com/young-coder/how-javascript-grew-up-and-became-a-real-language-17a0b948b77f
推荐理由：JS 的发展历程

How JavaScript Grew Up and Became a Real Language

Few imagined that the one-time toy language would become a professional platform

If you predicted in 1999 that, 20 years later, JavaScript would become one of the world’s most popular languages, you were either enjoying a psychic vision or you were slightly insane.

Not only was turn-of-the-century JavaScript unable to do what a professional language could do, it wasn’t even designed to be a serious coding tool. After all, developers who needed to create web applications already had a mature tool they preferred to use. That was Java, by way of the applet embedding system.

But in 1995, the pioneering web browser company Netscape realized they needed a simpler option for everyone else. They were in a difficult position — at war with Microsoft in the market, on the brink of closing a major strategic partnership with Sun Microsystems, and seriously pressed for time. They hired Brendan Eich to create the new language under an impossibly strict timeline. He polished off the first version of JavaScript in 10 days, just in time to be included in this handsome browser:

Netscape 2: The stage debut for JavaScript

What Eich really wanted to do was to build a browser-hosted version of an academic programming language like Scheme. But Netscape had a different vision. They wanted a language that looked like Java, even if it behaved differently. The similar names — Java and JavaScript — led to years of confusion.

“I was under marketing orders to make it look like Java but not make it too big for its britches. It’s just this sort of silly little brother language, right? The sidekick to Java.” — Brendan Eich

The era of rollover buttons

For the first five years of its life, JavaScript was a fill-the-gaps tool for people who weren’t up to programming in Java. This audience included amateurs, hobbyists, and people doing simple things in a big hurry. It also included web designers — a new class of tech workers who had the job of making web page user interface look sleek and graphical. They wanted something more polished than the tag and more modern than a spinning globe GIF.

In the professional world, this was JavaScript’s prime job — to create the UI glue that held over-designed web pages together. Every time you needed an interactive button, a pop-up menu, a fly-over image effect, you needed JavaScript.

Who wanted a rollover button? Everyone.

A rollover button circa 2000

Before long, JavaScript was in heavy use doing the least important job in the world — swapping one image for another every time the mouse came by.

Although it seems like madness to think that developers would use code to automate glowy buttons, and then distribute that code with their web pages, that’s what everyone did — over and over again. (Today, CSS provides this sort of frill, and it does so in a much more maintainable way, using style settings and animations rather than pre-generated image files.) Few people expected JavaScript would go much farther. And many coders were happier using a server-side programming language that could churn out the right JavaScript on command. The idea that JavaScript could power the business logic in an application was as ludicrous as imagining you’d replace your database stored procedures with Excel macros.

Prisoner of the sandbox

When people criticize JavaScript today, it’s usually because of limitations in the language itself — patched-on OOP features, weak type safety, the clunky DOM model, the confusion of == versus ===, and so on. But these are not the reasons that JavaScript seemed like such poor a programming tool in its early years. After all, there are plenty of ugly programming languages that became essential by being in the right place at the right time. (Candidates include BASIC, COBOL, SQL, and PHP.) JavaScript, being the only language that was natively supported in every web browser, just as websites were taking over the world, was definitely in the right place at the right time.

The real limitation with JavaScript was the sandbox — the tightly controlled environment that pinned your code in place. The sandbox cut JavaScript off from the desktop world. For example, JavaScript code couldn’t directly access the file system, the display, or any hardware. More severely, it cut JavaScript off from everything on the web server, like the databases that stored customers lists and product catalogs, and the server-side code that ran the business logic. Forced to live life on its own, it’s no surprise that JavaScript was left with little to do but twiddle buttons on a page.

Opening a pipeline with XMLHttpRequest

Oddly enough, there’s a solid case that Microsoft saved JavaScript. And it wasn’t today’s Microsoft, the company that celebrates open source development on every operating system. Instead, it was the bare-knuckled, anti-open-source warrior that consumed competitors with the philosophy “embrace, extend, and extinguish.”

Here’s how it happened. Around the same time that the world was going wild for rollover buttons, a team at Microsoft was investigating a way to make a more responsive web front-end for Outlook. They were building a product called Outlook Web Access, which looked like this:

Outlook Web Access in the year 2000

The goal of the Microsoft team was relatively modest. They wanted to make an efficient email reader that ran in the browser. Most of all, they didn’t want to refresh the whole page every few seconds. Instead, they were after a technique that would let the web page quietly check for new mail messages in the background. This goal might not seem earth-shattering, but — remember — Gmail hadn’t been invented yet. In fact, the entire Google company was only a few years old.

The Microsoft team created a small bit of plumbing with an ActiveX component they called XMLHttpRequest. The basic idea of XMLHttpRequest was simple — it gave JavaScript code a way to make web requests. Just like a web browser can contact a web server and make a request (for example, “hey, please give me that page!”), JavaScript code can use the XMLHttpRequest object to make its own requests (for example, “hey, please send me some more mail messages”).

All of a sudden, a web page could tap into the all the resources of the web server. Need some data from a database? Call the server and ask for it. Need the server to perform a calculation, a security test, a super-secret validation check? Call the server for that, too. And best of all, the page remains undisturbed while the call takes place in the background.

The XMLHttpRequest wasn’t without some oddities. First of all, it’s strangely named, with inconsistent capitalization that causes headaches in a case-sensitive language like JavaScript. Second, the name suggests that your code will send and receive XML messages. The reality is that messages can be almost anything — ordinary text, blocks of HTML, or JavaScript objects serialized to JSON. But perhaps the biggest problem was that XMLHttpRequest was built using ActiveX, which meant it could only work on Windows computers and only in Internet Explorer.

None of these quirks held it back. Within a few short years, other browsers were offering their own implementations of XMLHttpRequest — the same object in code, but with none of the ActiveX headaches.

Despite creating XMLHttpRequest, Microsoft was slow to take advantage of it in their own web development. They hesitated to use it in their public web-based email system, Hotmail. Instead, they waited until Google used XMLHttpRequest to stun the web development world, first with Gmail in 2004, and then with Google Maps in 2005. Here was a true glimpse of the Holy Grail: web-based programs that ran with the responsiveness of desktop applications.

Google Maps in 2005

The path to modernity

XMLHttpRequest was the crucial ingredient that changed the course of JavaScript. However, there were several more inflection points after that.

For years the JavaScript language was frozen in time. The problem was that the market-leading web browser, Internet Explorer, was upgraded on operating system timescales — which is to say, very slowly. Developers were forced to write code that checked browser versions and tried to adapt on the fly.

In 2006, developers got a solution in the form of jQuery. Although jQuery is more than a little dated today, 10 years ago it was an essential tool if you wanted to spend your time building functionality instead of troubleshooting browser compatibility issues.

In 2008, Google released a new JavaScript engine called V8. Much as jQuery gave developers broad compatibility for the first time, V8 gave them blistering performance. And because the V8 engine was a separate, open-source component, other projects could use it. Much later, this would open the door for innovations like Node.js and Electron.

Later in 2008, the first working draft of HTML5 appeared. HTML5 itself wasn’t about JavaScript, but it was paired with a new wave of JavaScript APIs. All of a sudden, developers had tools for storing local data, managing browser history, using audio, and running background tasks. And once again, the gap between web features and desktop capabilities narrowed.

JavaScript in modern times

Was JavaScript’s success an inevitable consequence of its privileged place in the browser? Or was it a fluke that needed luck and perfect timing?

One thing is certain — JavaScript was forced to earn its way. Through most of its life, JavaScript was no one’s favorite. Other people championed Java applets, then Flash, and even Silverlight. JavaScript faced these challengers and vanquished them all.

Perhaps the fairest assessment is that JavaScript proved something that — deep down — every developer knows. Namely, the most important factor for a new technology is its reach. If your technology has superior reach, it doesn’t need to start out being the best. All you need is good enough.

The future of JavaScript stretches down a rapidly branching road. We now have JavaScript running on web servers (thanks to Node.js) and powering desktop applications (thanks to Node.js and Electron). We have one-step-away languages like TypeScript that compile into JavaScript, giving developers a way to write for web pages without compromising their morals. And in the future, WebAssembly just might blow the doors off language limitations altogether, giving developers a way to use whatever higher-level language they want by piggy-backing on the JavaScript engine.

It’s time to admit it. JavaScript, for all its hacks and inconsistencies, is one of the greats. Brendan Eich put JavaScript inside Netscape Navigator. We stuffed the entire world into the the browser. The result was the modern web.

“Always bet on JavaScript.” — Brendan Eich

---

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/