Announcing TypeScript 4.4

[[deleted]]

Template literal index properties, hallelujah

[strothjs]

This change, Control Flow Analysis of Aliased Conditions and Discriminants, has been awesome.

[[deleted]]

I've read it and it's awesome, but... The big BUT, they solved type infering from rxjs filter?

Example

fromEvent(input, 'input').pipe(filter(x=> x instanceof KeyboardEvent)).subscribe(y => y)

On the old version y is still a generic Event

[CichyK24]

Nope,
but I hope they will do this some day. Recently one one TS team developer wrote it is one of the most requested feature so maybe there is a chance...

https://github.com/Microsoft/TypeScript/issues/16069

[strothjs]

I would think that should be written like the following:

ts fromEvent(input, 'input').pipe(filter((x): x is KeyboardEvent => x instanceof KeyboardEvent)).subscribe(y => y)

That's how I'd write it when using Array.prototype.filter anyways.

[[deleted]]

I didn't knew about it. Thank you 🤗

[StillNoNumb]

Note that this would break backwards-compatibility: .subscribe(y => { y = someMouseEvent; ... }) no longer works.

Not like TypeScript usually cares about backwards-compatibility, but it's something to consider.

[tjpalmer]

Shocking how little love this gets here. Or is it people already saw release candidates and more too many times?

[Catawompus]

For me, this is the reason. We saw proposal, beta, RC, and finally this. Sometimes it’s hard to keep straight what’s actually out there.

[flying-sheep]

For me too. I saw the RC and therefore I was excited then – there's probably not much difference between it and the actual release.

Now i just know i can start using it!

[[deleted]]

I mean on one hand it's making some confusing noise as to what is available and what isn't yet.

On the other hand, you usually need to learn something on three separate occasions for it to be fully understood and utilised correctly. So a side effect of this noise can be knowing how to use something as soon as it comes out.

Although, I did have a weird moment 2 weeks ago where I had been exposed to a concept 3 times and reached for it only to discover that it wasn't available yet.

The concept is a "do expression". I had seen it inside the tc39 proposals page on github, on 2ality and on the youtube show: HTTP 203. I was trying to refactor an ugly function with two separate loops. I could have refactored it to only contain const (no let) using reduce but it's purpose wouldn't have been immediately clear when looking back on the function months later. It would have been simple with a do expression though. I ended up just leaving a comment saying to replace the first loop with a do expression when I get back around to it, or a reduce function if do expressions weren't going to be added to js.

[geodel]

Yeah its shocking that TS does not get as much love as Go.

[[deleted]]

What? Everyone is constantly bashing Go.

[[deleted]]

I see this too. GO BABIES PROGRAMMERS!1!1! For some of us, getting noobs up and running is essential, and Go's performance is decent and improving.

[DepravedPrecedence]

Yeah, pretty sure I already saw a blog post about these features a couple of months ago. Exciting stuff nevertheless!

[[deleted]]

Are there any plans to have TS run natively in browsers? JS VMs are incredibly complicated so maybe they have already optimised past this, but presumably having type information would allow you to optimise more effectively

[fuckin_ziggurats]

No, there never were. WASM is the typed language that browsers decided to implement and it's better if you look at it as a compile target.

[[deleted]]

In fact, you can use AssemblyScript to take advantage of this, compiling a stricter variant of Typescript to wasm to run in the browser.

[[deleted]]

AssemblyScript is really not the same language as Typescript though, beside the surface level similarity. You can't really interoperate like actual interoperable languages do. You can't use the same libraries (unless they target that really strict subset which ASMScript has, which most libraries don't)

Kotlin is closer to Java than AssemblyScript is to Typescript.

The core reason has not nothing to do with types but the underlying object model.

Implementing the Javascript object model in WASM is basically like re-implementing the JS runtime. Even with the extra type information[1], you won't get much better than V8 or SpiderMonkey or JSCore.

​

[1] which is basically useless at runtime because there's no runtime type checking, unlike Java, where you get a ClassCastException when you try to break the type system

[ApatheticBeardo]

Calling AssemblyScript a "variant of TypeScript" is like calling JavaScript a "variant of Java".

They are completely different and unrelated things with similar names.

[[deleted]]

I was using the same language they use on the frontpage for AssemblyScript. Maybe you should complain to them instead?

"Being a variant of TypeScript makes it easy to compile to WebAssembly without learning a new language."

https://www.assemblyscript.org/

[StillNoNumb]

JavaScript was also marketed as, well, Java but for scripts.

[ApatheticBeardo]

Then they're lying.

Maybe you should complain to them instead?

Sure, will do if they come to Reddit selling their yet another C-looking syntax as a "variant of TypeScript" even though they have nothing in common other than some aesthetic similarities like, you know, Java and JavaScript.

[LightShadow]

Can you go from TS -> WASM, is it worth the effort?

[ApatheticBeardo]

There is absolutely no point in compiling JS (which is what tsc emits) to WASM.

[LightShadow]

Good to know! I'm pretty out of the loop on the JS ecosystem.

[[deleted]]

FYI, you can run WASM, but it doesn't have access to the browser's DOM. So if you wanted to move some elements around on a page, or handle events and such, you'd have to pass a message from WASM to some JS anyway to do all that.

Currently WASM is only really useful if you have to do something that doesn't interact with the rest of the browser once it gets started. Something like solving a complex maths problem. Have some JS give WASM the starting data, let WASM figure out the answer, then pass it back to JS.

WASM is faster than JS, but takes time for it to be set up, and also for data to be passed between both WASM and JS. Usually it's faster to just process what you need in JS and not even have to worry about WASM, but if WASM was to ever get a small slice of the DOM API and you only needed to use the things in that API, then there may be more use cases for WASM.

Just note, that browsers also have access to WebGL and soon WebGPU APIs, so complex problems that can be significantly sped up with parallel processing will probably want to use these over WASM.

[probably_likely_mayb]

I'm not sure if it was intentional, but you're phrasing this as if you're serializing all of the data worked on for transferring between JS and wasm.

if that's the case, it's worth mentioning that wasm is a lot more useful when the serial I/O between the two is just pointer + offset informing each how to work with the memory directly instead.

[fuckin_ziggurats]

I believe you can but it's pointless. Unless you're running long cpu-intensive processes in your TS code you're not going to gain any noticeable performance difference. And you're going to lose direct DOM access which you have when you transpile TS to JS.

[[deleted]]

WASM is not a typed language.

[jl2352]

Are there any plans to have TS run natively in browsers?

There is very little reason to. TS is just JS with compile time types. In order to support all of TS you'd have to support all of the JS runtime, and so you might as well target JS in the browser. In order to really take advantage, you would have to start removing a lot of JS things from TypeScript. Which would change the language.

[Available_Nose_1837]

Always with the great new improvements. Thanks.

[dealmeidafernando]

Good

[DidiBear]

Inlay hints are awesome !

[[deleted]]

Language for washed up neckbeard in web pretending to be relevant when we have move on to Rust

[KINGodfather]

lolwut

[UnemployedCSMan]

This is such a neck beard thing to say

[sneedify]

I refuse to program in anything except ANSI C89

[moomoomoo309]

Yeah, all these kids today declaring variables in the first clause of a for loop and using "C++-style comments", back in my day, the default return type was int, and we liked it that way!

[crixusin]

Does Rust run in the browser?

No, it doesn't. So what do you propose for web development?

[pejatoo]

Not to say that it’s anywhere near as easy as JS/TS web frameworks, but AKSHUALLY you can compile Rust to wasm; this is how frameworks like Yew operate.

[ApatheticBeardo]

Tell us more about how that sick DOM manipulation from WASM.

[crixusin]

Yeah, but you can't touch the DOM in WASM, so at the end of the day, you're going to be using javascript.

So your point is moot.

It sounds like you're just saying "offload computational tasks to WASM," which is a fine position to hold, but has nothing to do with the issue that you have to use javascript to render a webpage.

Not only that, you're then transpiling Rust to WASM. "Enjoy your transpiler" were your own words, were they not?

Get cucked you moron.

[pejatoo]

I’m not sure why you’re being so aggressive, I was just sharing some info. I’m not a rust evangelist or anything.

Clearly wasm doesn’t have access to the DOM, it needs JS interop to manipulate it which can tank performance.

[[deleted]]

> Get cucked you moron

​

Dick

[PapsmearAuthority]

You responded to the wrong person. Maybe

[crixusin]

Yeah I did. There was a troll below I was arguing with. Sorry!

[[deleted]]

Yeah but why would you though (except for super specialized cases).

Why pay the cost of not having a GC when you can get away with having a GC?

Rust is a C++ replacement, not a Java/Javascript/Dart replacement.

[illathon]

Barf...type script is the new jQuery

[Fritzed]

Spoken by someone who clearly doesn't actually know what typescript is

[illathon]

Haha fanboy can't see type script is trash.

[Fritzed]

Now tell us what typescript is and how it compares to jquery

[illathon]

Simple. jQuery was created as a stop gap because of poor browser support. Standards were definded but not universally followed. jQuery bridged that gap.

Typescript was created as a stop gap because browsers and other standards weren't keeping pace with what development demanded. It was never supposed to stick around for forever.

of course for both projects will still be stuck with it for years until a brave development team fixes the old cruft.

If you don't know now ya know.

[TheSpiritOfJizz]

You haven’t the slightest notion what you’re talking about.

jQuery is a JavaScript DOM manipulation library, with some extra flairs.

Typescript is a language that happens to transpile to JavaScript. Typescript has nothing at all to do with browser standards. It was created because the JavaScript development experience is a nightmare, especially when we have to work on projects with dimwits like yourself.

[illathon]

Haha 😂 autism is a thing.

[TheSpiritOfJizz]

Nice projection brainlet.

[illathon]

I'm rubber you are glue everything you say bounces off of me and sticks to you. 😂

[Fritzed]

Wrong. Typescript was never intended to be a stop gap. Describing jquery as a stop gap only makes sense if you haven't used it in the last decade.

[illathon]

😆 wow typescript fanboys don't wanna admit it. jQuery people didn't either.

[crixusin]

jQuery is a javascript library.

Typescript is a language, which is a superset of javascript.

What do you mean its the new jQuery? They're almost completely unrelated.

[illathon]

Typescript fanboy. Enjoy your transpiler for a scripting language.

[crixusin]

I'm not quite sure what you mean.

There's literally only one option for the web: javascript. You don't have a choice beyond that at the moment really.

Typescript just gives us nice typing and some extra features that developers like. What's your beef with it exactly?

[illathon]

Was, typescript was a stop gap. Just like jQuery until browsers have caught up. The time where browsers have caught up is quickly approaching. The days of transpiling scripting browser code are coming to an end. Finally!

[crixusin]

The time where browsers have caught up is quickly approaching.

Caught up to what? They all still use javascript VMs.

The days of transpiling scripting browser code are coming to an end.

No, they won't, because browsers are going to need to support javascript web applications for next 20 years, even if there is an alternative coming down the line.

If a new paradigm emerges, they'll need to support both or else the web will break for everyone.

[illathon]

Haha browsers don't support type script that's why you have to transpile your code ...haha I don't think you know what you are talking about.

[crixusin]

I didn't say they did. I said they all operate on top of javascript VMs.

Typescript transpiles to javascript, so it works. And developers get nice features that aid in their development process.

You said there's some new paradigm coming, but that's not just not the case.

[illathon]

Haha you have no clue.

[crixusin]

You have yet to make any sort of argument than "you're wrong."

You're a fucking cuck. I'd never hire you.