DEV Community: Akshay Kannan

Switching to UnoCSS

Akshay Kannan — Sat, 05 Nov 2022 10:13:00 +0000

My website has always been the breading ground for new tech. I've been using this website for testing out new tools and
I write about them if they are worth writing about, one such tool is Unocss. This post will be a deep dive on why I am
migrating to unocss.

CSS Utilities

First let's understand what is a css utility. Css Utilties or also known as atomic css is a way of defining small reusable classes,
that has a very little functionality. For example,

.p-1 {
  padding: 1px;
}
.p-5 {
  padding: 5px;
}
.p-10 {
  padding: 10px;
}

As you can see from the above code, we have separate css for each value of padding. So instead of defining css manually
everytime, you can simply define these helper css or use an existing css utility framework. I've been
working with a lot of such utitlity frameworks, and people have their own utilty css'. Some of the famous css utility
frameworks are Tailwind Css, Windi Css and Tachyons
etc. So basically these utility frameworks will have a list of helper classes which provide basic css functionalities.

Old-school way

The traditional way of using a css utility or helper is to build one yourself, that is what we (@Facilio)
were doing, when I joined. Like we would have our own helper css files which will have hundreds of utility css. Based on the
requirement we might add new classes. As you guessed, this is a lot of work and our production bundle had all
those css files even if certain classes weren't used. This is when I came across tailwind.

The Problem

I've been using tailwind css a lot, both in my personal projects as well as in work related ones. This seemed to
solve the initial problem we had of defining and maintaining all the inbuilt helper css'. Tailwind was good, but
I started facing problems when I had to use css properties that are not part of tailwind's utility css. Like for example,
let's say you want to give a padding exactly of 210px (to match certain design constraints), you can't do it in tailwind,
you can either use p-52 (208px) or use p-56 (224px). You can fix this by providing this special css property in
tailwind config, but this method won't scale as we can't keep adding custom css properties, this defeats the purpose of
using a utility css framework.

// tailwind.config.js
module.exports = {
  theme: {
    padding: {
      DEFAULT: '1px',
      '0': '0',
      '2': '2px',
      '3': '3px',
      ....
      '54': '210px' // <-- here
    }
  }
}

Another issue I faced with tailwind was that, tailwind was shiping it's entire utility classes
in our production build which affected the app's performance. Also I was working on multiple microfrontends at that
time and each one had a lot of these unwanted css utilities which made the issue even worse. After searching through
their docs I came across a concept they had called Purging which ships only the used css classes,
but this seems to only work in production and I still have to work with all those utility css during development.

This is where frameworks like Windi comes into play, they are similar to tailwind css, but they have a lot of utility
css classes compared to tailwind and they are on demand. I really like Windi's on-demand way of doing things. Traditional css
frameworks would generate the css' and then they would use the required ones in the production build. This might affect
your app's performance because of unecessary computations (since we are generating the css and are not using them). But
the on-demand way would first scan for the css classes you are using and then generate only those in our builds.

Thus I was able to solve the problem of removing unwanted css in my builds, but I still couldn't use custom css classes
(even in Windi CSS). To do so I had to override their config with a butt load of information, which was a lot to do for
a simple functionality.

The Solution

UnoCSS unlike other css frameworks is a css engine without any utility css of it's own, rather it uses different css framework's
presets. They generally work with build tools and after mentioning the preset you like you can use that framework's classes
in your projects right away. Guess what, you can give any number of presets or write your own preset and use it with UnoCSS.
And like Windi CSS they use the on demand way of generating css. I am using next js in this website so the build tool used
in next is webpack, also I was using tailwind with postcss previously, so the migration looks something like this,

Configuring UnoCSS with Next Js

First you can remove all the tailwind and postcss config files from your project, then remove the following packages,

{
  "autoprefixer": "^10.2.6", // remove
  "postcss": "^8.3.5", // remove
  "tailwind": "^2.2.4" // remove
}

Then add the following dependencies,

npm i @unocss/preset-uno @unocss/preset-web-fonts @unocss/webpack unocss -D

Now add a unocss config file and a next js config file (If you never had one like me before),

// unocss.config.js
import presetAttributify from "@unocss/preset-attributify";
import presetUno from "@unocss/preset-uno";
import { defineConfig } from "unocss";

export default defineConfig({
  presets: [presetUno(), presetAttributify()],
});

// next.config.js
const UnoCSS = require("@unocss/webpack").default;

const nextConfig = {
  reactStrictMode: true,
  webpack: (config) => {
    config.plugins.push(UnoCSS());
    config.cache = false; // have to be false for hmr
    return config;
  },
};

module.exports = nextConfig;

Now import the uno.css file in /_app.js file and use tailwind / windi css class names to see the magic.
You can add other frameworks presets or add a custom one also, check out their docs
to see on how to add your own custom presets. Apart from presets UnoCSS has a few other advantages,

You can write your own custom rules / classes, like you can add the following for a custom border css,

rules: [["my-custom-border", { border: "solid 1px pink" }]];

Dynamic Rules

You can also add dynamic rules by using regex,

rules: [
  [/^m-(\d+)$/, ([, d]) => ({ margin: `${d / 4}rem` })],
  [/^p-(\d+)$/, (match) => ({ padding: `${match[1] / 4}rem` })],
];

You can also change the order of precedence in which the styles should be applied, like in the following configuration border-1 is applied or has higher precedence than border-2 if used together,

shortcuts: {
  "border-1",
    { border: "solid 1px pink" },
    "border-2",
    { border: "solid 1px green" };
}

Also you can add custom css resets by installing @unocss/reset. If you use UnoCSS along with other CSS frameworks, they probably already do the resetting for you. If you use UnoCSS alone, you can use resetting libraries like Normalize.css.

Rust in javascript

Akshay Kannan — Sun, 12 Jun 2022 13:23:58 +0000

Why do we need rust in javascript ?

We have been using javascript based transpilers and bundlers for a long time now and we have achieved a lot
using this single threaded language. But as we keep building more and more complex stuff, relying a lot on
this language will not be ideal because of various reasons.

One such reason is the javascript's slowness, javascript itself is not slow but, when it comes to CPU intensive tasks
it slows down a lot. Another reason is the garbage collection
in javascript, where memory management is done by the language itself, unlike C++ & Rust. So to speed up the build process
we need a solution in another language, this is where Rust comes in. The thing I love about rust is it's compiler, which
gives self-evident error messages, which languages like javascript fails to do.

Rust

Rust is a low level, memory efficient programming language. It is mainly used in systems,
where performance is important like game engines, operating systems, and databases, etc. So it makes a great choice for
building transpilers and bundlers for javascript. Rust is being used by big companies like Discord, Nextjs, AWS, Cloudfare,
etc. This doesn't mean web developers have to start learning rust right-away, but you can start using tools which are built on
rust and slowly start adopting rust into your flow. The following are the few interesting tools built on top of rust for
javascript,

SWC (Speedy Web Compiler)

SWC is used for bundling and transpiling javascript / typescript and produce a output which is accepted by most browsers.
SWC is said to be 20X faster than Babel, where the former is built on rust and the latter is built using javascript. SWC
is maintained by Vercel and Nextjs is actively using it for their ecosystem. The following are the features they support
right now,

Compilation
Bundling (swcpack)
Minification
Transforming with WebAssembly
Usage inside webpack (swc-loader)
Improving Jest performance (@swc/jest)
Custom Plugins

To start using swc you can install @swc/cli and @swc/core, let's say you have javascript file called index.js, then you can
run the following command to produce a transpiled js file in output.js,

npx swc ./index.js -o output.js

// index.js
const test = () => {
  console.log("hello world");
};

// output.js
var test = function () {
  console.log("hello world");
};

//# sourceMappingURL=output.js.map

Check out this swc playground to know more about the functionalities that swc supports.

Deno

Deno is a runtime environment for javascript like Node.js, but unlike
node it can also be used as a runtime environment for typescript and webAssembly. Deno is built on rust and it also
uses SWC for linting and code formatting. It is considered to be the improved version of node in terms of speed and secureness.
It was mainly built to avoid the use of a centralized repository system (npm), and “heavy-handed tooling.”

Rust & WebAssembly

Webassembly is a machine language which is accepted by the browsers and they run in near native
speed. It was first introduced in 2017 and now a lot of apps are using it. There are various tools out there to compile
a language's code to Webassembly, so that other programming language developers can contribute to the web. In order to
generate a wasm code you need a compiler to convert it.

There are various libraries / compilers out there to convert different languages to web assembly, for example to convert
C++ to wasm there is Emscripten, also there is Asterius, a Haskell to wasm compiler, and
another library to convert typescript to wasm is Assembly script. Rust actually compiles
to wasm so that we can run it in browsers, The Rust team is committed to a
high-quality and cutting-edge WASM implementation.

Conclusion

Like Rust, we also have another programming language called Go Lang which is slowly finding it's place in javascript tooling
ecosystem. We have esbuild which is said to be the fastest js module bundler and vite is using esbuild to bundle the js
code we write. ESBuild is built using Go. Rust has a steeper learning curve
compared to Go, but Go was not built for building systems or tooling, Go lang is more commonly used for building web apis'
and can be considered as a good alternative for Nodejs.

I love a lot of things about rust starting from it's memory management, direct & self-evident erorr messages, etc, and I
am planning on learning it by building a small js module bundler, about which I might write a blog in the
future 😉.

What the heck is an Abstract Syntax Tree (AST) ?

Akshay Kannan — Sat, 23 Apr 2022 17:02:12 +0000

If you are a front-end engineer who has some experience around front-end tools like prettier, eslint, webpack, rollup, vite, etc., learning ASTs can be quite handy. There are a lot of things you can do using AST, for instance you can write codemods, which modifies our original source code using the transformer we write using ASTs, can be used to remove unwanted stuffs from our code base. Another interesting use case is writing a custom eslint plugin, check out this blog to write your own eslint plugin, can be used to introduce new eslint rules, which are outside of existing eslint configurations.

Why do we need AST ?

Have you ever wondered how eslint or prettier or even webpack work, they just collect the code we write and give a result, which can be a modified version of our code or give back other stuffs like warnings / errors on the code we wrote (linters). They are written on javascript, which can be confusing because they manipulate or do stuff on the javascript code we write but they themselves are written in js. This concept is called Meta Programming, where programs treat other programs as thier input / data. Let's break down the problem and see where AST comes in here.

In order to change our js code we need to have the code in a format that can be understood using js.
This format should have all the information right from imports to variable creation to exports from our js file.
The better way can be to represent it in a tree format which branches out right from the starting line having info about each token of our code.
If the format is a tree it can be represented as an javascript object as well (deep nesting the nodes as properties of the parent).

So we should have a parser, which should go through the code we give and return a tree / object representation of the code, so that we can tap into different properties which might be different tokens of our code. That tree is an AST and this why we need it.

Parsers

As discussed above we need a parser to get an AST of our code. There are a lot of parser right now, the following are a few of those,

Each parser have their own AST implementation, let's consider babel parser, the following is a tree generated from the below javascript code,

Code

let number = 10

As you can see from the code we have a variable declaration with variable name number with value name. This following is the ast for that line,

AST for code

{
  type: "File",
  errors: [],
  program: {
    type: "Program",
    sourceType: "module",
    interpreter: null,
    body: [
      {
        type: "VariableDeclaration", // variable declaration
        declarations: [
          {
            type: "VariableDeclarator",
            id: {
              type: "Identifier",
              name: "number", // name of the variable
            },
            init: {
              type: "NumericLiteral",
              extra: {
                rawValue: 10,
                raw: "10", // value of that variable
              },
              value: 10,
            },
          },
        ],
        kind: "let", // declaration type
      },
    ],
    directives: [],
  },
  comments: [],
};

You can check out Ast explorer site for playing around with different parser and write transformers for each parser. You can check out this post on how a parser works to generate an AST.

Writing your own module bundler

Akshay Kannan — Sat, 16 Apr 2022 08:11:48 +0000

I find build tools endlessly interesting and we seem to have a lot of 'em today. Now a days, it is easier to select a framework,
than to choose an optimal build tool. If you are a front-end developer, you must've heard about or tried to wrap your
head around module bundlers or build tools. Have you ever wondered how each build tool works ? Let's learn how a build tool
works internally, by building a basic one.

Note: This blog is inspired from Tan Li Haun's blog on module bundler. In his blog he built a bundler the webpack way, in this blog I am building the bundler the rollup way.

What are module bundlers ?

Bundlers help in bundling different pieces of javascript code that we write, into a single complex / larger javascript file.
We can also provide loaders to support files that are not javascript, so that image assets, css assets, etc, can also
be bundled inside our js file, which makes it easier to serve it to the browser. We do this, because for a long time
browsers did not support module system,
but it is not completely true now a days.
So if we give an entry point to the build tools, all the dependencies and the sub dependencies of it's dependencies will
be bundled together.

For building a basic javascript module bundler we should figure out the following things,

Resolve the dependencies of the files that are imported or required.
Remove any unused dependency from the bundle.
Maintain the order of the files that are included.
Resolve import statements, by differentiating node_modules and relatively imported modules.

So there are two ways our code will be bundled, to understand it let us compare how rollup and webpack will bundle the
following files, if app.js is provided as an entry file

// add.js
const add = (a, b) => {
  return a + b;
};
export default add;

// diff.js
const diff = (a, b) => {
  return a - b;
};
export default diff;

// app.js
import add from "./add.js";
import diff from "./diff.js";

console.log(add(1, 2));
console.log(diff(2, 1));

Webpack

const modulemap = {
  "add.js": function (exports, require) {
    exports.default = function add(a, b) {
      return a + b;
    };
  },
  "diff.js": function (exports, require) {
    exports.default = function diff(a, b) {
      return a - b;
    };
  },
  "app.js": function (exports, require) {
    const add = require("add.js").default;
    const diff = require("diff.js").default;

    console.log(add(1, 2));
    console.log(diff(2, 1));
  },
};

The above is a cleaned up code click here, to check
out the actual bundled code by webpack,

We have three files, add.js, diff.js, and app.js, app.js imported the first two modules and also has a console statement.
As you can see from the above example,

Webpack creates a module map for each module we have. The map was created with file name as property names and content inside the properties are methods with code from each module.
Also each method has exports and require arguments to import and export the contents within each module.
Thus when our dev server is started webpack uses the entry path and by creating the above module map it starts serving the bundled code.

Rollup

const add = (a, b) => {
  return a + b;
};

const diff = (a, b) => {
  return a - b;
};

console.log(add(1, 2));
console.log(diff(2, 1));

On first glance the rollup way of bundling seems light and straight forward, it bundles each code in the order of
dependencies to avoid temporal dead zone
and finally the entry point is present in the last portion of the bundled code. Thus we can try to mimic the rollup way
of bundling in this blog.

Building a module bundler

The following are the steps for building your own module bundler,

Create a module graph with it's dependencies.
Bundle the modules with respect to the module graph.
Write the bundled code in the target location.

function builder({ input, ouput }) {
  // create module graph
  const moduleGraph = createModuleGraph(input);
  // bundle the modules
  const bundledCode = bundle(moduleGraph);
  // write the bundled code in the output location
  fs.writeFileSync(output, bundledCode, "utf-8");
}

1. Creating a module graph

We need to write a ModuleGraph class, which will hold the info about each modules' path,
it's dependencies, content, AST, etc. We will be using ASTs (Abstract Syntax Tree) for manipulating the contents of each
file and knowing it's dependencies, to learn more about ASTs
check out this blog. For constructing the AST of
a javascript file we will be using @babel/core package here.

const babel = require("@babel/core");

class ModuleGraph {
  constructor(input) {
    this.path = input;
    // get content of the current module
    this.content = fs.readFileSync(input, "utf-8");
    // will return an ast of the module
    this.ast = babel.parseSync(this.content);
  }
}

We can use babel's parseSync method to get an ast of a module. Thus the above class can be used to create module objects
with all the required info. Now let's see how to create a module dependency graph.

function createModuleGraph(input) {
  return new ModuleGraph(input);
}

This method will be called to create a dependency graph. But from the ModuleGraph class above we won't have any
dependencies related info so let us change the ModuleGraph class a bit,

class ModuleGraph {
  constructor(input) {
    this.path = input;
    this.content = fs.readFileSync(input, "utf-8");
    this.ast = babel.parseSync(this.content);
    // store the dependencies of the current module
    this.dependencies = this.getDependencies();
  }

  getDependencies() {
    return (
      this.ast.program.body
        // get import statements
        .filter((node) => node.type === "ImportDeclaration")
        .map((node) => node.source.value)
        // resolve the path of the imports
        .map((currentPath) => resolveRequest(this.path, currentPath))
        // create module graph class for the resolved dependencies
        .map((absolutePath) => createModuleGraph(absolutePath))
    );
  }
}

From the above code we can see that, we need to

Get imports from ast.
Resolve the dependencies' path and create module graph for each dependencies.

Here resolving dependencies is quite tricky, webpack follows a different algorithm (which includes aliases and stuffs)
to resolve dependencies. For the sake of simplicity, we can follow the node js module import resolving alogrithm by using
path.join and joining the dirname of it's parent module and the current module.

function resolveRequest(requester, requestedPath) {
  return path.join(path.dirname(requester), requestedPath);
}

If app.js is passed as an input, then the following module graph will be created.

ModuleGraph {
  path: './test/app.js',
  content: 'import add from "./add.js";\n' +
    'import diff from "./diff.js";\n' +
    '\n' +
    'console.log(add(1, 2));\n' +
    'console.log(diff(2, 1));\n',
  ast: Node {
    type: 'File',
    start: 0,
    end: 108,
    loc: SourceLocation {
      start: [Position],
      end: [Position],
      filename: undefined,
      identifierName: undefined
    },
    errors: [],
    program: Node {
      type: 'Program',
      start: 0,
      end: 108,
      loc: [SourceLocation],
      sourceType: 'module',
      interpreter: null,
      body: [Array],
      directives: []
    },
    comments: []
  },
  dependencies: [
    ModuleGraph {
      path: 'test/add.js',
      content: 'const add = (a, b) => {\n  return a + b;\n};\n\nexport default add;\n',
      ast: [Node],
      dependencies: []
    },
    ModuleGraph {
      path: 'test/diff.js',
      content: 'const diff = (a, b) => {\n  return a - b;\n};\n\nexport default diff;\n',
      ast: [Node],
      dependencies: []
    }
  ]
}

2. Bundling

After creating the module graph, the next step is to create a bundled js code. Since it is a graph, I have written a small
snippet to traverse the graph and store modules' content in the order it should be bundled (i.e dependencies of a module should
come before the actual module - Depth First Search - Rollup way of bundling)

function build(graph) {
  let modules = dfs(graph);
}

function dfs(graph) {
  const modules = [];
  collect(graph, modules);
  return modules;

  function collect(module, modules) {
    modules.push(module);
    module.dependencies.forEach((dependency) => collect(dependency, modules));
  }
}

Now since we have collected the modules in the order it should be bundled we can concatenate the contents, but we would
still have the import statements. So we can use babel's transformFromAstSync method and try to remove the import-export
statement.

function bundle(graph) {
  let modules = collectModules(graph);
  let code = "";
  for (var i = modules.length - 1; i >= 0; i--) {
    let module = modules[i];
    const t = babel.transformFromAstSync(module.ast, module.content, {
      ast: true,
      plugins: [
        function () {
          return {
            visitor: {
              ImportDeclaration(path) {
                path.remove();
              },
              ExportDefaultDeclaration(path) {
                path.remove();
              },
            },
          };
        },
      ],
    });
    code += `${t.code}\n`;
  }
  return code;
}

:::tip
Here we are removing the export statement of the input module as well which is not ideal, so we can mark the input module
and not remove export declaration for that module alone.
:::

3. Writing in the target location

Finally we can write the bundled code in the target location, using fs.writeFileSync, but writeFileSync will only
write if the directory of the output is also present (i.e if output location is 'dist/index.js', it will write only if
dist folder is present). So I have a copied a small snippet from stack overflow to write a file by creating a directory,
if not present,

function writeFileSyncRecursive(filename, content, charset) {
  const folders = filename.split(path.sep).slice(0, -1);
  if (folders.length) {
    // create folder path if it doesn't exist
    folders.reduce((last, folder) => {
      const folderPath = last ? last + path.sep + folder : folder;
      if (!fs.existsSync(folderPath)) {
        fs.mkdirSync(folderPath);
      }
      return folderPath;
    });
  }
  fs.writeFileSync(filename, content, charset);
}

Now passing the input as app.js and output as dist/index.js to builder function, you will get the following bundled
code,

const diff = (a, b) => {
  return a - b;
};

const add = (a, b) => {
  return a + b;
};

console.log(add(1, 2));
console.log(diff(2, 1));

Thus we have written our own module bundler by following the rollup way. We can also support a few extra options
like code minification and mangling by using terser, we can also support iife
format by wrapping the bundle with an iife expression. Since this is a basic example on how a bundler works, I have
skimmed through a few stuffs, but in practice module bundlers are quite complex and interesting to learn about.

Check out the entire code in github