Marco Alka There's a few things, you're mistaking. I'll try my best to pint those out -> JS by itself is not slow :) JS is slow because it's a higher level lang with GC. The GC pauses hinder JS's execution speed. The sole reason JS is as fast as WASM in peak execution speed is because of JS's JIT support. Compiling to WASM allows writing very fast code and usually WASM files are way faster than similar JS code I am assuming that by allows writing very fast code you mean allows executing code very fast . But this is another misinformation. WASM files are executed by the same engine that executes JS JIT code.... thus their peak performance is the same. The reason why I'm saying peak performance is that JS being a higher level language has to stop code execution for GC cycles, which hinders JS's (JIT) overall perf. WASM files are way faster than similar JS code It depends. As I already have said, both JS and WASM have the same peak performance. But if you were to compile another higher level language to WASM, take for example Python, then it would execute code at a slower speed than JS. So it depends what you compile to WASM. Just plainly compiling anything to WASM won't increase its execution speed. (Btw... you can't compile Python into WASM yet as WASM still doesn't have a GC yet. There's currently a proposal for the GC but it won't support any lang fully. Only partial implementation of a few given languages will be supported by that GC. It's possible to compile and bring the whole Python GC but.... that will increase bundle size a LOT and you're still getting slower execution speed.) WASM files are quickly parsable as they can be parsed while they are being steamed in through the network thanks to WebAssembly.instantiateStreaming . This is a HUGE advantage over JS, as JS files has to download fully and parsed before they can be executed. It also takes some time before the JS JIT kicks in. Do you mean this by saying, WASM files are way faster than similar JS code ? Anyawy.... glad to see a fellow Rustacean on the web. Cheers!

Sanchit Also.... since we are talking about best practices use ES6 features like const , let and template literals .

Here bad code have to access the length property of array each time until the loop is iterated. This was performance bottleneck with very old browsers. All modern browsers no longer have any prob with such loops now a days. Here's the results that be seen on Chromium 84. By doing this optimizations you are only getting a performance benefit of a fraction of a single millisecond . That is unnecessary. Lastly.... if performance is your main concern, then you're better of using lower level langs or WebAssembly. Unnecessary JS optimization isn't a good practice. You should prefer readability over performance unless you really need that performance. This is what Google Dev Advocates had to say about this topic -> https://www.youtube.com/watch?v=eKuHlSZKlWM

Nice! Well done. I think it's safe to say you guys do hear and care about the community. Keep this up and Hashnode will grow tremendously. (Btw.... Looks like your E-mails still use your old logo rather than the re-branded Hashnode logo)

Tim Apple How far have you gone through the book? I am currently somewhere around page 150.

If you have an anchor tag that uses a SVG as a logo, the you'll have to use aria-label to help improve a11y.

I'd recommend FreeCodeCamp above all the resources if you're just starting out. https://www.freecodecamp.org/

It allows writing very fast code Marco Alka This is a common misinformation. At the current state of WASM, without SIMD and threading support, WASM runs as fast as JS in peak performance. Which means a JS code and it's equivalent WASM code will execute at the same peak performance. You may want to watch this explanation to understand why -> https://youtu.be/njt-Qzw0mVY?t=1044 (WASM will eventually get more performance advantage when support for SIMD and Threading lands... but for now, the execution speed is a tie between JS and WASM)

Have you learned Rust? If so, I'd love to have a chat with you.

I'd love to see this feature implemented.