Hello and welcome back to Front End Center! My name’s Chris Landtiser, and this week we’re taking a VERY high level look at JavaScript.

To understand what JavaScript does and how it’s become so ubiquitous, we need to look at the roots of the internet. Originally, web pages were minimalist, content oriented documents. Not because that’s what was in fashion, like trends today. Rather, most web pages were essentially text documents, hosted for remote viewing. Their mind blowing value wasn’t in design, or quirky micro-interactions. No. They could LINK between each other, across the globe. Mind. Blown.

Things have a way of growing more complex the more they’re used. Minimalist text documents eventually gave way to colors, layouts, movement and blinking animations. CSS handled the print-like styles of fonts, colors, borders and more.

At the same time, the web was lacking some sort of logical, programmatic language. Like traditional, computer-science programming, web development needed a way to run math, logic, or instructions on a web page. Until then, a page loaded based on the content, and then it was done.

Like any new technology, there were competing options vying to stand alongside the established HTML language. JavaScript was one of those contenders, and gained an edge through marketing via association with the Java language. Little details like being completely unrelated to Java will never stop the lofty goals of marketing campaigns.

Through the late 90s and beyond, JavaScript went through a series of growth and fractures that slowly built the somewhat quirky standard we use today. Tie it up with a bow, clean and simple. All done.

Or… not. JavaScript has developed a strange habit of turning up in unexpected places. For much of its early life, most of its functions focused on the user interface of a web page. It interacted with the Document Object Model, or DOM, and changed styles or semantic content. Animate a button, change a background, or even add new content based on contextual actions.

This is still a very large role for JavaScript, and the only capacity it serves for many designers and front-end developers. Some of the specifics can be a little weird, and it’s easy to overcomplicate your own code, but altering and updating your UI with JavaScript is ultimately pretty succinct.

That doesn’t account for the baked in complexity JavaScript can be capable of though! It’s able to run complex functions and math problems, and is flexible enough to adapt to many of the predominant methods of software architecture today.

The question is less: SHOULD JavaScript do it, and more CAN JavaScript be cajoled into doing it? So far, the answer is yes. Look for JavaScript powered microwaves and dishwashers at CES next year. The Internet of Things is a strange and wondrous place.

Intrepid developers have leveraged JavaScript to do amazing and potentially terrible things. Traditional technology “stacks” can combine a vast diversity of user interface, networking, server, operating system, and security technologies. With enough ingenuity and a bit of risk taking, that entire stack of complexity could be distilled down to JavaScript today.

Servers, connectivity, data handling and retrieval. All offer a selection of multiple options built with JavaScript. Some are well established, and others are fighting an uphill battle against mutual competition or just to be taken seriously.

JavaScript is steadily forging ahead in the mobile realm as well. An app can be coded in a web language like JavaScript, or you can use one of the many platforms that translate JavaScript into native iOS, Android, and PC code at the press of a button. Whether it’s the end product, or just the top layer compiled software, JavaScript is showing up everywhere.

It’s also become the poster child for a growing issue in web development.

The web is a unique meeting place of technical variety and low barriers to entry. While this can be a great boon to creativity and opportunity it makes the web something of a wild west.

Now, weird, bad, and absurd coding processes can be found everywhere. Development as a whole is an industry in its infancy. Unless you’re talking about cutting edge work, though, most development processes are considerably more settled.

Web developers attempt to apply as much of that applicable knowledge to ourselves as possible. One message that has been received loud and clear is “not to reinvent the wheel”. Across all kinds of development, redundant wastes of effort and program space are despised.

This has created a habit of code re-use that is downright polarizing. Resources like the jQuery library have been longstanding favorites to simplify many complex JavaScript interactions and processes. Critics of such libraries question the cost of including such a generalized tool when most developers need only one or two very specific solutions.

The larger problem seems to be how few developers dig beneath the surface to understand how that more complex JavaScript works. When your problem can be solved by adding one link to your code, it becomes a seemingly pointless challenge to learn the specific solution.

Does not reinventing the wheel excuse not knowing how to make the wheel in the first place?

A situation involving a JavaScript repository of code known as npm put the issue in the spotlight earlier this year. Developers can use npm to automatically include pre-written code from known and trusted sources. Part of the appeal is that it’s way more modular than a full library like jQuery. Need only a single feature? Add only a single feature!

However, when an open source developer felt he had been betrayed by the team behind NPM, he deleted the code he contributed and deleted his account.

What started as a small dispute suddenly had a world-wide impact. One particular contribution this developer made, called “left-pad”, was 17 lines long. It’s a pretty fundamental wheel if there ever was one, and so was included in a LOT of projects. Even more important, it was a included in projects that were then included in OTHER projects.

The end result? Thousands of developers working on projects of every size, suddenly unable to run their programs. Whether they had included “left-pad” themselves, or unknowingly used any other code that referred to it instead, they all came to a standstill.

The resolution was fairly swift, once the issue had been identified. But in an industry where you learn the methods to avoid wheel-inventing before you learn how to make the wheel in the first place, how long will it be before we have a repeat incident, or something worse?

There are already some safeguards and ideas in place to help solve this problem. Most developers who seem aware of them, though, are those already at the top of the industry and ahead of the problem. Spreading that information reliably and uniformly will be a huge step forward.

Here’s to JavaScript, in all of its quirky and entertaining glory. No matter what scale of web technology you work on, it’s a professional challenge you can’t ignore, and we’ll be hearing plenty more on the topic. Until then, this has been Chris Landtiser and Front End Center. Thanks for listening!