WebAssembly (WASM) vs. JavaScript: Performance & Real-World Applications

Performance Comparison

1. Execution SpeedWebAssembly (WASM) is a binary format compiled from languages like C, C++, Rust, and Go, making it significantly faster than JavaScript for computationally intensive tasks.WASM executes at near-native speed, utilizing low-level optimizations and ahead-of-time (AOT) compilation.JavaScript, on the other hand, is interpreted and Just-In-Time (JIT) compiled, leading to runtime overhead.
2. Memory & CPU UsageWASM has efficient memory management and can handle complex operations with less CPU overhead.JavaScript relies on garbage collection, which can introduce performance bottlenecks in certain applications.
3. Parallelism & MultithreadingWASM supports Web Workers and SIMD (Single Instruction Multiple Data) for parallel execution.JavaScript has asynchronous execution but lacks direct multithreading support in a way comparable to WASM.
4. Startup TimeWASM has a faster startup time since it is precompiled and optimized before execution.JavaScript requires parsing and JIT compilation before execution, adding startup latency.

Real-World Applications

1. High-Performance Web AppsGame Engines: Unity and Unreal Engine export to WebAssembly for smooth browser-based gaming.3D Rendering & Graphics: Applications like AutoCAD Web, Figma, and Google Earth leverage WASM for real-time rendering.
2. Scientific Computing & Data ProcessingMachine Learning & AI: TensorFlow.js and ONNX leverage WASM for optimized model inference in the browser.Data Visualization & Analytics: Libraries like Pyodide (Python in the browser) use WASM for high-speed computations.
3. Cryptography & SecurityWASM is used in blockchain applications, cryptographic libraries, and password hashing (e.g., Argon2, BLAKE3) to improve security and performance.
4. Embedded Systems & IoTWASM is portable, making it useful for running logic on low-power devices, drones, and industrial automation.
5. Server-Side & Cloud ComputingWASM is emerging in serverless computing (e.g., Cloudflare Workers, Fastly Compute@Edge) as a lightweight alternative to containers.

When to Use WASM Over JavaScript?

Conclusion

• JavaScript is still the dominant language for general web development, especially for UI interactions.
• WebAssembly is ideal for performance-critical tasks, enabling native-like performance in the browser and even on the server.
• Many applications combine both, using JavaScript for UI logic and WASM for high-performance computations.

So much faster…as in, starting at almost 20% faster?

OMG, you won’t be able to believe this! If I use WebAssembly, I might be able to see a response in 8ms rather than 10ms!

And something important to note is that much of the time spent waiting for a web page has nothing to do with JavaScript speed. There's server latency, poor page design with respect to minimizing network requests, and DOM rendering time. JavaScript is rarely the bottleneck. So to update the above example, it might be that a page renders in 899ms instead of 900ms. At the cost of a lot of work porting the code to C++, which could be better spent actually optimizing the page where it will actually help.

There are some use cases where WebAssembly can be way faster. It will be useful for games, which are often already written in C++ anyway. But for the most part, WebAssembly just means “you can compile C++ for use in a web page.”

And do you know what? I’ve developed GUIs (Graphical User Interfaces, i.e., like what web pages are) in C++, and developing GUIs in C++ sucks. Not that HTML+CSS+JavaScript is perfect, but it’s a lot better. And a lot more flexible. And a lot easier to debug. And a lot more component-driven. And the ecosystem is literally the largest that has ever existed for any language in history.

Other people have mentioned that you can’t yet manipulate DOM from WebAssembly, but several stacks already exist that handle that bridge. And there are over a hundred languages that compile to JavaScript, so if JavaScript were such a terrible language, wouldn't we be seeing the rise of one with solid modern engineering principles? Oh yeah, we are: TypeScript.

And as I mentioned above, most web sites are slow not because of JavaScript. So even if you could manipulate the DOM from WebAssembly directly, and you ported the code to C++, you would be hard pressed to even notice the speed difference. Aside from DOM and network issues, probably the next most common problem is the algorithm being used. Making your code 10x faster by converting from JavaScript to C++ is good, but making it 100x faster just by changing the algorithm in JavaScript a bit is a lot less work for a much better result.

So the real reason why we’re still using JavaScript and compile-to-JavaScript languages like TypeScript? It’s easier, it’s more powerful, it’s fast enough, and the ecosystem is unparalleled. Except for games and specialized libraries, I don’t see WebAssembly making a dent in the foreseeable future.

Hey there! 👋

WebAssembly (often shortened to Wasm) is an exciting technology that allows developers to run compiled code, like C, C++, or Rust, in the browser, alongside JavaScript. It's particularly useful for performance-critical parts of a web application. But like any tool, WebAssembly comes with its own set of challenges. Let’s dive into some potential pitfalls and its impact on the future of JavaScript frameworks.

Potential Pitfalls of Using WebAssembly:

1. Interoperability with JavaScript:

• The challenge: While WebAssembly can run alongside JavaScript, communicating between the two can be tricky and costly performance-wise. Every time data needs to be passed back and forth between WebAssembly and JavaScript, there is a non-trivial overhead. This can diminish the performance gains, especially in scenarios where lots of back-and-forth communication is required.
• Solution: It's best to minimize interactions between Wasm and JavaScript. For tasks like number crunching or algorithms that need minimal interaction, WebAssembly shines. However, for anything that needs frequent interaction with the DOM or the browser, JavaScript is still more efficient.

2. Limited Access to Browser APIs:

• The challenge: WebAssembly itself doesn’t have direct access to many browser APIs (e.g., the DOM, Fetch API, etc.). You still need to use JavaScript as a "bridge" to interact with these. This makes WebAssembly less useful for UI-heavy tasks.
• Solution: Currently, WebAssembly is ideal for offloading computational-heavy tasks like image processing, video encoding, or physics simulations, but leave UI and DOM manipulation to JavaScript.

3. Larger File Sizes:

• The challenge: WebAssembly binaries are generally smaller than their JavaScript equivalents, but if you’re using heavy libraries (like C++ libraries) or pulling in a lot of dependencies, the Wasm files can get quite large. This can lead to slower page load times, which defeats the purpose of optimizing for performance.
• Solution: Make sure to optimize and reduce dependencies wherever possible. Use tree-shaking and other optimization techniques to reduce the size of the WebAssembly file.

4. Debugging Complexity:

• The challenge: Debugging JavaScript is relatively straightforward with built-in browser dev tools, but debugging WebAssembly is much harder. Since Wasm is a low-level binary format, finding and fixing issues can become a real challenge, especially for developers unfamiliar with lower-level languages.
• Solution: As of now, tools for debugging Wasm are improving, but there’s still a steeper learning curve compared to debugging JavaScript.

5. Tooling and Ecosystem Maturity:

• The challenge: While WebAssembly is promising, its ecosystem is still evolving. Compared to JavaScript, the Wasm community is smaller, and the tooling isn’t as mature. This could slow down development if you run into bugs or need support.
• Solution: Keep an eye on the growth of the Wasm ecosystem. In time, it will become more robust, and using it will become easier.

How Might This Affect the Future of JavaScript Frameworks?

Now, what does this mean for the future of JavaScript frameworks?

1. Complementary, Not Replacement:

• WebAssembly is not a replacement for JavaScript. Instead, it’s a complementary technology. JavaScript frameworks (like React, Vue, or Angular) will continue to handle user interfaces, DOM manipulation, and browser interactions because these tasks are still JavaScript's strong points.
• Where WebAssembly comes in is for performance-critical tasks like game engines, simulations, or processing-heavy tasks. So, instead of WebAssembly replacing JavaScript frameworks, it’ll work alongside them to improve performance.

2. Frameworks Supporting WebAssembly:

• Future JavaScript frameworks may evolve to have better integration with WebAssembly. We might see frameworks that let you easily offload parts of your app to WebAssembly for better performance, like handling large datasets, image processing, or other CPU-intensive tasks.

3. Blurring the Lines Between Web and Native:

• As WebAssembly matures, the lines between web and native applications will blur. We might see more hybrid applications that use WebAssembly to achieve near-native performance in the browser. This could push JavaScript frameworks to adopt WebAssembly-driven components for performance-sensitive parts of the application.

4. New WebAssembly-First Frameworks:

• It’s possible we’ll see new frameworks that prioritize WebAssembly, with JavaScript playing a secondary role. This could be especially true for industries that require high performance, such as gaming, video editing, or data visualization.

WebAssembly is an incredibly powerful tool, but it’s not without its challenges. Right now, it's best suited for performance-critical tasks that don’t need heavy interaction with the browser’s DOM.

As for the future of JavaScript frameworks, we can expect frameworks to integrate more seamlessly with WebAssembly for performance gains, but JavaScript will continue to dominate the web for UI/UX and interactions.

Happy coding!

WebAssembly is not meant to be written by humans; it’s a low-level language, at a similar abstraction level like x86 assembly, or JVM bytecode.

Normally you use another language that you compile to WebAssembly - the two most popular choices being C++ and Rust.

Ignoring some technical limitations (e.g. like WASM not having access to the DOM), the performance gain for simple forms validation and AJAX requests and stuff, the things one normally uses JS for, will be minimal (let’s say, for example, JS is a thousand times slower than C++; the C++ program takes 0.001 ms, the JavaScript program takes 1 ms, and the network request and response take 150 ms, which will be the same for both - so the fast program will take 150.001 ms, while the slow one will take 151 ms - big deal, those numbers are essentially the same).

The benefit from WASM is when you want something like a custom video codec, a physics engine, a local AI, etc., in the browser. Another benefit is potentially making the life of some compiler writers easier (since they won’t have to write *-to-JS compilers anymore, but instead can target the simpler WASM language).

WebAssembly (WASM) and JavaScript serve complementary roles in modern web development, with distinct performance characteristics and applications.

Performance comparison:

• WebAssembly executes significantly faster than JavaScript, often approaching native code speed
• WASM provides predictable performance with consistent execution times
• JavaScript benefits from modern browser optimizations but still faces inherent limitations as an interpreted language

Real-world applications:

• WASM excels at: CPU-intensive tasks (3D rendering, video editing, scientific simulations), porting existing C/C++/Rust applications to the web, gaming engines, and cryptography
• JavaScript remains better for: DOM manipulation, typical web interactions, rapid development, and situations where peak performance isn't critical

Most sophisticated web applications now use both technologies together—JavaScript for UI and general functionality with WebAssembly handling performance-critical components. This hybrid approach leverages the strengths of both: JavaScript's flexibility and ease of development with WASM's near-native performance for computationally demanding tasks.

Do you mean WASM to JS or JS to WASM?

The first is… kind of pointless. The whole idea of WASM is a compact “bytecode” format for the web, compiling it to JS will bloat it (that’s how AsmJS worked, and the bloat is exactly the issue that WASM was made to solve).

The second… I’m not sure what kind of performance you’d get. Normally when browsers run JS, they use both AOT (Ahead-of-Time) and JIT (Just-in-Time) compilation - while if you want to compile to WASM, this means only AOT, you lose the JIT - and that’s actually where most of the optimization happens. I think the browser would prefer it to be able to see the high-level code, I’m not sure it would like it if you only fed it WASM.

C++ is a different story, this language is made to be used with AOT compilation. But JS is not like that.

Not yet, maybe not ever. JavaScript here to stay regardless of what some people want to believe. Webassembly is cool because it lets you compile code from lower level languages into native browser code, but it's usually seen as a feature for existing languages. You don't typically write webassembly code per se.

You might want to look into assembly script, it looks just like JavaScript but with more specific types such as i32 instead of number.

Based off of the trends, a little bit of gut instinct, and my current understanding of the industry - I wouldn't consider webassembly to be a JavaScript alternative, it's more of an alternative for specific edge cases at the moment.

Well, hmmm… there’s this:

extern "C" 
{ 
#include <stdio.h> 
#define WASM_EXPORT __attribute__((visibility("default"))) 
 
WASM_EXPORT 
int main(){ 
    printf("Hello world!\n"); 
    return 0; 
} 

(details vary, since every version of every compiler wants to see different preprocessor directives) followed by:

emcc main.cpp -O3 -o main.js -s EXPORTED_FUNCTIONS='["_main"]' SIDE_MODULE=1 

(For documentation on the preprocessor directives and command line options available to you, just file an issue in the compiler’s Github repository desperately pleading for help.)

Then there’s this:

console.log(‘This is so easy in JavaScript!”);

Slow for the CPU, but that C programmer is now outside enjoying a cigarette.

Although it’s a misdesigned, weakly-typed POS, there are a bunch of things that make JavaScript easy to work with. First of all JS code is easy to cut and paste. There is not as much copypasta available with a compiled runtime targeted by a dozen source languages. Libraries implemented in WebAssembly appear as opaque objects in JS. I recently used a JS library implemented in WebAssembly; it was written in C++ (by original authors obviously extremely uninterested in anything to do with JavaScript). It has a single method taking a Float32Array and returning a Float32Array. I have no idea WTF my thread is doing when it goes in there, but I also know that I’d have to wait years for a JS version to be released. WebAssembly is excellent for porting existing codebases into browser environments, where the original programmers had no idea their code would ever be running in a browser. But that means that as a JS programmer you’ll now be presented with APIs that weren’t exactly designed with you in mind. That’s life.

As much as we hate JS, there are ways WebAssembly might darken the future. There is no way to “View Source” in the browser, so you can expect all malware to be distributed as WebAssembly in the coming years. (This might actually compel people to turn it off in their browsers for security, which would really stick a dagger in it.) Companies wanting to write new, closed source projects have a powerful motive to start them in WebAssembly. You can even hire TypeScript developers off the street, have them write their stuff in AssemblyScript instead.

WebAssembly is faster but the speedup is extremely dependent on what you’re doing. JavaScript under V8 is actually pretty fast and will compile hotspots to machine code (although the code is still needlessly doing type checking because it’s still immersed in JS-world). I looked into WebAssembly’s usefulness for speeding up hotspots (see demo), and while there is some improvement, it isn’t consistent at all. I get different numbers for every combination of OS, browser, and WebAssembly compiler, which indicates that the tech is still quite new.

One of the biggest performance benefits of WebAssembly comes in larger projects- the code is compiled to a machine-friendly format once, by you. This current code delivery technique where we send out a megabyte of transpiler-generated ES5 dog food to be compiled to a machine-friendly format by V8 engines on a million cellphones has to stop. Webpack and Babel must be responsible for millions of tons of CO2 at this point.

The WebAssembly.RuntimeError() constructor creates a new WebAssembly RuntimeError object — the type that is thrown whenever WebAssembly specifies a trap.

Syntax

new WebAssembly.RuntimeError(message, fileName, lineNumber) 

Parameters

message Optional

Human-readable description of the error.

fileName Optional

The name of the file containing the code that caused the exception.

lineNumber Optional

The line number of the code that caused the exception.

Properties

The RuntimeError constructor contains no unique properties of its own, however, it does inherit some properties through the prototype chain.

WebAssembly.RuntimeError.prototype.constructor

Specifies the function that created an instance's prototype.

WebAssembly.RuntimeError.prototype.message

Error message. Although ECMA-262 specifies that URIError should provide its own message property, in SpiderMonkey, it inherits Error.prototype.message.

WebAssembly.RuntimeError.prototype.name

Error name. Inherited from Error.

WebAssembly.RuntimeError.prototype.fileName

Path to file that raised this error. Inherited from Error.

WebAssembly.RuntimeError.prototype.lineNumber

Line number in file that raised this error. Inherited from Error.

WebAssembly.RuntimeError.prototype.columnNumber

Column number in line that raised this error. Inherited from Error.

WebAssembly.RuntimeError.prototype.stack

Stack trace. Inherited from Error.

Methods

The RuntimeError constructor contains no methods of its own, however, it does inherit some methods through the prototype chain.

WebAssembly.RuntimeError.prototype.toSource()

Returns code that could eval to the same error. Inherited from Error.

WebAssembly.RuntimeError.prototype.toString()

Returns a string representing the specified Error object.. Inherited from Error.

Examples

The following snippet creates a new RuntimeError instance, and logs its details to the console:

try { 
  throw new WebAssembly.RuntimeError('Hello', 'someFile', 10); 
} catch (e) { 
  console.log(e instanceof RuntimeError); // true 
  console.log(e.message);                 // "Hello" 
  console.log(e.name);                    // "RuntimeError" 
  console.log(e.fileName);                // "someFile" 
  console.log(e.lineNumber);              // 10 
  console.log(e.columnNumber);            // 0 
  console.log(e.stack);                   // returns the location where the code was run 
} 

No. I think wasm programs within web browsers will not offer the same level of performance as native C/C++.

But wasm has/will have the same level or higher(?) performance as/than C# or Java (which is not JavaScript).

The main reason why wasm will not have the same performance as native C/C++ binary is a sandbox of the browser to protect your computer from malicious behaviors of the web application. To protect for security, the wasm program can’t run as fast as native C/C++.

First, though a wasm code is a byte code or a bitcode near a native binary code in the style, the time it run actually, it will be run via browser in the sandbox checking overrun out of memory block range/stack range, downloading files from other domains or copying from/pasting to a local clipboard in native OS, etc… .

Second, a native binary program will run being checked via cpu level protection such as IA32 #GP GPE —- general protection exception —-, but a Wasm program will run being checked via browser software level protection. The latter type mechanism is slower than the former.

Third, a native binary program can directly call/invoke OS API like Win32 API in the Windows OS, but a Wasm program basically must call/invoke browser service functions or JavaScript functions as canvas drawing functions which indirectly call/invoke OS APIs, which will lead some overheads to make performance/running speed lower.

On the other hand, the reason why wasm will have higher performance than C# or Java is that C# or Java uses GC(garbage collection) and wasm code which is built from C/C++ sources does not.

In the following, I want to explain pros of WASM.

Wasm need not be installed in a local machine explicitly to be used, run or played, so that end users are ease at using the various applications or playing games .

And it will perhaps realize “write once, run anywhere”, because it does not need some narrow special OSes but only needs a web browser obeying open HTML5 specifications .

I suggest that you should make a native binary version and a wasm version at the same time from the same C++ source. And end users at offices or homes near their own desktop computers should use a native binary version application for experiencing the most powerful performance/speed and should use a wasm version application in the travelling situation or outside offices or homes. For example, business persons can use wasm version applications in the any browser on any OS which will happen to be placed/found at a hotel lobby or any office which they does not belong to.

Try it actually in your browser and feel impressions yourself.

Here is a test widgets run under wasm VM programmed by me :

http://nowsmartsoft.atwebpages.com/

It is, but not by itself, and not yet. When? Good question.

A caveat to what follows, but WebAssembly (WASM) is here, today. Browser support is here, but if you want to use a program compiled to WASM as implementation of parts of the client-side code, then the Javascript API for WASM is how you load and bootstrap those WASM binaries.

WASM supplements Javascript, but doesn’t replace it. WASM, as it relates to Javascript, is an alternate virtual-machine that is also widely supported. WASM vs Javascript is better optimized for the arithmetic operations involved in stream transforms (video, audio, etc.), tensor networks, and complex decision trees.

But you suggest that it could be a replacement for Javascript. Consider what you need. The following two questions represent the opposing needs satisfied by answers to many instances of the general question, “What does WASM look like as a replacement for Javascript?”. Again, generally, the ends of that continuum are represented as follows:

1. How much of Javascript do you need to replace? Javascript has a well-defined Document Object Model to interact with structural elements given as HTML, style elements given as CSS, or to hook an independent framework like Angular or Vue into.
2. How little of Javascript do you need to replace? HTML+CSS as a render target is meant to allow browser rendering engines to optimize the image processing based on a fixed API, but the above frameworks, special-purpose libraries like React, jQuery, lowdash, and many, too many more have this in common: they subvert that API or else wrap it with an entirely different API.

The WebAssembly System Interface (WASI), and implementations like Fastly’s edge-compute-oriented implementation, “Lucet”, and DiesLabs’ “WebAssembly Gateway Interface”, show that the larger community has found satisfactory answers for how many instances of the “WASM replaces JS?” question. There are many examples of where that works well, now. There are also many counterexamples.

Back to the core question: Is WebAssembly a viable JavaScript alternative? Back to the answer: It is, but not by itself, and not yet.

For a Javascript dev to “use web assembly”, they are most likely either picking up a language like Rust or Zig or Nim. It could also mean using a library that uses programs compiled to WASM binaries to accelerate common tasks, thus being faster than any implementation you might write in Javascript.

Down the road, WASM+WASI might be one of the most meaningful developments for software since the iPhone proved “the market” wanted pocket-sized computers. Even if you already use Docker as a VM, it’s not so much “goodnight, Docker,” as it is “finally, a docker that can ….”.

Psst. You’re on. You finish the sentence.

WebAssembly can be faster than JavaScript because it’s the result of ahead-of-time compilation of some high-level programming language, such as C++ or Rust. JavaScript, on the other hand, is parsed, compiled, and optimized at runtime. All these operations have overhead, which is avoided with WebAssembly. Also, languages that are compiled into WebAssembly use static types to indicate exactly which code should be generated for specific operations. JavaScript, on the other hand, is dynamically typed, which means that the types of variables in expressions must be inferred at runtime as well. Until types are properly inferred, the JavaScript Engines cannot really optimize the code. All this means that the implementation of computationally intensive operations, such as image and video processing, or encryption, that have been compiled to WebAssembly will generally execute faster than equivalent implementations done in JavaScript.

But how much of your current JavaScript code is an implementation of computationally intensive operations, such as image and video processing, or encryption?

I assume that most of your current JavaScript code deals with responding to user interactions, and updating the browser DOM in response, either directly or using some framework. In such scenarios, it’s the DOM itself which constitutes much of the performance overhead. Moreover, at present WebAssembly cannot even access the DOM directly. Instead it must use a JavaScript bridge for such operations. You will find that the cost of marshaling data between WebAssembly and JavaScript in such cases often outweighs any of the benefits that are obtained from the advantages of WebAssembly, which I’ve listed above.

It depends on what you’re hoping to achieve, but broadly, yes. The entire point of WA is to provide a low-level bytecode that more closely connects the code you are writing to the 1’s and 0’s being run. This provides more predictable behavior, better (but more difficult) memory management, and multiple threads.

That said, the code is still running within a VM. JavaScript is already turned into bytecode by the optimizing compilers in today’s browsers. It’s just that the compile step is opaque to you. You will never achieve the performance of C when not compiling C completely. The question of course becomes whether that performance is even important.

Which is, of course, the great question surrounding WA. JavaScript is more than fast enough to achieve most ends. This means there isn’t a performance motivation to move over to WA, regardless of how close it gets to native C.

No, but it will get within a reasonable margin.

The question is a bit confusing, I will assume you mean code compiled to web assembly vs C/C++ code compiled to machine language.

Consider this questionable code in C:

void vulnerable_function(char* string) { 
    char buffer[100]; 
    strcpy(buffer, string); 
} 

What happens if I pass a string to this function that is longer than 100 characters? Well, in C this is called undefined behavior, and C compilers are allowed to do whatever they want. For performance reasons, they just don’t check anything and simply write over whatever happens to be in memory after the buffer array. In a typical CPU, what is after the buffer is the address of the instruction that called this function. When the function ends, the CPU will simply load that address and jump back to it. A malicious user can carefully override that address and make the function return to wherever he wants, and exploit that to execute anything.

If you know you will always call this function with small strings, then the code that a compiler generates would be perfectly fine, and it would be right not to have the checks. C and C++ simply assume it is your responsibility to ensure you are not asking it to do nonsense.

This is not acceptable in web assembly. You are running someone else's code, and their code must not be able to execute whatever it wants, only what you ( or your browser) allow. The assumption is that the developer will try to take over your computer.

So web assembly must check, and halt execution when such conditions happen. When web assembly is translated to machine code it must include additional instructions to validate memory usage. There can be no undefined behavior in web assembly at all, no trickery or invalid code should be able to escape your browser’s constraints.

This means WebAssembly can never get rid of the extra overhead required for security, so it can never match native code.

That said, the security overhead is not that big. WebAssembly can be JIT compiled to reasonably efficient code, so it gets close to what a native compiler would produce.

Well, yes, on it’s own it is, but there exists bottlenecks between the two, and you’re almost certain to need some traditional javascript to access the dom, for example, so there’s a threshold below which it would actually be slower, so managing a few hundred to a few thousand objects would be faster with well written javascript, but when you get to five figure numbers, then the javascript engine will hit limits that the webassembly code will handle more swiftly, but you still have to keep data transfer between the two apis to a minimum.

Also, it’s not the only way to get better speed out of your web app, there exists others:

1. Using web workers to take the load off the main thread.
2. Using webGL for super fast gfx rendering. OR
3. Offloading certain massively parallel processes to the GPU, using GLSL

If you want to know more I highly recommend Tom Lagier’s series of tutorials where he builds a memory visualisation tool, and he uses all of the above approaches, in one form or another, in one application! With some benchmarks and performance analysis. Well worth a read: Intuition Engineering and the Chrome Heap Profile (https://hackernoon.com/a-tale-of-javascript-performance-61c282f89f2a)