"What to know about Deno 2.0"

[@ngideo]

4:11 skips the intro

[@Tejas-zx7ie]

Thank you.

[@DAB009]

deo means god in Indian language Hindi 😅 thanks for helpful comment.

[@JohnDoe-lo6qj]

5:10 one Minute later to Safe life time

[@JasonCunliffe]

@@JohnDoe-lo6qj 25:53

[@DrDrero]

now how does deno registry fit into JSR?

[@stefankyriacou7151]

The main thing that always stopped me from using deno in production is the lack of monorepo support, running tests only for the module i've changed, and the modules dependant on the module i've changed is not something i'm willing to trade for all the other benefits of deno's simplicity.

[@seanknowles9985]

Same, monorepo support, all this advanced functionality in the cloud environment with edge but something as basic as monorepo support has been missed makes me think they've not prioritised. Very frustrating as just get to get a repo going doesn't work so easy. Lastly they only implemented npm node_modules support after the success of Bun.

[@larscwallin]

Just imagine also having an IndexedDb implementation on the server, so you could run the same storage implementation on the backend as on the frontend😻

[@SKeyreaper]

LET'S GOOOOO

[@neoesm]

I'm seriously pumped and mega bullish in Deno. I just had to switch a project from bun to deno because bun as it stands atm is missing a bunch of stuff. I like all runtimes but recently deno has been solving everything for me

[@cg219]

Hmmmmm This seems like a reversal. Lets see how this goes. Still looking for 2.0 Will Deno 1.xx run in the Deno 2.xx runtime or will they be segmented??

[@pookiepats]

😂 excellent deductionary chops sir, it appears you watched the video.

[@cg219]

@@pookiepats whats the timestamp where Kevin mentioned it?? Mustve looked away at that time everytime

[@kevinwhinnery]

There will be some breaking changes from 1.x to 2.x, but with individual APIs rather than a wholesale switch. This will be closer to major version changes in React versus the schism in Python 2 and 3, for example.

[@cotyhamilton]

Would like to know what Ryan thinks… he was against centralized registry and required metadata file like package.json I hope http imports stay in 2.0

[@cg219]

Yeeeeeeeah Im curious about this too. Seems like some stuff is getting walked back

[@pookiepats]

Literally answered in the talk

[@kevinwhinnery]

You'll hear from Ryan directly in the not too distant future - this direction is something he's pretty passionate about.

[@lionelrowe617]

@@kevinwhinnery can you confirm that http(s) imports will continue to be fully supported, and won't be deprecated, even if no longer the recommended method of handling dependencies? Continued support is implied by your deno.jsonc "patches" example, but I don't think you explicitly stated that (unless I blinked and missed it) 😅

[@DanelonNicolas]

omg!!! I love it!!! ❤❤❤❤❤ I want it live now ! 😊🎉

[@dealloc]

I wonder how they are going to solve the issue with squatting. Because right now there's quite a discussion within the Rust community about some new CoCs and their rights to remove content and what implications that can have; One example is a prominent maintainer of multiple popular libraries that works on many projects. And to avoid a situation where he'd have to rename his entire work _if_* he's going to publish it, he often registers the name first with an empty project. Moreover, these projects can take everywhere from months to years, especially as he's also maintaining other libraries. Technically you could say that is a form of squatting but at what point does it warrant removal? When and how is a name considered "abandoned"? What happens if someone contacts Deno about wanting to take over a name that _seems_ abandoned? It will require a huge effort on Deno's side to take each and every case as individual with all the context in mind.

[@mikwit]

Because you can easily import from URLs instead of a single registry it should be low drama. Anything that was removed can still be accessed by url instead of being whipped off the face of the earth like rust crates.

[@dealloc]

@@mikwit Obviously the registry is going to be used by most people because of convenience of managing dependencies. There are pros and cons to both ways. If the problem of name squatting was solved by just using URLs within Rust, then you could also just use Git repo URLs for Cargo already.

[@shafu_xyz]

Is Deno slowly starting to look like Node?!!

[@kevinwhinnery]

I don't think it will ever be exactly like Node - we want the programming model to be as close to browser JavaScript as possible, and over time I think you will see the runtime and standard library become more opinionated (versus Node I would foresee leaving tooling/platform APIs to userland). That said, in service of DX, we may end up working with or emulating the Node ecosystem in some ways.

[@cg219]

I wonder if DenoKV will see changes in 2.0.

[@kevinwhinnery]

Not specifically related to 2.0, but KV will be adding some exciting updates soon (and will continue to outside of the 2.0 release schedule)

[@rikkitp]

I want to know how Deno plan to working out npm problem "node_modules becoming black hole"

[@kevinwhinnery]

Our new registry is going to be built on top of similar technology to the current registry (only downloading files on-demand), so we should be able to retain much of the efficiency of our current system. We'll be posting a technical blog post with more details in the coming weeks.

[@WalterSear]

This left me with the impression that the only thing 'to know about Deno 2.0' is a fix for package management - somewhat underwhelming for a version release. And, for a 25 minute presentation.

[@pookiepats]

😂 not an actual dev if this didn't excite you, you're underwhelmed by the first real viable anti-npm / node compat catastrophe ? FOH dude you're a poser, this is fabulous!

[@WalterSear]

@@pookiepatsExcept this doesn't solve a key problem that npm/--compat was meant to solve - deno's lack of access to the node ecosystem. It only solves the problem that was incorporated along the way, and as a feature to boot - the lack of package management. Once is a mistake. Twice is teething problems. Three times is a deal breaker. I can't afford to spend any more time on Deno. Maybe 3.0 will turn things around.

[@bricecarpentier5817]

@@pookiepatslol, dude. This is a marked as a major version of Deno and literally the only new thing they talked about is a package manager, when the lack of one was touted as such a better thing throughout v0 and v1. There’s literally nothing to see. I’m super bullish on Deno, but this was vastly underwhelming and if you can’t grasp that then I guess there’s at least one poser in the room

[@cg219]

@@bricecarpentier5817 looks like he just responded to everyones post with the same energy lol.

[@JohnMcclaned]

deno is so good, it's just too painful to run into the 'not implemented' warning

[@abbass_almusawi]

What to know about Deno 2.0?

[@AwesomeAsh99]

Very interesting.

[@okerror1451]

holy bleeping christ this is some cool stuff. feel like a dinosaur not using this yet

[@amitlevy1861]

Deno lacks documentation and support of private npm packages, until that is added, I cannot move convince my company to use deno

[@pookiepats]

Another ignorant fart that comments without watching, your company is lucky you're not pitching anything

[@butterfly7562]

The reality is, although deno is good, but bun appear and better

[@_modiX]

Sorry I strongly disagree with the points on HTTPS imports. You can handle all of these problems with a deps.ts (no duplicates, because centralized, deno.json (for easier imports) and lock.json (for integrity). All of those things can be enforced using shebangs, by providing the proper arguments to the deno runtime automatically.

[@Stevexupen]

8:17 dude manage to sneak in dik pic into his presentation

[@tariqshafi3162]

Most of node js devs still use node js and not convince to use Deno. But most of node js and Deno devs going to easily got convinced to use Bun js

[@nXqd]

progress, make it work wth current framework and save typescript =)) nodejs is dying

[@dinoscheidt]

Mh. Deno looks to me like a great idea in isolation, but when looking at the whole end to end life cycle I am not so sure. We have everything run in containers incl. DevContainers (so go ahead npm script and delete the file system 🤷🏻‍♂️), docker and kubernetes is adding native wasm execution with virtually no cold starts and npm is THE ecosystem to distribute not just js but binaries, wasm and utilities. In a world where containers don‘t exist and wasm wouldn’t be a thing, deno is probably a great solution. But for me: Deno provides both too little for me / my engineers too drop docker as our line of Defence for pure bare metal JS isolates and too marginal improvements to use it over wasm (when actually needed). I feel Deno is at a weird spot between the chairs…. too little benefit for integration anxiety of having stuff suddenly also not work on the package level. Incl lack of tooling, mono repo support etc… Mh…

[@starlederer]

I love: * pnpm-style dependency store * importing by full URLs * consistency with web standards but I hate: * unacceptably slow lsp * too many built in things (ts, jsx support) * no-build-step approach

[@cg219]

Why don't you like built in ts support ??

[@ollierkul]

Built in ts support is maybe Deno's strongest selling point imo, makes it so easy to just write and run TypeScript.

[@pookiepats]

First legit comment I've seen, agree on no LSP; bummer.

[@pookiepats]

​@@ollierkulI'd argue it's KV, people act like setting up TS is difficult. You can grab any config through AI / google / gist... it's trivial and better done as needed.

[@ollierkul]

@@pookiepats That's true, but I still love the simplicity of being able to have a single ts file and run it, no config, no extra files. KV is awesome though, been playing with it a bunch myself and using it for a serious project.