However, it’s hard to know how much we can actually gain from them. On the other hand, it takes a lot of time to learn or to switch to them. So, it’s important to compare the costs and benefits.

We need a standard benchmark to measure performance between languages. This is what I will do in this article. We will choose some basic but common scenarios to test and compare the results.

Last but not least, no benchmark can 100% reflect the actual scenarios you will encounter. If you have a very sensitive performance scenario, I suggest you write your own benchmark. But for most common scenarios, I hope this article will help.

Playground

We provide a playground where you can run benchmarks on your favorite browsers and OS. The results may vary slightly depending on the environment. If the differences in the timing of different languages in the same test are not large, then we can regard it as the same.

And you can find all the source code here.

Basic language tests

We borrowed some tests from the debian’s benchmark games. It provides some basic tests that can measure the languages. The data structures used in the tests are very similar to those we commonly encounter, so I think this is a test worth referencing.

One thing to notice is that we run each test in a single thread. However, each test is run in a worker. We want to know the performance of each language in a single thread.

BinaryTrees

You can check the detail of this test here. Now we got the result(less is better):

If we run the test for the first time, we can see that Rust in WASM got the best score. But if we run again, we’ll find that JavaScript got the best score.

Don’t be surprised if you run the tests multiple times; the V8 engine usually gets better when it runs the second time (it will optimize the code based on the runtime info). And you will find that the result is unstable. The truth is, these three languages don’t have a large gap in performance. Actually, I don’t think C++ and Rust have any advantage in this competition.

FanncukRedux

Here is another test called FanncukRedux and you can check the detail of this test here. Now we got the result(less is better):

This test has a relatively stable result. JavaScript is the best. We get the same result in multiple tests.

Practical tests

How a language behaves in production depends not only on the language engine itself but also on the ecosystem. The underlying libraries your app uses will determine its performance. In this group, we chose some popular low-level libraries on their platform to test.

Deflate compress

We use the deflate algorithm to compress Hamlet in this test. Deflate is the default algorithm we use for the zip format. We use

• zip for C++
• deflate for Rust

One thing to notice is that in the JS part, we use the CompressionStream from the browser. That doesn’t reflect the performance of the JavaScript engine itself. But in the browser environment, it’s the best we have.

From the results, we can see the browser’s built-in API has a significant advantage over WASM. C++ has a slight advantage over Rust, but not a large one.

Font parsing

In this test, we choose three libraries from three languages to parse a font format and measure the horizontal advance of a very long text.

• Opentype.js for JavaScript
• FreeType for C++
• ttf_parser for Rust

In the results, we can see Rust has a significant advantage. And ttf-parser is literally designed for performance.

Conclusion

In conclusion, this benchmark study provides a comprehensive comparison of various programming languages running in the browser. Although some languages have slight advantages, the performance differences are often not substantial. Some languages, like Rust with its font parser, excel in specific areas. If you need that specific advantage, go for it. But most of the time, JavaScript is sufficient.

Github: https://github.com/PoloDB/PoloDB

Get started

PoloDB is an embedded database written in Rust. If you are developing an app in Rust, PoloDB would be a perfect fit for you. This is because Rust’s API has been designed with compatibility with MongoDB in mind, making PoloDB essentially compatible with MongoDB.

Let’s look at the example:

use polodb_core::Database;
use serde::{Serialize, Deserialize};

#[derive(Debug, Serialize, Deserialize)]
struct Book {
    title: String,
    author: String,
}

let db = Database::open_file(db_path)?;
let collection = db.collection::<Book>("books");
collection.insert_one(Book {
    title: "The Three-Body Problem".to_string(),
    author: "Liu Cixin".to_string(),
})?;

In the above example, the Book structure is serialized into BSON format and persisted on the disk. Since PoloDB is schema-less, it's not required to create a table for it in SQLite. It's free to insert any form of data.

For example, you can insert a document structure directly:

let typed_collection = db.collection::<Document>("books");

let docs = vec![
    doc! { "title": "1984", "author": "George Orwell" },
    doc! { "title": "Animal Farm", "author": "George Orwell" },
    doc! { "title": "The Great Gatsby", "author": "F. Scott Fitzgerald" },
];

// Insert some documents into the "mydb.books" collection.
typed_collection.insert_many(docs, None)?;

Every row has its own identifier, which is called a primary key in traditional databases. PoloDB uses the _id field of the document as the primary key. If you don't specify one, PoloDB will create one for you.

collection.insert_one(doc! {
    "_id": "Orange",
    "price": 300,
})?;

Remember, primary must be unique in the collection.

Query

Querying in PoloDB is also very straightforward. You can query the collection by the field of the data:

// find all
let result = collection
            .find(doc! {
                "author": "Liu Cixin"
            })?
            .collect::<Result<Vec<Document>>>()?;

// only find the first one
let result = collection.find_one(doc! {
	  "author": "Liu Cixin"
})?;

You can even query the field in the embedded document:

collection.insert_one(doc! {
    "name": "Banana",
    "price": 200,
    "info": {
        "description": "This is a banana",
        "color": "yellow",
    }
})?;

collection.insert_one(doc! {
    "name": "Orange",
    "price": 300,
    "info": {
        "description": "This is an orange",
        "color": "orange",
    }
})?;

// query a fruit with color yellow
let result = collection.find(doc! {
    "info.color": "yellow",
})?.collect::<Result<Vec<Document>>>()?;

If you need more complex queries, you can refer to this documentation.

Update

It’s easy to update one or many rows of data in PoloDB. To update rows, you need to provide the conditions for which rows to update and specify how to update them.

let collection = db.collection::<Document>("config");

collection.update_many(doc! {
    "_id": "Orange"
}, doc! {
    "$set": doc! {
        "price": 500,
    },
})?;

If you want to update only one row in the collection, use the update_one method.

collection.update_one(doc! {
    "_id": "Orange"
}, doc! {
    "$set": doc! {
        "price": 500,
    },
})?;

There are many ways to update a row in MongoDB. In addition to the $set directive, you can use $inc to increase the value of a field:

collection.update_one(doc! {
    "_id": "Orange"
}, doc! {
    "$inc": doc! {
        "price": 1,
    },
})?;

You can find more directives for updating at https://www.polodb.org/docs/curd/update.

Delete

PoloDB provides delete_one and delete_many methods to delete one or many rows in a database. Just provide the correct filter parameter to select the rows you want to delete:

let deleted_result = collection.delete_many(doc!{
    "_id": key,
})?;

The method returns the number of rows that were deleted from the result.

Conclusion

PoloDB is a simple yet powerful database system that is still under development. It needs your input to improve. This article demonstrates its basic functions, but there are also many advanced features such as sessions and transactions. If you are interested, you can read the documentation and give it a try. I believe PoloDB would be helpful for your app.

All codes of this tutorial are uploaded to shadertoy. You can try the shader online: https://www.shadertoy.com/view/7tGfWm Before we start, I want you to have some basic concepts about GLSL. If you do, it may be easier to understand the code. And you can safely skip the code. I’ll make the principle clear.

Draw a wave

The image is composited with multiple waves. Let’s draw a wave in a shader. Let's create a new project in Shadertoy.

The shader we are going to write is called “fragment shader”. It’s a program to evaluate the color of every image pixel. The first parameter fragCoord indicates the coordinates of the pixel to evaluate. Because the coordinates of the pixel depend on the device, we need to normalize the coordinate from 0 to 1 first.

This procedure is done by one line of code:

// Normalized pixel coordinates (from 0 to 1)
vec2 uv = fragCoord/iResolution.xy;

If we want to draw a wave, we should find a function to represent the wave. Of course, we use trigonometric functions. We use sine here.

vec3 sin_shape(in vec2 uv, in float offset_y) {
  float y = sin((uv.x * 3.14 * 2.0));

  float y0 = step(0.0, y - uv.y * 2.0 + offset_y);
  return vec3(y0, y0, y0);
}


void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
    // Normalized pixel coordinates (from 0 to 1)
    vec2 uv = fragCoord/iResolution.xy;

    vec3 col = sin_shape(uv, 1.0);

    // Output to screen
    fragColor = vec4(col,1.0);
}

Add some noise

The waves we drew are dull. We need to make them more fun. So I decided to add some “noise” to it.

vec3 noised_sin_shape(in vec2 uv, in float offset_y) {
  // Time varying pixel color
  float y = sin(uv.x * 3.14 * 4.0 + iTime * -0.6);
  
  float x = uv.x * 8.;
  float a=1.;
 for (int i=0; i<5; i++) {
  x*=0.53562;
  x+=6.56248;
  y+=sin(x)*a;  
  a*=.5;
    }

  float y0 = step(0.0, y - uv.y * 4.0 + offset_y);
  return vec3(y0, y0, y0);
}

void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
    // Normalized pixel coordinates (from 0 to 1)
    vec2 uv = fragCoord/iResolution.xy;

    vec3 col = noised_sin_shape(uv, 1.0);

    // Output to screen
    fragColor = vec4(col,1.0);
}

Composition

In the final image, we got three waves painted in different colors. We should find a way to composite three waves(even more). We can know if a pixel is in the region of a wave by the result of the sine function. Things got complicated when we got three waves. We need to write a lot of if/else statements to determine the colors. And this method doesn’t scale. We need a mathematical way to solve this problem.

Math is an abstract tool of reality. Imagine if you want to draw this picture with brushes and paints. How will you paint?

When we draw an image with brushes and paints, we draw the layers individually. How about using the thickness of the paints to determine the wave?

The value of the grayscale is like to represent “the thickness of the paints”. And we can use the grayscale to determine which color to show.

vec3 sin_shape(in vec2 uv, in float offset_y) {
  // Time varying pixel color
  float y = sin((uv.x + iTime * -0.06 + offset_y) * 5.5);

  float x = uv.x * 8.;
  float a=1.;
 for (int i=0; i<5; i++) {
  x*=0.53562;
  x+=6.56248;
  y+=sin(x)*a;  
  a*=.5;
 }

  float y0 = step(0.0, y * 0.08 - uv.y + offset_y);
  return vec3(y0, y0, y0);
}

vec2 rotate(vec2 coord, float alpha) {
  float cosA = cos(alpha);
  float sinA = sin(alpha);
  return vec2(coord.x * cosA - coord.y * sinA, coord.x * sinA + coord.y * cosA);
}

vec3 scene(in vec2 uv) {
    vec3 col = vec3(0.0, 0.0, 0.0);
    col += sin_shape(uv, 0.3) * 0.2;
    col += sin_shape(uv, 0.7) * 0.2;
    col += sin_shape(uv, 1.1) * 0.2;

    vec3 fragColor;

    if (col.x >= 0.6 ) {
      fragColor = vec3(0.27, 0.11, 0.64);
    } else if (col.x >= 0.4) {
      fragColor = vec3(0.55, 0.19, 0.69);
    } else if (col.x >= 0.2) {
      fragColor = vec3(0.68, 0.23, 0.65);
    } else {
      fragColor = vec3(0.86, 0.57, 0.68);
    }
    return fragColor;
}

void mainImage( out vec4 fragColor, in vec2 fragCoord )
{
    fragCoord = rotate(fragCoord + vec2(0.0, -300.0), 0.5);
    // Normalized pixel coordinates (from 0 to 1)
    vec3 col0 = scene((fragCoord * 2.0)/iResolution.xy);
    vec3 col1 = scene(((fragCoord * 2.0) + vec2(1.0, 0.0))/iResolution.xy);
    vec3 col2 = scene(((fragCoord * 2.0) + vec2(1.0, 1.0))/iResolution.xy);
    vec3 col3 = scene(((fragCoord * 2.0) + vec2(0.0, 1.0))/iResolution.xy);

    // Output to screen
    fragColor = vec4((col0 + col1 + col2 + col2) / 4.0,1.0);
}

Adjust the view

Now, we are very close to the final image. We need to adjust the view and the parameters of the sine function to make it closer.

vec2 rotate(vec2 coord, float alpha) {
  float cosA = cos(alpha);
  float sinA = sin(alpha);
  return vec2(coord.x * cosA - coord.y * sinA, coord.x * sinA + coord.y * cosA);
}

After rotating the camera, it’s very close now. But it looks very dull, and it can’t express the beautiful view of the Monterey. I guess we miss some details. I think it’s the gradient of colors. So I add a filter to it, and it’s better now.

We got the final image of this tutorial probably. But it needs to be better. The curve of the wave is not smooth enough. We have yet to finish a procedure every gamer knows: anti-aliasing.

Anti-aliasing

There are a lot of ways to implement anti-aliasing. We use a straightforward method there: supersampling. There are still a lot of patterns of supersampling. We use the simplest one: mix four pixels into one.

Imagine we draw a 4x bigger size image of the screen. And we mix 4 pixels into one. Then we got a smooth curve.

Animation

If we want to generate the animation of the waves, we can use the time as the parameter of the sine function to make the wave move forward. In shadertoy, the time is passed by a global variable called iTime.

Conclusion

Finally, we use less than 100 lines of code to implement this. There are some math concepts, but it’s pretty easy. But it’s funny and beautiful. There’s still a gap between this toy and the official Apple screen saver because we don’t have a 3D model. Alternatively, we use 2D shapes to implement. It’s simple and fun. That’s the point.

Nowadays, more and more web apps need to provide an extension system for their web app. We need the clients to extend our systems, but we can’t trust the clients’ code. We need to prevent the clients from destroying or hacking the host system. It’s not safe, and we need an isolated environment on the web.
We have some solutions. Some apps run the extensions in the web workers. Some run them in the iframe. Even more, the WebAssembly, or using an interpreter in JS to provide an isolated environment.
They have their advantages and disadvantages. Some of them have terrible performances. Some of them are not entirely isolated. And the most annoying thing is it’s hard to use the same solution on some native apps (mobile).

The new language

I am introducing a new language named LichenScript. “Lichen” represents a thin layer. LichenScript is close to TypeScript. They have similar syntaxes and APIs.

https://www.lichenscript.com/

LichenScript is designed to be portable. We choose simple and stable grammar to make LichenScript easy to compile to C and JavaScript. The compiler is not complex because the relationship between the product and the source code is not complex. The code compiled to C can run on the most popular platforms, including the mobile platforms and WebAssembly(with the power of Emscripten). It’s great to share the code on both Web and Mobile.

LichenScript is statically typed, which is similar to TypeScript. The different thing is types help the code generation. When you compile LichenScript to C, the compiler uses the typing information in the product code to make the program faster. It’s is very difficult for the complex TypeScript to do this because it’s too flexible. Although performance is not the primary goal of LichenScript, we will try to make it as fast as possible.

When you compile LichenScript to JavaScript, the code can not access the js variable except you provide the bridge between them. The type checker ensures that.

Playground link.

You can try the language in the playground. Actually, it’s not hard to integrate the compiler into your app. Here we have a good example.

The syntaxes

The most different syntax between LichenScript and TypeScript is pattern matching. The most different syntax between LichenScript and TypeScript is pattern matching. I am pretty excited to introduce this feature. Because many years ago, I tried to introduce pattern matching to JavaScript. I failed. Today, I introduced it to the language I designed.

It’s a handy feature to solve complex logic. I hope you like it. To know more about this, you can read the documents.

LichenScript uses most of the common language features in JavaScript such as lambda expressions. People can learn it very quickly. Advanced features such as async/await are under development.

LichenScript also borrows some concepts from OCaml and Rust. For example, `if` is an expression in LichenScript. Talk is cheap. How about downloading and trying it? 😉

Interoperability

The module system of LichenScript is quite interesting. You can still use the traditional npm to assemble the modules. Here is a very good example: lichenscript-fs.

In the source code of lichenscript-fs, the module can directly import the source code of JavaScript and C to interoperate with them. It’s quite easy to provide the native API to LichenScript. In the future, the Rust library will be imported too.

We found that the binary’s size is quite small of LichenScript because the runtime is very small. A simple program that reads and writes JSON data uses only 100kb on macOS.

Further

The goal of LichenScript is to be a practical and stable language. We will try to keep it small and simple. Aggressive syntaxes will not be introduced. It’s trying to be an excellent “glue” language.

Conclusion

LichenScript is a new language. It’s still a lot of work to do. And I have a lot of interesting things about this language to share. If you are interested, please join us. Submit issues or PRs.

Discord: https://discord.gg/TJntnVwr

Twitter: https://twitter.com/cdz_solo

Why

Currently, js_of_ocaml is the most popular method to run OCaml in the browser. Js_of_caml have a great ecosystem. But it has its limitations.

Because it emulates OCaml with JavaScript, some implementations are inconsistent with the original ones. In most scenarios, it’s OK. But sometimes, you want consistency. You don’t want the result running in the browser is different from native.

Another disadvantage of js_of_ocaml is that it’s hard for it to interface with C codes. A lot of OCaml modules depend on C codes. Some of them provide JS stubs, some do not, but all provide C stubs. One week ago, I wrote a library in OCaml with some C libraries, and I want to adapt it to the web. I found it’s hard for me to implement. I compiled my code with Emscripten and invoke it from js stubs. It’s hacky. So I imagined running OCaml directly on WASM.

And I found this repo. It’s a great idea. It’s OK for this repo to run a Hello World demo or to run pure OCaml code. But it’s not good enough if you want to link C libraries. You can’t even use popular libraries such as Core_kernel. Also, I found this repo is inactive. So I decided to reinvent the vehicle.

How

I forked the official OCaml and hacked its runtime. I was adding support of libraries such as Unix library, Ctypes, Base, Core_kernel. All of them are embedded in the binary because it’s not easy for Emscripten to build dynamic modules.

My Forked version with a demo.

Why not drop your OCaml bytecode to try?

I draw a picture to demonstrate the differences between js_of_ocaml vs WASM runtime. It’s easy to know the relations between OCaml codes and stubs.

At last, we can get a single WASM file(about 2Mb) and a js glue file(about 200kb). They include a complete OCaml runtime, and they can run a lot of popular OCaml programs. And I can link my C libraries through Ctypes, which are very extensible.

Performance

After I get the WASM file, I wonder about its performance. It’s OCaml running in a virtual machine(OCaml runtime) running in another virtual machine(WebAssembly). Will it be slow? How it performs compared to js_of_caml.

So I use both of them to run the ocamlc(the compiler of OCaml) to compute the dependencies of the standard library.

node ../boot/ocamlc.js -depend *.ml *.mli  1.80s user 0.10s system 145% cpu 1.296 total
node ../runtime/ocamlrun.js ../boot/ocamlc -depend *.ml *mli  1.90s user 0.03s system 112% cpu 1.720 total

Js_of_caml would be a little faster than my WASM version. Well, it would be a little frustrating. I would say js_of_ocaml is still an excellent solution to run OCaml in the browser. Since the gap is not very big, the WASM way is still worth a try. This method can be used on mobile platform such ad iOS and other strict platforms. It’s portable.

I am looking forward to the “native” WASM version of OCaml. And I don’t know if the OCaml team is planning it. Would you please tell me?

Troubles

But there are also some troubles. Using this method, you have to customize a runtime for your application. But it’s not a happy job. It’s complex and annoying. Once you add a library with C stubs, you have to rebuild the runtime again. So I imagine a tool can automatically extract the C stubs from OCaml libraries and embedded them in the runtime. It’s fancy, but I don’t know if it would be too hard to implement. But currently, I can enjoy the runtime to run my application. If you have any ideas, please tell me.

Github: https://github.com/vincentdchan/PoloDB

Lightweight. PoloDB doesn’t have separate processes such as MySQL. It’s just a library can be embedded in your application, just like SQLite. It cost less memory to initialize and run. So it’s suitable for personal devices. The performance of your clients’ devices isn’t usually as good as your powerful servers. It isn’t easy to embed a massive database in your applications. PoloDB is the right choice.

The database file is only a file. You can transfer it anywhere, don’t need to zip it or to dump data. Besides, it’s very easy to backup.

Portable. PoloDB is written in Rust. It can be compiled to run on various platforms. Currently, it supports macOS, Linux and Windows. Further, it will support iOS/Android, even Raspberry Pi(Actually, I am working on it).

It supports various programming languages bindings. Currently, it supports Rust, C/C++, Node.js, Python. Theoretically, every language can use PoloDB; it just needs time to adapt.

Flexible. PoloDB is NoSQL. It acts like MongoDB. It’s very flexible. JSON is the data format PoloDB used. You don’t need to create some schemas before using it. You open the database and insert data to it.

Nowadays, many applications update quickly, functions of applications changes very often. Flexible data structure helps you iterate quickly.

Powerful. Although it’s lightweight, it’s a full-featured database. It supports atomic commits(transactions). Data indexing is under development. In the future, more and more features will be added to PoloDB. For example, data encryption, data backup, JS runtime, etc.

You see, it’s better to store JSON in PoloDB than JSON text files. With PoloDB, you don’t need to read large JSON from disk into memory and parse data. PoloDB read data when you need it because the database has a particular structure; it knows how and when to store and read.

Open Source. PoloDB is a personal project currently. I use off work time to complete it. All the codes are published on Github under MIT licenses. You can copy and learn all the details of PoloDB. It’s an incredible project, but it has no secrets. Also, you can customize PoloDB for your circumstance; it benefits performance.

The development of PoloDB is at a very early stage. But it can work now; you can try it yourself by following instructions. PoloDB is easy to use, but it’s not simple to implement. It still has a lot of works to do, such as writing documents to explain it, writing strict tests, adapt it to more platforms. My time is limited; merge requests are welcome to submit.

Most importantly, I hope you can use it and give me feedback so that I can improve it. Hence, you can use better PoloDB.

Introduction

Tree-shaking, a supporting feature for DCE(dead code elimination) to help DCE on cross-module usage, is a crucial feature for a bundler. It's especially true for JS. Reducing the bundle size means reducing the network cost each time a bundle is delivered for web application.

Project on Github

中文版

Without this plugin

Before the implementation of this plugin, webpack uses a very simple solution for DCE. For example:

In the above example, webpack finds the references of the imported variables. Obviously, isNumber is completely not referenced in the module. As a result it can be eliminated in the final bundle if it’s never used in other modules.

The above example is very silly because you won’t import something you don’t need unless you forget to remove them. However, the modern editor and lint tools will remind you to remove unused imports. Thus we need a more powerful solution.

Motivation

Unexpected code after tree-shake · Issue #6264 · webpack/webpack

The above issue illustrates that Webpack tree shaking mechanism still has some room for improvement. We can find out the relationships between the exported variables and imported variables among modules.

If an exported variable is not imported by another module, it will be eliminated along with its “children”(Other variables that are only referenced by it).

Function2 is not imported by the entry, function2 and the entire external2 can be eliminated. Unfortunately, webpack’s previous mechanism couldn’t catch such case until the introduction of this new plugin.

Feasibility

Think about the role of webpack: it traverses the graph of all modules from entry and bundles them together. At the same time, webpack knows which exports are used. How about traversing all the scopes and bundle the scopes together? That’s the way it can eliminate unused scopes and module. In fact, we can regard scope as a node in the graph.

In the above code, deepEqual is related to fun5, equal is related to fun6. If fun6 is not imported by another module, the imported function equal would be eliminated.

What is a scope?

In computer programming, the scope of a name binding — an association of a name to an entity, such as a variable — is the region of a computer program where the binding is valid: where the name can be used to refer to the entity. Such a region is referred to as a scope block. In other parts of the program the name may refer to a different entity (it may have a different binding), or to nothing at all (it may be unbound). — Wikipedia

Where you can feel scope when you are coding is something like block in the code. But it’s not quite equivalent. Here are types of scopes in ECMAScript:

For a ES6 module, module scope is regarded as a root scope. Within the module, only scopes of class and function can be exported, they are children of module scope. So not all the scopes would be regarded as a node in the graph.

How this plugin works

This plugin contains a scope analyzer, which can extract all the scopes from modules. The output of the analyzer would then be used to find out the references of variables in the module.

Some of scopes could be bound to variables, such as class and function. These scopes that are exported is the atom for traversing.

When webpack gives inputs about which exports are used, this plugin returns which imports could be eliminated.

Implementation Details

If I have seen further it is only by standing on the shoulders of giants. — Isaac Newton

We need a scope analysis to find the references between variables. An existing tool like https://github.com/estools/escope could help.

This scope analysis is based on the ASTs. The plugin hooks the webpack to acquire ASTs of modules, and analyzes them.

Then, the analyzer finds out all the scopes belong to module scope(the root scope), with the referencing data of the imports. If we can know which scopes is used by other modules, the analyzer can traverse all child scopes and tag all the variables from other modules. The imports which have no tag can be regarded as unused.

Edge cases

To improve is to change; to be perfect is to change often. — Churchill

There are many edge cases for JavaScript analysis, some of them are listed below:

Here’s a simple demo to try:

https://vincentdchan.github.io/webpack-deep-scope-demo/

Local References by Module Scope

If a scope or an imported variable is referenced in module scope, it wouldn’t be eliminated.

Re-assign function to a variable 👎

Because of the lack of data-flow analysis, any operation about writing a variable(such as re-assigning) would make the analysis skip this variable. Therefore, isNull will not be eliminated in the above example.

If a function expression is assigned once when the variable is declared, the function would be regarded as an independent scope, the analysis will work.

Pure function call 👍

If an anonymous function is wrapped in a function call, the analyzer will not regard it as a independent scope because the function call could have side effects. But if the function call is tagged as pure, the analyzer can regard it as a scope like structure. Therefore, if allPass is not used, all the variables would be eliminated.

Practical Advice

There several practical advices for this plugin:

ES6 module is required

Actually, the analysis is based on the ES6 module, which is known as import/export syntaxes. It can’t work on other module system such as CommonJS/AMD… Hence, the project is required to use ES6 module. For example, use lodash-es instead of lodash. Otherwise, focus on the configuration for babel-loader, TypeScript, etc. Prevent them to transpile your code into ES5 style, which can lead to failure of analysis.

Use PURE annotation for pure function call

This plugin can’t infer whether a function contains side effects. So /*@__PURE__*/ annotation is required for some export function call, which is first introduced by Uglify. Of cause you can use some babel plugins to add them automatically. And please notice that don’t let another compiler such as babel or ts-loader to erase the comments.

Summary

With this plugin, webpack does better tree-shaking. It helps eliminate dead code and shrink the size of bundle. On the other side, it requires the programmers to write clean and appropriate code because even the best compiler can not optimize the worst code. Now we have a better webpack, do you have some awesome code to be compiled? Please submit before and after usage stories so we can better understand how effective this is on your project/framework!

Better tree shaking with deep scope analysis was originally published in webpack on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the first part of my stories with GSoC 2018. I will share my personal experiences and all the things happened with GSoC 2018 in the series.

About Me

I am from China, Guangzhou. I major in Computer Science and I am serving my 3rd year at South China Agricultural University. This year before Google Summer of Code (GSoC), I served my internship in a Chinese Company named Bytedance. My job is front-end development. I am really interested in the technologies behind front-end development. During the internship, I was required to use Redux + React for developing new features. I learned a lot from these.

Programmers always have a passion for discovery. That’s what I will do. Before I served my internship, I learned a lot about compilers myself. In my point of view, a compiler is like a precise machine. It helps programer to create other machines(compiling programs). I have written some toy interpreters myself such as halang. It has many bugs, no tests, and it's a poor project. But I learned how a parser compiler works in this project.

After some silly projects like halang. I realized that implementing a compiler from zero is very hard. It was at this point that I wanted to work on some complete compiler, and add some features on it.

That time I chose babel. Last year, I submitted a PR about implementing the new feature of TC-39 stage-0 proposal: pattern matching. Since the champion in charge of this proposal of TC-39 has changed, there are updates that now need to be made to it. Here is the PR and I continue to work on it as the spec is defined.

Story With Webpack

As you know, webpack is also a project armed with compiler technologies. It was very exciting for me to see webpack on the GSoC 2018 organizations list this year.

Before GSoC started, I tweeted to Sean (one of the owners of webpack) to ask if webpack can offer some projects about AST analysis (as this was what I wanted to focus on). Sean replied immediately and give me a suggestion about deep scope analysis. It’s about implementing new tree-shaking features that are more intuitive and automatic. I think it’s very cool and will be an exciting challenge for me.

Tobias Koppers has ownership over this feature in webpack, and he is my mentor in GSoC 2018 now. I often talked to Tobias about details of webpack and implementations of new feature, and he’s very nice to work with.

It’s my pleasure that webpack selected me, and I am looking forward to what’s in store next in my GSoC 2018 journey.

Work To Do

GSoC provides a timeline officially on the homepage. But I will have my own timeline with my mentor. Here’s my Github repo contains the jobs I have done:

https://github.com/vincentdchan/webpack-deep-scope-analysis-plugin

And here’s what I will do during the GSoC:

• Improve escope to analyze the scopes of code
• Add tests infrastructure for testing
• Extract module dependencies from plugin
• Do tree shaking with the plugin

If I really finish this, webpack will support tree-shaking in the new version. This has the potential to have profound impacts in front-end performance by removing even more dead code from bundles that are created. It’s unbelievable that I could have the potential to make such an impact on the front-end community at this scale. Thank you GSoC and Thank you webpack.

Last but not least

I believe that I will finish the job at the end with happiness. Let’s enjoy it!

My story with GSoC 2018: Beginning was originally published in webpack on Medium, where people are continuing the conversation by highlighting and responding to this story.