Just adding some interesting info: There is an ECMAScript Optional Static Typing Proposal.
Deno Joins TC39
131–140 of 158 posts
Re: Deno Joins TC39
#132Earlier 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 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…
This would be a big (but exciting) departure from the current TS goal of "Impose no runtime overhead on emitted programs." [1]
Recently, I've been using Zod [2] and find it to be a satisfying equivalent: you define a schema, and then you get both a TS type AND a JS parser/validator (which works as a TS typeguard).
[1] https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi... [2] https://github.com/colinhacks/zod
Re: Deno Joins TC39
#133Earlier quoted context omitted.
ESM is not a frontend thing. ESM is the standardized way of doing module imports in JS. It has a lot of benefits for server side developers too: - It has language syntax for importing and exporting instead of relying on an implicit global. - It is asynchronous, allowing for top level await. - It is reliably statically analyzable. - Because it is asynchronous, module asset loading can happen in parallel which can mean…
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?
Re: Deno Joins TC39
#134Earlier quoted context omitted.
Immutability is the whole point of records and tuples. You can read more about them on the proposal: https://github.com/tc39/proposal-record-tuple .
Ah so these are actual persistent data structures. Got it, that makes more sense. The use of the term "tuple" here is odd; I've only ever seen it used to describe fixed-width, non-homogenous sequences. These look more like immutable lists (though I guess they can serve both purposes).
> I've only ever seen it used to describe fixed-width, non-homogenous sequences.
That's what they are here. Array are heterogenous in JS, and tuples are too. And since they're immutable, their size is fixed.
Re: Deno Joins TC39
#135Earlier 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…
This would be a big (but exciting) departure from the current TS goal of "Impose no runtime overhead on emitted programs." [1] Recently, I've been using Zod [2] and find it to be a satisfying equivalent: you define a schema, and then you get both a TS type AND a JS parser/validator (which works as a TS typeguard). [1] https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi... [2] https://github.com/colinhacks/zo…
Zod looks super cool. I'll have to check it out in depth.
Re: Deno Joins TC39
#136Earlier 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 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 should support TypeScript directly. If they supported a statically typed language that had the runtime checks to be sound, that might be a great language, but it wouldn't be TypeScript.
Re: Deno Joins TC39
#137Earlier quoted context omitted.
Ah so these are actual persistent data structures. Got it, that makes more sense. The use of the term "tuple" here is odd; I've only ever seen it used to describe fixed-width, non-homogenous sequences. These look more like immutable lists (though I guess they can serve both purposes).
> I've only ever seen it used to describe fixed-width, non-homogenous sequences. That's what they are here. Array are heterogenous in JS, and tuples are too. And since they're immutable, their size is fixed.
Technically. I guess what I’m getting at is these are separate use cases that happen to be served by the same data structure in some languages, and “tuple” to me refers to the much less important/powerful use case, which is why I didn’t realize what the term referred to when I first heard about this proposal.
For instance: Rust has tuples that are fixed-length heterogenous sequences, but you can’t actually work with them as sequences in any meaningful way; you can’t map or loop or filter over them. The term “tuple”, to my mind, refers to that “multivalue” or “unlabeled-struct” kind of use case. The fact that we use arrays for that in JS always seemed to me like a historical accident/convenience.
Re: Deno Joins TC39
#138Earlier quoted context omitted.
I miss being able to create a hash from an array in a quick way. You always end up with let bar = [{id: zz, }, {id: y},...] let foo = {} bar.forEach(v => foo[v.id] = v) I'd love to have something like: let foo = bar.toMap(v => [v.id, v])
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.
Re: Deno Joins TC39
#139Earlier quoted context omitted.
I hope the pace will accelerate. The real questions is what functions we need though. Some candidates that I would love to see are better helper functions on iterators, and Uint8Array base64/hex. Most of the "standard library" in most languages is related to IO, and for JS is dependant on the host (the web, Deno, Node) so not something TC39 will touch directly. Do you have ideas for standard library functions that yo…
'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 Re: Deno Joins TC39
#140Earlier quoted context omitted.
Congrats on your new role! Currently, I feel like addition to JavaScript is a lot slower than new CSS features, for example. What do you think are the chances that JS will one day get a larger batch of STL functions, instead of about a dozen each year?
Please have someone on your team take a good hard look at the current proposal-pipeline-operator: https://github.com/tc39/proposal-pipeline-operator It started as a Function Composition proposal (using the pipe operator |>) but after a change of leadership it has turned into something much different. We might need another perspective on the current trajectory of this proposal, as in its current form it seems to many…
If you want a feedback, I do not find |> versions much (if at all) easier to read. The noise is as high as in a regular function-based chaining:
await chain(
Object.keys(envars)
.map(envar => `${envar}=${envars[envar]}`)
.join(' '),
text => `$ ${text}`,
text => chalk.dim(text, 'node', args.join(' ')),
colored => console.log(colored),
)
React example is special though. It feels like very helpful in expr-only context, but in-array ifs and fors would do better there:
{[
for (v of vs) {
const text = foo(v)
yield {text}
},
if (vs.length == 0) {
yield No items
},
]}