HACKER Q&A
📣 alcover

JS++ ? Why not make a new, strongly typed JavaScript ?


Javascript has a nice syntax but needs to be faster and more reliable.

With strong typing JS++ would eliminate many runtime bugs. Without all the crazy implicit conversions, boxing, 'eval', etc... fantastic speeds could be achieved.

Lots of electricity and developper hair could be saved.

JS++ would break backward compatibility but this could be softened by retaining the old syntax as largely as possible. With implicit and explicit typing.

It should be easy/automated to convert js to js++.

Inb4 ActionScript 3 : yes, something like that.

  👤 dusted Accepted Answer ✓
It's probably a terribly unpopular opinion, but I think the weak typing is the main attraction of JS. When I want stronger typing, I have C or (god forbid) C++.

If you've ever written typescript, you can see how a strongly typed JS gives you the worst of both worlds.

👤 silicaroach
Honestly, ask yourself _why_ you think you need strongly typed JS. Are type errors the most common source of errors in JS? Not even close. So why add another level of complexity for negligible gain.
👤 fjfaase
I have understood that current JIT compilers for JavaScript are smart enough to recognize when a function is called with the same type of arguments and compile the function into an optimized form making use of this typing knowledge. So, adding types to JavaScript might no result in a great performance boost. If will definitely make JavaScript more verbose which might have a negative effect on performance.
👤 stephenr
I’m still surprised that for all the “enhancements” it’s had in the last decade or so JavaScript still doesn’t allow basic things like optional type declarations (ie type hints in php).

Want to accept muck? Leave it as is. Want to accept something specific? Specify the class to accept, or even specify the shape if you want to go the duck typing route.

👤 wdiamond
you can typify untyped code, but you can't untypify typed code. because typify is to make constraints and untypify is real life, I mean, a window is a house device and a computer device, the meaning window relies on other information of context besides type. that other information is unkown so if you close de door to unkown you will never know if that exception could be handled by machine at first runtime. it's more related to the tradeoff between scale and flexibility. i'm not concerned with scale, it's tedious and prone to automation. the question is do you believe in money or in future code? I mean a code that is so untyped that behaves like human.
👤 probinso
It exists and it's called Elm. it's not work backwards compatible, but it's a really solid language
👤 dragonwriter
There are plenty of strongly typed (and often both strong and static typed) languages that compile to JS or WebAssembly for web use (or portability anywhere JS/WASM run).

If you are going to break from JS semantics by using strong typing rather than JS’s mostly-very-weak typing, I don't see what the point is of making code deceptively look like JS.

👤 techsin101
last time i had a bug due to type error was probably years ago. all bugs i get are due to logical errors or misunderstanding stuff.