Live data from Hacker News

TypeScript 5.0

devblogs.microsoft.com

61–70 of 332 posts

Re: TypeScript 5.0

#61

Without Angular, we may very well not have TypeScript today. The top thing listed in this release (TypeScript doesn't follow semver, btw) is about Decorators. I find the whole story about Angular's role in TypeScript early days to be very fascinating because I don't hear people talk about it anymore (just search "AtScript TypeScript" if you weren't around at the time). It was the Angular team that forced Decorators t…

One of my most regretted decisions was evaluating Flow vs Typescript and going with Flow. Years later I had the opportunity to use Typescript and it was so nice comparatively. I've enjoyed it ever since. Of course, that was with years of development in its belt so maybe the experience wouldn't have been as nice if I went with it originally.

So it would seem that going with the flow turned out to mean not going with Flow; how confusing![1]

I went with TypeScript early on because the compiler chain felt better integrated than the alternatives. No messing with chains of babel translators and source mappings; just use one tool. Maybe I liked the syntax better, also. Although as I recall, in the beginning, somebody my company interviewed had set up TypeScript using Babel, and it was all very over-my-head and impressive. He turned out to be too good to work for us, but some of his ideas really stuck with me.

[1]This is why I dislike cutesy names for software projects. Just call it FacebookTypeAnnotatedJavaScriptFrobulator3003 (FTAJSF3003) or something.

Re: TypeScript 5.0

#62

Does Number.isInteger() still not serve as a Type Guard? https://github.com/microsoft/TypeScript/issues/21199#issueco...

In TypeScript, type guards are considered to be exhaustive, so if you have a string | number and check it against a function that says it returns "x is number", then TypeScript will think that in the negative case, it's a string. If isInteger was marked as a type guard, then you could write code like this: function f(s: string | number) { if (!Number.isInteger(s)) { console.log(s.substring(0, 0)); } } which is clearl…

That seems like an important feature request. I see TypeScript adding fancy stuff without fixing core limitations.

Re: TypeScript 5.0

#63

Earlier quoted context omitted.

for a lot of people it was some combination of: - Flow has more adoption (it did, for a while, in the OSS sphere) - Microsoft is evil (remember, this was before everyone was using VS Code and loving it. (Also, tautologically, TypeScript has been one of the biggest things that changed this public perception for the people I hang around)) - Facebook is awesome (oh, how times have changed...) - Flow has total type sound…

TypeScript could be used with React at least since 2015, that's when I first used that combo in production.

it's going to be really hard for me to find now after all these years but there's a video somewhere on YouTube of someone at a conference showing their first attempts at getting TypeScript to work with JSX involving lots of special comments that they would compile out with babel or something (it's been a few years, hopefully I remember that correctly). It was pretty extreme (and cool!).

Re: TypeScript 5.0

#64

Earlier quoted context omitted.

for a lot of people it was some combination of: - Flow has more adoption (it did, for a while, in the OSS sphere) - Microsoft is evil (remember, this was before everyone was using VS Code and loving it. (Also, tautologically, TypeScript has been one of the biggest things that changed this public perception for the people I hang around)) - Facebook is awesome (oh, how times have changed...) - Flow has total type sound…

Total type soundness is not a goal of Flow. For example, array bounds are not considered. Flow considers this program to have no errors, but TypeScript (with the correct option enabled) will: let m = [1, 2, 3]; console.log(m[4].toFixed()); Also, DefinitelyTyped itself launched before Flow (2012 vs 2015), so the timeline on that point isn't right.

TypeScript tries to be sound too. It wouldn't really make sense to write a type checker if that wasn't your goal. As the person who wrote the "100% soundness is a non-goal" line in the design goals document, that's there to serve the same role as "Flow sometimes has to make a tradeoff" in the Flow docs in terms of clarifying whether or not 100% soundness is a design goal. For both projects, the answer is "no".

It's unfortunate that people have, over the years, decided that just being upfront about this fact means that TypeScript has a vastly different prioritization of soundness than Flow. We don't; both checkers use soundness as the default assumption when designing behavior.

Re: TypeScript 5.0

#65

Earlier quoted context omitted.

One of my most regretted decisions was evaluating Flow vs Typescript and going with Flow. Years later I had the opportunity to use Typescript and it was so nice comparatively. I've enjoyed it ever since. Of course, that was with years of development in its belt so maybe the experience wouldn't have been as nice if I went with it originally.

I'm curious what criteria you used to pick Flow vs. Typescript.

This was fairly early days (I want to say early 2016?), so its fuzzy now (and pre VS code going mainstream which has lowered TS friction pretty significantly) but I think a lot of it was a fairly basic pros/cons list with a lot of reading peoples opinions of using each technology. I think my ultimate reason was that Flow was comment-based and so was technically more "rip out"-able if I changed my mind later.

EDIT: oh, also as someone else mentioned it was a React project, so I'm sure that played a part.

Re: TypeScript 5.0

#66
post #45
post #32

Earlier quoted context omitted.

We have WASM dude. But TS people are in TS bubble for what it's worth.

Until WASM can touch the DOM you’re still going to need JS (and hence, TS).

In fairness, rust-in-wasm has pretty complete DOM bindings. You can quite easily write DOM manipulation code in Rust without ever touching JS/TS. Whether that's a good idea is another matter.

Re: TypeScript 5.0

#67

I have a strange take - I think Typescript types are better most other languages, including Java, C++ and Go. It's strange since TypeScript is adding types to a weakly typed language. If we could push JavaScript performance to be another order of magnitude faster it wouldn't be necessary to use other languages, imho. Of course, pushing it that far without effectively creating a new one would be difficult, to say the…

[deleted]

Re: TypeScript 5.0

#68

Earlier quoted context omitted.

I'm curious what criteria you used to pick Flow vs. Typescript.

for a lot of people it was some combination of: - Flow has more adoption (it did, for a while, in the OSS sphere) - Microsoft is evil (remember, this was before everyone was using VS Code and loving it. (Also, tautologically, TypeScript has been one of the biggest things that changed this public perception for the people I hang around)) - Facebook is awesome (oh, how times have changed...) - Flow has total type sound…

As an "old person" it still weirds me out to see Microsoft get so much praise for their open-source developer tools

Re: TypeScript 5.0

#69
post #7

Question, is there anything decorators can do that higher order functions and higher order classes cannot already accomplish? I typically dislike decorators because they are spooky action at a distance, and whenever I look at code in a language that has decorators, the code almost becomes a DSL of sorts. Not that HoF and HoC don't tend towards the same problems, React used to be famous for how often HoC got used in t…

My favorite usage for decorators in java is for defining http requests, it lets you write stuff like this @GET("/users/{id}") function loadUser(id: int): Promise {} @PUT("/users/{id}") function updateUser(id: int, user: User): Promise {}

Can't fathom why annotation are used for this, except maybe as a holdover from years ago when Java didn't have certain language features. Other approaches in Java are much nicer and involve zero annotations. Example (from the Spark Java microframework documentation):

    path("/api", () -> {
        before("/*", (q, a) -> log.info("Received api call"));
        path("/email", () -> {
            post("/add",       EmailApi.addEmail);
            put("/change",     EmailApi.changeEmail);
            delete("/remove",  EmailApi.deleteEmail);
        });
        path("/username", () -> {
            post("/add",       UserApi.addUsername);
            put("/change",     UserApi.changeUsername);
            delete("/remove",  UserApi.deleteUsername);
        });
    });
All your endpoints concisely and composibly mapped out in code, and not smeared across dozens or hundreds of methods and classes. Not an annotation in sight; just plain old Java.

Re: TypeScript 5.0

#70

It's easy to miss, but I'm most excited for "--moduleResolution bundler" ( https://devblogs.microsoft.com/typescript/announcing-typescr... ) My understanding is it should allow you to finally have TypeScript files that import other TypeScript files and include the file extension. This is important because, for one, it means Deno TypeScript modules and non-Deno TypeScript modules are now compatible (can import each ot…

FYI, I just tested this, and it seems to work. I was a little concerned about the commentary in the PR about this new mode being "definitely not suitable for Deno", but I think what you want to do is the same thing I've been really irritated that I couldn't do before.

Namely, I have an Nx monorepo full of standard TypeScript code, but that code works with a many things: Node, Electron, frontend apps with Angular or Svelte or whatever, etc.

I want to use Deno for some new stuff, but Deno couldn't import any of that code without modifying that code so it no longer worked with all the non-Deno stuff.

For a quick test, I made a new default Nx monorepo and a regular TS library and a Deno library and a Deno app.

I changed all imports to use '.ts', and added this to the tsconfig.json:

    "moduleResolution": "bundler",
    "allowImportingTsExtensions": true,
...et voila! My Deno code can finally import all that normal TypeScript code I have sitting around.

Haven't tested anything else yet, so I am not sure what, if any, issues those two changes above, plus including the .ts extension, might cause for other existing TypeScript projects.

Post reply on HN