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/[email protected]/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).
I think they're much better as a part of import maps, and later fetch maps so they can apply to non-JS resources like CSS.
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.
Eich was pushing for them in 2011 and they still haven't arrived.
The proposal is humming along through the stages at a good pace.
They don't, using libraries that guarantee runtime immutability has a heavy performance cost in JS currently.
Is immutability part of the proposed standard? And if so, what’s the benefit over using Object.freeze?
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).
That's what they are here. Array are heterogenous in JS, and tuples are too. And since they're immutable, their size is fixed.
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.
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.
The do expression proposal is currently stage 1, so its very early. You can check out the issue tracker there to see some of the related discussion. Standards work can be deceptively hard, even for simple things. I think the do expression proposal is a good example of that.
Edit: forgot to link to the issue tracker I referenced above https://github.com/tc39/proposal-do-expressions/issues
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;
}I believe an Electron alternative is an important part of the Deno stack, so hopefully we'll ship a first iteration next year.
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.
If you want a "no compile" JSX:
```jsx
const x = <div color="red">hello</div>;
// is the same as
const x = h("div", { color: "red" }, "hello");
```
First, there’s the “new JSX transform”, which involves auto-imports, has a different function signature, and defines fallback behavior for certain circumstances.
Second, JSX is only specified as a syntax extension. Some implementations—like SolidJS and its underlying dom-expressions compiler—don’t compile to hyperscript at all.
Huge fan of the achievements that Deno has made in recent years. Several questions:
How do you aim to promote Deno as a viable alternative to node, considering it's significant network effect and legacy?
Do you believe that Deno's 'more sane' defaults for security will appeal to developers in the long term? Do you think that the front end community will be receptive to these defaults?
Choosing TS as your language de jure, do you think that you will alienate any dyed in the wool JS devs? Can we expect that TS is now effectively the superset of JS going forwards?
Do you believe Deno's lack of support for NPM style package management will result in cleaning up the frontend community's over reliance on 'leftpad' style packages? Do you think that Deno's approach to dependencies fosters a more considered approach to transitive dependency bloat?
Again, huge fan of Deno, and happy to hear about this announcement.
This is a great question, but not one I can answer in a small HN comment :-). I may write a blog post about it one day. The core of the argument is that Deno can save you an insane amount of time / discussion (OOTB linting, formatting, testing, standard library, etc). It aims to unify the ecosystem into a single style, like in Go.
> Do you believe that Deno's 'more sane' defaults for security will appeal to developers in the long term? Do you think that the front end community will be receptive to these defaults?
I think many developers do not care about permissions, and also will not in the future. This is a problem, but not something that can be tackled overnight. Security is often not emphasized enough in our industry unfortunately. Because of this I think sane defaults and opt ins are good - they push people to think about security at the most basic level. Maybe the log4shell attack also shows people that it is a good idea to sandbox server side scripts aggressively (something we have been pushing for), to prevent large scale system takeovers through a single vulnerable entrypoint.
> Choosing TS as your language de jure, do you think that you will alienate any dyed in the wool JS devs? Can we expect that TS is now effectively the superset of JS going forwards?
There is work being done on this. I don't have too much to share right now, but expect some updates on this early next year. JS has to evolve to support some form of type annotations first class to stay relevant.
> Do you believe Deno's lack of support for NPM style package management will result in cleaning up the frontend community's over reliance on 'leftpad' style packages? Do you think that Deno's approach to dependencies fosters a more considered approach to transitive dependency bloat?
Maybe, maybe not. I think it is still to early to tell. I do think that so far it is looking like it. People seem to be doing less weird stuff like "leftpad" with Deno so far. Ideally all these little helper modules should just be part of JS directly (hit me up with suggestions!)
> Again, huge fan of Deno, and happy to hear about this announcement.
Thanks, glad you like it :-)
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.
For example, we might want to make sure software used in avionics, aerospace, weapons systems, voting machines, medical devices, cryptography, power plants, policing, finance, etc is carefully engineered. But I agree with your main point that there's still a baseline of competence necessary -- we need both good tooling and good people.
That reminds me of a lament from a friend at the Software Engineering Institute that the profession missed the boat on the kind of licensure most engineering disciplines have. (That is, any software developer can refer to themselves as an "engineer" without taking any tests, accepting any liability, or meeting any other legal requirements.)
> Better support for explicit resource management
refer to?
This is all when vanilla JS keeping very energetically absorbing new features from *-Scripts thanks to TC39 seemingly intentionally picking them?
'clamp' and 'sortBy', as in Lodash.
Set methods for union, intersection, difference, etc.
function* range(x, y) {
while (x <= y) {yield x++}
// or ‘<‘ if you want half-open one
}
for (let n of range(3, 5)){
console.log(n)
}
array = [...range(3, 5)]
console.log(array)Array.prototype.indexOf is also pretty simple as are many core functions.
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])
You still need to create the middle datastructure ( [[k1,v1], [k2, v2]] ) but it is an improvement :)
let foo = Object.fromEntries(bar.map((v) => [v.id, v])); import { map } from "my-iter-lib";
Object.fromEntries(map((v) => [v.id, v], bar));
Object.fromEntries(
Iterator.from(bar).map((v) => [v.id, v]),
)
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 in the community it might take JS in the wrong direction.
Thanks!
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>
},
]}