Fly.io doesn't look much at all like Cloudflare Workers; it's not a Javascript API, but rather a platform for running arbitrary containers in discrete VMs.
I mean, I guess all 3 are ways to run code closer to users. We really like Deno here! I'm maybe less bullish on the prospect of coding to a particular CDN's Javascript API (which is not a problem Deno has).
Deno Deploy so far feels a lot closer though. For instance, CFW forces you to bundle your code into 1 js file, whereas with Deno Deploy you can just point to an arbitrary .js hosted anywhere on the internet, and any transitive dependencies will be fetched and cached for subsequent runs. It doesn't support dynamic imports yet, but fingers crossed that's on the roadmap.
UPDATE: apparently CFW has been updated to support deploying as unbundled files since I last checked.
> I'm maybe less bullish on the prospect of coding to a particular CDN's Javascript API (which is not a problem Deno has).
Workers, Sites, Workers KV, and now Durable Objects... it is much more than a JS API. I recently experimented with Durable Objects and they do make developing against a kv-database much simpler, even if it is limited while in beta. Our development is all-in Cloudflare atm, but we also look fondly at fly.io to move other workloads (over from AWS) that Cloudflare won't / can't support.
Sorry, I didn't mean to sound dismissive! The thing I'm not bullish about is people programming directly to a set of CDN APIs. What I like about Deno is that it runs anywhere. There's clearly an upside to programming directly to your CDN! It lets you integrate more ambitiously!
I didn't mind the colour changing background. However I did find the raindrops in the "At a glance" section to be very jarring and stopped me actually reading the key features - not what you want from a promotional page.
Thanks for the hint, this is a useful to know setting. However your statement appears to be wrong, requiring reduced motion does not stop the background rainbow animation from happening. I am running Firefox and verified my prefers-reduced-motion setting in the example result box of https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref....
The unbundle/bundle pendulum swings. A lot of this include everything (even deployments in the tooling of a language) feels like the ASP/.NET ecosystem.
It used to be you could install IIS on windows and get asp. Then they bundled it really tight so you were tied to a version of IIS based on the windows version. (eg NT4=IIs4, w2kserver=IIS5) Then they unbundled it with .net. But now you needed the entire .net bundle to just run some asp and you were tied to the version of the framework. No one was ever happy with how they bundled anything on the dev side.
I never had any issues with the IIS version, it has always just been a minimum version, we always installed whatever .NET version we really wanted on top.
Sharpest edge to me is that it's not quiet TypeScript. This means that you can't write a TypeScript file that works in both Deno and regular TypeScript (if you use any imports). Because of the issue that in TypeScript you can't import ".ts" file but you can import ".js" file, whereas in Deno you explicitely import ".ts" files. [1]
I actually like writing with Deno, and think the module resolution in Deno is easier to understand (it's literally url or explictely what's written on the import). But it's just sad that the TS team is not moving the same direction with the module resoultion, because it splits the TS community to those who write Deno and those who write regular TS.
> Because of the issue that in TypeScript you can't import ".ts" file but you can import ".js" file
That seems really annoying and is something I would expect to work. From the linked issue, does the problem go away if you make sure to always just import without the extension, and does it work both directions (deno TS->TS on JS and TS on JS->deno TS)?
The no extension shortcut as well as the index file shortcut have not been included in deno as a learning from node, which in my view is probably a wise move - keep it super simple by just specifying the exact filename.
Exactly this. Deno is designed to align with web module semantics, and omitting the extension is only really feasible when resolving modules on disk where roundtrip times are short and looking for multiple extensions in parallel is cheap. Deno, as well as the web, supports module resolution across the internet, where this resolution strategy would become prohibitively expensive.
Deno's position is much more sensible than the typescript teams position, but not working with the rest of the TS ecosystem is a huge price to pay.
I hope that either Deno implements some 'legacy' way of working that is compatible with the way the official typescript team do it, or the typescript team realize the error of their ways. I'm not sure if that's likely to happen short of a fork though.
In fairness to the TypeScript team, their position on this subject has been consistent for a very long time, since well before Deno. They do not see themselves as being in the business of rewriting import specifiers because there's just too many things that different groups would want them to do.
I'd also like them to support importing .ts files and rewriting those imports to .js, but given that they've been clear about their position I think it's up to Deno to solve this without forking the ecosystem.
The typescript team has some weird hangups around import paths that bring up issues. I wasn't aware of this Deno issue, but there's a similar one with ESM modules: TS wants you to import "somefile.js" when you actually want "somefile.ts". It's completely non-obvious, and breaks anything that checks if the file to be imported exists on disk.
Yeah, I find this issue very irritating. Forcing you to claim you're importing a file that doesn't even exist except as part of the output of a build step means that you're tying your implementation of a language to a specific set of tooling and environment.
It's treating a language like it's a dumb file rewriter rather than something semantically meaningful. It would have made no sense for Deno to do the same thing - if you import a .js file from a remote server, you want that js file, if it doesn't exist automatically trying to load a .ts file from the same location would be pretty odd behaviour.
Typescript is a language, the tools should understand it as a language and it should be self-consistent.
The other thing that irritates me is that all that typing information is lost at runtime, when it could be very useful in a bunch of situations, but hey, you can't have everything.
In theory, even though this would probably never actually happen, could a browser add Deno to its build and use it to execute Typescript directly without having to rely on Javascript? Seems like a cool way to eventually get rid of the "baggage" that requires Typescript to not have Types at runtime and that sort of thing.
edit: And I realize that Deno currently doesn't maintain your types during runtime either, but in theory that would be fixable since it doesn't have to rely on Javascript.
TypeScript is deliberately not a language in the sense that you mean, and this is very much a load bearing part of the design and why it was successful. Many other languages have tried what you're suggesting, most infamously Dart, and all crashed aground on the problem of interoperating with the existing ecosystem.
TypeScript is best understood as a very advanced linter for JavaScript, not a separate language with its own semantics that happens to compile to JavaScript.
This has many consequences. For example, its type system is unsound to a profligate degree compared to most other typed languages. As a result, it is common for the type system to be wrong about the type of a variable, meaning that any runtime use of type information would have to also cope with being wrong, e.g. by inserting runtime type checks. Runtime type checking for structurally typed interfaces is heinously slow, as you have to type check every field of every transitively reachable interface.
I'm a long-time Node user and gave Deno a pretty close look recently. There's a ton to like, but the ecosystem of nodejs modules is hard to overcome, and I spent a lot of time fighting with the subtle differences between them instead of getting things done, whether it was me learning new patterns, having to search for good modules to solve a problem, or having to transpile node modules to deno. That had me in a bad place, but then the sandboxing (which was uniquely suited for my usecase) had a design challenge that blew up the fit for what I was doing. At that point, I gave up on it.
Given what they're doing with Deno Deploy, I almost wonder if the future of Deno is being a vendor-independent version of Cloudflare Workers.
Sharpest edge I've encountered is the very much WIP WebCrypto API support. In practical terms, this means things like signing/verifying JWTs is not very well supported: https://github.com/panva/jose/discussions/243
That said, the situation is improving rapidly, and I've been personally willing to bet that the support will be solid by the time I finish prototyping and need to start adding auth to my latest project.
Although I don't use Deno, I'm impressed by Deno's efforts to make the installation and deployment process as easy as possible.
For example, Deno is installed as a single runtime exe. Compare that to the hundreds of tiny files spewed out by installers from other interpreted languages.
And now we have this service to deploy Deno apps in the cloud. I have long felt that easy deployment of server-based web apps has been seriously neglected and developers underestimate how important it is (particulalry if your are creating a web app that you want to share or sell to others). It's no surprise that SaaS dominates today when the self-hosted alternative is so ludicrously complicated in comparison.
It's ironic that some of the most popular interpreted languages for web apps (like Python and Ruby) are the opposite of easy when it comes to server/cloud deployment.
I hope Deno's efforts in this space will encourage developers from other languages to tackle this sorely neglected problem.
Rust is not well suited for the same things as javascript / typescript / jsx / etc.
Also javascript and typescript are not well suited for compilers and dev tooling.
It shouldn't be seen as a negative that Deno is using rust in places where it really shines, which is a totally different use case than what deno is typically used for.
Other than browser based applications why would you choose JavaScript/TypeScript etc over Rust?
Developer tooling is not complicated and there is plenty of existing tools written in JavaScript, so it seems weird when they rule out there own language as not good enough. It should make anyone think twice before using Deno server side if it is not good enough for themselves.
The parts used to make your car were likely delivered to the factory by a semi truck, and not by another car. Should you buy a semi truck to go to the mall then, since even the carmaker thinks that cars aren't good enough? Obviously not. Different requirements are a thing.
Typescript/Deno is very ergonomic and presents a lower barrier for entry for writing web servers. However, it's a relatively large and slow to start runtime which makes it less than ideal for developer tools.
You should use the right tool for the job. Not every language is good for every job or every person.
I have done work on compiler, developer tooling and a lot of other stuff people would consider 'compilated' and working on those was far less complex than some business logic in API's I have had to work upon.
So if the experienced developers writing Deno are using Rust for type safety etc to catch their mistakes, then why would you trust yourself to use a less strict lanaguage on a likely more complex project?
My guess: Deno would perform too slowly which would hurt the UX. It would also be harder to maintain than a language like Rust. And of course Rust doesn't need a runtime.
Not everything is about performance. Deno lets developers be more efficient than Rust, and it is easier to hire developers that already knows TypeScript/Node.
The Python and Ruby interpreters and runtimes are written in C. Turns out that compiled systems languages are good choices for implementing other programming languages.
Maybe because Deno folks are pragmatics and not fanatics.
Rust is faster than V8. I'm not sure if ALL Deno tooling is written in Rust, but it makes sense to write, say, Typescript => JavaScript converter in Rust if it's 10-100x faster.
All that tells you is that if you want a very fast Typescript => JavaScript converter then you too should use Rust (or Go or C++) and not JavaScript executed by V8.
But writing a web app?
You're free to use Rust for that as well but millions of people chose nodejs instead and those are the people that might choose Deno in the future.
And indeed, you can see as a great example from the discussion on this thread how they eventually arrived at relying on Rust for most steps in the tsc toolchain: https://github.com/denoland/deno/issues/5432
The conclusion reached there is as you have stated: Rust is simply an order of magnitude faster in most cases.
IMO, one of the coolest features of Deno Deploy is that the deployment primitive is the humble URL, rather than being coupled to git or some git hosting provider.
You can simply give it a URL to a JS file and it will fetch all its dependencies and run it. They also offer an API for triggering deploys programmatically [1], which you can use to trigger deploys as a step in your CI pipeline for GitLab.
In fact, their GitHub integration is actually just listening for a webhook on new commits to the default branch, and the deploy is triggered using the raw.githubusercontent.com URL, so they don't have to waste time cloning the entire repository, which can save on the order of minutes for large repos. [2]
I'd imagine you could probably issue some access token in GitLab for Deno deploy to fetch the code. Deno deploy works with private _GitHub_ repos and I imagine that's basically what they do there.
Alternatively, you could also just set up a CI script to upload your code to a random s3 bucket, call the deploy API, then delete it if you want to minimize the chance of leaking.
It seems like a lot of trouble to run Javascript on the server. I still do not understand, why?
Deno is a huge step up from the enormous clusterfuck that is node.js with its broken design. But why use Javascript on the server? What is the point? Why use it as a general purpose programming language when it is so unsuited?
That is the thing I have never understood.
I use node.js extensively in scripting tests with Appium, I chose Node.js because (a) it seemed the the system the Appium people supported the best and (b) I needed to deal with my prejudice and actually use this system I was so dismissive of.
I am horrified that anybody would think, at this point in the history of computer languages, that Javascript is a suitable system for application development. I like the syntax, but the rest of it is, in the context of the competition, complete crap.
It has got to the point that people are writing financial software, that has the capacity to utterly ruin the user in a very real sense, in Javascript.
Just do not do it!! There are any number of better systems!!!
One reason would be to reuse existing libraries that are written in JavaScript. Since it's a popular language, there are lots of low-quality libraries, but also some higher-quality ones.
Ignoring tooling or pre-existing libraries (mainly because Deno is at an early stage of trying to boot a new JS/TS ecosystem), what makes Javascript that different as a language from, say Python or Ruby?
Besides minor syntax differences, the main differences to me seem to be that JS has a greater commitment to asynchronousness / async-await and has a better static typing solution through Typescript, which seem like solid wins for JS/TS.
Python is as bad a choice as Javascript for application development.
It is possible to develop large ad complex applications in any language, and people do. But modern languages provide the support a programmer needs to write reliable application software.
Python is suitable for scripting. Application development is not scripting.
There are so many better choices, just so many. Why choose such a poor tool for application development as a language designed fro scripting?
This is exactly how simple I want deploy configuration to be. All that's needed is the URL of the entry point. Then slightly fancier is the ability to specify a Github URL which auto-updates on pushes. All previous production deployments and even pre-production branches are accessible simultaneously from their own subdomains.
What is the usecase for Deno Deploy? Can you build full blown web apps with it? Or is it mostly for building small services, e.g. image transformation, CDN, etc.?
Could build full blown apps with it, but database are a problem. Calling to a central database from all over the world wouldn't work that well, but using something like DynamoDB Global Tables would work great. I'd assume Deno comes up with something like Cloudflare Workers KV as well, key-value stores with eventual consistency are possible with replicas all over the world.
Is there any open source engine similar to this or Cloudflare Workers where I could deploy JavaScript code to be run in isolates by a single process, optionally serving over HTTP? Trying to find a way to avoid the overhead with current open source FaaS solutions running arbitrary containers.
Osgood and Rusty-workers. They're not perfectly isolated to a high security standard such that you could deploy your own v8 workers SaaS. And they do have quirks and slow development. I haven't tested in production but if it's just your trusted apps wanting to exceed the cloudflare workers 30 scripts limit then both are wonderfully powerful solutions to put behind a https proxy.
I may be missing something, but how do you get this to work vscode? It couldn't find the type definitions. But other than that, deploying works just fine.
102 comments
[ 4.1 ms ] story [ 147 ms ] threadUPDATE: apparently CFW has been updated to support deploying as unbundled files since I last checked.
Workers, Sites, Workers KV, and now Durable Objects... it is much more than a JS API. I recently experimented with Durable Objects and they do make developing against a kv-database much simpler, even if it is limited while in beta. Our development is all-in Cloudflare atm, but we also look fondly at fly.io to move other workloads (over from AWS) that Cloudflare won't / can't support.
Then I learned about them after this pivot, I guess.
Things are looking up for serverless + edge computing, given 5G deployments are also gathering speed.
But your guess made sense :)
The site respects it.
I actually like writing with Deno, and think the module resolution in Deno is easier to understand (it's literally url or explictely what's written on the import). But it's just sad that the TS team is not moving the same direction with the module resoultion, because it splits the TS community to those who write Deno and those who write regular TS.
[1]: https://github.com/microsoft/TypeScript/issues/27481
That seems really annoying and is something I would expect to work. From the linked issue, does the problem go away if you make sure to always just import without the extension, and does it work both directions (deno TS->TS on JS and TS on JS->deno TS)?
The no extension shortcut as well as the index file shortcut have not been included in deno as a learning from node, which in my view is probably a wise move - keep it super simple by just specifying the exact filename.
I hope that either Deno implements some 'legacy' way of working that is compatible with the way the official typescript team do it, or the typescript team realize the error of their ways. I'm not sure if that's likely to happen short of a fork though.
I'd also like them to support importing .ts files and rewriting those imports to .js, but given that they've been clear about their position I think it's up to Deno to solve this without forking the ecosystem.
It's treating a language like it's a dumb file rewriter rather than something semantically meaningful. It would have made no sense for Deno to do the same thing - if you import a .js file from a remote server, you want that js file, if it doesn't exist automatically trying to load a .ts file from the same location would be pretty odd behaviour.
Typescript is a language, the tools should understand it as a language and it should be self-consistent.
The other thing that irritates me is that all that typing information is lost at runtime, when it could be very useful in a bunch of situations, but hey, you can't have everything.
edit: And I realize that Deno currently doesn't maintain your types during runtime either, but in theory that would be fixable since it doesn't have to rely on Javascript.
TypeScript is best understood as a very advanced linter for JavaScript, not a separate language with its own semantics that happens to compile to JavaScript.
This has many consequences. For example, its type system is unsound to a profligate degree compared to most other typed languages. As a result, it is common for the type system to be wrong about the type of a variable, meaning that any runtime use of type information would have to also cope with being wrong, e.g. by inserting runtime type checks. Runtime type checking for structurally typed interfaces is heinously slow, as you have to type check every field of every transitively reachable interface.
Given what they're doing with Deno Deploy, I almost wonder if the future of Deno is being a vendor-independent version of Cloudflare Workers.
That said, the situation is improving rapidly, and I've been personally willing to bet that the support will be solid by the time I finish prototyping and need to start adding auth to my latest project.
For example, Deno is installed as a single runtime exe. Compare that to the hundreds of tiny files spewed out by installers from other interpreted languages.
And now we have this service to deploy Deno apps in the cloud. I have long felt that easy deployment of server-based web apps has been seriously neglected and developers underestimate how important it is (particulalry if your are creating a web app that you want to share or sell to others). It's no surprise that SaaS dominates today when the self-hosted alternative is so ludicrously complicated in comparison.
It's ironic that some of the most popular interpreted languages for web apps (like Python and Ruby) are the opposite of easy when it comes to server/cloud deployment.
I hope Deno's efforts in this space will encourage developers from other languages to tackle this sorely neglected problem.
Also javascript and typescript are not well suited for compilers and dev tooling.
It shouldn't be seen as a negative that Deno is using rust in places where it really shines, which is a totally different use case than what deno is typically used for.
Developer tooling is not complicated and there is plenty of existing tools written in JavaScript, so it seems weird when they rule out there own language as not good enough. It should make anyone think twice before using Deno server side if it is not good enough for themselves.
Specifically, Typescript has a larger talent pool of experts to hire from. Although, I do hope that changes for Rust over the next 5 years.
You should use the right tool for the job. Not every language is good for every job or every person.
So if the experienced developers writing Deno are using Rust for type safety etc to catch their mistakes, then why would you trust yourself to use a less strict lanaguage on a likely more complex project?
If Deno wouldn't use itself because of reasons like this; then people should really think twice before using it to build anything server side.
If you're building on top of GCP services, there are official JS/TS libs but no official Rust libs.
If you're doing data science then the ecosystem of Python libraries (another interpreted language) will get you up and running much faster than Rust.
So yes, there are plenty of cases where using an interpreted language will be much more productive than limiting yourself to Rust.
Rust is faster than V8. I'm not sure if ALL Deno tooling is written in Rust, but it makes sense to write, say, Typescript => JavaScript converter in Rust if it's 10-100x faster.
All that tells you is that if you want a very fast Typescript => JavaScript converter then you too should use Rust (or Go or C++) and not JavaScript executed by V8.
But writing a web app?
You're free to use Rust for that as well but millions of people chose nodejs instead and those are the people that might choose Deno in the future.
The conclusion reached there is as you have stated: Rust is simply an order of magnitude faster in most cases.
You can simply give it a URL to a JS file and it will fetch all its dependencies and run it. They also offer an API for triggering deploys programmatically [1], which you can use to trigger deploys as a step in your CI pipeline for GitLab.
In fact, their GitHub integration is actually just listening for a webhook on new commits to the default branch, and the deploy is triggered using the raw.githubusercontent.com URL, so they don't have to waste time cloning the entire repository, which can save on the order of minutes for large repos. [2]
[1] https://github.com/denoland/deploy_feedback/issues/29#issuec...
[2] https://github.com/denoland/deploy_feedback/issues/29#issuec...
Alternatively, you could also just set up a CI script to upload your code to a random s3 bucket, call the deploy API, then delete it if you want to minimize the chance of leaking.
Deno is a huge step up from the enormous clusterfuck that is node.js with its broken design. But why use Javascript on the server? What is the point? Why use it as a general purpose programming language when it is so unsuited?
That is the thing I have never understood.
I use node.js extensively in scripting tests with Appium, I chose Node.js because (a) it seemed the the system the Appium people supported the best and (b) I needed to deal with my prejudice and actually use this system I was so dismissive of.
I am horrified that anybody would think, at this point in the history of computer languages, that Javascript is a suitable system for application development. I like the syntax, but the rest of it is, in the context of the competition, complete crap.
It has got to the point that people are writing financial software, that has the capacity to utterly ruin the user in a very real sense, in Javascript.
Just do not do it!! There are any number of better systems!!!
Besides minor syntax differences, the main differences to me seem to be that JS has a greater commitment to asynchronousness / async-await and has a better static typing solution through Typescript, which seem like solid wins for JS/TS.
Python is as bad a choice as Javascript for application development.
It is possible to develop large ad complex applications in any language, and people do. But modern languages provide the support a programmer needs to write reliable application software.
Python is suitable for scripting. Application development is not scripting.
There are so many better choices, just so many. Why choose such a poor tool for application development as a language designed fro scripting?
[1] https://github.com/IntrinsicLabs/osgood
[2] https://github.com/losfair/rusty-workers
Whatever happened to Java multi-tenant JVMs (aka MVM)? I always expected that to become the norm.
Did the flaming dumpster fire of JBoss, J2EE/Spring, internecine warfare between coinhabitant WARs sour everyone to the idea?