Mario Giambanco

Director of User Experience Development

Jun 5, 2020

The gist of your argument (IMO) is that because JS follows "some" similar processes of a compiler (tokenizing, specifically) that it is in fact, compiled. The problem with this argument, as j stated, is that all languages would fall into this and that's not correct.

When anything is actually compiled, it's expected to act and operate identically on all hardware and os's it's compiled for. If I write an iOS app in Swift and it's compiled for iOS, I can expect that app to work exactly the same on any platform that can run an iOS app (obviously, different versions of iOS may produce different results but that's getting off topic)

VS Chrome has a Javascript engine, Safari has a Javascript engine, Firefox has a .... Javascript engine. And while some of these browsers may use the same engine as a base, this is also why "sometimes" things work fine in Chrome and IE and sometimes they don't. They are all processing the JS as it comes in and "interpreting" it as they're designed to do so.

In a compiled JS app - they wouldn't. The code would be executed and the result is the result every time.

Another point, going further down this rabbit hole - a compiled language usually means the OS or the machine itself is executing the code directly. If JS was compiled, there would be no reason for the browser to execute and interpret the code. Now you could say Chrome is the "os" in this case and Chrome is executing the compiled code but IMO that's a stretch. There is still an engine looping through and interpreting the code. iOS, MacOS, Windows, Linux, et all are not interpreting compiled code - they're simply executing it.

Another point, going further down this rabbit hole - a compiled language usually means the OS or the machine itself is executing the code directly.

java is compiled, c# is compiled both are not running natively. Although the new javac coming up will allow native AOT compilation.

In a compiled JS app - they wouldn't. The code would be executed and the result is the result every time.

that's a tricky one. it depends on the linking process. If I use dynamic linking (.dll, .so) I actually use foreign ABIs in my compiled code so they could fail from system to system. at least in C, C++, Rust I got those problems I cannot talk about the other ones.

Also it would depend on the compile target that's the main reason why the VM exists so the translation between Highlevel and lowlevel isn't that complicated. Usually it's Highlevel -> stackmachine / VM -> asm target -> machine language

before I was writing my own compiler I would've taken a similar stance to be fair. It really gets tricky and hard to answer esp since JIT which basically takes the compiled code (VM/Interpreter -> fun fact Java starts 'somewhat interpreted' usually), creates statistical data about it and changes the execution layout and compiles 'more and more, based on the behaviour'

Still compiled as you actually mentions would mean that the VM code is 'listed' (compilare). But even here we could argue.

I don't wanna bore you further. it is just really tricky and it's like quantum physics and chemistry at which point do they merge? I really prefer pointing at the 'preprocessing' shit since a jvm always starts with the VM code and js just 'can' start with the VM code (caching).

that's the core difference and actually the 'interpreter' debate is off because we're actually debating 'script' vs 'compiled' to some degree.

anyhow ... bla

Search Hashnode