[donatj]

The reasoning behind most of this, that the output JS is not a strict subset of the input is silly and imho represent a misunderstanding of what Typescript is going for. It’s a full fledged language that compiles to readable JS, not just annotated JavaScript.

There are many features in Typescript where it simply isn’t just outputting a subset of the input, and many of them are the best parts of Typescript.

If you just want JavaScript with types, there are other languages that do that, but Typescript offers so much more.

[Vinnl]

> imho represent a misunderstanding of what Typescript is going for.

It's pretty what TypeScript's going for though:

> Avoid adding expression-level syntax.

https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

[donatj]

I’m curious what they mean by “expression-level syntax” specifically, because they certainly added a lot of syntax that isn’t ECMA and aren’t just Babel, backporting future ECMA features.

[Vinnl]

As long as it's stage 3 EcmaScript, I (and the TS team, AFAIK) wouldn't count that as TS syntax - that's actual ES for all intents and purposes.

Other than that it's mostly syntax that affects how your code runs - i.e. if you were to remove all syntax that TS adds, the code should still run without further modifications in any interpreter that understands ES. (And features like enums don't satisfy this condition, hence why they don't match TS's design goals.)

[Zababa]

> It’s a full fledged language that compiles to readable JS

Compiling to readable JS is not one of TS's goals. For example:

https://www.typescriptlang.org/play?noImplicitAny=false&targ...

[donatj]

That seems very readable, especially in comparison to something like Dart or Elm’s output, both of which can output thousands of lines from something as simple as your example.

From the language goals

> 4. Emit clean, idiomatic, recognizable JavaScript code.

https://github.com/Microsoft/TypeScript/wiki/TypeScript-Desi...

[mhoad]

I don’t really see the value proposition of having a compilation step that also prioritises readability when you have source maps.

I love Dart personally and I mostly see it’s compile to nonsense looking code as a feature not a bug because it’s an ACTUAL compilation step worked on by ex Chrome team members who understand V8 internals not just code splitting and running terser over it and calling it a day. Want to get the same compilation optimisations that Google uses to run all of their multi billion dollar ad business? Cool, that’s enabled by default out of the box. [1]

The part where Dart on the web falls over for me is that they have shitty support right now for modern web APIs. They are building against some ancient version of Chrome’s WebIDL files so you can totally forget about things like web components for example.

So in that sense it doesn’t feel like a sensible choice in 2022 for basic web development which is a shame because it’s otherwise probably the best developer experience I’ve ever seen.

[1] I say this somewhat theoretically, I don’t know that Dart is in anyway an obvious thing to point to in terms of web performance from what I had seen casually. I think their goal there you can write huge business critical applications with stupidly large code bases and still get good performance. But nobody’s experience after using Google Ads is to talk about how snappy it was.

[Zababa]

> I don’t really see the value proposition of having a compilation step that also prioritises readability when you have source maps.

It's to increase adoption. Some people still remember migrating to coffeescript and away from it. It's in line with tsc accepting regular JS files, the degrees of strictness, things like that. Typescript is optimized to be adopted by the maximum number of people, which in turn increases its usefulness, the feedback they can get, their influence on JS. People are going to write bindings for popular libraries, even migrate them.

Some other people (like at my job) have some people use typescript, and others the generated code. It makes debugging and reasoning about code easier.

As for Dart, I'm not really convinced. The language seems to have the same philosophy as Go (incremental improvement over old technologies), and while for Go it works because Go is relatively "low level" (lower than Dart), for Dart it's just weird.

[mhoad]

If you’re going to be working in a multi language code base I am with you. Handing people garbage looking generated or compiled code and saying work with this is going to require a solid set of well defined interfaces at a minimum and maybe like you said even giving up all of that and having to make one thing look like the other. All of what I said was under the assumption that you don’t need to think about JavaScript again.

Im making the argument that JavaScript is a target that we have all been collectively forced into due to the limitations of the web as a platform but short to medium term horizon that is changing where things like WASM are maturing and will let a lot of new options flourish (.NET folks seem to be probably leading this charge currently)

But just stopping to think about the implications of that kind of changing landscape and what’s coming, I don’t think aiming for 100% JS interop not just from a code perspective but it also the entire tooling and developer ecosystem perspective is going to be as important.

Again, I just think people are somewhat forced to at the moment because the web has always been a one language show. That wasn’t because JS was the best choice but rather a limitation of the platform itself which is already in the early stages of changing.

For Dart specifically I kind of get what you’re talking about I guess because it’s pretty commonly referred to as the best bits of JS and Java put together while ditching the worst parts of each so it’s clearly aimed at productivity for application sized code bases rather than something low level but again… that’s literally why they have a proper complication step because getting it down to something a lot more low level is exactly what a compiler is for. That doesn’t feel weird to me at all, that actually feels like an incredibly sensible choice.

[Zababa]

Good points about JS being a target and that currently evolving. Lots of people these days code without any knowledge of assembly, maybe one day JS will be like that too. On the other hand, if your risk profile is more conservative (like many companies), you may want to let early adopters try out this "JS-less" world before investing in it. Since TS has a huge focus on large projects, and thus large companies, being conservative here makes sense.

For Dart, I wouldn't be so enthusiastic when describing it. The VM, hot reload, and all of that are impressive, but I'm not impressed by the language itself. The language seems to be an incremental improvement on 2005 Java and 2005 JavaScript, which are themselves not great. For example, it lacks data classes (records) and sealed classes. It took a long time to get nullability, the type checker (and system) are not impressive (things can easily fail at runtime).