Deno Deploy Beta 2
deno.com
deno.com
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.
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.
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.
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.
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.
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.
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.
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.
UPDATE: apparently CFW has been updated to support deploying as unbundled files since I last checked.
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.
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.
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?
The site respects it.
But your guess made sense :)
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.
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.
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?