41–50 of 127 posts
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 pos…
Anyone using Demo in production? If yes, what's your experience has been as compared to, say, Next.js?
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 wheth…
Anyone 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. 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.
Earlier quoted context omitted.
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]
I don't see any difference between deno as a company and your SAAS bernard.app.
Earlier quoted context omitted.
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.
If they provide a compelling product offering, and the people understand what's available where, and choose to use it, then I guess that can be called vendor lock-in. But it's hardly nefarious.
Watch as the same happens with Bun.
Earlier quoted context omitted.
If they provide a compelling product offering, and the people understand what's available where, and choose to use it, then I guess that can be called vendor lock-in. But it's hardly nefarious.
It is nefarious when you build up your entire product for years, spamming it everywhere as "node but better", yell "it's so open source too!" on every roof, only to sneakily slide in lock-in features, it's worse than being nefarious. You most likely had this plan in mind all along, and actively lied to get there. Watch as the same happens with Bun.
In this relationship of 3 years and counting, they are the positive contributor because they give you something useful for free and you presumably haven't given them anything.
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 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…
For deno that would be fresh (the framework). And the speed of development is just not there, compared to the competitors (but everything has trouble keeping up with next right now)
Earlier quoted context omitted.
It's a lock-in strategy. There is zero reason for a language runtime to be opinionated about the database. All the good programming advice will tell you such a coupling is a bad idea. What if you want to move parts of your application to a different language in the future, do you need to redo the entire database? That is just nuts! Database providers, cloud application platforms should be agnostic of the language the…
> There is zero reason for a language runtime to be opinionated about the database. The API is extremely simple. It's little more than a hash map. That's hardly opinionated. > All the good programming advice will tell you such a coupling is a bad idea. That advice is outdated. Virtually any modern application will want a database, and this API can serve as a foundation for it – a foundation that conveniently already…
Earlier quoted context omitted.
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?