[IanSanders]

It's not about C++, it's about selecting a more appropriate tool that JS. JS is often used only because the developer knows nothing else. What's even more ridiculous, often JS is not even the easiest route.

Serious question, what are reasons to use JS in non-web contexts, apart from developer familiarity?

[vorpalhex]

It doesn't matter if it was a Delphi interpreter. Having an unsandboxed interpreter running unsigned code was a stupid move. That some C++ developer thought it wise to do this is perhaps part of the issue.

V8 on the server has a very nice eventloop that's very easy to leverage for high performance while avoiding horrifying overflow issues and fits well for a large majority of web request/response patterns while still offering significant developer speed.

[Moru]

To be fair, this is the case in just about everything. If you know one language or tool, most will use that tool to do what they need instead of learning something else that might or might not be used ever again.

Some even find it fun to bend something that isn't meant to be bent.

[Wowfunhappy]

It's the only kind of JIT'd code you're allowed to run on iOS without going through Apple's approval process. Pebble apps use JS for any code they need to run on the phone (as opposed to the watch) for this reason.

[saagarjha]

(Technically there's also WebAssembly as of recently, but it's part of JavaScriptCore so this is somewhat pedantic.)

[paraboul]

> @paraboul is on point: JS is often used only because the developer knows nothing else.

I never said that.

[IanSanders]

Apologies, I misinterpreted. Redacted

[saagarjha]

JavaScript is one of the fastest scripting languages, for one. It often has pretty decent bindings to native code as well.

[cookiecaper]

JavaScript is the only thing that you can really run on any semi-modern device. TVs, phones, laptops, desktops, servers, the only thing you can expect to execute on all of them is JavaScript. If you write your core libraries in JavaScript, you'll have that much less to worry about re-implementing and maintaining in something else. You'll have flexibility to potentially execute the same code on either client or server, phone or desktop. There are situations where that's pretty useful.

More than that, at least last time I checked, V8 is really fast. It is many times faster than the usable Python implementations, or practically any other memory-managed runtime. Only luajit seemed to sit in the same ballpark when I pulled up the shoot-out a couple years back.

I personally hate all of these facts, but sometimes, they really do mean that prioritizing JavaScript, or at least something that compiles down to JavaScript, is the best choice.

[saagarjha]

> JavaScript is the only thing that you can really run on any semi-modern device.

Wait, hold on: you can usually run C on most devices.

[cookiecaper]

Generally true, but we both know that it's not so simple, and I'm surprised HN took this bait so readily.

With JS, you have to worry way less about hardware-specific builds, platform-specific linking implications, differing system behavior and intrinsics, or any of the other substantial hangups that become relevant when you need to distribute a native application across a wide range of devices.

We don't need to repeat the rest of the thread where everyone hops in and says "tut tut, hypothetically, it would be possible for it to not be that way". We're talking about the way things actually are. In an ideal world, JS would've been out of the picture about 3 years after it was born. :)

[Moru]

The difference is that C needs to be compiled to run on anything, javascript does not.

[saagarjha]

Right, but JavaScript needs a runtime to work at all. And I don't think there was any requirement that the language couldn't be compiled?

[GoblinSlayer]

It's not like you seriously want to run C without a runtime.

[saagarjha]

Many people do in fact do this, often for embedded systems. And most other systems happen to ship with a C runtime.

[pjmlp]

There are C interpreters, commercial and open source since the mid-90's, don't mix languages with implementations.