Deno Joins TC39

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

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.

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.

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

Nobody disputes that TypeScript is open source, but there’s still a vast difference between a single open-source implementation and a specification that’s suitable for standardization. The implementation inevitably has bugs, and there needs to be a way to decide which bugs are actually “features” that other implementations will need to emulate.

(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.

Ok that makes a lot of sense, the link you shared helped explain things in denoland quite well (and reminds me that I really need to give it another go).

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

There's an issue for that to be added as part of import assertions https://github.com/tc39/proposal-import-assertions/issues/11...

I don't think it's clear cut that it should be out of band 100% of the time. I think there are use cases where inline is useful.

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.

Exactly. I am very much in favor of them though. They would be a great addition to the language.

> My understanding is that engines already optimize the objects/arrays version of those concepts pretty well

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

TCO is something that specific JS engines need to implement. It is implemented in JSC (Safari), but not in V8 or SpiderMonkey. Also see https://v8.dev/blog/modern-javascript#proper-tail-calls.

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

Proper tail calls are ALREADY part of the spec.

Google and Mozilla simply chose to ignore the spec.

Do you have any insight into how the TC39 process works, and how one might drive this work forwards? I feel like expression-orientation is the main thing missing from JavaScript at this point, and I'd love to contribute. But it's not at all clear to me how to actually do so.

https://github.com/tc39/proposal-do-expressions

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;
    }

Thanks, Aaron. I think people who have been using Node for years are skilled at the old Node ways and have huge inertia in their skills, their own code, and others' Node code. For them, the ideal platform would be Node plus some upgrades. I'm guessing they would rather extend their inertial frame of reference than leave it behind.

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.

Glad to hear this is still on the table! I have been very keenly watching this space waiting for this to land here :)

Why not PWAs?

could you imagine that some JS proposal adds the ability to ignore TS-like type annotations to the engines, so we don't even have to strip them?

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

> JS has to evolve to support some form of type annotations first class to stay relevant.

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?

In my opinion, what has been most harmful for evolution of the software engineering profession is the tendency to blame individual developers for not being infallible instead of fixing chronic failures in tooling, processes, and funding.

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

Is there some proposal for making the type syntax valid? No type checking just JavaScript parsing code with types and ignoring it.

'enumerate', as in Python.

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

Set methods for union, intersection, difference, etc.

'range' a-la python

Immutable data structures are on the agenda over in https://github.com/tc39/proposal-record-tuple and I would vote for that in Deno while I have the chance.

I often miss map, reduce and filter on iterators, though this is already a stage 2 proposal: https://github.com/tc39/proposal-iterator-helpers.

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

'zip' a-la python

'reversed' a-la python

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:

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

Deno has permissions to do this: https://deno.land/manual@v1.11.3/getting_started/permissions. Deno Deploy (our serverless offering) has no support for permissions yet (still in beta), but we are expecting this to happen soon.

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 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.

I heard there was a movement internally for a while to block adoption of ES modules because the core team members "didn't like ES modules" (again, what I saw tweeted a long time ago and don't remember the source). So that certainly can't be helping adoption of it. This is one of the reasons Deno is superior - it makes use of language features not a badly designed module format.

PRs on doc are always appreciated.