Sitemap

Why use JavaScript for web and then hate it for performance? (My opinion)

2 min readApr 26, 2025

--

When a browser downloads a script from a web server, do you really want that script to make system calls to your client OS kernels ?

JavaScript is a sandboxed language. its like a baby which can’t talk directly to kernels or doesn’t have a standard library to do so. Its a simple interpreted language which is platform independent. that’s enough to do the job at browser level with current non blocking async model . lets see an example for a fetch request from browser.

your JS code→ V8 executes → Browser intercepts fetch()
↓
Browser Internals C++ code for network (networking stack)
↓
System call at kernel level: socket(), connect(), send(), etc.
↓
Kernel handles the network operation through kernel handler.

You would not want an uninspected C or Java piece of code to get downloaded and run on your client browser specially when you go search on websites you just found. They do have std. libraries to make sys_calls and use your hardware to execute something.

Get Vikastiwarisync’s stories in your inbox

Join Medium for free to get updates from this writer.

At servers, It has a Node runtime environment equipped with a library called Libuv which abstracts system calls for memory managements, network calls, file operations and process management. Even there, the methods exposed for system calls are limited. The context switching, i/o, thread pool management is abstracted away from JavaScript. Its a beautiful peace of technology which can be easily used without diving too much into the details and being performant at the same time. lets see one example of file read.

JS calls fs.readFile()
↓
Node uses libuv to send file read to thread pool.
↓
Thread pool handles blocking I/O.
↓
Once done, callback is added to the event loop queue.
↓
V8 resumes your JS with the result.

Is it perfect ? No! but its perfect for the job!

--

--