[discussion] TypeScript compatibility?

[trusktr]

Could JSPP perhaps adopt support for TypeScript syntax, but keep having it's own type system?

For example, imagine if we could write

const n: int = 123

using TS syntax, but using JSPP's type system.

This would make JSPP a lot more adoptable I think, and if JSPP's type system is better than TS's, then this would be a win scenario for people looking for TypeScript alternatives while staying compatible with all the tooling already built around the language.

TypeScript has numerous issues with unsound types and management of issues that users face, so I think there is an open space for a real competitor to arise.

---

How does JSPP's type system compare to TypeScript? Could it be possible to have most, if not all, of JSPP's features with TS syntax?

---

Also seeing as how JSPP has specific number types other than just number, if JSPP had a TS-compatible syntax option, it could perhaps be an alternative type system for which something like AssemblyScript, the TypeScript to WebAssembly compiler could be built upon.

At the moment, TypeScript is pretty much the only library monopolizing static types in JavaScript, and AssemblyScript rides on that ecosystem currently.

Alternatives like Hegel.js are also promising, but not very developed yet.

---

It would be really great to see an alternative to TypeScript rise to power (Flow hasn't, the IDE tooling is not very featureful, and is flaky and slow), and I think a real good strategy for that is to provide existing TypeScript users an easy path (same syntax) to a new system (JSPP).

[rogerpoon]

You may want to look into how to export JS++ code to JavaScript or TypeScript. The proposal you're suggesting would be practical only if we adopted all of the TypeScript syntax going forward.

The JS++ syntax is more advanced. I've discussed the compiler engineering behind this here: https://www.onux.com/jspp/blog/glr-parsing-and-disambiguation/

As one of our users that read that post highlighted:

In a nutshell: the colon syntax is easier for the compiler writers and harder for the developers, and the traditional C syntax is harder for the compiler writers and easier for the developers.

Regarding this:

This would make JSPP a lot more adoptable I think

A sound type system can be adopted for one line of code, one file, one module, one class, or the entire project. Sound type systems scale; TypeScript's type system does not scale; please see the independent conclusions here for a 30k LOC migration from JS to TS. With TypeScript, you end up with vendor lock-in in an attempt to scale.

The problem is one of trends versus fundamentals. There are government organizations relying on JS++, and they cannot be bothered to chase every new JavaScript library or trend. The risk with TypeScript and its syntax is when it goes out of style and the next shiny new toy becomes the flavor of the day. JS++ tries very hard to free you from vendor lock-in while providing a powerful and concise language.

In terms of AssemblyScript and the like, JS++ can go beyond WASM. Type system soundness is the fundamental building block for generating native code, and the performance of the native code depends on the talent of the compiler engineering team. I've had more than one person dig through our blog posts and ping me to green light the JS++ Feather low-memory alternative to JavaScript's Electron:

I'll give you one example: the flow sensitivity in TypeScript/Flow's type system is not conducive to instruction-level parallelism (ILP) in modern pipelined processors because their type systems increase the likelihood of runtime branch mispredicts. Thus, it should be unsurprising that TypeScript isn't just "a little bit" less green, but significantly less energy efficient compared to plain JavaScript:

See Pereira et al.: Energy Efficiency across Programming Languages.

Regarding this example:

const n: int = 123

In ES6+, const is broken for references and would require C++ const semantics in order to fix (and it's probably too late for JavaScript to do that). The JS++ team considers every edge case for problems in JS that date back to the '90s—not just for the type system but for syntax, the standard library, and everything in between.

You may be interested in my latest email to the community regarding exporting JS++ to JS (and how a JavaScript user, writing in plain JavaScript or TypeScript, can use an entire library written in JS++ with no knowledge of JS++ or what it is).

I'm happy to help with anything relating to JS++. From complete beginner questions such as installation or writing your first functions to advanced generic programming/type systems/design patterns/etc. It'll be my 25th year in computer programming in 2022, so I can pretty much help on a wide range of issues. JS++ has been an active project for 10 years and predates TypeScript by one year, so we're happy when more individuals and organizations adopt. Just ping me on the JS++ chat. (If I don't respond right away, it might be because I'm sleeping and will get back to you the next day.)

[IngwiePhoenix]

I personally prefer JS++'s methodology when it comes to type system and syntax. Sure, I did voice some interest in bringing in JSX some years ago - but that was more of a would-like-to-have, not a neccessity, because I could always use a JSX-capable RegEx based "transpiler" to translate JSX syntax into regular syntax, and feed the result of that into JS++.

The good thing about JS++ is it's consistency. The bad, is that the source code is not open so there is no way to embed it in own projects - only the option to use another runtime and use JS++ to export the code to plain JS. (i.e.: Embedding JerryScript and having it run JS++ exported code.)

Squeezing TypeScript-ism into JS++ would - in my opinion - ruin one of the best promises that JS++ has by reducing it's consistency in both typing and syntax (= readability for developers).

I do like the idea but I don't see it as something that would make sense to implement imho.

[rogerpoon]

Good to have a show of support from the JS++ community. I didn't expect that. Thanks Ingwie!

Right, ultimately, JS++ is a language designed for software engineering -- with strong emphasis on the engineering. Code that was written 5 years ago should still work. You should not have to dig through multiple pages of a compiler's changelog just to figure out what you have to change. TypeScript's list of breaking changes is exhausting.

The team that wrote the code from 5 years ago might not even be at the organization anymore. This is true for almost all large enterprise code bases with multiple contributors. In JS++, you can expect that if it compiles, it'll work. In TypeScript, it might not compile at all; if it compiles, it may silently fail at runtime because the type system is unsound and strange errors slipped through.

[IngwiePhoenix]

Welcome!

I might not be actively using JS++ myself right now - but I do keep my eye out for, one day, to be surprised by the open-sourcing of the project :)

[rogerpoon]

There are pros and cons. Before I get into it, JS++ is distributed under an open source license (BSD License).

I don't think JS++ would have lasted 10 years if it weren't being generously financed. Anton, whom you've spoken to, was a full-time C++ compiler engineer on the Onux payroll for some ~5 years and now works as a senior compiler engineer for a publicly traded hardware company in Boston. Open source bringing an army of developers willing to work for free is a myth that only applies to the most popular projects, and JS++ is highly specialized requiring C++, compiler engineering, and deep JavaScript/web knowledge (especially of corner cases). The number of web developers that can make meaningful contributions to a large-scale C/C++ compiler code base (the JS++ compiler code is currently around 500,000 lines) is vanishingly small.

Note that JS++ handles edge cases like 'instanceof' across iframes, the ActiveX "unknown" type (legal in ECMAScript, undocumented on MSDN, so even Microsoft doesn't seem to know about their own shenanigans because, as mentioned, the developers in a large code base are likely not employed at the company anymore), browser inconsistencies, etc. The majority of professional JavaScript developers haven't even heard of these edge cases. Likewise, when I discussed the implementation at the hardware level for flow-sensitive type systems and its relationship with energy efficiency, there's no such discussion for deep systems programming in type system textbooks or literature.

I've looked at the OP's cited Hegel.js. It won't work. Just the edge cases listed above will break Hindley-Milner type inference, and there are hundreds more that can only be learned from experience. The Hegel author's CV only dates back to 2015 though.

The BSD License for JS++ is enough for most people. They don't actually need or want to edit compiler code. Our commercial users are glad JS++ is financed and commercially supported though. It gives them the confidence the project won't just quietly disappear.

By the way, you actually talked to me about open source last year in the JS++ chat. Please refer to that so we don't hijack OP's thread.