Articles

On Advocacy

We’re fierce and protective when we talk about stuff we care about. And as developers, we care a lot about these topics:

  1. Accessibility
  2. Web Performance
  3. CSS
  4. JavaScript
  5. Frameworks
  6. Inclusivity and Equality

There are no problems with voicing your opinion. We all have our opinions and we want them heard. I understand and respect that.

But we should be mindful of the way we say things. If we voice our opinions as complaints, name-calling, and shaming, our opinions don’t get heard. No change would happen. They simply create a vicious cycle of worry, hate, and anxiety.

If we change how we project our voice, we can make real change happen. And our culture will change for the better.

Maybe we should step away from the online-world for a bit

We developers have become quite a toxic bunch of people to be with. We create fierce “debates” on every media we’re in. Twitter, Facebook, wherever we’re at.

We talk about how CSS suck (and how they don’t).

We talk about Accessibility and Performance (and bitch companies that don’t do them well).

We talk about frameworks vs no-frameworks. React vs Vue vs Vanilla JavaScript. And why you SHOULD learn frameworks vs why you SHOULDN’T learn frameworks.

We also talk about how some technologies are “dead” (even though they still continue living for quite some time).

Everyone has opinions. Most of these opinions are complains. We spread anger, fear, and worry in our communications. Daily

This should stop (but it won’t, because you can’t control what people say or do). What you can do is take a break and ignore what everyone else has to say.

Dealing with nested callbacks

JavaScript is a strange language. Once in a while, you have to deal with a callback that’s in another callback that’s in yet another callback.

People affectionately call this pattern the callback hell.

It kinda looks like this:

firstFunction(args, function() {
secondFunction(args, function() {
thirdFunction(args, function() {
// And so on...
})
})
})

This is JavaScript for you. It’s mind-boggling to see nested callbacks, but I don’t think it’s a “hell”. The “hell” can be manageable if you know what to do with it.

JavaScript async and await in loops

Basic async and await is simple. Things get a bit more complicated when you try to use await in loops.

In this article, I want to share some gotchas to watch out for if you intend to use await in loops.

A new (and easy) way to hide content accessibly

When I want to hide content accessibly, I always turn to Jonathan Snook’s snippet.

.element-invisible {
position: absolute !important;
height: 1px; width: 1px;
overflow: hidden;
clip: rect(1px 1px 1px 1px); /* IE6, IE7 */
clip: rect(1px, 1px, 1px, 1px);
}

But yesterday, I happened to chance upon Scott O’Hara’s article on hiding content. Scott says we only want to hide content in three different contexts:

  1. Hide it completely
  2. Hide it visually
  3. Hide it from screen readers

JavaScript async and await

Asynchronous JavaScript has never been easy. For a while, we used callbacks. Then, we used promises. And now, we have asynchronous functions.

Asynchronous functions make it easier to write asynchronous JavaScript, but it comes with its own set of gotchas that makes life hard for beginners.

In this 2-part series, I want to share everything you need to know about asynchronous functions.

Publishing packages that can be used in browsers and Node

When you create a package for others to use, you have to consider where your user will use your package. Will they use it in a browser-based environment (or frontend JavaScript)? Will they use it in Node (or backend JavaScript)? Or both?

If you want to create a package that’s usable in both browsers and Node, this article is here to help.

You’ll learn:

  1. How to write packages for use in browsers
  2. How to write packages for use in Node
  3. How to publish your packages for use in both browsers and Node

How to ignore files from your npm package

You can decide what files people get when they download your package in three ways:

  1. With the .gitignore file
  2. With the .npmignore file
  3. With the files property

We’ll look at each method and discuss which methods you should (or shouldn’t) be using.

The best time to npm init

When should you npm init?

Most developers run npm init right after creating and navigating into a new project.

It makes sense to npm init at the start of the project because we use npm to download dependencies. Once we npm init, we can begin downloading (and saving) our dependencies.

For most projects, this workflow works.

But if you’re creating an open source project, the best time to npm init is slightly later. If you npm init right after creating and navigating into the project, you’ll miss out a few things.

How to publish packages to npm (the way the industry does things)

It’s simple to publish a package onto npm. There are two steps:

  1. Create your package.
  2. Publish the package.

But publishing packages the way the industry does it? Not so simple. There are more steps. We’ll go through what steps are required, and I’ll show you an easy way to publish and update your package.

Hold on while i sign you up…

🤗
Woohoo! You’re in!
Now, hold on while I redirect you.