7 ms·
Deno Joins TC39
- lucacasonato 5y agoHey - I am Luca Casonato, Deno's new delegate at TC39. I am happy to answer any questions you all might have :-)
- robertvh 5y agoCongrats! Can you extend on your ideas for async iteration?
- lucacasonato 5y agoMainly pushing proposals like https://github.com/tc39/proposal-iterator-helpers https://github.com/tc39/proposal-iterator-helpers that make it easier to work with (async) iterators.
- mschuetz 5y agoWhat are your thoughts on the do expressions proposal? Cause I think they'd be awesome for cleaner scoping of temporary variables.
- benmccann 5y agoDo you have a link to the proposal?
- mschuetz 5y agohttps://github.com/tc39/proposal-do-expressions 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; } With do expression it would become this: let result = do { let tmp = 123; tmp * 2; }
- lucacasonato 5y agoI think they are great! Especially in combination with pattern matching (https://github.com/tc39/proposal-pattern-matching https://github.com/tc39/proposal-pattern-matching), or when using JSX.
- nicoburns 5y agoDo 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.
- spmurrayzzz 5y agoThe TC39 process is well-documented, you can check out the stages and guidance for providing input here: https://tc39.es/process-document/ https://tc39.es/process-document/ 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 https://github.com/tc39/proposal-do-expressions/issues
- Vinnl 5y agoHey Luca! What does > Better support for explicit resource management refer to?
- lucacasonato 5y agoThings like https://github.com/tc39/proposal-explicit-resource-management https://github.com/tc39/proposal-explicit-resource-managemen.... Essentially better language level support for objects which represent some IO resource that should be reliably closed when a user is done with it. Something like the `defer` statement in Go is really missing from JS.
- jerrygoyal 5y agoAs modern JS is getting closer to typescript in terms of new methods, latest syntax etc. What is the future of TS? will it be there for just type checking?
- brundolf 5y agoIt’s always been there just for type checking, hasn’t it?
- lucacasonato 5y agoYes.
- egeozcan 5y agocould 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.
- lucacasonato 5y agoYes, this would be great, and it will probably happen eventually. This is something we want to work on soon - expect something in the coming weeks.
- ducaale 5y agoSince TS/Deno has native support for JSX syntax, do you think Browsers will eventually support it as well?
- lucacasonato 5y agoNo, I don't think so. JSX is too proprietary and not specified well enough. It is also rather ambiguous. 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"); ```
- baybal2 5y agoWhat you think of more *-Scripts built on top of JS keeping coming? Are you not afraid of TypeScript following the CoffeScript into obscurity because of WebDev community keeping chasing the new thing? This is all when vanilla JS keeping very energetically absorbing new features from *-Scripts thanks to TC39 seemingly intentionally picking them?
- lucacasonato 5y agoNo, I think this will eventually stop. JavaScript is getting more mature. I would not be surprised if the TypeScript syntax will be legacy in a few years, because JS caught up.
- megaman821 5y agoIs there some proposal for making the type syntax valid? No type checking just JavaScript parsing code with types and ignoring it.
- lucacasonato 5y agoNo such proposal exists right now, but this will be a point of immediate focus for me.
- pier25 5y agoHow will Deno react if that happens?
- lucacasonato 5y agoDeno will behave just like Chrome or Firefox would: we ignore the checks when running your code. We would have a `deno check` subcommand to perform a typecheck. You could optionally run this automatically before a `deno run` by passing a `--check` flag.
- bartq 5y agoWhen cross platform windowed WebGPU on Deno? It would be interesting for many kinds of apps.
- lucacasonato 5y agoWe are not sure about windowed WebGPU right now. We will try to come up with some form of "Deno Desktop" next year, but I have no real ETA for that.
- selfmodruntime 5y agoCongrats 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?
- lucacasonato 5y agoI 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 you think are missing?
- amitport 5y ago'zip' a-la python
- lucacasonato 5y agoI have often needed this too. Noted.
- deleted 5y ago[deleted]
- tarjei_huse 5y agoI 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])
- runarberg 5y agolet foo = Object.fromEntries(bar.map((v) => [v.id, v]));
- phist_mcgee 5y agoHey luca, 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.
- deepstack 5y agoPersonally front end developers need to step up their games learn how to develop or else don't think they have business developing software front-end or back-end. This whole idea of bring in as much developers as possible at cost of developer competency has being harmful for developer and tech community.
- asoneth 5y agoIn 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 https://www.youtube.com/watch?v=A3AdN7U24iU
- andrewflnr 5y agoWhile I agree in this case: at the edges, there still exist people who just should not be allowed to be doctors or engineers. The main difference with software is that the stakes tend to be drastically lower...
- SiVal 5y agoWill there be a Deno equivalent of Electron?
- AaronO 5y agoAaron@Deno here, we've been exploring something with the Tauri team but don't have a concrete release on the roadmap since we're focusing on other priorities. I believe an Electron alternative is an important part of the Deno stack, so hopefully we'll ship a first iteration next year.
- spankalee 5y agoWhy not PWAs?
- mattlondon 5y agoGlad to hear this is still on the table! I have been very keenly watching this space waiting for this to land here :)
- SiVal 5y agoThanks, 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.
- benjaminjackman 5y agoHi Luca - congratulations! I have a quick question, have their been any proposals to add Subresource Integrity hashes (https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...) to the import syntax? I think this effects Deno more acutely than other projects since Deno supports / (encourages?) directly importing from a url with a precise version number encoded in the url. It would be nice to add another layer of safety on top and be able to assert that the module received is exactly as expected. Thanks!
- lucacasonato 5y agoI am not aware of any specific proposals right now. There was some talk a while back about supporting SRI hashes inside of an import map, but that sorta dissolved. For Deno at least you can use a `lock.json` file with the `--lock` and `--lock-write` flags: https://deno.land/manual/linking_to_external_code/integrity_checking https://deno.land/manual/linking_to_external_code/integrity_...
- spankalee 5y agoSRI really, really should be out of band, otherwise SRI digest changes invalidate the entire module graph (and import cycles become a major pain). 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.
- 5y ago
- hajile 5y agoAre you going to push for records and tuples? Eich was pushing for them in 2011 and they still haven't arrived. https://brendaneich.com/2011/01/harmony-of-my-dreams/ https://brendaneich.com/2011/01/harmony-of-my-dreams/
- frutiger 5y agoHe doesn’t need to, the authors of the proposal are on the committee and are planning to see it through. The proposal is humming along through the stages at a good pace.
- lucacasonato 5y agoExactly. I am very much in favor of them though. They would be a great addition to the language.
- BrendanEich 5y agoYes, Bloomberg has a big JS investment due to the Terminal (20MLOC of JS last I heard) and they have employed the records and tuples champions.
- adamddev1 5y agoOr how about TCO (tail-call optimization)? Please pretty please!
- speedgoose 5y agoDo you have discussions about not adding too many features to JavaScript? It's already quite complex for beginners.
- lucacasonato 5y agoThis is always a consideration when adding new features. It is however also important to keep the language up to date with other modern languages. If you don't innovate, you die. There is always a cost/benefit calculation to be made.
- lloydatkinson 5y ago> Better support for non-JS assets in the ES module graph Whatever happens please never give into any misguided pushes to support commonjs/amd/umd or any of the other non-standardised disaster module formats that cause Node and npm etc to be so painful! It's only very recently that modern build tools are managing to overcome such poor foundations...
- lucacasonato 5y agoNo no, this is about things like importing WASM through the `import` keyword, or referencing assets statically through syntax: Asset References: https://github.com/tc39/proposal-asset-references https://github.com/tc39/proposal-asset-references Alternative module reflections (wasm imports): https://github.com/tc39/proposal-import-reflection https://github.com/tc39/proposal-import-reflection
- nicoburns 5y agoI wouldn't worry about that. Node is moving to ECMAScript modules.
- akyoan 5y agoNode is not "moving to ESM", they don't even plan to deprecate CJS. They will continue to support both for the foreseeable future. Their docs still use `require` in a lot of places even though ESM has been enabled on stable releases for almost 2 years.
- lloydatkinson 5y agoI 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.
- ecares 5y agoPRs on doc are always appreciated.
- scanr 5y ago> More extensive standard library functions for (async) iteration Great news! I wrote an open source library called axax that adds a number of utility methods to async iterators - map, filter etc. I think having them as part of the language would be awesome. Standardising async cancellation would be neat too if Deno wants a challenge....
- lucacasonato 5y agoI think async cancellation is pretty well covered by `AbortSignal` now. It is a Web API (not JS), but it is supported in all major runtimes.
- tmikaeld 5y agoI'm surprised not to see Cloudflare amongst the TC39/ECMA members, considering their current downline entirely depend on Javascript.
- disease 5y ago> 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 just Web, but mobile and desktop) projects. Surely enough thought and work has been put into TypeScript to make it the next standard.
- AprilArcus 5y agoTypeScript is great and everything, but Microsoft owns the standard and the single functioning checker, and haven't published a specification or even a grammar.
- TimTheTinker 5y agoThe TypeScript checker/compiler is Apache 2.0 licensed, so I'm not sure there's room to complain, unless you disagree with the direction they're taking the project: https://github.com/microsoft/TypeScript/blob/main/LICENSE.txt https://github.com/microsoft/TypeScript/blob/main/LICENSE.tx...
- anderskaseorg 5y agoNobody 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/ 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.
- jamil7 5y agoWould expanding wasm capabilities be a better long term option here instead of supporting TS directly? Opening the browser up to a whole lot of languages, including Typescript (AssemblyScript exists already).
- abagheri43 5y agoIt was a good article. I really enjoyed what was published
- maga 5y agoThis is great news! Good luck, Luca! > Better support for explicit resource management +1 Since everyone is making feature requests, I'd like to point out `ArrayBuffer.transfer`[1] -- ability to effectively move data without copying would do wonders for low-level/high-performance code in JS. [1] https://github.com/tc39/proposal-resizablearraybuffer https://github.com/tc39/proposal-resizablearraybuffer
- lucacasonato 5y agoYeah, this is something we have been thinking about too. Something else along those lines would be read-only buffers, and with that a copy-on-write operation for buffers. They could result in a significant speedup for many operations.
- lucacasonato 5y ago* a copy-on-write copy operation of buffers (that returns a read only buffer)
- thegagne 5y agoSomething I’d like to see, in browsers, Cloudflare Workers, Deno, etc: explicit network firewall in the software stack. An example with Workers, one script might only need to fetch from Backblaze. I’d like to set their host as a whitelisted address, and so even if a log4j type vuln happens, it can’t go anywhere except Backblaze. I think this could even work in browser-land? If you don’t need to pull in any resources outside the original host, deny any fetch made unless it’s added to a whitelist. For browsers this would need to be opt-in for backwards compatibility, but an ideal state would be opt-out (to allow all).
- kentonv 5y agoFWIW, in Cloudflare Workers, a log4j-type RCE vulnerability would be impossible because Workers does not allow dynamic code loading (eval() and similar are disabled). Of course, a lesser form of the vulnerability -- data leaks rather than RCE -- would still be possible. I agree that being able to restrict outbound traffic would be useful to mitigate that. As a hack that works now, you could monkey-patch `fetch()` to intercept calls and deny them based on URL. (I'm the tech lead of Cloudflare Workers.)
- thegagne 5y agoThanks for thinking about this Kenton. I agree the data leak is more the concern here, or even accidental use as a ddos attack agent. The scenario is an import of something like worktop, if worktop released a malicious version. Monkey patching is an option of course, but a native solution would be nice.
- easrng 5y agoYou want a Content Security Policy[0] [0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Co...
- thegagne 5y agoAh yes, I forgot about that browser side, but server side is that a thing?
- anarchy8 5y agoIt's kinda weird that Deno is in TC39 but Typescript isn't?
- zsolt224 5y agoJust adding some interesting info: There is an ECMAScript Optional Static Typing Proposal. https://github.com/sirisian/ecmascript-types https://github.com/sirisian/ecmascript-types