Deno Joins TC39 (opens in new tab)

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

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.

(Here’s the specification for ECMAScript, for example: https://tc39.es/ecma262/)

To be clear, I am not bashing Microsoft here—just pointing out a reason that TypeScript can’t be declared “the next version of JavaScript”, which is the context of this thread.

From the link I see this example:

    in src/deps.ts

    // Add a new dependency to "src/deps.ts", used somewhere else.
    export { xyz } from "https://unpkg.com/xyz-lib@v0.9.0/lib.ts";

    Then essentially a create/update lock-file command is run. 

    Then the lock file is checked into version control. 

    Then another developer checks it out and runs a cache reload command.

Having said I think having it in the import syntax would provide a few benefits:

1. No extra steps need to be run & hopefully IDEs could auto-complete the hash.

2. Would hopefully be standardized with the browser allowing for native browser support as well (or perhaps lock.json could be standardized with something like import maps)

3. Having it right there provides an extra level of assurance that the integrity hash is going to be used (especially in files intended to be used in the browser and in deno ... not sure how common that is though).

Cycles are definitely an issue, I am not sure there is even way to work around that, except to pull the cycles apart (which may not always be possible but is usually not a bad programming practice when it is). However at the library level, libraries tend not to circularly import each other. If it's being done at the inside a project level the build tool would be generating it so dealing with the module graph being invalidated may not be a hassle (or even necessarily a bad thing), in that case it could modify the files or it could be generating a lock file / import map (which I agree has benefits at that level of not forcing every source to be transpiled, but some of that probably still has to happen for module reloading e.g. appended search parameters to the module path for cache invalidation / module reloading during development like vite.js does for example, and realistically given the nature of the ecosystem some transpilation is going to have to happen either because of .ts or just because of browser differences).

For a top-level deps.ts / dep.js file pattern there probably won't be any cycles. That pattern is to declare a root deps.js file for your project that locks things down and re-exports from third party libraries a use the exports from that as the basis for other imports. For this pattern I think SRI would be extremely helpful and add enough benefit to justify it (even though SRI may not be used in the cases you listed).

Also for smaller projects or main modules having the SRI hash inline is really helpful.

They don't, using libraries that guarantee runtime immutability has a heavy performance cost in JS currently.

As this is an engine feature rather than a spec thing, there is nothing me (or any other TC39 delegate) can do.

Google and Mozilla simply chose to ignore the spec.

Allows you to contain temporary variables to where they are needed, rather than having them remain active through the remainder of the current scope. You could do that with immediately invoked function expressions, but they are too verbose to be really viable for this. You could also use extra functions, but extra functions don't always make sense. Currently I'm frequently doing this:

Without do expression:

    let result;
    {
        let tmp = 123;

        result = tmp * 2;
    }

    let result = do {
        let tmp = 123;
     
        tmp * 2;
    }

Then there are others of us who have been saying no to Node and legacy JS for years. We have no such legacy to maintain and no intention of ever creating any. But some of us (at least I) would reconsider platforms built from scratch on a new TypeScript foundation rather than layered on a pre-ES6 foundation. That would include a Deno-based Electron. You might have more luck converting people who don't use Node than getting Node users to abandon their legacy.

The state of cross-platform desktop apps is terrible. All attention is on mobile, and desktop OS makers have almost zero interest in supporting cross-platform desktop apps. (MS cares a little more than zero, Apple less than zero and barely tolerates their own Mac-only developers.) Only something browser/Chromium based seems realistic for the next few years.

On the server, there are a lot of alternatives to Node that are considered better by (and very popular with) large segments of the market. Deno will be one of them, I think. But for cross-platform desktop apps, Electron would be rejected completely if the alternatives weren't so bad and unlikely to get better. A better Electron, despite its inherent problems, could end up more popular than server-side Deno. Just a thought.

this may help development heavily, also making the browser and deno nearly identical environments.

What are you thinking in this regard? Just to define type annotations that can be made but will not necessarily be type-checked at runtime? To have them serve as inputs to the interpreter for optimisations? Or even breaking at runtime if types don't match their annotations?

The medical profession, aviation, even rail transportation [1] have all progressed past the point where avoidable failures are entirely the responsibility of the individual.

Of course, there was resistance in those fields as well because some considered themselves an "above-average" doctor or pilot who didn't need safeguards, checklists, union rules, or laws. But it empirically improved outcomes.

[1] https://www.youtube.com/watch?v=A3AdN7U24iU

'clamp' and 'sortBy', as in Lodash.

Set methods for union, intersection, difference, etc.

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])

  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:

  <ul>
    {[
      for (v of vs) {
        const text = foo(v)
        yield <li>{text}</li>
      },
      if (vs.length == 0) {
        yield <li>No items</li>
      },
    ]}

- 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 a significant startup speedup for larger projects.

- It is standardized, so it behaves the same across Node, Deno, the web, bundlers, linters, and other tooling.