Sure, but it'd be nice not to have everything in the known universe depend on JavaScript.

I disagree. Having a common language in many places has led to huge improvements over the board in the JS ecosystem, it's become the "C" of the modern era, and you can build a lot of stuff on the foundations that others have laid.

I still hate JS though.

Which is anything but positive, as it also shares C's style of unsafety due to its semantics.

Javascript performs unchecked memory accesses? Or are you alluding to their both being weakly typed?

No,but implicit conversions, including from operators into numeric values isn't much better.

The amount of page differences between "JavaScript the good parts" and the actual language reference speaks for itself.

That book was created before many alternatives came out; now if you are working in a team project you should look at JavaScript the same way you look at assembler, you know it will be the final thing but you shouldn't be creating it directly, but instead "compiling" from TypeScript, ELM, etc. (langs with no implicit conversions, strong typing, etc)

Those alternatives are nice in startup land, in enterprise consulting land, we get to use what the customer IT department sanctions as allowed programming languages and tools installed on computers for external consultants.

One might argue the same point based on the fact that there even exists a book called "JavaScript: The Good Parts".

Which is ultimately irrelevant here. Consider, C is rock solid safe compared to machine/assembly.

(Though, I tend to share the annoyance of javascript...)

C is just as unsafe as Assembly, as the weekly CVE entries prove.

The only differences between C and a powerful macro assembler like MASM, is that C is portable across CPU architectures and exposes less internals.

Rock solid?

With all the UB that Assembly actually doesn't have, and the types of memory corruption issues shared with Assembly programming, not really.

My point is that safety or otherwise of the target language is just not relevant. Even C has compile errors if you use the wrong type for an operation. Assembly largely does not.

Taken to the extreme, any language ultimately goes down to machine code. So if it was a relevant fact, it would be relevant for all languages.

> Even C has compile errors if you use the wrong type for an operation. Assembly largely does not.

There are strong typed assemblers, e.g. IBM i.

Also Assemblers don't remove code under your feet, like optimizing C compilers with their UB tricks happen to do, introducing security bugs.

Absolutely! I'm just pointing out that this need is so strong that people have reached for the slow throughput of Scala.js just to get its fast startup time. If we can have both, that's even better!

No intention of arguing with Scala.js' creator :-) But, I do not think it has a "slow throughput" at all. In my experience, it's had pretty good performance.

Oh it does have pretty good performance, on par with hand-written JavaScript. But that's still 3x slower than Scala/JVM on our benchmarks, and those benchmarks are ported from the Octane benchmark suite used by V8 (so supposedly that's where V8 shines).

Everything is relative. Scala.js remains significantly slower than Scala/JVM in terms of throughput.

^ From the creator of Scala.js :)

I am excited that now there will be an option for getting both quick startup and fastest execution time!

Saw the same for clojure. People used clojurescript/plank for live dev.