The Practice Of JavaScript (Draft)

Everything I Wish I Knew Day One

About this book

Working draft

This book is a work in progress. If you see anything you'd like to feel free to submit it to the project's issues

Note to readers viewing this on GitHub: This book is in reStructuredText and uses special extensions not available on GitHub. Read this on devel.tech for the best viewing experience.

First, BOOKMARK THIS PAGE! There are going to be a lot of updates and valuable links / resources to dig deeper into from here.

This online book will overview JavaScript based on my experiences with it in practice. It's geared toward beginner and intermediate audiences. It's available for free to read online at https://devel.tech.

My name is Tony Narlock, I've been using JavaScript for over 10 years. I've been continuing my study and use of JS personally, in open source, and professionally, at startups and devel.tech. This is my second book after The Tao of tmux (read it online for free) which was self-published on Leanpub in 2017.

In this book, I will bring my lessons in how I learned and used JavaScript. I am by no means a "natural" programmer, this book serves as how I would learn JS if I did it a second time around. Because of that, I won't spend my time reciting JS as a technical specification, but as general concepts I've abstracted from its use.

I will also go into some of the areas of JavaScript that can be ambiguous, such as JavaScript's type inferences. These rough edges, over time, will become more intuitive as you ship more JavaScript code.

Note for beginners

If I could go back to when I was starting programming, there would be some "soft skill" things I would let myself know. These are highly opinionated things, so if they don't fit with your circumstance, that's fine.

Progress

Don't feel you have to memorize the language from end to end. I have been programming for 15 years and still utilize documentation, even for basic language concepts. There's too many intricacies to know everything by heart. Over time you'll grow rusty and have to dig up docs.

What matters most as a programmer is you having enough knowledge to synthesize components, understand code, and articulate challenges you are facing so you can support researching and resolving problems by yourself. When you're on day 0, you can't even articulate what you don't understand. So we want to get you over that initial hump.

And don't feel like you have to be gifted or become a star programmer over night. The only direct correlation for how good of a programmer you are is the effort you put into practicing it. It's no different than practicing any other discipline.

On Naysayers

If I dropped programming the first time some person raised doubts of my potential - I'd be nothing. I have a long list of people who dished me the "tough news" that I'm unteachable, that I don't get it, that I "don't listen" to their big reveal I'm a washout and have to stop trying. Whether it was family, work, job interviews, school, whomever. Often, I'd be left to writhe in agony for a time, because they had the position to get the last word.

Doubters speak in vague platitudes with utmost confidence and nothing to back it up. As humans, we are instinctively sophisticated social creatures, and don't even notice it. I'm not a psychologist, but gained some street smarts from life experience and dealing with people - I've found there's no shortage of people feeling like losers to talk a winner out of winning.

What do doubters fear? They're afraid of a person just like yourself: Someone who is willing to work hard, be realistic, humble, and surpass them the honest way. To them, your success is their failure. They do things, often passive aggressively, to plant seeds of doubt, project their insecurities, all manner of behavior to sabotage your progress.

What if we could turn their negativity energy into your fuel. If they want you to fail, double down in your efforts. Do not enable their character flaws.

That's why it feels so great to work hard over months to improve yourself. You get to rocket past all the doubters and watch them turn to specks in the rear view mirror. Satisfying.

Aptitude and bona fides

Many job interviewers are insanely bad at gauging your technical ability.

It's so bad, the market is filled with scammers who can't code, but just interview and talk well.

The more skilled you get, the more your peers will tend to downplay your achievements (e.g. it's easy, a gimmick, luck, and so on.) Particularly when they don't have them. Countless interviewers handwave my open source software projects and contributions, even my live websites during technical interviews. Despite portfolios being the quickest and best way to establish bona fides.

Portfolios: Better than nothing

Before you try to counter argument, it's not that you have to have a portfolio of work to prove yourself. Nor is it the only indicator.

Example: You have code published that demonstrates you can perform a role well, and someone says you're not qualified to do it, you've sniffed them out.

Public proof of your ability helps keep your sense of where you stand and clueless / insincere people in-check. More so than having nothing at all.

People who get stuff done feel they're behind, having gained metacognition to understand their deficits in an area. They have no need to justify or rationalize their failure by bringing out a yard stick. They have work to do.

This book and the path to winning

The best strategy to win is to keep learning, regardless of what other's are saying. If you assume you are bad, and you study harder, you don't hurt yourself if it was them all along. Due to Dunning-Kruger, you will never be able to completely discern your own shortcomings from an onlooker overestimating themselves and underestimating you. It's always better to assume it's you who is ignorant and study twice as hard.

My point with this section for beginners is you can't let people psych you out of achieving goals. Maybe you already know it and it's common sense, but I think a lot of people struggle with dramatic fluctuations in their self-worth and ability in my generation. I'd rather be safe in airing these things out than not writing it.

I hope to save you time by explaining the core concepts needed to internalize to become self-sufficient in JavaScript. These are the things that are roadblocks and hard to describe first starting out. I delve into this topic in the Fundamental Concepts section.

Other learning resources

A caveat: Do whatever helps you. If you're on a roll and feel like you're getting results, that last thing I want to do is step in your way.

"Must-read" Books

If I were to recommend one book as required reading material to be meaningful at JS, it'd be JavaScript Patterns: Build Better Applications with Coding and Design Patterns. Not so much for the patterns themselves, but the concepts grasped within them. They'll come up again and again. That book should be your best friend.

Even if you use intend on using ES6 features, the inherent ES5 fundamentals espoused in JavaScript Patterns don't go away when you use JS today.

Coding bootcamps

If you already attended one: I hoped it worked out for you. If you were one of the fortunate ones, congratulations on your success. I'm one of the few who believe you'd be successful even if you didn't go. If it didn't work out for you, I hope this book gives you some resources to set you on the path to being self-sufficient in JavaScript.

If you have not attended one: Time for some street smart wisdom.

The average bootcamp costs enough cash to pay your rent, food, and seed a startup.

You don't need a school's say or go-ahead to apply for junior-level roles in JavaScript. You don't need to spend $15,000 for "immersion" when the means to become hirable are already free. How do I know this? I grew up in open source, and got my first jobs through open source and startup incubators. When somebody is serious about hiring a junior level position, they're paying you to learn, not the other way around.

Your JavaScript immersion has commenced, I am a seasoned programmer and you have my explicit permission and validation and good will to be immersed (not that you ever needed it, happy to give you a free self-esteem boost! You're worth it!). GitHub can store and catalog your code for free. Every major browser has a built-in JavaScript console. Editors and tools are free. Node.js is free. Heroku and AWS have free tiers.

Online courses

If they're affordable to you, go ahead.

Udemy has lots of good stuff. If you go to their website, you can search JavaScript, but make sure after that you sort by the top ratings, and read into the course page to check it's reviews and video demo.

For books, see the previous section. My only "must-read" book is JavaScript Patterns: Build Better Applications with Coding and Design Patterns.

This book has a whole section dedicated to all the free stuff. Once you exhaust all those, you'll be better informed and wise enough to figure out what / if you want to buy anything at all.

What is Javascript?

JavaScript, also known as JS, is a programming language geared toward interactive applications. Every major web browser has integrated support for running JavaScript in websites since the 90's.

In 2017, JavaScript's reach also permeates into server side programming, mobile, and desktop applications.

JS and you

Is JavaScript a proper fit for your circumstances?

Even those who don't see themselves using it full time in the near future, I think it's worth taking the time to learn. I'd describe it as a solid all-rounder language with sensible tooling. Cross-platform. Fast to market, basically no build times (unless your packaging CSS/JS, and even that's quicker than most other languages).

To those who only have dabbled JS, it's a good language to practice. If you haven't touched JS in a while, and feeling a little rusty, you'll be delighted by the advancements in documentation, library quality, and the updates to the language standards itself (ES6 and beyond).

There's a high likelihood if you're a programmer, you'll have a need to glue together JS.

Today, JS is being used in ways thought incomprehensible 10 years ago. node on the server, electron on the desktop, react-native on mobile devices.

Even if you don't intend on using JS, a solid understanding of Javascript helps drive home some nice OOP and functional concepts.

Open source libraries are abundant, active, well-documented, and well-maintained.

The community is solid, friendly, and welcoming across all experience levels. If you want to get your foot in the door with an open source commit, this is great place to start.

It's easy to begin. The package and import system is executed well thanks to npm and packages, reuseable code components you download from the internet, go right in your node_modules/ in your project directory.

JavaScript's strengths

  1. Understanding the language well can help you learn other programming languages better, since it encapsulates some OOP concepts, some functional concepts (like callbacks).

    This is discussed in greather depth below, but javascript is a great multi-paradigm language.

  2. It works on the browser, on the server (node.js), and on the desktop (electron)

    There are two general ways to code JS:

    1. The browser way: Using the browser's JavaScript engine, with access to the page's DOM.

    2. The Back-end / Server-side / Command line way: with node.js, you can use JavaScript similar to Perl or Python.

    Both are well supported.

  3. High quality, well-maintained libraries

    JavaScript's permissively licensed, publicly available packages are freely available for you to use. You can search available packages on NPM's or Yarn's website, but I prefer the community-centric lists like GitHub's trending JavaScript projects and awesome-javascript.

  4. High quality build tools

    When trying to compile JS and CSS files in 2017, I've switched to Webpack and haven't looked back. Top level tools like webpack, Grunt, gulp.js, tie in libraries that allow building source javascript and css files into neat packages.

    They even support "super-languages" like TypeScript and CoffeeScript for JavaScript, in addition to Sass and Less for CSS.

  5. Headache-free package management

    npm, the package manager of node.js can be used to manage build utilities, server-side, and browser dependencies like jQuery. It's all done through a package.json file that's human readable. And also, packages are automatically detected, no need to worry about complicated PATH adjustments.

  6. Fast Fast Fast packagement

    Take it another level, you can speed up your package downloads with yarn

  7. Fast. It's faster than Python and Ruby. While it's slower than C, C++, or Java in runtime, there's no build times with JS, so your feedback loop is fast.

I didn't even begin the list of resources yet. If you want to learn JavaScript, before you go out buying things, let's see what is available free.

The important thing with all-rounder languages like JavaScript and Python is we're trying to see the forest for the trees.

Language A may be the fastest language, but there's not enough momentum to ship web apps to market with it. Language B may have great type safety, but the needs of meeting market demand and need to iterate fast make type safety more of a limitation to projects. Language C has mature libraries and tooling, but is verbose and has a long feedback loop. Language Z may be popular a social aggregator, but there's plenty of languages that have buzz that bring engineering teams to their knees in wasted time.

One improvement may be to block off the voices of those who make talk about languages but can't back it up. Take a step back, meditate, and see what language out there is giving you results.

Software engineering is inherently about tradeoffs. We can't throw out the baby with the bathwater and pick languages that haven't proven themselves to ship. Look at examples of other CTO's that have succeeded and failed. If you're going to go all-in, pick a language you can ship and iterate with, fast. A language with the most vibrant and active library community.

It flies

Maybe some may argue that JS is a scripting language, so not as fast as C, C++, and so on. This doesn't really take into account the arena JS competes in.

The issue with benchmarks (like Alioth's) is they don't deal with real world development. The typical JS script completes sooner than it takes to build apps in many compiled languages. It's meant for interactive applications, API's, websites, and geared toward bringing you to the market.

Those are qualitive factors you only get when all of the elements of an application fall in place, and a mere algorithm ran over 1000 times seems insignificant. If you're doing hard mathematical calculations, JS isn't trying to win that race.

The feedback loop is so fast I can run large test suites every time I save a file. There's no laggy IDE. It's nimble, yet featureful and powerful.

And relative to other scripting languages, it is very performant. And for the user, and the types of things you'd program for JS, it's also fast. That's stuff in your web browser, server applications, and so on.

Nimble

One thing I love about JavaScript is not having to worry about types breaking everywhere. Since packages tend to be relatively small, and the domain of the language closer to the front end, developers inherently end up evaluating most necessary correctness while they iterate.

The goal of javascript applications is to be able to prototype and refine quickly with the needs of the customer, MVP, or whatever the itch being scratched.

If you're making a larger application, or really love type safety (coming from Java, C++, or C#, etc.), TypeScript is there. And it's pretty mature, even Angular 2+ and Visual Studio Code use it.

Beginner friendly, hard to master

JS features a low barrier of entry, while still being able to take you to the finish line. Experts use JS. Large companies use JS at scale. GitHub championed electron and Atom.

Even if you pigeon-hole JavaScript to being purely front-end browser components, it's still cognitively challenging to manage stuff like state, scaling codebases, and so on. I'd say front-end JS is more complicated than what the backend guys are doing.

There's more potholes in terms of handling state. There's need to have good aesthetic intuition and also solid programming skills to glue stuff together and do the finishing touches.

There's a reason why front-end terms run circles around the old guard. More and more often, the line between front end and backend is converging due to javascript programmers increasingly needing to fix backend problems. In the process, the javascript programmers are getting stronger at the backend as a side effect. When tasked with a fullstack responsiblities, continually programming in JS enhances programmer intuition and manifest reasoning.

That's a pretty bold statement, let's repeat it:

continually programming in JS enhances programmer intuition and manifest reasoning

The basal level of code quality and design choices you churn will get better as you practice. The average work you do with JS will challenge you in so many ways. Build tools, scaling code, callbacks and event binding, closures and lambdas, objects.

You're going to see the same concepts in other languages, and after the developer has done JS for a few years, that innate skill transfers other places by making acclimating to concepts in other languages easier.

Featureful

JavaScript lets you do a lot while not letting you do it every way.

JS doesn't have monads, generics, or some obscure OOP smalltalk sugar.

Monads, generics, and other languages features are great things. But Javascript has its own idiomatic form that's a product of years of refinement in the community.

Some language concepts, while meritious in other languages and paradigms, don't fit in JS as well.

Multifaceted

Node.js (server-side JS) is, even taking browser JS out of the picture, one of the most popular programming languages. Server-side JS is used in production and at scale. Netflix, PayPal, Ebay, Walmart, LinkedIn.

I think it's safe to say, they get a fair share of traffic!

Running JavaScript on the phone using front-end browser libraries like react isn't a fantasy. See the thread Ask HN: Companies who adopted React Native over a year ago, do you regret it?. It's not just a few loud zealots trying to shore up their niche, companies are choosing facebook/react-native and reporting successes again and again.

Imagine being able to hire easier, iterate faster, and not having to fumble around with multiple Android, iOS, and whatever other platform codebases.

Battle-tested

If you haven't touched JavaScript since 1997, 2000, 2003, or even 2009, maybe you have a well-justified excuse. JavaScript code did suck on average back then, and the interpreter's support for features weren't so good.

Think of it this way, for all those years, JavaScript has been attle tested continually since JS has been the official browser language on the internet since the 90's. No other language shares the commonality it's a scripting language every user, regardless of operating system, runs about every day.

It's a language that was too big to fail, but the ship was righted by it's community, who worked through it's rough edges through ingenuity and hard work. Abstraction libraries like jQuery, frameworks like Backbone that solved the headaches of binding, functional frameworks like Underscore.js that handles functional mapping across objects, countless open source projects played apart in what would culminate in ECMAScript bringing onboard new features inspired by what the community naturally begin integrating.

This of course is my rendition of how it happened. As someone who was mostly on the implementation side of JavaScript, and not writing JavaScript engines or drafting ECMAScript standards, I am inherently biased toward the community being the driving force. And I stand by that, because no one person, or board of shadowy figures in an office called the shots. Passionate, hard working volunteers played a significant role.

Between 2010 to 2017, new JavaScript engines like v8, Chakra, SpiderMonkey, and a ton of others (they keep advancing and bringing up new ones) are around. They're fast.

Standardized

With a burgeoning community of coders and thousands of projects, there comes a need to keep things confistent. To handle the nuances across projects, teams, and codebases, a myriad of standards and linting work groups and tools have materialized:

Code Standards

Code Standards are specifications adopted by an organization or committee and published online so the world can see them. They change from time to time in popularity and the scope of their policies. In my hay day, it was idiomatic.js, in 2017, here are the hottest style guides:

Linting tools

Linting tools have evolved from checking for stuff that's definitely breaks, such as trailing commas in early version of Internet Explorer, to enforcing code standards.

The concept of code utilities in general has grown from unrealiable helper tools to deterministic, reliable helpers. Even for other languages like C++, clang-format supports Google's C++ Style Guide out of the box. Of course, it doesn't introspect for things beyond formatting.

JavaScript's linters, on the other hand, have grown to be pretty intelligent over the years. ESLint gives you the oppurtunity to pick from AirBNB, Google, or StandardJS's standards out of the box when you create a new configuration.

Here are some of the knowing linters for JS:

Best practices == Moving target

The ECMAScript language itself has advanced over the years to incorporate influences from other languages, such as generators and the yield* expression.

Linters have configurations to disable rules for a reason. In some cases, certain ES6 features are considered bad practice by these community standard bodies.

For one, I still don't fully understand why for...of isn't allowed by Airbnb's standards as of 2017-11-07. It's cleaner code. I found their rationale about why ES6's for...of to be a bit muddy. Something about mutability. I consider mutability in for loops a feature and not an antipattern.