Anyone using Demo in production? If yes, what's your experience has been as compared to, say, Next.js?
Deno 1.33: Deno 2 is coming
11–20 of 127 posts
Re: Deno 1.33: Deno 2 is coming
#12Building 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 wheth…
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…
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).
Re: Deno 1.33: Deno 2 is coming
#13Building 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 wheth…
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…
Deno Inc. has two core products: The free Deno runtime and the for-profit Deno Deploy, a Deno hosting service with 35 locations around the world. The question that often popped up was where to store data. Deno Inc. provided several guides to connect to different cloud services. But they want the friction reduced to a simple `await Deno.openKv()`.
Deno Inc. has enough expertise in running a global service that two other companies rely on their work to offer edge functions to their customers (Netlify and Supabase). Adding a database to the service makes sense. And to be clear, they don’t develop a brand new database. They build atop of SQLite and FoundationDB.
Re: Deno 1.33: Deno 2 is coming
#14Is 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 rand…
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.
Re: Deno 1.33: Deno 2 is coming
#15Is 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 rand…
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 preven…
[flagged]
Re: Deno 1.33: Deno 2 is coming
#16Anyone using Demo in production? If yes, what's your experience has been as compared to, say, Next.js?
The equivalent of Next.js would be Deno + their "Fresh" web framework.
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.
Re: Deno 1.33: Deno 2 is coming
#17I'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?
Re: Deno 1.33: Deno 2 is coming
#18Is 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 rand…
The json structure is not a breaking change. You can use the old and the new structure
Why would you ever add the complexity of having to support two different formats then?
Re: Deno 1.33: Deno 2 is coming
#19For 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.
Re: Deno 1.33: Deno 2 is coming
#20Building 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 wheth…
Building a KV store into the runtime, that has more features when using deno deploy is just that: vendor lock-in. It's just one more way to force you into paying for the service when you have locked yourself in and you can't use an alternative store.
Deno is not and has never been an "alternative runtime" to node.