Forem: Nahuel Scotti

How to make your Javascript code run faster

Nahuel Scotti — Thu, 31 May 2018 15:58:00 +0000

A long time ago, in 2011, I wrote my first DNI (Spanish ID) validation script. I did it with ActionScript.

Some years later, after the Flash era, I re-wrote it for Javascript.

Recently, I went into a heavily Functional Programming learning process and as a goal, I propose myself to create a new module applying what I learned.

The result (not following FP paradigm too much I would say) is:

Better DNI

singuerinc / better-dni

The fastest Spanish DNI (NIE / NIF) validation out there.

The fastest Spanish DNI (NIE / NIF) validation out there — And lighter: 660 bytes.

Installation

// npm
npm i better-dni
// yarn
yarn add better-dni

Usage

isValid / isNIF / isNIE / ctrlChar

import { isValid, isNIF, isNIE, ctrlChar } from "better-dni";

// validates any type of DNI (NIE or NIF)
isValid("Z7662566Y"); //=> true

// checks if it is a valid NIF
isNIF("06672804K"); //=> true

// checks if it is a valid NIE
isNIE("X1302311M"); //=> true

// returns the control letter in upper case
ctrlChar("X1302311M"); //=> 'M'
ctrlChar("X1302311"); //=> 'M'

Generators

NIF

import { randomNIF, randomNIFWith } from "better-dni";
randomNIF(); //=> '31719111H'

// returns a valid random NIF given the control letter
randomNIFWith("C")

…

View on GitHub

Quickly I found out that there are many modules doing the same…

Replicate what others already did is a little boring, so I changed my goal to

“Create the faster module to validate a DNI”

In this process, I found many ways to improve the speed of the code, although sometimes it looks a bit uglier, some of them made the code twice faster.

Note that you would get better results with newer versions of Node. I think https://jsperf.com is quite good in speed since it runs isolated with just one or two lines of code, but when I tried in “normal” computers with the whole module the difference is quite big. I would say that you should test your code in different environments and see where you can optimize.

Here is what I discovered:

str.substr() vs str.slice()

'0123456789'.slice(-9); // => '123456789'
'0123456789'.substr(-9); // => '123456789'

Winner: slice / x21 faster! / test

toLowerCase() vs toUpperCase()

I have to admit that I have never thought before why would one method be faster than the other. I was looking into the V8 code and looks like https://github.com/v8/v8/blob/master/src/string-case.cc#L16 is the answer to that.

'A'.toLowerCase(); // => 'a'

'a'.toUpperCase(); // => 'A'

This is especially useful if you need to compare two strings.

Before comparing them, better to convert them to lower case.

Winner: toLowerCase / slightly faster / test

Random image related to speed. You need one in all posts. Photo by James Traf on Unsplash

indexOf() vs object prop

const y = 'xyz'.indexOf('y'); // => 1

const y = {x: 0, y: 1, z: 2}['y'] // => 1

Winner: indexOf / slightly faster / test

String concatenation vs Template literals

I don’t know why I imagined that template literals were more complex than a simple string concatenation.

const x = 'x';

'yyy' + x;

'yyy${x}'; // faster

Winner: Template literals / slightly faster / test

Convert to number

parseInt('1234', 10); // => 1234

+'1234'; // => 1234

Winner: +sign / x6.12 faster! / test

Math.floor() vs Bitwise shift

I took some inspiration from this blog post.

Math.floor(1.123456789); // => 1

1.123456789 << 0; // => 1

Winner: Bitwise shift / slightly faster in jsperf but Math.floor() performs better much better in my MacBook Pro. / test

Other tips that could help your code to run faster

Tip 1

Do easy validations first and return as quickly as possible. Take a look at these snippets:

if(someComplexValidation(value) && value.length !== 9) return;

if(value.length !== 9 && someComplexValidation(value)) return;

It’s the same code right? Do the “easy” validation first so your code does not run and return if the first validation does not pass.

Tip 2

Avoid using costly methods like “toUpperCase()” and try to use smart alternatives:

const n = 'XYZ'.indexOf('y'.toUpperCase()); // => 2

const n = 'XYZxyz'.indexOf('y') % 3; // => 2

Tip 3

If you know that you can achieve the same result with different methods, find the one that works better for each specific case:

const x1 = 'xyz'.substr(0, 1); // => 'x'

const x2 = 'xyz'[0]; // => 'x'

const x3 = 'xyz'.slice(0, 1); // => 'x'

I hope this would help you to optimize your code!

Do you want to contribute, make it faster? Open a pull request:

singuerinc/better-dni

Migrate from Jekyll to Gatsby

Nahuel Scotti — Wed, 25 Oct 2017 07:04:27 +0000

A bit of history

Some years ago I created my blog with Jekyll and it has been working well for a while.

I have never been a huge fan of Ruby, but because of requirements or convenience I made some apps with it (Rails / Sinatra / Jekyll / etc).

I used to like Jekyll because I could write my posts in Markdown and easily to iterate through them. At that time I took a theme called Lanyon and I tweaked a bit. That was a enough for me.

But recently I found that I was installing Ruby and Jekyll in my machine just to manage my blog (I mostly develop with Node). I tried to develop it inside a Docker container, but was extremely slow.

Some weeks ago one of my colleague at work talked me about Gatsby, and since I was learning React and I started looking at GraphQL (after attend a talk at Nordic.js) I was very interested in give it a try.

Migration from Jekyll to Gatsby

Data

One of the biggest concern about migrating from one generator to another is how you move the data. In my case I have around 45 posts, so it is not a big deal to convert from one type to another, but still a manual work that I wanted to avoid.

Luckily Gatsby works with Markdown and it can take the data from your YAML front matter block, so you don’t have to change anything. You just need to install gatsby-transformer-remark plugin.

Then, in your gatsby-config.js file add:

plugins: [
  'gatsby-transformer-remark'
]

Theme

My blog is clean and simple, I don’t need too much css, instead of bloating my blog with a theme I added Tachyons. I managed to replicate 99% of my previous theme with classes from Tachyons. Something that I would like to do better is to remove the part that I do not use from it.

The current css file has less than 30 lines, the rest of the layout is created with tachyons classes: https://github.com/singuerinc/blog/blob/master/src/layouts/index.css

Slug + Date

This was the only “tricky” one, since I wanted to preserve the same page names in order to make a 1:1 transition it was not possible with the default behavior from Gatsby. I don’t have a date field in my front matter block, so I need to extract the date from the file name.

The slug in my case is generated with this (default in Jekyll) structure:

https://blog.singuerinc.com/[n-categories]/YYYY/MM/DD/dashed-title/

// Given this data:
categories:
  - app
  - macos
  - vuejs
  - electron

filename: 2017-05-09-introducing-tomeito.md

// I would like to get:
/app/macos/vuejs/electron/2017/05/09/introducing-tomeito/

How I created it? Inside the gastby-node.

I used the onCreateNode function to tweak the slug:

exports.onCreateNode = ({ node, getNode, boundActionCreators }) => {
  const { createNodeField } = boundActionCreators

  if (node.internal.type === `MarkdownRemark`) {
    const { categories } = node.frontmatter

    const filename = createFilePath({ node, getNode, basePath: `pages` })

    // get the date and title from the file name
    const [, date, title] = filename.match(/^\/([\d]{4}-[\d]{2}-[\d]{2})-{1}(.+)\/$/)

    // create a new slug concatenating everything
    const slug = `/${slugify(categories.concat([date]).join('-'), '/')}/${title}/`

    createNodeField({ node, name: `slug`, value: slug })

    // save the date for later use
    createNodeField({ node, name: `date`, value: date })
  }
}

Deploy

I used to deploy to GitLab Pages, but I notice that from time to time it had his downtimes, so now I’m testing Netlify with almost the same CI workflow:

Conclusions

Some key points:

Node instead of Ruby
Much faster development workflow, hot reload out of the box.
I can query what I need and transform the data before using it. (I’m looking into the gatsby-plugin-feed to recreate the Atom Feed)
React and GraphQL for free with Gatsby.
Since I am confident with the Node ecosystem I’m able to contribute: First pull request to Gatsby: https://github.com/gatsbyjs/gatsby/pull/2569
Netlify vs GitLab Pages (hopefully 100% uptime)

Final thoughts:

Although the blog is the same, in content and look, the way that is created has completely changed. For me it is a whole new experience, easier, and faster.

I wanted to move the blog to Node long time ago and it is finally there!

Now it is time for my portfolio (also built with Jekyll): https://www.singuerinc.com/

Show me the code

If you want to take a look at the code you can do it, it is published in GitHub: https://github.com/singuerinc/blog

Originally published at https://blog.singuerinc.com/jekyll/gatsby/graphql/2017/11/01/migrate-from-jekyll-to-gatsby/