Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno Joins TC39

deno.com

Post reply on HN
Print view View original

141–150 of 158 posts

Re: Deno Joins TC39

#141

Post by runarberg »

keville wrote: post #138
runarberg wrote: post #85

Earlier quoted context omitted.

let foo = Object.fromEntries(bar.map((v) => [v.id, v]));

It is not necessary to create any extraneous data structures to do OP's one-liner. This creates n+1 new arrays that must be garbage-collected.

Object.fromEntries takes iterable, so if you have a map from a handy iterator library you could get rid of the parent array returned from `bar.map`.

    import { map } from "my-iter-lib";
    
    Object.fromEntries(map((v) => [v.id, v], bar));
Or with the proposed iterator-helpers:

    Object.fromEntries(
      Iterator.from(bar).map((v) => [v.id, v]),
    )
However the inner arrays are harder to get rid of... In fact even OP’s oneliner defines the inner arrays. I would hope there were some engine optimizations though which could minimize their footprint.

Re: Deno Joins TC39

#142

Post by spankalee »

munificent wrote: post #122
disease wrote: post #86

> As TypeScript is a core part of the Deno ecosystem, we are also very interested in pushing for even closer alignment of TypeScript and JavaScript in the future. I've wondered why the frontend community hasn't gotten together and said, "The next version of JavaScript - is TypeScript!" I've been using TypeScript for five years professionally now and cannot understate how much easier it has made large frontend (not ju…

If TypeScript becomes the next version of ECMAScript, then browsers will have to support it. The day that TypeScript is supported directly on end-user machines instead of going through a developer-controlled compiler pipeline is the day that almost all evolution of TypeScript stops. There's not really much positive value out of having browsers run TypeScript natively. The main feature is static checking, but static c…

This is also why Deno running TypeScript directly is a bad idea.

Re: Deno Joins TC39

#143

Post by keville »

runarberg wrote: post #141
keville wrote: post #138

Earlier quoted context omitted.

It is not necessary to create any extraneous data structures to do OP's one-liner. This creates n+1 new arrays that must be garbage-collected.

Object.fromEntries takes iterable, so if you have a map from a handy iterator library you could get rid of the parent array returned from `bar.map`. import { map } from "my-iter-lib"; Object.fromEntries(map((v) => [v.id, v], bar)); Or with the proposed iterator-helpers: Object.fromEntries( Iterator.from(bar).map((v) => [v.id, v]), ) However the inner arrays are harder to get rid of... In fact even OP’s oneliner defin…

Please see my other comment in this thread for the `reduce`-based solution that requires no extra data structures. They're not that hard to get rid of!

Re: Deno Joins TC39

#144

Post by Soremwar »

spankalee wrote: post #142
munificent wrote: post #122

Earlier quoted context omitted.

If TypeScript becomes the next version of ECMAScript, then browsers will have to support it. The day that TypeScript is supported directly on end-user machines instead of going through a developer-controlled compiler pipeline is the day that almost all evolution of TypeScript stops. There's not really much positive value out of having browsers run TypeScript natively. The main feature is static checking, but static c…

This is also why Deno running TypeScript directly is a bad idea.

They don't though. They transpile it behind the scenes

Re: Deno Joins TC39

#145

Post by adamddev1 »

hajile wrote: post #90
adamddev1 wrote: post #78

Earlier quoted context omitted.

Or how about TCO (tail-call optimization)? Please pretty please!

Proper tail calls are ALREADY part of the spec. Google and Mozilla simply chose to ignore the spec.

It would be so nice to have it though! It could do a lot popularize recursive problem-solving and function writing, without having to go into modifying these functions to make them stack-safe.

Re: Deno Joins TC39

#146

Post by amitport »

wruza wrote: post #139
amitport wrote: post #17

Earlier quoted context omitted.

'range' a-la python

Range a-la python is a generator and is pretty straightforward in js as is. There is no need for a complicated solution and/or as part of stdlib, imo: function* range(x, y) { while (x

It's also straight forward to implement in python. It is common enough to be standard so people won't reinvent the wheel. And it should be available to people learning the language before they learn generators.

Array.prototype.indexOf is also pretty simple as are many core functions.

Re: Deno Joins TC39

#147

Post by lloydatkinson »

forty wrote: post #133
lloydatkinson wrote: post #76

Earlier quoted context omitted.

Exactly this and I'm a little disappointed, though not surprised that the response was "well it works for me so what's wrong with it? it's only for frontend". It's actually part of the language. You also forgot another super important point: - It actually works. How many times have we all run into some weird error or stack trace because node/npm/babel/webpack/typescript/jest/regenerator-runtime/babel-core/quantum-flu…

Precisely, aren't babel & webpack front end issues?

No

Re: Deno Joins TC39

#148

Post by moron4hire »

munificent wrote: post #136
moron4hire wrote: post #128

Earlier quoted context omitted.

This is not true. There are a number of ways that TypeScript's type-checking can be subverted at runtime, particularly when dealing with APIs that return JSON. You have to trust that the API has returned exactly what you are expecting, or write your own very detailed validation scripts. It's similar to the sorts of testing one would do in vanilla JavaScript without TypeScript, but now executing all the time at runtim…

TypeScript is an optionally typed language. It's core to the design of the language that the static type system is purely statically typed and doesn't come into play at runtime. You could argue that that's not the best kind of language for users. I wouldn't disagree. I work on Dart which used to be optionally typed but now has a fully sound type system with runtime checks. But that's orthogonal to whether browsers sh…

That's a strangely puritanical viewpoint.

I wouldn't say it's core to the design of the language. I'd say it's a key design decision for the development of the compiler, but those are two different things.

Also, I don't understand what you mean by "it wouldn't be TypeScript". Languages change. They change all the time. Did adding nullish coallescing before it became availalbe in JavaSciprt?

It's also not true that TypeScript is purely static and doesn't have any runtime component. There are a bunch of helper sort of functions that TypeScript can optionally include, so there is some precedent for having runtime-oriented code generated by TypeScript, rather than just eliding type information after successful static checking.

So perhaps there could be a syntax for imposing runtime-checking as an optional element. Something like:

    interface Point {
        x: number;
        y: number;
    }

    async function getPointFromAPI(): Promise {
        const request = await fetch("/api/points/current");
        const point = await request.json>();
        return check point;
    }
Type `Checked` would signal to the compiler that type information for T needs to be made available at runtime, and the `check` keyword would perform the check and "unwrap" the type to a bare reference to T.

I don't know what it would look like, but it would be a huge value add.

Re: Deno Joins TC39

#149

Post by forty »

lloydatkinson wrote: post #147
forty wrote: post #133

Earlier quoted context omitted.

Precisely, aren't babel & webpack front end issues?

No

Why would you babel or webpack your nodejs backend code? (Genuinely asking, I have never needed to do it in the last 10 years, so I assumed this was all about browser compatibility and not having to download thousands of small file over the internet respectively)

Re: Deno Joins TC39

#150

Post by munificent »

spankalee wrote: post #142
munificent wrote: post #122

Earlier quoted context omitted.

If TypeScript becomes the next version of ECMAScript, then browsers will have to support it. The day that TypeScript is supported directly on end-user machines instead of going through a developer-controlled compiler pipeline is the day that almost all evolution of TypeScript stops. There's not really much positive value out of having browsers run TypeScript natively. The main feature is static checking, but static c…

This is also why Deno running TypeScript directly is a bad idea.

The difference is a that a developer has a lot more control over what version of Deno their server-side app runs on than they do what version of a browser their client-side app runs on.
Post reply on HN