Tech’d Out: How This Podcast from Two Fullstack Instructors Will Help You Finally Get Programming

Disclosure: Fullstack Academy, the coding bootcamp, has previously sponsored Hacker Noon.

I’m Corey Greenwald, and me and my partner in crime Geoff Bass are instructors at Fullstack Academy in New York city. In our years as instructors and developers, we’ve come to realize that knowing how to program isn’t all there is to understanding the idea of programming. To see the whole picture, you need to learn the history of tech and why things work the way they do. So we started a podcast called Tech’d Out to help you learn the who, what, when, where, and why of programming, in addition to however much you know about the how.

In the first episode of Tech’d Out, we decided to explain — ready for this? — the Internet! We all know the point of the internet is cat memes, so no surprises there — but how did it reach the point where any of us can type “c-a-” into Google’s search bar and wind up with all the grumpy, jerky, sassy, derpy, cheezburger-loving felines we want? Learn exactly how in the breakdown of our first episode below, and then subscribe to the podcast for the inside scoop on other tech concepts like data, styling, frameworks, and more.

The Internet in a Nutshell

Ok, let’s start with the basics. We all know we can go to something called a “web browser,” type an “address” into a bar at the top, and suddenly find ourselves with the web page we’re looking for. The whole thing might seem magical and complex, but we’re here to tell you the process behind it is actually quite straightforward.

When you type something into the bar at the top of a browser, you are making a request for information — a certain type of content or a particular page. The address you type goes through a domain name server (you might have heard it referred to as DNS), which takes the address (or “name”) you typed in and converts it into an IP address. That IP address is a numerical code that represents where the content you’re looking for can be found. Your request for content is then forwarded to the address where that content is located.

At that address is a server, which receives your request for content and then delivers that content to your browser. Tada! Servers just sit there all day, listening and waiting for requests like yours — much like a server at a restaurant waits to take your order. So instead of conceptualizing servers as machines with blinking lights, think of them as waiters, ready to take your content order as soon as you’ve made your decision.

Now, there’s still one more step between you and the content you want: Web browsers still have to take the information that has come back from the server and transform it into something visual, instead of a bunch of code most people don’t know how to read. Web browsers, of course, aren’t the only things that communicate with servers to get data, but they are the only things that can act as a visual medium for interpreting the information the server has sent back. They “draw” the information on the screen for us, so to speak.

So What Makes Up a Web Page?

All right — here’s where things get interesting: in order for a browser to be able to “draw” or visually convey the information we’ve requested, it needs certain things. Just like a painter can’t paint without, say, some sort of canvas and some sort of paint, a web browser can’t visually convey information to us without — drum roll please! — HTML.

HTML is an acronym for HyperText Markup Language, which forms the bulk of the content on any web page. Anything you can see on the page — buttons, logos, text — is HTML.

After that comes styling, which makes the content look nice and keeps your screen from just being black and white text with blue links. Styles are a way of organizing the content and are referred to as CSS (Cascading Style Sheets).

The final piece of the puzzle is the thing that allows you to interact with the web page. Earlier we mentioned that if we go to Google and type in “c-a-” it will predict that we are going to be searching for something to do with cats and will start giving us search suggestions. (And if you don’t believe that the internet is for cats, you haven’t met the machine learning algorithm that started scraping the Internet and got obsessed with cats). How is a web page able to interact with us like that? How can it seemingly think logically about your search and offer helpful suggestions? The answer to that is: JavaScript.

JavaScript

JavaScript is what enables a web page to be interactive. But with so many different languages out there — like Ruby, C, Python, etc. — why is JavaScript the one people focus on? The short answer is: You can’t write Python in a browser. By 2020, JavaScript will be the only option for interactivity within the browser.

Evolution of Java

To understand how JavaScript became the standard, you have to go back to the early days of the Internet (insert time machine noises here), a time when its purpose was far from cat videos: University researchers wanted a way to a) share their research, and b) link related research items. So the Internet, which started as static pages of information, quickly evolved to be dynamic.

The next advances happened in the early 90s with the debut of a browser called Mosaic, which was the first web browser to emphasize a graphical user interface (GUI). As you might guess from the term “graphical,” a GUI adds images to the mix and displays them in line with text. Big change. From there grew the first big commercial web browser from a company called Netscape. That now-famous browser was called Netscape Navigator.

But the minds behind Netscape Navigator didn’t stop there. They decided to create a new language to enable developers to experiment with stylings and enable users to interact with the web page. The first candidate for that language was Java, which came out around 1995. User interactivity was made possible via embedded programs called Java applets. Development continued, and Netscape decided it would be nice to have a second “glue” language — what would come to be know as a scripting language — to help out with things like attaching functionality to content. That initiative resulted in the creation of JavaScript — which it’s important to note has little to nothing in common with Java itself (aside from basic syntactic similarities). It got its name for no other reason than that Java was popular at the time. (We have to declare branding fail on this one.)

What might surprise you is that the industry didn’t initially support JavaScript, and developers didn’t spend much time on it, either, because it was perceived as a mere scripting language. And then things changed.

JavaScript Reigns Supreme

Browsers began to battle for dominance. Microsoft reverse-engineered its own version of JavaScript, which they called — wait for it — JScript. (Branding fail number two.) It was very similar to JavaScript (how surprised are you?!), but not identical.

As more browsers began to take advantage of the functionality that scripting languages offered, ECMAScript was devised. Think of it as the formalization of JavaScript — the language in its ideal form, which took an exhaustive approach to JavaScript best practices. See, developers now agreed that there needed to be a standard among browsers (the browser industry had exploded, and they all differed dramatically) and that was the goal of this new ECMAScript. Without such a standard, the code of any given web page might only work on one or two browsers, leaving users on other browsers unable to access those web pages. So when you hear the term “ES5” or “ES 2015,” those are referencing _E_CMA_S_cript. Now that there was a standard based on JavaScript, it’s no surprise that JavaScript turned out to be the language best able to comply with those standards, or that it was now on the path to Internet domination.

Around 2000, Web 2.0 was introduced. It wasn’t a new version of the Internet, per se, but because JavaScript now allowed interaction with the page, developers could now implement functionality behind the scenes on any given page, meaning web pages were becoming more dynamic. Web 2.0, with its dynamic pages, made it even more clear that with JavaScript, there was no longer any need for Java applets or Flash. That’s when the other languages began to fade bigtime, and JavaScript truly got a chance to shine as the language of the web.

But it wasn’t all smooth sailing. Browsers were still implementing JavaScript differently from one another. Despite ECMAScript, there were inconsistencies on the JavaScript level and in the ways Java interacted with HTML and CSS. It was still a struggle for developers to achieve the same performance across different browsers, a process that often required each web page to have a different set of code for each type of browser.

By this time, Microsoft Explorer had destroyed Netscape Navigator, and from its ashes rose Mozilla Firefox — and so another set of browser wars began, the three big players being Explorer, Firefox, and Opera. At this point, too, web_sites_ had become web applications. Sites were no longer the static pages of the past but applications in their own right.

jQuery Levels the Playing Field

jQuery is the massive library that finally enabled developers to standardize the process of communicating with web browsers. The premise was simple: Adopt jQuery, and it will take your single set of code and translate that to all the different browsers upon which your website might be viewed. Web developers no longer needed to write different version of scripts for each browser. As ECMAScript was the standard for JavaScript, so jQuery became the standard for how JavaScript would interact with different browser environments.

A secondary effect of jQuery was that it gave Internet Explorer’s competition a better chance. Until jQuery, smaller development teams who could afford to develop for only a single browser usually chose Explorer, making it more and more powerful. But jQuery leveled the playing field — if developers followed jQuery standards, they still only had to write their web application once, but it would work on all browsers, and then users could choose the browser they liked best, instead of being limited to the browser the majority of applications worked with, regardless of how user-friendly it might be.

JavaScript Becomes the Language of the Web

By now, JavaScript had truly become the language of the web — or at least the front-end of the web, the part the user interacts with. But where there is a front-end, there is also a back-end, which is the part that actually retrieves the content you request. And the back-end, unlike the front-end, can be written in just about anything from Django to Spring. So what did that mean for JavaScript?

Google Chrome Enters the Fray

In 2008, one of the biggest players in the browser game joined the competition: Google Chrome. What made Google Chrome orders of magnitude better than previous browsers was its performance, which was made possible via the JavaScript engine they developed.

Everything that is done on a computer, whether that computer is a whole desktop or just a smartphone, has to take place at a binary level.

But how do you translate the world into binary so a computer can understand it? Primarily, you do this by compiling. Compiling takes English-like code and converts it into machine signals that the computer can understand. If something can’t be converted into a machine signal, then it can’t be compiled. That’s how compiled languages work.

So the Google Chrome V8 engine was able to take JavaScript code and compile it into machine language in real time. It was highly efficient and extremely fast, and it made JavaScript much faster, too. Until now, developers and users alike had complained that JavaScript was slow — but all that changed with the advent of the Google V8 engine.

JavaScript Goes Full-Stack

And then in 2009, something even bigger happened to JavaScript. One lone developer took Google’s V8 engine and put it on his computer. He attached some other things to it and made it possible for people to actually write JavaScript directly on a computer, instead of just in a browser, as JavaScript had always worked. Yep, now it could be run directly on a computer and was no longer confined to a browser environment.

JavaScript, now unboxed and able to run directly on a computer, could now access all of that computer’s resources, files, its file management system, applications, etc. Now developers could build applications that would run on their machines — which meant they could also build applications that would run on their servers.

With the release of Node.js, what was once a purely front-end language could now be run server-side and listen for user requests, transforming JavaScript into a full-stack language, which supports both front-end and back-end development.

So What’d You Think?!

What a ride, huh? Who knew there were browser wars, or that JavaScript was once a second-fiddle language? Who knew the internet was created so academics wouldn’t have to wade through piles of paper to get any research done? Who knew cat memes weren’t the ultimate goal? If you walked away from today’s history lesson feeling smarter than you did when you started, then join us regularly and see just how much you can learn from a podcast. Tech’d Out is available on iTunes and Anchor.