Deno 1.33: Deno 2 is coming

Building a KV store into the language is kind of nuts. I love how it abstracts away the local SQLite and deployed FoundationDB behind one interface. Testing would be super easy, as there is no question of &quot;do I spin up an entire db instance or mock the db interface?&quot; as SQLite is relatively lightweight and the burden for keeping both cases consistent falls to the language instead.<p>That being said, was wondering whether you can take advantage of this without using deno deploy, or if you&#x27;d be locked in by using deno kv. Also, wondering how many bugs will only show up when deployed due to the different backbends.

I still don&#x27;t understand the true goal of Deno.<p>It started as &quot;better node.js&quot;, with better security and modern tooling. Better security was not achieved imo, it&#x27;s not flexible enough but painful enough that you want to allow everything straight away. The module system suffers the same issues as of npm, and since everything is loaded from the same domain its hard to tell what is official or not.<p>They have a builtin server, linter, testing, benchmarking, a hosting platform, now a kv store.<p>I feel like they are getting away from being a language and heading toward being a framework. Why not, but will probably not help adoption imo.

Is it considered a stable version? The amount of unnecessary breaking changes is really frightening.<p>I mean, why would one ever need to change standard module names or demo.json structure?<p>Maybe it looks a bit better, but I’m sure it invokes a lot more pain for all developers, who need to watch out carefully with every release.<p>I consider this a JavaScript curse to be honest. Every webpack version breaks apis in random ways, react native is notoriously hard to upgrade because of this etc<p>Why isn’t it considered a problem in the community?

I love the direction deno is going with a batteries included standard library for server side JS. It makes so much sense to me to consider it for simple stuff so I could have backend and frontend code all in modern JS or typescript. Things like internal tools, dev tools, etc. that just need to pop some HTML, rendered markdown, collect a few forms, run some business processes, etc. No need to wrestle the node ecosystem, no need to context switch between backend and frontend code with other languages like python.<p>I really think this has a strong future in enterprise as dedicated frontend, backend and devops roles all merge into one. Everyone just learns and uses typescript for everything. Everyone is a &#x27;full stack&#x27; engineer now. I hate to say it but it&#x27;s almost like the dream of java all over, except the language and tooling isn&#x27;t painful.

Something that still stop me from using Deno is the incompatibility between Deno and other tooling regarding the import of TypeScript files. Namely, it is not possible to import a `.ts` file via a `.js` import [0].<p>[0] <a href="https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;discussions&#x2F;18293">https:&#x2F;&#x2F;github.com&#x2F;denoland&#x2F;deno&#x2F;discussions&#x2F;18293</a>

For the Windmill [1] project, we wrap deno to make it the backbone of a self-hostable infra to run scripts (like aws lambda), workflows (like temporal&#x2F;n8n) and UIs (like retool). This release is amazing for a few reasons. We leverage enormously that you can define script with dependencies in the same file and provide a monaco editor backed by the deno lsp through websockets. So without deno, windmill would not be possible. We also support python too but it&#x27;s a much slower as a language and make more sense for slow, long-running processes like ML.<p>&gt; Improvements to npm and Node compatibility<p>Every little improvements to npm compatibility actually unblock a very wide range of npm packages to now &#x27;just work&#x27;^tm. I would have been interested to get numbers of incompatible library but `npm:crypto` has been the biggest blocker for our users.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;windmill-labs&#x2F;windmill">https:&#x2F;&#x2F;github.com&#x2F;windmill-labs&#x2F;windmill</a>

While it is interesting to see the work going on this, unless something really messes up node, I don&#x27;t see any big adoption ever taking off, other than how egcs forced GCC to come back on track.

I&#x27;m a little thrown on the reasoning for shuffling round the std&#x2F;encoding&#x2F;* modules to std&#x2F;*<p>Seems like it would just clutter the std&#x2F;* &quot;namespace&quot; and cause churn in dependencies?

Bun, deno, now supabase, they’re all trying to build custom runtimes with everything included from database to SSR react island based frameworks.<p>I think it’s a cool idea generally, but let’s not mistake deno for replacing a generalized runtime. Deno, bun, etc. are proprietary infrastructure in a box that are being designed to integrate tightly with the rest of their deployment platforms

Deno&#x27;s major adoption point can be it&#x27;s native typescript support but without an easy way to bring an npm package into it, developing its community will be tough. So I can totally see why they are ployfilling `node:crypto` since many cloud SDKs are using those in their packages.

Nice to see ongoing development and a view ahead.<p>For work I would need a good interface for SQL. In pet projects I am using sqlx for Rust and sqlc for Python. In both you can write SQL directly and get query validation and parsing into struct &#x2F; PyDantic for free. Is there something like this for Deno?

Didn&#x27;t take too long to start the 2.0 version. I really like how Rust does not do this.

Not the goal of Deno, but right now it’s my favorite way to write single-file CLI scripts paired with zx. All the dependencies are defined at the top of the file and auto installed, TS for static type checking and familiarity, good ESM support, easy to shell out when things are easier with Bash, colors and arg parsing. Not sure I would pick it for anything in production but pretty close to my ideal for quick and dirty things.

Last time opentelemetry was a no go for Deno. <a href="https:&#x2F;&#x2F;github.com&#x2F;open-telemetry&#x2F;opentelemetry-js&#x2F;issues&#x2F;2293">https:&#x2F;&#x2F;github.com&#x2F;open-telemetry&#x2F;opentelemetry-js&#x2F;issues&#x2F;22...</a><p>is it planned for v2?

Anyone using Demo in production? If yes, what&#x27;s your experience has been as compared to, say, Next.js?

deno seems to follow a very similar line to php. you can do a lot with php without dependencies. but if you are not careful, there is a possibility that you will create garbage. i&#x27;m sure this will take deno further, similar to php.

Did they describe the changes going into Deno 2.0 vs. this minor release? (“Minor” as in semantic versioning—-not to downplay the great work that went into it.)

&gt; allowing any code editor with LSP support to work great with Deno projects.<p>Really? And why did he switch to vscode to get autocompletions for deno kv?