DEV Community: Otto Nagengast

Moment.js & The Selflessness of Developers

Otto Nagengast — Fri, 18 Sep 2020 03:10:20 +0000

A couple of days ago, I saw a post on Hacker News about some announcements from Moment.js. If you’ve done web development with JavaScript, there’s a good chance you’ve used Moment.js. If you’re not familiar with it, it’s a library that makes it much easier to work with times and dates.

I clicked through to the announcement to see if there were any new or deprecated features that I should be aware of. Instead there was something very different. At the top of their main documentation page, the Moment.js team had added a long preamble.

First they discussed how popular the package is (12 million downloads a week!) and then some common complaints (Moment objects are mutable!). Then they dropped a bomb: “We recognize that many existing projects may continue to use Moment, but we would like to discourage Moment from being used in new projects going forward.” Woah!

The surprises kept coming. The authors explained some of the main drawbacks of Moment.js and they provided extensive links to deeper explanations and alternatives. But they also make it clear that they are not killing Moment.js. It is too important to too many projects. They will continue to make critical fixes and updates. They just won’t be adding new features. As they put it, “ [Moment.js] is not dead, but it is indeed done.”

...
Do you want feedback on your JavaScript code?
Come join our code review Slack group!
Just click the link at the top of our landing page: https://antcode.dev.
...

Stop and think about this situation for a moment (pun intended). To appreciate how peculiar it is, let’s consider a similar situation in a different context. What if Apple operated like Moment.js? You walk into the Apple store to buy a new phone. An employee tells you, “Actually, you shouldn’t buy an iPhone. You should go buy a Samsung. The camera is way better, and the battery lasts way longer. But you can keep using your current iPhone. We’ll make sure any software updates work seamlessly with your old model.” If this happened to me, I would think the salesperson was either crazy, pissed at Apple and trying to get revenge, or playing some reverse psychology trick to actually get me to buy an iPhone.

But in open source, this sort of thing is normal. People build something and put it out into the world. Other people start using it, and they notice flaws. Some of them choose to contribute code to fix those flaws. Most just complain and hope that someone else will fix them. The maintainers work hard to make everyone happy which is a nearly impossible task. In fact, users of open source projects can sometimes get downright nasty and mean with the maintainers.

What do the maintainers get for all of the work, stress, and abuse? Money? Maybe they’re lucky to get some sponsorship money but it’s not going to make them rich. (The Moment.js team explicitly turned down sponsorship because the core team members all have good jobs and don’t need the money). What about recognition? Maybe, but how much does the world care about GitHub stars? Their resume? Perhaps but there are more efficient ways to get lucrative software engineering jobs.

I would argue that the main motivation is selflessness. Developers want to help other developers. They want to contribute to the common good. What a beautiful thing. With one piece of code, a developer can help people around the world now and for years to come. But then when something new comes along that better serves the common good, it is time to graciously and selflessly step aside.

This is what the maintainers of Moment.js did this week. We should congratulate them not just on their great work but also admire them for their ability to put the community before themselves.

How to Cram for a Job Interview

Otto Nagengast — Wed, 16 Sep 2020 05:08:52 +0000

I remembered that I had the interview 30 minutes before it started. I do stuff like this a lot. Details just don’t stick in my mind - even if they are really important details.

I threw on some khakis and a shirt with a collar and ran out the door. Thankfully, the company was just a couple blocks away so I could make it on foot. I jogged through the lunchtime rush of people and arrived in a heaving and sweaty mess. The receptionist offered me some water. I chugged it. She offered me some more. I drank that glass a little more slowly and tried to gather myself.

I had been interviewing for a couple of weeks at other companies already, so I wasn’t overly nervous. However, I was totally unprepared. I whipped out my phone and started Googling. I instinctively prepped for the questions I was asked at other interviews. Ten minutes later, the recruiter came to take me to the first session of the afternoon. The next day, I got an offer.

I only did well at that interview because I knew what to expect so I could cram. You probably remember the feeling from school. You become a pro at gaming the system by studying just what you needed to in order to do well on the exam. You can do the same thing with job interviews.

Here is a list of 7 points to prep before going in.

They are ranked by importance so if you’re pressed for time, just start at the top and get as far as you can.

1. Learn what the company does. Be able to explain it in a couple
of sentences.

2. Come up with an answer to the question: “Why do you want to
work here?” A good fallback is to talk about 3 things: the
company’s product / service , the company’s culture, and the
role.

3. Prepare questions to ask your interviewers that you can't find
answers to on the internet. Here are good ones that work well
(ranked by quality):

1. What is the main focus of the company at the moment?

2. What do you think is one thing that this company does
exceptionally well?

3. What's the average amount of time people spend in one role
before changing to another one?

4. What kind of person would not be happy working here?

5. What are the best and worst parts of working here?

6. What have been some growing pains for the company?

4. Understand the size and importance of the problem that the
company is solving.

5. Look up what stage they are at and how many employees they have.

6. Understand how the company fits into the competitive landscape.
Who are their main clients? Who are their competitors?

7. If you’re told beforehand, look up who you'll be talking to.
What's their current position? How long have they been there?
Where were they before? Use that information to better engage
with people during the interviews.

That's it!

If this was helpful, I'd be really grateful if you could like it so that it pops up in more people's feeds.

Happy interviewing!

Are you applying to jobs and want to perfect your portfolio?

Come get some feedback on your code in our code review Slack group.

To join, just click the link at the top of our landing page: https://antcode.dev.

A Brief History of JavaScript

Otto Nagengast — Mon, 14 Sep 2020 08:53:51 +0000

JavaScript is the most popular programming language in the world and has been for years. How did this happen?

The World Wide Web + JavaScript, Together Always (almost)

In 1993 a team led by Marc Andreessen at the University of Illinois released the Mosaic web browser. It was the first browser with a graphical user interface which made the web accessible to anyone who had even basic computer skills.

A young Marc Andreessen

The Mosaic web browser

The Mosaic team was based in a research center, the National Center for Supercomputing Applications (NCSA). As the Mosaic browser took off, the people who ran the NCSA slowly took control of it. Andreessen was pushed out, so he moved to Silicon Valley and found a job. But then he was approached by Silicon Valley legend Jim Barksdale to make something for the web. Andreessen decided to make another browser. He hired the old Mosaic team back, and they rebuilt a browser entirely from scratch. But this version was better, of course, because they learned from all their mistakes from the first one they made.

The result was the Netscape browser. It crushed Mosaic and it made Marc Andreessen the first of a new generation of young people made unbelievably rich by the internet.

Marc Andreessen, still young but now rich and famous

Webpages Needed Interactivity

From the very beginning, it was clear that webpages had a fundamental limitation: They weren’t interactive.

Every time you clicked on a link, the current page you were looking at would go away while a whole new page was fetched from a server and then rendered on your screen. This was because webpages could only use HTML and CSS. They needed something to make them come alive!

JavaScript = Life

Andreessen and Netscape believed that 2 languages needed to be supported in the browser: Java and a smaller, simpler scripting language. Roughly speaking, companies would build sophisticated stuff in Java. Designers, hobbyists, and hackers would build smaller things in this new scripting language that Netscape would create.

Andreessen tapped Brendan Eich to come up with something. And in 10 days, he invented the first version of JavaScript.

Brendan Eich, Father of JavaScript

Except what Eich created wasn’t called JavaScript at first. Andreessen named it Mocha. (I guess coffee was the most inspiring thing around developers in the 1990s in Silicon Valley). Then the name was changed to LiveScript and shipped in a release of the NetScape browser in September 1995. But three months later, they changed the name again to JavaScript, which has since generated confusion for people everywhere. Why did they pick JavaScript? Marketing.

That’s right - marketing. Sure, JavaScript was inspired by Java but not enough to warrant including Java in the name. The truth is the NetScape team wanted people to associate their new language with the hot language of the day - Java - even if in reality the two languages weren’t connected in any meaningful way.

JavaScript is Caught in a War

The internet was clearly the next technological wave, so everyone wanted in on it. Including Bill Gates.

A young Bill Gates, seducing us with his operating system

Bill Gates and Microsoft created Internet Explorer and bundled it with Windows software, which meant that Internet Explorer became the default web browser for most people. Over the next couple of years, Netscape and Internet Explorer battled for market share.

JavaScript got caught in the middle of this. Instead of using JavaScript, Microsoft created their own version called JScript (seriously). Netscape decided to try to find peace where great powers at war go to find peace: Switzerland.

Specifically, they went to ECMA, which used to stand for “European Computer Manufacturers Association”. But now it’s global and is just known as ECMA. ECMA sets standards for technologies so that they can safely and confidently be used everywhere.

Netscape put forth an ambitious proposal, ECMAScript 4, that would have made some huge additions to JavaScript. The language would become more sophisticated (which would have pleased big companies) but harder to use (which would have made it less accessible). Some famous JavaScript developers, like Douglas Crockford, did not agree with this direction. Neither did Microsoft. They also wanted to crush everyone else in the browser wars, so they weren’t particularly interested in playing nice. Ultimately, ECMAScript 4 never came to be.

The browser cold war continued for several years. Caught in the middle were developers who had to either build two sets of websites (one for JavaScript and one for JScript) or ask users to view their site on a specific browser.

Developers Rise Up!

Despite being neglected by the big companies, it was developers who came to JavaScript’s rescue. It all started with a now-famous blog post from a designer / developer named Jesse James Garrett. He introduced the world to a concept called Ajax (Asynchronous JavaScript + XML). The essence of the idea was that in the browser you could separate the fetching of the data from the presentation of that data. This enabled a much better experience for the user. No longer would they have to see a blank page and hourglass loading icon every time they clicked on a link. The concept behind Ajax was pretty simple:

Diagram from the original blog post

Now asynchronous web applications are completely the norm, but in 2005 this was revolutionary!

Jesse James Garrett had opened the floodgates. Developers started building all kinds of sophisticated JS tools and frameworks. Most notably is JQuery which enables tons of things including easy DOM manipulation and Ajax requests. While the big companies squabbled, developers just got on with building great stuff. Decentralization for the win!

The New Kids on the Block

Two guys, who happened to run a company called Google, took an interest in web browsers. Larry Page and Sergey Brin hired some engineers who had worked at Netscape (and then its spin-off Mozilla) to build a new browser. Larry and Sergey showed it to their boss / babysitter Eric Schmidt who was impressed. They assigned an up-and-coming young star at Google, Sundar Pichai, to run with the idea.

In 2008, Google released Chrome. The real hero in the story is the V8 engine that powers Chrome. The V8 engine outperformed the engines in all the other browsers. It showed the world that highly-performant applications could be written for the browser in JavaScript.

Ryan Dahl saw the power of the V8 engine and used it to create NodeJS which enabled developers to write web servers in JavaScript. Now with just JavaScript, developers could build the whole stack for an app.

A New Beginning

JavaScript was too important and too popular to be neglected by the big companies any longer. They came together to finally agree upon one standard. This was ECMAScript 5. Almost 10 years after ECMAScript 4 was proposed, ECMAScript 5 was accepted as the standard and all the major browsers implemented support for it.

The reach and scale of the internet was continuing to grow and now JavaScript was firmly and indisputably attached to that rocketship. The result is that developers built even more stuff in JavaScript. Here’s a comparison of the number of packages built for major programming languages. The number of NodeJS packages just grows at another level:

Among those packages are things like React, Redux, Vue, and Angular. The vast majority of web developers today use at least one of those frameworks to build web apps.

And to think that at the beginning, JavaScript was supposed to be a little scripting language. Look at how far the little language has come!

The JavaScript Future is Bright

Big companies and individual developers continue to build JS tools and frameworks. WebAssembly (WASM) provides a high-performance complement to JavaScript. TypeScript elegantly adds typing to JavaScript while still enabling people to write Vanilla JS.

JavaScript’s uses may change in the future but it seems poised to continue to be an essential part of building modern web applications. Its future seems as bright as its past was interesting.

Marc Andreessen today looking at the bright future of JS that he helped create

Do you want feedback on your JavaScript code?

Do you want to help other people get better at JavaScript?

Come join our code review Slack group!

Just click the link at the top of our landing page: https://antcode.dev.

Sources & further reading
JavaScript Wikipedia Page

Auth0 History of JavaScript

Fireship’s Weird History of JavaScript

How The Internet Happened by Brian McCollough

Image sources (in order of appearance)
One, two, three, four, five, six, seven, eight, nine, ten, and eleven.

A Perhaps-Too-Simple Guide to Git

Otto Nagengast — Sat, 05 Sep 2020 05:20:19 +0000

For probably my first year writing code, I used Git like I take a multivitamin: I was told I should do it, but I didn’t really understand how it works and I only vaguely understood the benefits. Unsurprisingly, I made a ton of Git mistakes. Running ‘git rebase’ was terrifying. There were many times when I sat down to bang out some code and hours later, I was still going line by line fixing merge conflicts wondering what the hell just happened.

But little by little, I started understanding Git. I even came to appreciate it. It is an amazing piece of technology. Although it is highly sophisticated, it is useful and accessible to even beginner developers. You can find lots of beginner guides out there to using Git. You can find lots of guides that define the key terms. In this post, I want to focus on giving you the intuition you need to confidently use Git.

Why is Git useful?

Git really does just 2 things. It tracks changes to a set of code and it enables people to manage those changes. Based on that core functionality, Git offers 2 primary benefits: time travel and collaboration.

Time travel

Over time, a codebase changes. New features are added. Bugs are fixed. Parts are rewritten (or “refactored” as developers like to call it). Ideally, all these changes are positive. But sometimes they are not. Let’s say you unintentionally introduced a bug into your code and now things are seriously broken. You have 2 options. You could write more code to fix it. Or you could just undo the broken code that you added; you could just go back in time to when your code didn’t have that bug. With Git that is as easy as running one command. This isn’t a hack. Huge companies use Git to undo changes to products that millions of people use.

Collaboration

Changes happen over time and they also happen between people working on the same codebase. Git enables you to track and manage changes that different people make to the same codebase. If you have even one collaborator on a project, this benefit becomes evident immediately.

What is Git?

I think definitions are important, so let’s look at the official definition from the Git homepage:

Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.

Git is easy to learn and has a tiny footprint with lightning fast performance. It outclasses SCM tools like Subversion, CVS, Perforce, and ClearCase with features like cheap local branching, convenient staging areas, and multiple workflows.

There’s clearly lots of advantages to Git. It’s free, open source, fast, efficient, small, and it works with any size project -- all great! But there are also some things in that definition that maybe weren’t so obvious. One of them may have been “SCM”.

I’ll admit, I had to Google it. The first result on Google didn’t seem right:

So I tried “what does CSM mean” and that also did not work:

Finally, I tried “what does CSM mean git” and got what I was looking for:

No surprises there, hopefully. It should make sense by now that Git is a source code management tool. It turns out that there are other SCMs out there too. Git is actually only 15 years old. SCM tools had existed for decades before Git came along. Apparently they just weren’t that great. Linus Torvalds decided to make a better one and that became Git. (By the way, Linus also created Linux and maintained it for many years -- what a legend).

Another key term from the definition is “distributed version control system”. The “distributed” part in particular is what really sets Git apart. In practice, one of the things it means is that each person working on a codebase keeps a full version on their own computer. A big benefit of this is that it is much faster to work on the code because you don’t have to be constantly in sync with a central server. There are a lot more benefits to a distributed version control system, and you can read about them here.

How do you actually use Git?

As I said before, there are tons of guides out there about the commands you need to run to use Git. This one is a good example. Here I’m instead going to focus on giving you an intuitive understanding of the concepts so that you can understand when to use those commands and what they are doing.

Core Concept #1: Git is silently monitoring your files.

I think of Git like a courtroom stenographer. It sits there silently in the background just recording all the changes you make to your code. It only “speaks up” when you ask it for something. You can ask it to show you the changes or you can tell it to do something with those changes.

Core Concept #2: Remote and local repositories

In any Git project there are two versions of the same repository: the remote repo and the local repo. The remote repo lives on some remote server (i.e. “the cloud”). These days, that remote server is probably GitHub, GitLab, or Bitbucket. Your local repo is a copy of the same code that is in the remote repo, but the local repo is stored on your computer. When you’re working with Git, one of the main things you’ll be doing is keeping the remote repo in sync with your local repo and vice-versa. I’ll elaborate. Let’s say you’re adding a new feature. You will make changes to your local repo. Once you’re finished, you will then push these changes to the remote repo. Everyone else on the project can then pull these changes so that their local repo is up to date with the remote repo.

Core Concept #3: The commit

We organize human history by years. The Magna Carta was written in 1215. The US was founded in 1776. You are X number of years old.
We organize a codebase’s history by commit. This feature was added in “commit ABC”. That bug was introduced in “commit XYZ”. The latest stable version is “commit JKL”.

A commit is a snapshot of the current state of the codebase. When a change is made, there is a new current state of the codebase, and this new current state is captured in a new commit. That’s the cycle, over and over: commit + changes = new commit.
These commits form a timeline of the project. This timeline is called the “git history”.

Core Concept #4: The branch

At any point in time, any number of things could happen. You could go eat some food. You could call a friend. You could close your laptop. In other words, branching out from this point in time are many possible futures.

The same intuition applies to Git. From any one commit in Git, there are many possible futures. Maybe the background of the new page could have been green instead of blue. Maybe you use TypeScript instead of JavaScript. Each of these possible futures would be contained in a branch.

When you’re working with other people, this branching feature becomes especially useful. Let’s say you want to add a new feature. You would get the latest version of the codebase. The convention is that the main version of a codebase is stored on a branch named “master”. So to be more precise, you will get the latest commit on the master branch. You create a new branch off that commit and start implementing your feature. Once you’re done, you create a new commit and add that commit to the master branch.

What if while you were working on that feature your boss comes to you and asks you to fix a small bug? You can just create a new branch from the latest master commit, fix the bug, create a new commit, and add it to the master branch. Then you can just go back to the branch you were building the new feature on and pick up where you left off.

The pattern is the same over and over. You create a branch off of the latest commit in the master branch, make changes, create a new commit, and then add that commit to the master branch.

Now that you have the intuition, let me just clarify 2 terms that you will come across a lot. The first is “merging.” When you add a commit from your branch to the master branch, what actually happens is that your branch is “merged” into the master branch. It’s like two roads merging into one. Your branch becomes the master branch, just like the one road becomes the other road. This analogy is not perfect though because your branch doesn’t actually disappear automatically. What is really happening is that the contents of your branch are copied and merged with the contents of the master branch. Your branch and its contents will still exist until you delete them.

The other term is “pull request,” and it is far less intuitive than merging. If you’re working on a codebase with other people, you probably won’t be allowed to just add a commit to the master branch, especially if you’re working at a company. Instead, you make a request to add your commit. Someone else reviews it, makes sure everything looks good, and then they merge your branch into the master branch and your commit is added.

In GitHub this request is called a “pull request”. This is weird. You pull changes from the remote repo and push changes to the remote repo. This is how naturally everyone describes it. When you submit a request like this, in your mind, you say “I am requesting to push these changes into master.” Therefore, I think it’s more intuitive to call a “pull request” a “push request”. But the logic GitHub uses is that you are requesting that your changes be pulled into master. That’s why it’s called a “pull request”. GitLab, probably GitHub’s main competitor, actually calls these requests “merge requests” which makes a lot more sense to me.

Core Concept #5: Git can find differences.

This is where Git starts to amaze. Just storing snapshots of the state of the repo isn’t that impressive. But Git can determine the differences between 2 snapshots. This is impressive.

Recall that a git history is just a chain of commits. This is useful but this is like knowing just dates on a timeline. For example, World War I started in 1914. Then World War II started in 1939. But how did we go from one world war to another one? Why did a second world war happen just 25 years after the first one ended? To answer these questions, we need to look at how things changed in between those two points in time.

The same intuition applies to the history of your codebase. Git can find the differences between two commits, so it can tell you what changed between one commit and the next. With Git, you can easily see how the codebase changed over time.

This difference-finding functionality has all kinds of uses. When you create a pull request (merge request), Git will determine the differences between your commit and the latest commit on the master branch. GitHub (and the other products) display these differences in a UI. If you’re reviewing code, you only have to look at what changed. Another common use is to find bugs. If you know when a bug appeared, you can compare two commits to see the precise code that introduced it.

Core Concept #6: Merge conflicts

If you’ve had bad experiences with Git, it’s likely because of merge conflicts. They have caused developers to use more bad words than perhaps anything else. The thing with merge conflicts, however, is that Git has to have them. Even if Git could read your mind, they couldn’t be eradicated completely. This will make sense shortly.

Imagine you’ve been working on a new feature in a branch called: “new-buttons”. Yesterday, your collaborator added a new commit to the master branch. Before you keep working on your feature, you want to make sure that you are working with the latest version of the code. To do this, you have to do the following: You pull the latest commit from the master branch on the remote repo. Now your local version of master is up-to-date with the remote one. Now you need to merge this up-to-date version of master into the “new-buttons” branch you’ve been working on. Let’s pause for a moment. These steps may be unfamiliar but if you’ve read this far, you should have the intuition to understand them. If they don’t make sense yet, reread the paragraph, think about it some more, and if you’re still not getting it, just ask in the comments and I’ll be happy to help :-)

You merge the master branch into your “new-buttons” branch — and there are merge conflicts. Why? You touched the same code that your colleagues touched in their commits. Let’s get some intuition for why this is a problem. Remember that branches are like alternate futures branching out from one point in time. In one of those alternate futures, you have short hair on November 23, 2030. In another one, you have long hair on that date. But in any one future / branch, you can’t have both. If you tried to combine those two possible futures, if you tried to merge those two branches, you would have to pick: Will you have short or long hair?

When there is a merge conflict Git is telling you, “You need to pick.” Let’s say both you and your collaborator changed the background color of the app. When you try to merge their changes into your branch, Git will raise a merge conflict and ask you to resolve it by picking either your version or your collaborator’s version of the conflicting code. Git doesn’t know which one you want to use. Maybe you don’t even know! Maybe you need to call a meeting and make a decision with your collaborator. Thanks to Git, you know that you and your collaborator have incompatible versions of the future and that you need to fix this.

Merge conflicts can be avoided by making sure that no two developers touch the same piece of code. Because merge conflicts are so annoying, and can require a lot of work to resolve, developers go to great lengths to stay organized and coordinate work between one another in order to avoid them. However, in practice merge conflicts are nearly impossible to avoid if there is more than one person working on a project. Thankfully Git not only clearly flags the conflicts, but it also makes it easy to pick the versions of the code you want to use in order to resolve them.

Conclusion

I hope you now have some good intuition about Git that will help you have a better experience working with it. From here, I would suggest jumping into particular commands and workflows in Git. You could start with this great article that goes in-depth on the main parts. I would encourage you to think about what each command and series of commands is actually doing so that you can continue building your intuition.

Good luck and happy coding!

Cover photo credit: Caleb Jones on Unsplash