Forem: flavio ⚡️🔥

I wrote 1 blog post every day for 2 years. Here's 5 things I learned about SEO

flavio ⚡️🔥 — Tue, 18 Feb 2020 05:00:00 +0000

It’s been 2 years since I started posting one blog post every day on this blog.

On January 25 2018, just one day before turning 35, I started my blogging journey.

In this blog post I am going to tell you 5 things I learned about SEO that you might not be familiar with.

SEO trick number 1: do not worry about SEO

If you read the internet for ways to get more readers to your blog, you will find that SEO is one of the things often mentioned.

Most of the time you will see people talking about keywords, and keywords tools.

We like tools, so we start using them, spending days to get the maximum value out of the free ones, spending a lot of time.

Right? Wrong.

I have a confession to make: I never used a keyword tool. I do not currently use one, and I find that just thinking about it bores me.

The last thing I want to do is to be bored, and having to treat my blog as a job.

The idea of having to research keywords before writing a blog post makes my blog feel like a job. And I don’t like jobs.

SEO trick number 2: link building is optional

In addition to keyword research, one thing that often comes up in SEO circles is link building.

I do receive a good amount of emails asking me to link to so-and-so site, to link to a special infographic someone created about something I talked about, and it’s all kind of annoying.

I am sure this is something that works, because links are still one of the key metric used by search engines, but do you really want to spend time annoying people?

I never added any link by request. Not for free, not paid. And I never asked for links.

And if you think, as a developer, about creating networks of sites all linked together, that’s been done and Google took measures against that. And even if you don’t get caught, it’s a dirty game.

And links must come from relevant, authoritative sites in the specific niche you want to rank. You can create a kitchen recipes blog and then add links from a programming blog, but what really works is a big recipes blog linking to the small recipes blog.

Initially, creating content for other sites is one way to do that. Big sites always need fresh content, and by doubling down on creating content (for your site, and for other sites) you can create the foundation for the years to come.

I did that, and the good thing is that I was able to serve an existing audience with relevant content I’m passionate about. Very different than spamming people inboxes or sites with requests for links.

SEO trick number 3: write things that help people

Instead of thinking about keywords and link building, I usually think about problems.

What problems do people have? You can think about possible problems all day, but the best way is to have people tell you.

I now ask my email subscribers what are their top problems or things they are struggling with, but you can also find this in other places. One place I like, in my space, is Twitter.

Other spaces might have the same information in blog post comments, or YouTube videos comments. You just need to observe to find good ideas for your niche.

Then write a post that solves that problem.

One way I really like is to talk about the problems I had, and how I solved them.

For example I am writing an app and I need to work with dates. I have to search some particular topic on Google, which leads me to checking out 10 sites for the correct and up to date answer. I spent 30 minutes and now I can spend 10 minutes more to write the answer in a blog post.

A quick one.

SEO trick number 4: length does not matter. What matters is solving problems.

What matters is solving people problems. Google and the SEO wizards call this user intent.

I see that SEO people like to suggest you to write 3000+ posts to rank on Google. That’s a great tip to if their goal is to discourage you from writing more. They call it long-form content.

Now, as a non-SEO person, but as a person that does things and observes what works and what doesn’t, I can definitely say that if you solve a problem for a person with a 4-lines blog post Google will thank you by sending you more people with that problem.

They know using their algorithms when a person found the answer they needed. This is Google’s job. Their job is to solve people problems by providing the perfect content they are looking for.

If you can provide that, Google will help you.

Not every post on your blog can solve a problem, of course. That would be boring. But if you have posts that solve problems you’ll notice, as those are the ones that will get the more visitors.

Not every post must be small of course, and if long form content is best for you, do that.

SEO trick number 5: it takes a lot of time, and you must play the long game

By observing a lot of people coming and going into my niche in the last few years, I observed a pattern that might be kind of obvious.

Initially there is a lot of enthusiasm and the content quality and frequency is optimal. After some months, people start to give up. Slowly. There is never a big decision, but content starts to be less frequent, less cool, and without a fixed frequency.

You don’t need to post every day, or every week, but I like blogs/sites that have a clear schedule. Like, every 2 weeks we have a post. Good for me.

But 3 posts in a month and then nothing for 5 months? Not so nice. It must be me, of course, but I like things to have a regular cadence.

I know it’s hard because initially you will not see any result. And I know this because I am creating new blogs on the side, about different topics, and they are very slow to rise above the near-zero levels.

You are tempted to consider it a failure each other day.

How do you solve this? By working on projects you are passionate about.

If you write about your passion, you will never lose enthusiasm because you are creating a little corner of the internet that’s yours, you made it, you made it beautiful, and now it’s also available for everyone else, but even if no one shows up, it stands on its own.

You find it beautiful. Like creating a mushroom out of wood, or carving your own spoon.

And when people will discover that they find your work absolutely great, then it will be a never ending source of joy every day.

Originally posted on https://flaviocopes.com/blog-seo/

How I prototype a Web Page using Tailwind

flavio ⚡️🔥 — Wed, 04 Dec 2019 05:00:00 +0000

Sometimes I work on single web pages for my projects.

Maybe I want to redesign the blog. Maybe it’s a landing page for a new project.

This is the process I use.

I like to use Tailwind to build prototypes.

I set up all the pipeline for Tailwind and PostCSS first:

Create postcss.config.js:

const purgecss = require('@fullhuman/postcss-purgecss')
const cssnano = require('cssnano')

module.exports = {
  plugins: [
    require('tailwindcss'),
    require('autoprefixer'),
    cssnano({ preset: 'default' }),
    purgecss({
      content: ['./layouts/ **/*.html', './src/** /*.vue', './src/**/*.jsx'],
      defaultExtractor: content => content.match(/[\w-/:]+(?<!:)/g) || []
    })
  ]
}

Create tailwind.config.js:

module.exports = {
  theme: {},
  variants: {},
  plugins: [],
}

Craete a tailwind.css file:

@tailwind base;
@tailwind components;
@tailwind utilities;

Create a package.json file:

{
  "main": "index.js",
  "scripts": {
    "build:css": "postcss tailwind.css -o output.css",
    "watch": "watch 'npm run build:css' ./layouts"
  },
  "dependencies": {
    "@fullhuman/postcss-purgecss": "^1.3.0",
    "autoprefixer": "^9.7.1",
    "cssnano": "^4.1.10",
    "postcss": "^7.0.21",
    "tailwindcss": "^1.1.3",
    "watch": "^1.0.2"
  }
}

Create a layouts/index.html page, and add your HTML.

Start a terminal shell, go to the project folder and run:

npm run watch

Then I make the browser automatically sync the changes every time I save the page or the CSS is regenerated, using browser-sync, a great utility you can install using npm install -g browser-sync:

browser-sync start --server --files "."

This starts a server and also automatically opens the browser and points at the newly created local web server.

Now I open VS Code and the browser side by side, and I start prototyping!

How I stopped worrying and learned to love the JavaScript ecosystem

flavio ⚡️🔥 — Sat, 28 Sep 2019 05:00:00 +0000

Until a few months ago I could not even look at JavaScript without having a feeling of anxiety.

I was 100% under the so-called JavaScript Fatigue and I could not get out of it.

This lasted years.

Today, I love JavaScript and its ecosystem.

How did this happen?

I’ve been using JavaScript in some form or another since the nineties, and I have some books on my shelf that looks very funny today, full of document.write statements.

JavaScript has hugely changed in the last few years. At first, I could not pick up all the things that were going on. I could not accept so many changes all at once. JavaScript was changing but I was resistant. I took so much to learn it properly, and now it’s changing under my feet.

I found really spot on a comment made on a blog post when it argued that “learning modern JavaScript was tough if you haven’t been there since the beginning“:

I would argue being there since the beginning (yes, I’m that old) makes it even tougher - Tim Tate

I dived into JavaScript and Node.js seriously in 2012, and I had never experienced a language change so incredibly huge as ES6. The previous big change happened in 2009 with ES5. ES6 literally changed everything. It was such a huge revamp of JavaScript that every day you had so many things that could get into that spec but you didn’t really know if they made it, and you had to catch up as everyone on Twitter was talking about those things that maybe were the next big thing.

var was left in the dust.

function never exist any more.

Prototype-based inheritance, which took a long time to learn properly, is gone, hidden under the 🌈 carpet of classes.

This was just the surface.

Build all the things

One big shift that was happening was building.

We went from a very simple thing, including our JavaScript with script tags, to having build steps that compile our language to some incomprehensible huge file. At first I resisted strenuously, I got up in my tower fully armed with cannons to fight the build army.

But when the Babel forces came along, I initially fought even harder but in the end I raised the white flag, and I joined the enemy.

I realized Babel is not some fancy library that introduces future, edge features, and when those land in the browser we’ll forget Babel. No, Babel is here to stay, for the foreseeable future.

When ES2017 will fully land in the browser, Babel will allow for ES2018, ES2019 and so on. There’s no escape. Embrace the future, Babel is your friend.

Use the simplest alternatives

The tooling is one of the hardest part of JavaScript nowadays. Yes, you can learn all about Webpack but when you start out, ignore everything and use ready-made solutions like create-react-app, the React Boilerplate that hide the tiny details for you and let you focus on the code.

Don’t start by setting up an environment, learn by using Glitch: there’s no simplest thing to start diving into modern JavaScript.

No more huge releases

ES6 was so big that the ECMAScript committee decided to do smaller releases next time. This is why ES6 is also called ES2015, and was the first release with the year- we’ll have a yearly release from now on.It’s easier to catch up, will have less changes as the time to add them is limited, and it’s predictable (surrend, there will be change).

Ignore the buzz

If you’re like me, you might follow a lot of people on Twitter that are always on the edge. Maybe some thought leaders that dictate what’s the next big thing. They say to use X, everyone else uses X.

Maybe they like to show their snippets using the latest APIs which are not even close to be standard, but can be used with a flag in the browser.

They might have a good reason. You do not. Don’t fall in the trap of the new shiny toys, focus on your work.

There is not a new framework every week

There is a joke floating around that says “whatever JavaScript framework flavor of the month” or “there’s a new library every week”. That’s true, there is a gazillion people working on JavaScript and this is great, it brings innovation and evolution, the kind JavaScript experienced in the last few years, which were huge for the language ecosystem.

But the thing to note is that the big things do not change much frequently.

React is 6 years old.

Vue is 5 years old

5 years is a very long time in tech. Those are stable technologies. Learn it now, they are here to stay for long, too - not going away.

You have plenty of time to become an expert in any of those frameworks, they are not going to go away any time soon.

Accept that things come and go

That said, anything has a lifecycle.

A few years ago jQuery was used everywhere, now rarely new projects start with it.

In 2013 Backbone.js was huge. Now it disappeared from the map.CoffeeScript, removed from the face of earth.

Ember.js, Angular.js and Meteor rocked and stayed at the top of their popularity for a few years, now the most talked ones seem to be React, Vue and Angular (which is different from Angular.js).

Each cycle for those major frameworks usually lasts quite a few years. I still have lots of Ember.js applications running just fine, there is no need to update them if they do their job, and I don’t plan to touch them.

Tech evolves and matures, then it gets used rather than talked about.

You are not stupid for using jQuery

Some people have a thick skin, but if you read around enough, you fill find out those that despise technology that once everyone used - since they know better, they want to inform you that you are wrong 😆

Having used PHP for a long time, I got used to this, it’s normal to have people criticizing something popular. Even Go, which is amazing for its simplicity and sometimes criticized for that. You will always find someone that throws shit at something.

As an example, I have to cite this tweet by Pieter Levels, which built a huge independent business with a single PHP file.

But as a beginner you might find out someone that says you’ve chosen an old tech, that no one uses it any more, that you should use React instead.Ignore them, move them out of your mind.

Remember:

If it works for you, it’s the right stack.

Most of the times tech is built from giant companies with needs completely, radically different than yours, or the ones of your small team. Go with what you know and make a difference even without using leading edge technology.

Now, probably you don’t need jQuery. But not in place of a framework - plain JavaScript is super fine.

The other part of the spectrum is over-engineering. Don’t use a tech just to feel smarter. Know it better. And learn when to use a framework or library helps you.

You don’t have any obligation to know everything. Find your balance.

While it might sound from reading your Twitter feed, no one knows all the things. There’s no way one can learn all the stuff that’s going on in frontend development. This is a lifetime school. There’s absolutely now way to graduate.

Pick tech with user-friendly documentation

It’s not by chance that React and Vue have an amazing documentation.It’s a key part of their success.

JavaScript will evolve again

Last year the ECMAScript language introduced await/async and now that feature of the language is used a lot. Promise-based code looks simply bad, you feel the urge to rewrite everything.

Don’t do it, and instead use new features for new code you write.The same will happen this year, with ES2018. Everyone will talk about them for a while, then we’ll get back to work and we’ll start talking about the ES2019 features.

Embrace the change. It’s much better than betting on a tech that then stalls and fades into being irrelevant in a few years: JavaScript is here to stay!

Learn the basic fundamentals, and pick your own journey

Developing on the Web Platform requires a commitment to learn something new often, even just to find out what’s possible.

Sometimes learning in 20% of the time the 80% of the things you will need is enough, without diving too much into the edge cases.

The journey has just begun

JavaScript is still very young compared to other languages, it’s hugely popular and it was able to dramatically change in the last few years. It attracts lots of new talented developers every day, and it’s fascinating thinking about the JavaScript we’ll write in 10 or 20 years from now.

What is Imposter Syndrome

flavio ⚡️🔥 — Tue, 17 Sep 2019 05:00:00 +0000

Every person, sooner or later, is going to suffer from this thing which we label “imposter syndrome”.

You might have this feeling now, but you don’t know that it has a name attached.

Let me describe some situations where you might find imposter syndrome in the wild.

You are a developer, have no Computer Science degree, and you feel people that got the CS degree know a lot more than you, and you should get one too in order to be called a developer too
You work on a project and you call it a little side project, not a real project, because - you know - it’s just a simple app
You constantly belittle yourself, and have low confidence in your abilities
You think other developers know a lot more than you do.
You think some day someone will find out what you are not worth your job position, as you can’t solve the coding interview quiz #423 on a random book
You think you don’t belong to the “coder’s club”
You’d like to start blogging but you fear other’s opinions and even think that you can’t add anything new to the table, so you don’t even start

I know these examples because I have people emailing me those very specific issues.

Now sometimes I think the solution is to tell you

everyone’s winging it
no one really knows what they are doing
people you look up to like to show themselves as overconfident publicly, but under the hoods they’re not really like that
things will always be like this

But this is still very self-deprecating.

The real response to all this thinking is to realize how far you went from when you started.

Look back.

There was a day when you could not even figure out how to start the computer. What code even was. You didn’t know you could actually create programs and make the computer do what you want.

Look at you now.

You are the best version of yourself and yet you are perfectly sure that tomorrow you’ll be an even better version.

You are improving. Just like your code.

But you know you are not perfect at your craft, and I think that this is a feeling that might never go away. After all programming is such an enormous field.

And we all know that person that is very overconfident, and will deprecate others just because they don’t know that specific thing they happen to know a lot about… well, don’t be that person.

Find your sweet spot.

I’m sure you’ll even get better at your craft if you start believing more that you were made for it.

The hardest part of solving a bug is identifying that bug. The rest comes easier.

How to write Unmaintainable Code

flavio ⚡️🔥 — Sat, 07 Sep 2019 05:00:00 +0000

In this tutorial I want to illustrate how to write unmaintainable code.

By writing unmaintainable code you can make sure you will never get fired because you’ll be the only one capable of understanding what the code does, and most importantly why.

Please note: this post is ironic

Assign weird, fantasy and casual names to your variables, functions and objects. There should be no correlation between the name and what the item does or how it behaves.
Prefer abbreviations and acronyms over descriptive names. One-letter variables are great.
Favor reuse of variables in the code. Always use i in your loops.
Use your own language for names. After all, there’s no need to all use English.
Same applies to comments. Feel free to write them in whatever language you speak, who cares if the next developer is from another country?
As for comments, I was joking. Do not write any comments.
If you really want to write comments, do not bother to update them when you change the code that they describe.
Prefer global variables over getting too clever with scoping
Never test your code. You are good, your code is good too.
Prefer overcomplicating than being too simplistic. No one was ever fired for creating a complex and ego-fulfilling architecture that required a 3-months long useless rewrite of code that was perfectly working.
Optimize whatever you can in clever ways. Computers are slow, we should avoid overheating them and help fight climate change. Rewrite your code in assembly is often a good idea.
Relatively unknown languages and frameworks are always better than popular and battle tested solutions. Prefer them over the solution everyone else uses.
Better yet, create your own framework.
Never use 3rd party libraries
Overuse 3rd party libraries
Use every design pattern you read about, and try to fit it into your design even if it’s not, really
Use tools built by large corporations because they know it better and your 1-person startup will surely benefit from the thousands of man hours that went into building them. Bonus points if they are very complicated to use and have their own set of clever-sounding naming conventions.
Do not use version control, and do not even version the code at all. After all there’s just one right version of the program. You can easily remember all the changes you perform and most importantly why a change was made. No need to track it in an external repository.
Freely copy and paste code from Stack Overflow or random blogs without understanding it first
Indentation does not matter. At all. Mix spaces and tabs, too.
Freely overuse abstractions. Abstractions are great. Make everything reusable and overthink things like a king.
Perhaps you’ll reuse this library in every project you’ll make in the next 20 years, who knows? Better think about all the possible edge cases first.
Always implement every single great idea you have
2000-lines functions are a great idea
Assume there’s a 10x engineer watching over your shoulders while you code.

Is JavaScript still worth learning?

flavio ⚡️🔥 — Fri, 06 Sep 2019 05:00:00 +0000

I was searching for some JavaScript related questions on Google when I noticed Google suggesting me in the “People also ask” box some questions I thought pretty funny:

Those got my attention.

Clicking the answer of led me to a reassuring answer, as I expected without a doubt. But I also had my own thoughts on the topic, so I though “let me write them”!

Let’s get it straight: JavaScript is more alive than ever.

JavaScript has never been more popular than today. And it’s never been more powerful than today.

When I started learning about JS in the late 90’s, the vast majority of the developers used it to make snow rain on the website at Christmas, show alert and dialog boxes, and do all weird kinds of effects. It was kinda fun, but only the pros would use it to create things more complicated than a poll or something.

When I got into JS seriously in 2012-2013, JS was much more serious. Gmail, Google Maps and other thick client applications showed us all what was possible with JavaScript. Node.js was just starting to become popular but the number of people using it in production was thin.

Nowadays many people learn JavaScript as their first and only programming language. And they might never learn another one for years, because I’d say that thanks to being the only language that works inside Web browsers, JavaScript is the most popular and powerful language in the entire world.

If anyone tells you any different, maybe it’s because their favorite programming language is much less popular and they hope one day people stop using JS and use the one they invested so much into :)

How to make your first Pull Request on GitHub

flavio ⚡️🔥 — Thu, 11 Jul 2019 05:00:00 +0000

Many tutorials exist about this topic but they make things overly complicated by assuming one has to contribute code to a project. So there’s all the Git setup before that.

What if you just need to edit a file, maybe the project README to fix a typo?

You don’t need to know how to code or how to use Git to do that. But once you start doing Pull Requests, you can do many more things and collaborate on projects with other people! And maybe this will push you to also contribute code later on.

I assume you already have a (free) GitHub account. If you don’t, then go to github.com and get one.

Let me show you the process.

I went to this page https://web.dev/prefers-color-scheme/ and I found a possible typo. This line is missing a dot at the end.

I’m not a grammar nazi, this is just for the sake of finding an example 😄

I know that site is hosted on GitHub, and that exact article is hosted here: https://github.com/GoogleChrome/web.dev/tree/master/src/site/content/en/blog/prefers-color-scheme

I open the index.md file https://github.com/GoogleChrome/web.dev/blob/master/src/site/content/en/blog/prefers-color-scheme/index.md directly on GitHub and I press the pencil icon in the file toolbar. Hovering it says “Fork this project and edit the file”.

This brings up an editor view with this information:

You’re editing a file in a project you don’t have write access to. Submitting a change to this file will write it to a new branch in your fork flaviocopes/web.dev, so you can send a pull request.

I can go and add that dot, then at the form at the bottom I explain the changes I made:

I pressed the “Propose File Change” button and a compare view showed up.

There I can review the changes I made, to make sure all is fine, and finally I can click the “Create Pull Request” button. Currently the changes have been made to your fork of the project, which was made automatically by GitHub when you clicked the pencil icon.

At the top of this view you can see that I’m about to submit a PR to the GoogleChrome/web.dev project from my form flaviocopes/web.dev, from my branch patch-2 to their master branch.

Pressing the “Create Pull Request” button shows another form where I can write a detailed description for the Pull Request.

Pull Requests can contain many different changes, so in theory you could have lots of files edited in the same PR, this is why you can add a summary.

This repository has a template for the PR text, to help the team manage it. Our PR is very simple so I remove the template and just paste the content from the commit message from before.

Notice the hint on the right? They tell me the project has a CONTRIBUTING.md file, which explains how to contribute and the guidelines. Pretty cool.

Seems we need to sign a CLA (Contributor License Agreement) to complete our PR. I already signed a Google CLA in the past so this step is clear for me, but you might need to fix that. Most projects don’t really need it.

I clicked “Create pull request” and the PR is now sent!

Now it’s up to the project maintainers to step in and accept it, you just need to wait for an email telling you that it’s been merged, or any comments other people had.

[… a couple hours passed by…]

I got an email back, the PR was rejected because that dot was actually in the correct place! (I didn’t know that).

But anyway here’s a thing I wanted to add: don’t be angry or upset if a PR you submit is not accepted. The maintainers of the project work on it for months or years and they know better than you about what’s better for it.

Plus, especially with code, views might be very very different and a PR you think is great might not be welcome.

It’s also best to ask before working on a substantial PR, to see if it’s something the project actually needs.

But this is a topic on its own.

JavaScript Equality Operators

flavio ⚡️🔥 — Fri, 31 May 2019 05:00:00 +0000

Those operators accept two values and return a boolean:

== checks for equality
!= checks for inequality
=== checks for strict equality
!== checks for strict inequality

Let’s talk what we mean for strict. Without the strict check, the second operand is converted to the type of the first before making the comparison. Strict prevents this.

Examples:

const a = true

a == true //true
a === true //true

1 == 1 //true
1 == '1' //true
1 === 1 //true
1 === '1' //false

You cannot check objects for equality: two objects are never equal to each other. The only case when a check might be true is if two variables reference the same object.

Some peculiarities to be aware: NaN is always different from NaN.

NaN == NaN //false

null and undefined values are equal if compared in non-strict mode:

null == undefined //true
null === undefined //false

What's the best way to create authentication for a single-user Node.js app?

flavio ⚡️🔥 — Fri, 31 Aug 2018 10:28:50 +0000

My app is not going to have more than one user.

Idea: when the app first loads, if it's the first time ever it will create a token and send it to the client (JWT?). It sets initialized to true in its config file.

Then the client will use that token. No other client can connect.

If the client loses the token, nothing can be done except setting initialized back to false in the app config file.

Any other strategy you'd use?

Build an HTTP Server

flavio ⚡️🔥 — Sun, 19 Aug 2018 13:00:00 +0000

Here is the HTTP web server we used as the Node Hello World application in the Node.js introduction

const http = require('http')

const port = 3000

const server = http.createServer((req, res) => {
  res.statusCode = 200
  res.setHeader('Content-Type', 'text/plain')
  res.end('Hello World\n')
})

server.listen(port, () => {
  console.log(`Server running at http://${hostname}:${port}/`)
})

Let's analyze it briefly. We includes the http module.

We use the module to create an HTTP server.

The server is set to listen on the specified port, 3000. When the server is ready, the listen callback function is called.

The callback function we pass is the one that's going to be executed upon every request that comes in. Whenever a new request is received, the request event is called, providing two objects: a request (an http.IncomingMessage object) and a response (an http.ServerResponse object).

request provides the request details. Through it we access the request headers and request data.

response is used to populate the data we're going to return to the client.

In this case with

res.statusCode = 200

we set the statusCode property to 200, to indicate a successful response.

We also set the Content-Type header:

res.setHeader('Content-Type', 'text/plain')

and we end close the response, adding the content as an argument to end():

res.end('Hello World\n')

The Node Event emitter

flavio ⚡️🔥 — Sun, 19 Aug 2018 05:00:00 +0000

If you worked with JavaScript in the browser, you know how much of the interaction of the user is handled through events: mouse clicks, keyboard button presses, reacting to mouse movements, and so on.

On the backend side, Node offers us the option to build a similar system using the events module.

This module in particular offers the EventEmitter class, which we'll use to handle our events.

You initialize that using

const eventEmitter = require('events').EventEmitter()

This object exposes, among many others, the on and emit methods.

emit is used to trigger an event
on is used to add a callback function that's going to be executed when the event is triggered

For example let's create a start event, and as a matter of providing a sample, we react to that by just logging to the console:

eventEmitter.on('start', () => {
  console.log('started')
})

When we run

eventEmitter.emit('start')

the event handler function is triggered, and we get the console log.

You can pass arguments to the event handler by passing them as additional arguments to emit():

eventEmitter.on('start', (number) => {
  console.log(`started ${number}`)
})

eventEmitter.emit('start', 23)

Multiple arguments:

eventEmitter.on('start', (start, end) => {
  console.log(`started from ${start} to ${end}`)
})

eventEmitter.emit('start', 1, 100)

The EventEmitter object also exposes several other methods to interact with events, like

once(): add a one-time listener
removeListener() / off(): remove an event listener from an event
removeAllListeners(): remove all listeners for an event

You can read all their details on the events module page at https://nodejs.org/api/events.html

Understanding setImmediate()

flavio ⚡️🔥 — Sat, 18 Aug 2018 13:00:00 +0000

When you want to execute some piece of code asynchronously, but as soon as possible, one option is to use the setImmediate() function provided by Node.js:

setImmediate(() => {
  //run something
})

Any function passed as the setImmediate() argument is a callback that's executed in the next iteration of the event loop.

How is setImmediate() different from setTimeout(() => {}, 0) (passing a 0ms timeout), and from process.nextTick()?

A function passed to process.nextTick() is going to be executed on the current iteration of the event loop, after the current operation ends. This means it will always execute before setTimeout and setImmediate.

A setTimeout() callback with a 0ms delay is very similar to setImmediate(). The execution order will depend on various factors, but they will be both run in the next iteration of the event loop.