▲ 608 points
back
382 comments
From the post:
> For example, it is integrated with GitHub in such a way that on every push it will provision a new server running specifically that code, deployed to the edge, worldwide, and persisted permanently. Want to access the code your app was running a month ago at commit f7c5e19? It will be served up instantly at a moment's notice. It costs you nothing to have that bit of JavaScript responding to requests indefinitely.
These things sound great and almost a dream come true but how realistic is it to consider being able to do this in most web apps? As soon as your application uses a SQL database and you have database migrations then you're out of luck because a commit from 2 months ago might expect a different database schema than the current version and while it's common to migrate in backwards compatible ways, the backwards compatibility is usually only temporary until you finish migrating from A to B.
Long story short, this sounds cool but in practice is really only applicable to static sites or dynamic sites where you plan to keep a version of your database and code base backwards compatible from day 1 to current day (which I've never seen done in any app developed over the last ~20 years of freelancing for many different companies). The post mentions "The open source Deno runtime shows how clean and productive a modern, batteries-included, programming environment can be" so it sounds like they expect you'll be running database backed apps and not only static sites.
I hope that app isn't actually running on a server somewhere for each commit indefinitely, and that it's moreso intended for serverless setups, like the Netlift edge functions they mentioned...
We could do with some more consciousness for energy & compute resources in this industry, as decoupled it may be from the real world, clicking the button to deploy an EC2 instance somewhere does use real power and will contribute to hardware wear.
I'd spawn a new DB for that instance too. It can still go a long way to give you a look at how your application worked in the past.
There are ways to version your database schema. Then you just need to make sure your code version is tied to your database version.
> The post mentions "The open source Deno runtime shows how clean and productive a modern, batteries-included, programming environment can be" so it sounds like they expect you'll be running database backed apps and not only static sites.
It suggests you'll be running a datastore, not necessarily an SQL database (the most overrated technology in existence IMO, especially for web apps where essentially none of its strong points are relevant). Storing old data as-is and migrating on read is definitely doable, and you can keep backwards compatibility to day 1 that way relatively easily. I worked on a system much like the one from "An oral history of Bank Python" that did exactly that, and had been doing so on a large scale for around a decade. Having a better-integrated datastore that can present multiple views of the same data is another way to achieve that, if you want to keep the migration out of the "application" code.
Interesting how this will play out. It's an ambitious goal to consolidate client side and server side javascript ecosystems which is quite fragmented today. On the other hand, this may only increase fragmentation further by introducing another target to develop for (wait for transpilers that can automagically convert between deno and node code). I will always look at javascript as this problem kid that cannot get its shit together in life, perpetually chasing the romance of utopia.
There is already a system for building a NPM node package from a Deno package, called dnt (deno to node). It's maintained by some Deno team members. Here's a blog post they wrote about porting "Oak" (a deno HTTP server framework) to Node: https://deno.com/blog/dnt-oak
The nice thing about Deno conceptually, is that it's much more similar to the browser platform than node is. It uses ES6 only, has things like `fetch` built-in by default, and generally follows browser standards around interfaces like Request, Response, etc. Instead of needing a complicated build process to make Node code work on the browser, now we have a complicated build process to make Deno/Browser code work on Node. ¯\_(ツ)_/¯
Deno code is really close to browser code. If you have ESM code that runs in the browser and doesn't need access to the DOM then it's a good bet it'll run on Deno, and vice versa. They use web standards for most things, and anything proprietary is put on the Deno global object. For standards that need adapting to work outside the browser, they're working with Cloudflare and others on WinterCG, which is defining a common baseline for these non-browser runtimes.
there is a group formed including Deno that will work together to try to maintain standards + compatibility
I do think Deno is a step in the right direction, by reducing the need for transpiler steps (e.g. TS to JS) and embracing JS standards instead of building their own (which is what NodeJS did, but this was in a time when JS had no standard for dependencies or per-file isolation).
It's what I kind of love about it though - the JS ecosystem is Neverland.
Deno overstates the problem it is intended to solve because its founders needed to justify achieving funding by being developer-famous.
Let's say a company were to adopt this tech over Node, well, it seems like it would be slightly better, but probably not much of a game-changer.
I'll leave it to y'all to talk about what tech is truly interesting as I don't want to seem ideological/biased, I just don't see how Deno is particularly notable.
The rise of JavaScript-only clouds intended as "defacto" solutions for web development scares the hell out of me. Monocultures are dangerous. At least in the early Node era, it sat alongside all the other flavors of server infra out there with a near-infinite variety of languages, platforms, OSes. Now we're being told that the future of web development is…Deno? That's it? One tool? One language? One platform?
Not the web I intend to build and participate in, I can tell you that right now.
> Early in cloud computing, virtual machines were the compute abstraction […]
This is funny to me because serverless sounds to me like the return of PHP (etc) shared hosting. What's old is new again?
This question is going to make me sound like a jerk, but why do you want to write your back-end in JS? Deno looks like a great improvement over node.js, but I don't feel compelled to use it. It seems like people jumped to node based on some performance promises that didn't really pay off (IMO). And since then, we have newer options like Rust, Go, and Elixir as performant back-end options, and even older choices like Ruby and Python have continued to improve.
Seems like the standard arguments would be that developers already know JS, and that you can share code with the browser. I don't find these highly compelling.
EDIT: I haven't learned typescript yet, based on the replies, it seems like that could be a good reason to choose it. Seems like a nice middle-ground between typical scripting and compiled languages.
+ People get paid, hopefully a few even get big $.
- Investors want unicorn returns.
Good luck!
The color changing on this page gives me a migraine:
I like Deno in principle, but I'd love to see how Slack, Github and Netlify are using it.
I don't know if marketing was involved with using the term 'isolate' or not but if they are isolates as described by companies such as Cloudflare and Google, it might help to speak a bit more about the actual implementation at the infrastructure level.
Isolates are a really interesting approach to deal with the inherent nature of scripting languages to deal with the lack of threads as most scripting languages are inherently single-thread/single-process. If you have a 2000 line ruby class named 'Dog' you can easily overwrite it with the number 42. This is awesome on one hand, however it makes scaling the vm through the use of threads too difficult as threads will share the heap and then you have to put mutexes on everything removing any performance gain you would have normally gotten. Instead the end-user has to pre-fork a ton of app vms with their own large memory consumption, their own network connections, etc and stick it behind a load balancer which is not ideal to their compiled, statically typed cousins and frankly I just don't see the future allowing these languages as we continuously march towards larger and large core count systems. I'd personally like to see more of the scripting languages adopt this construct as it addresses a really hard problem these types of languages have to deal with and makes scaling them a lot easier. To this note - if you are working on this in any of the scripting languages please let me know because it's something I'd like to help push forward.
Having said that, they should never be considered as a multi-tenant (N customers) isolation 'security' barrier. They are there for scaling not security.
I’ve never been interested in JS as I mostly work in C++ but the ease of install/use of Deno over Node made me actually want to try it. It’s nice to have access to a bunch of web tech with a single binary. Very excited to see where this project goes!
> Cold start (time to first response, ms) O(100) O(1000) O(10000)
Ugh, that's not how big O notation works.
I played with an early version of Deno a few years back and it was already way more comfortable to use than node. It's a real counterexample to second-system syndrome.
The only reason I didn't continue was a lack of ARM support.
It will be interesting to see if Deno can provide the level of productivity improvement node.js delivered (was supposed to deliver? continues to deliver?).
It's one thing for it to claim supremacy over node, but can it attract the TJ Holowaychuk's of the world and truly generate a full ecosystem.
Interesting raise. I leave the front marketing page of Deno Deploy open in my browser for a few moments and I get the ubiquitous "This webpage is using significant energy. Closing it may improve the responsiveness of your Mac."
Says it all about the state of the JavaScript ecosystem really.
Deno deploy seems cool and all, but I haven't seen any great rationale for using their service over say Cloudflare Workers.
> Cold start (time to first response, ms) O(100) O(1000) O(10000)
I think ~100 ~1000 ~10000 would be clearer than using the big O notation, since this has nothing to do with fuinctions.
Comments are a bit negative. I for one think they are onto something here. Surprised it's only 21M. I would have expected in these market conditions to beef up more for the next 2-3 years.
I find Deno very interesting. It's written in Rust by Mozilla, executing TypeScript by Microsoft on V8 engine by Google, and its name is sorted version of Node.
That aside, I have been very productive with Deno. Web Standards are going in the right direction, and Deno helps using them easy. The Request/Response model with streams make a lot of sense, and provides lots of way to optimize.
I understand performance is not the best compared to Elixir or Rust, but the ability to quickly download Deno, run a web server, import modules through URL, and start hacking and testing, then bundle into a cross-platform executable is a life-saver. No installation step, no build tool in between.
As a Deno fan I was surprised to learn that the free tier for Deno Deploy includes 100k requests per day and 100GB of bandwidth monthly. I know I'll be trying it out now.
Does this mean we can finally get a REPL where a file can be loaded, modified, then reloaded, without having to restart the whole thing?
Seriously my biggest pet peeve with both deno and node.js. In every other REPL I've used this is basic functionality. When I talk about this to JS people they look at me like I'm from mars.
Running little processes on the server without the VM/K8s expensive abstraction has a lot of potential. I'm sure Deno will do great! At least this way of deploying web apps has a lot of potential.
> JavaScript is unlike other programming languages in that it is the universal scripting language. Its universality combined with security from the browser and its raw performance lends itself to a solution for these problems, at least for a certain common class of applications.
You want to sell Javascript based solutions, go for it. But don’t push this nonsense like “No language like Javascript”. The only reason Javascript has a wider adoption than others is because it’s forced upon us. Browsers understand just Javascript to display web pages, period. Doesn’t make it the best because of that reason. I say this as an experienced IT consultant managing a wide array of projects over my career across industries.
You know what usually bites me when I touch code that has not been touched for 6 months (usually a late contract renewal)? It’s not my Elixir or Ruby code that’s running on autopilot. It’s the stupid Javascript with its Node based dependencies all failing randomly in each direction just because some developer used a library for something trivial they could have written themselves or super likely because Babel or Webpack decided to change their config files so my entire JS pipeline breaks. JS is a language full of patchwork and its entire ecosystem, more so - it certainly has gotten better over the years. If it works for you, then great. But it’s a far cry from a “one solution for everything that’s better than everything else”.
Personally, I use Coffeescript. It has been a breeze from all aspects.
Where's the angle for the investors - what will Deno do to produce the returns necessary for such a high amount? I thought Deno would be the eradication of Node and bring stability to Javascript. From the outside it seems to be firmly on it's way to being just another Zeit/Vercel. :(
A lot of marketing fluff and exaggerations but the core of is very interesting. Combine this with a real serverless Postgres like https://neon.tech/ and this could indeed change a lot the way mainstream apps are build an deployed.
Deno sounds like a powerful runtime, but what is there to sell?
I won’t build on anything that isn’t permissively licensed. They can’t charge for anything without license protection.
Somebody doesn't understand O notation.
I would love to try Deno deploy, but right now there are two deal breakers for me:
- why is the CPU time limit so low? 10ms (or even 50ms in Pro version) seems a limit very easy to blow for any sufficiently complex app
- why is there no data storage offering available? I'm not sure I see the point of edge deploys while data is still only accessible through a centralized database server. Having a way to deploy a sqlite database next to the running app seems like an easy way to realize the gains of edge deployments.
I'm currently trying Fly.io which seems to cover both of these issues, but I wonder if I'm missing something here - or perhaps this service is intended for very different use cases.
Is Deno going to be the first runtime environment to IPO?
I'm not deep in Node world but I use it and see it being used, who is using Deno out there? Have there been some notable/major ship jumps? Or is it not that kind of situation (perception from when it came on the scene is that's exactly what it is, constantly trying to woo Node devs over). And also there's alot of recognizable brand competition out there from things like Cloudflare, Netlify (but they're an investor in this?), Vercel on fire the last year or two, and not to mention the big FAANG types. Again, who's using this?
Got a 502, oopsies
What does O(100) mean in the comparison table?
I think it's a good opportunity for Meteor, which is a very interesting framework but with some technical debt, to jump ship on Deno and start fresh again. Maybe they could try replacing their in-house synchronization mechanisms by managed services such as AppSync. Randomly wondering :)
"JavaScript is unlike other programming languages in that it is the universal scripting language."
WTF? How is that even slightly true?
C is the universal scripting language, in exactly the same way.
Nothing happening in this space makes any sense to me.
heh, I knew for sure Deno would be successful from the first moment it appeared on HN and people here were critical of it.
My rule of: The more HN criticizes it, the more likely it succeeded, still rings true.
The business end here is Deno Deploy - a heroku-like. That's what the "startup" behind the funding is. The tech is in service of that.
JavaScript is popular because of browsers not because it is in any way a good language. Name another popular language with half its quirks.
WASM will eventually spell the end of JavaScript’s hegemony as it becomes easier to build web apps in other languages. So good luck Deno. You’re betting on a sinking ship.
Wow I had a play, within 30 seconds I had deployed their hello world. Checked devtools and it took between 30-100ms (I am not on a great internet connection, but this proves it is somewhere near me globally!).
Also loving .deno.dev as a fairly nice top level domain for a blog. E.g. johnsmith.deno.dev.
I read half and thought "how did this get any funding".
Who validated this idea and with what measures?