12 ms·

Deno 1.33: Deno 2 is coming

213 points by mephju 3y ago

can3p 3y ago
Is it considered a stable version? The amount of unnecessary breaking changes is really frightening. I mean, why would one ever need to change standard module names or demo.json structure? 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. 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 Why isn’t it considered a problem in the community?
- iddan 3y ago
  The json structure is not a breaking change. You can use the old and the new structure
  - nikanj 3y ago
    Why would you ever add the complexity of having to support two different formats then?
    - Aerbil313 3y ago
      Old one will be deprecated in a major version change afaik.
    - PoignardAzur 3y ago
      The two formats aren't that different, and the old version is now deprecated. I doubt it adds that much complexity.
    - ithkuil 3y ago
      Because the new format is easier for their (new) users but removing the old one would be a pita for their (existing) users. You can't get things 100% right all the times so you have to decide what to do when you realize there is a better way. You have a few choices: a. You don't improve the interface and instead you offset the issue by adding more documentation, helper scripts, templates/examples etc. b. You improve the interface, possibly in a backwards compatible way. So, (b) presents some maintenance costs, but (a) too has some costs! Some organizations tend to prefer (a) because it's easier to just make it somebody else's problem (e.g. some other team will do documentation, some other team will do the developer advocacy). So it's a locally optimal solution and hence it's often chosen despite (b) being a globally optimal solution, since the product will be easier to use.
- brundolf 3y ago
  Deno has a very cool architecture where almost all of the standard library is imported from outside of the runtime. Which means you can pin specific versions of unstable APIs, and never get caught by surprise even as they're being iterated on rapidly. They also say in the post that eg., the deno.json file changes are backward-compatible As far as I know, Deno 1.x runtime upgrades are always backwards-compatible
- frou_dh 3y ago
  The standard library is separate from the Deno runtime and is currently pre-1.0 (0.185.0). As the blog post touches on, upgrading Deno itself does not force you onto the latest version of the stdlib. You will need to change the import URLs to get it.
- threatofrain 3y ago
  I think Deno feels a fire under their ass. The JS ecosystem has not really embraced Deno in terms of tooling, libraries or frameworks and the serverless ecosystem has not embraced Deno as a runtime (aws/gcp/azure functions), so they're iterating rapidly to see if they can get something to really stick. And then there's Bun. I love Deno for system scripting but the friction with the rest of the JS ecosystem has prevented me from adopting it further.
  - sph 3y ago
    [flagged]
    - osener 3y ago
      Disgraceful?! I'd much rather OSS authors have an additional SaaS offering to support their work and work on it full-time rather than get them to work nights and weekends for free while AWS collects the checks for deploying their work.
    - xupybd 3y ago
      I like to get paid for my work. Most people do. There is nothing disgraceful about that. I don't see any difference between deno as a company and your SAAS bernard.app.
      - sph 3y ago
        My SaaS is not an open source project nor a language runtime. How would you feel if Go, Elixir or Rust (just to name a few) were run by a company that depends on their success, so try to push aggressively new features and mindshare, often with disastrous result? Are Go, Elixir or Rust developers working for free? There is a difference between getting paid to work on open source, and structuring an open source company as a VC-backed startup that needs to grow fast or die. I guess everyone has already forgotten about Docker, Inc.
        Sytten 3y ago
        This is a bad analogy, it is more like if the Tokio runtime was built by a VC backed business which is really not that bad. Honestly the anti business sentiment on HN is just becoming annoying. Get shamed when not building OSS, get shamed if you take VC money, etc. People are supposed to be saints that work for free so you can then take that and build your own proprietary stuff? Seriously...
StefanWestfal 3y ago
Nice to see ongoing development and a view ahead. 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 / PyDantic for free. Is there something like this for Deno?
- lacasito25 3y ago
  There's pgtyped, which I believe does almost the same as sqlc https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped
- jerrygenser 3y ago
  I was interested in looking up sqlc for python but it seems to be for go? Is there a different version than this? https://github.com/kyleconroy/sqlc https://github.com/kyleconroy/sqlc
  - cropcirclbureau 3y ago
    They appear to have beta grade[0] support for Python and Kotlin. (TypeScript on the roadmap as well) [0]: https://docs.sqlc.dev/en/latest/reference/language-support.html https://docs.sqlc.dev/en/latest/reference/language-support.h...
  - StefanWestfal 3y ago
    They put some work into the Python adoption and it is enough for smaller projects but I did not try it for to complex use cases. You can see it under examples. What is nice is that you can set the option to parse into PyDantic rather the dataclasses.
billllll 3y ago
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 "do I spin up an entire db instance or mock the db interface?" as SQLite is relatively lightweight and the burden for keeping both cases consistent falls to the language instead. That being said, was wondering whether you can take advantage of this without using deno deploy, or if you'd be locked in by using deno kv. Also, wondering how many bugs will only show up when deployed due to the different backbends.
- samwillis 3y ago
  There is a good little overview of Deno KV here (by @simonw): https://til.simonwillison.net/deno/deno-kv https://til.simonwillison.net/deno/deno-kv So it's backed by SQLite on the OS local version. I'm intrigued if there will be a way to swap out the backend for other cloud providers.
- wokwokwok 3y ago
  I dunno. Is having a database that happens to be a product you sell as part of your runtime good, or are you creating some mixed incentives here? Are you a database vendor now? If not, don’t build a database. If this is a mature product that someone else is looking after, and it’s good and free and we’ll maintained like redis or SQLite, sure. …but it seems like building cloud databases is not the core competency of a group building a javascript runtime. Once money is involved, it’ll either be a distraction from their core mission, or become their core mission. A KV db you can use for quick hacks? Sure. Awesome! A scalable production database you’re selling to people? O_o why are you doing that?
  - frou_dh 3y ago
    They need this because Deno Deploy (their Edge platform) is not a normal/traditional deployment target. If Deno were nothing but "Deno CLI" (the equivalent of the 'node' executable, that runs as a typical server process on a Unix box) then you would be right. But there are two separate Deno runtimes (CLI and Deploy).
  - 3y ago
abdellah123 3y ago
> allowing any code editor with LSP support to work great with Deno projects. Really? And why did he switch to vscode to get autocompletions for deno kv?
jatins 3y ago
Anyone using Demo in production? If yes, what's your experience has been as compared to, say, Next.js?
- frou_dh 3y ago
  The equivalent of Next.js would be Deno + their "Fresh" web framework. https://fresh.deno.dev/ https://fresh.deno.dev/ My impression of Fresh is that it's neat technology but basically a barebones MVP at this stage. They haven't done much development on it since v1 last year, presumably because the team has been busy with other stuff like what's described in the article.
  - presentation 3y ago
    Yeah I tried it out but it’s clearly just a demo and not at all production ready. Maybe they should be prioritizing some this as a killer app that would bring people over, or else achieving full compat with the industry incumbents.
  - re-thc 3y ago
    It uses Preact other the hood which often has edge cases vs React and its ecosystem, which makes adoption harder.
- gorbypark 3y ago
  I am using Supabase in production (small DAU app for a large company), which uses Deno Deploy as their function provider. So far no issues and it works well. It’s also quite easy coming from a nodejs / browser js background to pick up, as it’s just JavaScript after all.
- presentation 3y ago
  Seems like Deno is having an SEO problem with all the people autocorrecting its name to Demo lol
- vbezhenar 3y ago
  I wrote tiny script which reloads kube deployments when GitHub CI finishes. I liked the fact that I did it with zero dependencies. Standard library is good enough, and I even had to use some crypto. Zero effort configuration is superb, I hate when I need to configure node for all the things, it easily takes few hours. I disliked the fact that this script constantly eats few percent of CPU despite being idle 99.999% of the time. Not a big deal but a sign of bad engineering.
tehbeard 3y ago
I'm a little thrown on the reasoning for shuffling round the std/encoding/* modules to std/* Seems like it would just clutter the std/* "namespace" and cause churn in dependencies?
- lenkite 3y ago
  Yeah, this is a very stupid change std/encoding/* is also actually the right place, why pollute the top level namespace with encodings ?
  - frou_dh 3y ago
    How's it namespace pollution? It won't cause any clashes in either std or the user's code. It's just a few directories moving slightly higher up in a directory structure (which as an aside, is even deeper than you might think, because it also includes the deno.land domain, remember).
    - lenkite 3y ago
      Just un-necessary pollutes the drop-down list in auto-completes when someone is coding stuff that has nothing to do with encodings. There is a reason for categorization and this change breaks it.
rubenfiszel 3y ago
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/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's a much slower as a language and make more sense for slow, long-running processes like ML. > Improvements to npm and Node compatibility Every little improvements to npm compatibility actually unblock a very wide range of npm packages to now 'just work'^tm. I would have been interested to get numbers of incompatible library but `npm:crypto` has been the biggest blocker for our users. [1]: https://github.com/windmill-labs/windmill https://github.com/windmill-labs/windmill
- olric 3y ago
  [dead]
a1371 3y ago
Deno's major adoption point can be it'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.
- Sheepsteak 3y ago
  You can import npm packages now. They added it a few release ago. https://deno.com/manual/node https://deno.com/manual/node
  - a1371 3y ago
    The polyfills are not complete yet as this update points out
pjmlp 3y ago
While it is interesting to see the work going on this, unless something really messes up node, I don't see any big adoption ever taking off, other than how egcs forced GCC to come back on track.
- presentation 3y ago
  The only true benefit I’m seeing as a potential Deno user is the faster startup time to reduce cold boots in a serverless setting - everything else is more in the category of “nice to haves” like ease of setup (I’m used to the workflows with Node so while it’s obtuse it’s something I know and is well documented on the web) and a tighter security model (I haven’t personally ran into any issues with this in Node but can see the benefits). But nothings stopping Node devs from prioritizing the cold boot time, or for other upstarts like Bun with more of a focus on maintaining Node compat, or going with V8 Isolates instead, to give Deno a solid run for its money.
  - qazxcvbnm 3y ago
    I was unaware of information on superior startup time for Deno and couldn't find references from a quick search. Would you be able to provide more information? Snapshots having landed in Node (https://nodejs.org/en/blog/release/v18.8.0 https://nodejs.org/en/blog/release/v18.8.0), is Deno still superior here?
    - presentation 3y ago
      Maybe I’m thinking more of Deno Deploy but they claim sub 400ms cold starts/40ms warm starts so yeah, pretty fast. Only other option I’ve seen that ballpark is with Cloudflare Workers.
vrglvrglvrgl 3y ago
[dead]
conaclos 3y ago
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]. [0] https://github.com/denoland/deno/discussions/18293 https://github.com/denoland/deno/discussions/18293
- mark_and_sweep 3y ago
  Which other tooling allows you to import a `.ts` file from a `.js` import? Not knowing much about the issue, this seems like a rather strange decision to me: If I'm importing a `.js` file, and it does not exist, I'd prefer an error message rather than the sort of magic that you're suggesting: "Oh, but I found a `.ts` file with the same name, so let me just go ahead, transpile the file to JavaScript and let you import the result!" That's rather unexpected IMHO.
  - hermanradtke 3y ago
    This is literally how esm support in node works today unless you turn on an experimental feature flag. https://www.typescriptlang.org/docs/handbook/esm-node.html https://www.typescriptlang.org/docs/handbook/esm-node.html
  - conaclos 3y ago
    Literally most of other tools: TSC, esbuild, bun, swc, babeljs, ... It is even the recommended way in TSC, esbuild and others to import a .ts file in order to emit esm-valid code. I understand the point of Deno. However, it is just too hard to adopt a tool that cannot be used in tandem with others. I do not know who downvoted my comment: it is not a healthy behavior.
    - mark_and_sweep 3y ago
      I'm not sure you understand the point of Deno if you say that the Node ecosystem does something strange so Deno should do it, too... Magic file resolution was one of the regrets explicitly mentioned in Ryan's first talk introducing Deno.
datadeft 3y ago
Didn't take too long to start the 2.0 version. I really like how Rust does not do this.
- vbezhenar 3y ago
  I think that difference is that Deno is some kind of commercial startup and Rust feels like community project backed by few huge corporations. So Deno needs to generate hype while Rust's not hurrying anywhere.
  - datadeft 3y ago
    Are you familiar with the concept of no-2.0 for Rust? The do this on purpose so the users (the software engineers) never need to convert a version x project to a version y unlike for example Python (2 -> 3). I think this is amazing.
- faitswulff 3y ago
  I wonder if they considered an edition like system for Deno versions. I would say that it’s likely too much upkeep for a commercial project, yet I somehow doubt that the Rust project has more capacity, whether that’s funding or engineering resources.
pictur 3y ago
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'm sure this will take deno further, similar to php.
- yurishimo 3y ago
  Couldn't you also make this argument for JS in general? I think many folks looking from the outside in at JS would argue that the amount of "JS garbage" has already surpassed PHP. I know you specified _without dependencies_, but I don't know that it's a fair comparison. The standard library for PHP and JS seem fairly similar to me; I work with both languages daily. Using NPM packages are much easier imo for greenfield projects. PHP before Composer still had a ton of 3rd party script usage, but with explicit imports instead of autoloading.
schemescape 3y ago
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.)
yoav 3y ago
Bun, deno, now supabase, they’re all trying to build custom runtimes with everything included from database to SSR react island based frameworks. 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
qbasic_forever 3y ago
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. 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 'full stack' engineer now. I hate to say it but it's almost like the dream of java all over, except the language and tooling isn't painful.
- deleted 3y ago
  [deleted]
h1fra 3y ago
I still don't understand the true goal of Deno. It started as "better node.js", with better security and modern tooling. Better security was not achieved imo, it'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. They have a builtin server, linter, testing, benchmarking, a hosting platform, now a kv store. 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.
- tough 3y ago
  Deno is really useful on edge computing like serverless lambda functions in things like NextJS/Vercel or Supabase and such
  - paulryanrogers 3y ago
    Why? Performance? Security?
- veidr 3y ago
  Wild take, but agree with your first sentence. 1.) it was never a language 2.) indisputably better security any time you take advantage of any of the features to disable reading of environment variables, using network, reading files, etc.
  - LunaSea 3y ago
    I see close to no case where you would not enable all access rights
    - veidr 3y ago
      Well they might not be your use cases, but surely you can imagine them, right? A build tool, that reads input files and writes output files, and nothing else. A CLI that interacts with the bug tracker, and needs to read the environment and do networking, but doesn't need to read the filesystem, launch subprocesses, etc. A serverless function that doesn't need anything but networking. Even when you need to allow whatever you're building to read the filesystem, just specifying which files/folders can be read is in an of itself a huge win. Thinking on it a little more, I wonder what kind of gigantic monolith use cases are there that need to read/write completely arbitrary filesystem locations, and need to spawn subprocesses that can't be known ahead of time, and need to do networking, and need to read arbitrary environment variables that can't be specified ahead of time, and also need to load dynamic libraries, and also need that other permission I'm forgetting? I mean, I am sure there are some, but that certainly isn't the default I'd choose.
esturcke 3y ago
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.
fithisux 3y ago
Last time opentelemetry was a no go for Deno. https://github.com/open-telemetry/opentelemetry-js/issues/2293 https://github.com/open-telemetry/opentelemetry-js/issues/22... is it planned for v2?

213 points by mephju 3y ago

Is it considered a stable version? The amount of unnecessary breaking changes is really frightening. I mean, why would one ever need to change standard module names or demo.json structure? 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. 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 Why isn’t it considered a problem in the community?

iddan 3y ago
The json structure is not a breaking change. You can use the old and the new structure
- nikanj 3y ago
  Why would you ever add the complexity of having to support two different formats then?
  - Aerbil313 3y ago
    Old one will be deprecated in a major version change afaik.
  - PoignardAzur 3y ago
    The two formats aren't that different, and the old version is now deprecated. I doubt it adds that much complexity.
  - ithkuil 3y ago
    Because the new format is easier for their (new) users but removing the old one would be a pita for their (existing) users. You can't get things 100% right all the times so you have to decide what to do when you realize there is a better way. You have a few choices: a. You don't improve the interface and instead you offset the issue by adding more documentation, helper scripts, templates/examples etc. b. You improve the interface, possibly in a backwards compatible way. So, (b) presents some maintenance costs, but (a) too has some costs! Some organizations tend to prefer (a) because it's easier to just make it somebody else's problem (e.g. some other team will do documentation, some other team will do the developer advocacy). So it's a locally optimal solution and hence it's often chosen despite (b) being a globally optimal solution, since the product will be easier to use.
brundolf 3y ago
Deno has a very cool architecture where almost all of the standard library is imported from outside of the runtime. Which means you can pin specific versions of unstable APIs, and never get caught by surprise even as they're being iterated on rapidly. They also say in the post that eg., the deno.json file changes are backward-compatible As far as I know, Deno 1.x runtime upgrades are always backwards-compatible
frou_dh 3y ago
The standard library is separate from the Deno runtime and is currently pre-1.0 (0.185.0). As the blog post touches on, upgrading Deno itself does not force you onto the latest version of the stdlib. You will need to change the import URLs to get it.
threatofrain 3y ago
I think Deno feels a fire under their ass. The JS ecosystem has not really embraced Deno in terms of tooling, libraries or frameworks and the serverless ecosystem has not embraced Deno as a runtime (aws/gcp/azure functions), so they're iterating rapidly to see if they can get something to really stick. And then there's Bun. I love Deno for system scripting but the friction with the rest of the JS ecosystem has prevented me from adopting it further.
- sph 3y ago
  [flagged]
  - osener 3y ago
    Disgraceful?! I'd much rather OSS authors have an additional SaaS offering to support their work and work on it full-time rather than get them to work nights and weekends for free while AWS collects the checks for deploying their work.
  - xupybd 3y ago
    I like to get paid for my work. Most people do. There is nothing disgraceful about that. I don't see any difference between deno as a company and your SAAS bernard.app.
    - sph 3y ago
      My SaaS is not an open source project nor a language runtime. How would you feel if Go, Elixir or Rust (just to name a few) were run by a company that depends on their success, so try to push aggressively new features and mindshare, often with disastrous result? Are Go, Elixir or Rust developers working for free? There is a difference between getting paid to work on open source, and structuring an open source company as a VC-backed startup that needs to grow fast or die. I guess everyone has already forgotten about Docker, Inc.
      - Sytten 3y ago
        This is a bad analogy, it is more like if the Tokio runtime was built by a VC backed business which is really not that bad. Honestly the anti business sentiment on HN is just becoming annoying. Get shamed when not building OSS, get shamed if you take VC money, etc. People are supposed to be saints that work for free so you can then take that and build your own proprietary stuff? Seriously...

StefanWestfal 3y ago

Nice to see ongoing development and a view ahead. 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 / PyDantic for free. Is there something like this for Deno?

lacasito25 3y ago
There's pgtyped, which I believe does almost the same as sqlc https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped
jerrygenser 3y ago
I was interested in looking up sqlc for python but it seems to be for go? Is there a different version than this? https://github.com/kyleconroy/sqlc https://github.com/kyleconroy/sqlc
- cropcirclbureau 3y ago
  They appear to have beta grade[0] support for Python and Kotlin. (TypeScript on the roadmap as well) [0]: https://docs.sqlc.dev/en/latest/reference/language-support.html https://docs.sqlc.dev/en/latest/reference/language-support.h...
- StefanWestfal 3y ago
  They put some work into the Python adoption and it is enough for smaller projects but I did not try it for to complex use cases. You can see it under examples. What is nice is that you can set the option to parse into PyDantic rather the dataclasses.

billllll 3y ago

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 "do I spin up an entire db instance or mock the db interface?" as SQLite is relatively lightweight and the burden for keeping both cases consistent falls to the language instead. That being said, was wondering whether you can take advantage of this without using deno deploy, or if you'd be locked in by using deno kv. Also, wondering how many bugs will only show up when deployed due to the different backbends.

samwillis 3y ago
There is a good little overview of Deno KV here (by @simonw): https://til.simonwillison.net/deno/deno-kv https://til.simonwillison.net/deno/deno-kv So it's backed by SQLite on the OS local version. I'm intrigued if there will be a way to swap out the backend for other cloud providers.
wokwokwok 3y ago
I dunno. Is having a database that happens to be a product you sell as part of your runtime good, or are you creating some mixed incentives here? Are you a database vendor now? If not, don’t build a database. If this is a mature product that someone else is looking after, and it’s good and free and we’ll maintained like redis or SQLite, sure. …but it seems like building cloud databases is not the core competency of a group building a javascript runtime. Once money is involved, it’ll either be a distraction from their core mission, or become their core mission. A KV db you can use for quick hacks? Sure. Awesome! A scalable production database you’re selling to people? O_o why are you doing that?
- frou_dh 3y ago
  They need this because Deno Deploy (their Edge platform) is not a normal/traditional deployment target. If Deno were nothing but "Deno CLI" (the equivalent of the 'node' executable, that runs as a typical server process on a Unix box) then you would be right. But there are two separate Deno runtimes (CLI and Deploy).
- 3y ago

abdellah123 3y ago

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

jatins 3y ago

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

frou_dh 3y ago
The equivalent of Next.js would be Deno + their "Fresh" web framework. https://fresh.deno.dev/ https://fresh.deno.dev/ My impression of Fresh is that it's neat technology but basically a barebones MVP at this stage. They haven't done much development on it since v1 last year, presumably because the team has been busy with other stuff like what's described in the article.
- presentation 3y ago
  Yeah I tried it out but it’s clearly just a demo and not at all production ready. Maybe they should be prioritizing some this as a killer app that would bring people over, or else achieving full compat with the industry incumbents.
- re-thc 3y ago
  It uses Preact other the hood which often has edge cases vs React and its ecosystem, which makes adoption harder.
gorbypark 3y ago
I am using Supabase in production (small DAU app for a large company), which uses Deno Deploy as their function provider. So far no issues and it works well. It’s also quite easy coming from a nodejs / browser js background to pick up, as it’s just JavaScript after all.
presentation 3y ago
Seems like Deno is having an SEO problem with all the people autocorrecting its name to Demo lol
vbezhenar 3y ago
I wrote tiny script which reloads kube deployments when GitHub CI finishes. I liked the fact that I did it with zero dependencies. Standard library is good enough, and I even had to use some crypto. Zero effort configuration is superb, I hate when I need to configure node for all the things, it easily takes few hours. I disliked the fact that this script constantly eats few percent of CPU despite being idle 99.999% of the time. Not a big deal but a sign of bad engineering.

tehbeard 3y ago

I'm a little thrown on the reasoning for shuffling round the std/encoding/* modules to std/* Seems like it would just clutter the std/* "namespace" and cause churn in dependencies?

lenkite 3y ago
Yeah, this is a very stupid change std/encoding/* is also actually the right place, why pollute the top level namespace with encodings ?
- frou_dh 3y ago
  How's it namespace pollution? It won't cause any clashes in either std or the user's code. It's just a few directories moving slightly higher up in a directory structure (which as an aside, is even deeper than you might think, because it also includes the deno.land domain, remember).
  - lenkite 3y ago
    Just un-necessary pollutes the drop-down list in auto-completes when someone is coding stuff that has nothing to do with encodings. There is a reason for categorization and this change breaks it.

rubenfiszel 3y ago

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/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's a much slower as a language and make more sense for slow, long-running processes like ML. > Improvements to npm and Node compatibility Every little improvements to npm compatibility actually unblock a very wide range of npm packages to now 'just work'^tm. I would have been interested to get numbers of incompatible library but `npm:crypto` has been the biggest blocker for our users. [1]: https://github.com/windmill-labs/windmill https://github.com/windmill-labs/windmill

olric 3y ago
[dead]

a1371 3y ago

Deno's major adoption point can be it'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.

Sheepsteak 3y ago
You can import npm packages now. They added it a few release ago. https://deno.com/manual/node https://deno.com/manual/node
- a1371 3y ago
  The polyfills are not complete yet as this update points out

pjmlp 3y ago

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

presentation 3y ago
The only true benefit I’m seeing as a potential Deno user is the faster startup time to reduce cold boots in a serverless setting - everything else is more in the category of “nice to haves” like ease of setup (I’m used to the workflows with Node so while it’s obtuse it’s something I know and is well documented on the web) and a tighter security model (I haven’t personally ran into any issues with this in Node but can see the benefits). But nothings stopping Node devs from prioritizing the cold boot time, or for other upstarts like Bun with more of a focus on maintaining Node compat, or going with V8 Isolates instead, to give Deno a solid run for its money.
- qazxcvbnm 3y ago
  I was unaware of information on superior startup time for Deno and couldn't find references from a quick search. Would you be able to provide more information? Snapshots having landed in Node (https://nodejs.org/en/blog/release/v18.8.0 https://nodejs.org/en/blog/release/v18.8.0), is Deno still superior here?
  - presentation 3y ago
    Maybe I’m thinking more of Deno Deploy but they claim sub 400ms cold starts/40ms warm starts so yeah, pretty fast. Only other option I’ve seen that ballpark is with Cloudflare Workers.

vrglvrglvrgl 3y ago

[dead]

conaclos 3y ago

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]. [0] https://github.com/denoland/deno/discussions/18293 https://github.com/denoland/deno/discussions/18293

mark_and_sweep 3y ago
Which other tooling allows you to import a `.ts` file from a `.js` import? Not knowing much about the issue, this seems like a rather strange decision to me: If I'm importing a `.js` file, and it does not exist, I'd prefer an error message rather than the sort of magic that you're suggesting: "Oh, but I found a `.ts` file with the same name, so let me just go ahead, transpile the file to JavaScript and let you import the result!" That's rather unexpected IMHO.
- hermanradtke 3y ago
  This is literally how esm support in node works today unless you turn on an experimental feature flag. https://www.typescriptlang.org/docs/handbook/esm-node.html https://www.typescriptlang.org/docs/handbook/esm-node.html
- conaclos 3y ago
  Literally most of other tools: TSC, esbuild, bun, swc, babeljs, ... It is even the recommended way in TSC, esbuild and others to import a .ts file in order to emit esm-valid code. I understand the point of Deno. However, it is just too hard to adopt a tool that cannot be used in tandem with others. I do not know who downvoted my comment: it is not a healthy behavior.
  - mark_and_sweep 3y ago
    I'm not sure you understand the point of Deno if you say that the Node ecosystem does something strange so Deno should do it, too... Magic file resolution was one of the regrets explicitly mentioned in Ryan's first talk introducing Deno.

datadeft 3y ago

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

vbezhenar 3y ago
I think that difference is that Deno is some kind of commercial startup and Rust feels like community project backed by few huge corporations. So Deno needs to generate hype while Rust's not hurrying anywhere.
- datadeft 3y ago
  Are you familiar with the concept of no-2.0 for Rust? The do this on purpose so the users (the software engineers) never need to convert a version x project to a version y unlike for example Python (2 -> 3). I think this is amazing.
faitswulff 3y ago
I wonder if they considered an edition like system for Deno versions. I would say that it’s likely too much upkeep for a commercial project, yet I somehow doubt that the Rust project has more capacity, whether that’s funding or engineering resources.

pictur 3y ago

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'm sure this will take deno further, similar to php.

yurishimo 3y ago
Couldn't you also make this argument for JS in general? I think many folks looking from the outside in at JS would argue that the amount of "JS garbage" has already surpassed PHP. I know you specified _without dependencies_, but I don't know that it's a fair comparison. The standard library for PHP and JS seem fairly similar to me; I work with both languages daily. Using NPM packages are much easier imo for greenfield projects. PHP before Composer still had a ton of 3rd party script usage, but with explicit imports instead of autoloading.

schemescape 3y ago

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

yoav 3y ago

Bun, deno, now supabase, they’re all trying to build custom runtimes with everything included from database to SSR react island based frameworks. 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

qbasic_forever 3y ago

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. 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 'full stack' engineer now. I hate to say it but it's almost like the dream of java all over, except the language and tooling isn't painful.

deleted 3y ago
[deleted]

h1fra 3y ago

I still don't understand the true goal of Deno. It started as "better node.js", with better security and modern tooling. Better security was not achieved imo, it'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. They have a builtin server, linter, testing, benchmarking, a hosting platform, now a kv store. 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.

tough 3y ago
Deno is really useful on edge computing like serverless lambda functions in things like NextJS/Vercel or Supabase and such
- paulryanrogers 3y ago
  Why? Performance? Security?
veidr 3y ago
Wild take, but agree with your first sentence. 1.) it was never a language 2.) indisputably better security any time you take advantage of any of the features to disable reading of environment variables, using network, reading files, etc.
- LunaSea 3y ago
  I see close to no case where you would not enable all access rights
  - veidr 3y ago
    Well they might not be your use cases, but surely you can imagine them, right? A build tool, that reads input files and writes output files, and nothing else. A CLI that interacts with the bug tracker, and needs to read the environment and do networking, but doesn't need to read the filesystem, launch subprocesses, etc. A serverless function that doesn't need anything but networking. Even when you need to allow whatever you're building to read the filesystem, just specifying which files/folders can be read is in an of itself a huge win. Thinking on it a little more, I wonder what kind of gigantic monolith use cases are there that need to read/write completely arbitrary filesystem locations, and need to spawn subprocesses that can't be known ahead of time, and need to do networking, and need to read arbitrary environment variables that can't be specified ahead of time, and also need to load dynamic libraries, and also need that other permission I'm forgetting? I mean, I am sure there are some, but that certainly isn't the default I'd choose.

esturcke 3y ago

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.

fithisux 3y ago

Last time opentelemetry was a no go for Deno. https://github.com/open-telemetry/opentelemetry-js/issues/2293 https://github.com/open-telemetry/opentelemetry-js/issues/22... is it planned for v2?