Deno is competing against Node.js, which is MIT-licensed. Deno is arguably better, but it would have to be _so much better_ to get people to even give it a second look if it was commercial.

One of the funniest/best business models out there is SQlite (https://sqlite.org/copyright.html). They give it away to the public domain, but some lawyers wrongly claim that that is not enough, so they will "sell" you a warranty asserting it is all public domain.

https://deno.com/deploy

or like Joyent

vc's will issue course correction very soon.

looks like a repeat of docker.

> I notice your script files are all pretty small, have you run into any upper limits on performance or scalability so far with this approach?

Not that I can tell. But if we need to, we can always do a minified bundle in production later on. So far it's just nice to not have to even think about it!

If you're on Windows like me, sadly there's still a nasty bug with path mismatches between the LSP server and the VSCode extension (https://github.com/denoland/deno/issues/9744) which requires reloading the window to fix spurious errors, but I'm sure it'll be fixed soon enough.

Vscode extension is maintained by the official team and will provide the best experience. There are unofficial plugins for sublime and Vim. They use LSP too and provide a comparable experience.

Each game server (a stand-alone Deno program that might or might not run on its own machine) connects to the switchboard over websocket and authenticates itself with an API key (since people will be able to make their own game servers).

When a player wants to join a server, they POST a request to the switchboard, which gives them back a token that they can send to the game server after establishing a WebSocket connection to it. The game server checks the token with the switchboard and gets back public user account info if it's valid.

Each game server's logic is currently single-threaded. I guess we might end up offloading some work to WebWorkers later on.

A server can publish some state info through the switchboard that will be broadcasted to other servers from the same user. This is used to show player counts in game rooms from a lobby, things like that.

I run the whole thing on a couple cheap Scaleway servers, with Cloudflare in front (no AWS nor containers or anything of the sort). My previous platform, built with Node.js (https://jklm.fun) is able to sustain at least 2000 concurrent players like that, though admittedly those are board-like games which are not very demanding, unlike the games for Sparks.land which will be more fully-fledged... so we'll see how that holds up!

I think that lets you deploy to things like edge devices that don't have a hard drive, and even more ephemeral environments.

As an outsider who likes to lurk, I have the impression both ECMA and Node committees are stuck in the "we're nice and therefore right" field.

They made technological choices that broke the platform (eg. require vs import). It took ages of pain to innovate on things that matter (eg. promises, async)

I wish Deno the best, but I'll just try to stay away from JS from now on (same as I've been avoiding Python after the 2to3 migration).

Deno is more of an ecosystem reboot than a fork, I would think.

When you create something in a field that already has other entrants, that's a completely different thing from trying to unify all the other entrants, and ending up just creating another also-ran.

There's nothing wrong with identifying an area that you think you can contribute something innovative to and building something opinionated for it.

Although I would look for similar examples elsewhere to understand where it is all headed. And one of those could be the rise and adoption of the JVM. There are a bunch of old dependencies, multiple repositories (compared to just one popular npmjs), a couple of build tools (ant, maven, gradle) compared to npm, yarn, then multiple languages (invented for somewhat similar reasons as Typescript). One thing is sure that the dependencies stay somewhere for-almost-ever, and all else kind of evolves around it.

It seems that the main problem at the moment is the developer (me, you, everyone) who instead of writing 20 lines of code uses a dependency that has 10 other transient ones. You cannot fix it but rather challenge those situations at work and reduce the tech debt for good. Maybe there should be a build tool that throws errors depending on the amount of dependencies. Maybe there should be a frontend framework which will only need 10 dependencies for the helloworld instead of 1500; otherwise we kind of think that if a boilerplate template has 1500 deps then surely adding another 100 will not make much harm.

Its value is less about the existing dependency tree of libraries and more about how many apps directly depend on libraries that are npm-hosted.

There are many 200+ kloc apps out there making millions/yr each that deeply depend on libraries and frameworks hosted in npm.

I generally think the NPM ecosystem is pretty cool, but I have noticed that even simple stuff like creating a RESTful service doesn't seem to have stablised in the ways I would have expected given node's target audience, and you end up writing a lot of the boilerplate yourself. Hopefully this will result in hundreds of replies telling me how I should be doing it, but even the fact that it's not trivial to find that out is a sign of a fragmented ecosystem.

And don't do anything. I'm amazed by how often I read the source for a package I'm interested in, only to find it's about 10 or 20 lines of code.

The convenience of adding a package means that if you're not sure how to do something, you can easily just add a package to do it rather than figuring out how to do it yourself. A lot of the time, you can just read the source and adapt it rather than installing the package.

I think this shows the lack of willingness to write a vanilla, all-compatible javascript. Also it seems people use new features without understanding how those get compiled to a lower version.

Sorry when I meant vanilla I did not mean ES9.

Maybe but who cares when your code does not execute instantly on Lambda and requires you to use GaalVM to convert bytecode to binary. Besides you have a lot of people who would say Kotlin is better.

Javascript, like Python wins here. Well Javascript kind of wins because it is interpreted but devs do not use it directly but rather with a bundler/compiler.

> Plus, aren't Deno libs compatible with Node libs

Not really, if your dependency relies on say `https` module then it'll not work on Deno as it does not have it. And in the case of Deno modules, they are not on `npm` to begin with but even if you import them then they are written in Typescript.

The fact that URL-based imports make you uncomfortable is good. Let that discomfort guide you to adopt some extra security measures to protect yourself from third-party dependency exploits

Also: Nobody prevents you from using a package manager anyway. Just because you can use urls in imports doesn't mean you have to. But it is very convenient that deno downloads exactly the code that is imported. A package manager will always just throw everything at you. Some packages in node.js try to fix this by splitting the project into submodules like @babel/core, @babel/env, .... But that made installing dependencies worse. Just let deno figure out what is required is way more elegant IMO.

Deno caches everything offline and only reloads if you use --reload flag.

I would recommend going through the manual to learn more about deno workflow.

https://deno.land/manual

- Typescript as a first class citizen: Agreed, it's not hard to get TS set up in Node, and it's a "one and done" cost.

- An actual `window` global with familiar browser APIs: I've never needed or wanted this, though I could see how the server-side rendering crowd could benefit, but I still have to believe there would by necessity be enough difference between the browser-based window that implementing SSR is still non-trivial.

- Sandboxing w/ permissions: I honestly think this is going to be useless. As you stated, if you're really running untrusted code better to rely on process permissions. This actually reminds me of many of the overly complicated security/permissions architecture in the Java SecurityManager stuff that I rarely if ever actually saw being used.

- URL-based imports (no need for NPM): NPM certainly has its warts, but I think a lot of Deno supporters woefully underestimate how most server-side JS developers love having a single primary global package repo.

- Bundling into self-contained binaries: Again, this is nice, but also gets a "Meh, I don't really care" from me.

- Things like top-level-await which Node.js still treats as experimental: Once you learn how to do an IIFE who really cares?

- Better-designed APIs than the Node standard lib (esp. when it comes to promises instead of callbacks): Again, a minor nice-to-have, especially with Util.promisify.

- it makes a ton of sense if you don't want to maintain two different versions of the same library. With WASM there is zero need for Node native modules anymore, so there is no need to have platform specific idiosyncrasies that go beyond Web APS's. Is the fact that it's called "window" a favourite of mine? Certainly not, but when you try to get a library running that you really need, that was originally written for the browser or vice versa, you don't care what the thing is called, as long as it's backwards compatible.

- defense in depth, multiple sandboxes are better than one

- this has to do with the window point, it's a lot easier to make code cross platform compatible if you only have to reference publicly accessible http endpoints

- maybe that's not interesting for you, but I've had to deliver command line tools as binary, and I'm super duper happy that I could do so in JS, the security I gain from controlling the runtime version is also much better than what I'd get from that being the users responsibility, besides that fact that not knowing exactly which runtime your code is gonna end up on is also a big source of security vulnerabilities

-

But what I’d like to question is why the idea of parsing everything is considered bad. Semver itself, while miles ahead of what came before, is still just lies we tell the compiler.

You can never actually rely on the fact that a miner fix will not be a breaking change and the like.

Rich Hicky had a great talk on the subject of imports and breakage, and the conclusion that I agree with was to actually load and check every function in all the libraries you use, so that if there is an incompatible change you will not be none the wiser.

I’m glad people are trying to experiment here, as package management is far from a solved problem and issues with it cause sweat, tears and blood to most devs during their careers.

Depends on your point of view. With TypeScript being built in, you don't have to think about using tsc or whatever version of TypeScript you have. It's just what version of Deno you use. If someone doesn't like that, then they still can have the option of using TypeScript by itself.

> Node.js has a `global` global object and the only API I would understand having in common with the `window` object is the `fetch()` API.

It also supports `addEventListener`, which is commonly used by browser code on the window object.

Just the existence of something defined as `window` makes more sense than a `global` which never existed in browsers in the first place.

> Sandboxing is so basic that any large project will have to enable all permissions.

That's pretty dismissive. Why should an app that doesn't interact with the file system be allowed to write or even read from it? I don't know how this feature can be considered a drawback. Don't like it? Don't use it. I don't see how it detracts objectively from Deno.

> I would consider this a disadvantage.

Then you can still use NPM. Others of us get the option to just import packages from a URL instead of publishing it to a central repository.

> Again, I would say that this is rarely useful in a world where a lot of operations use container technology.

Why? Building Docker images requires extra software, Linux images, time spent running apt-get or apk, time spent downloading and installing your runtime of choice, and so forth. Having Deno build a binary can give you a bit of a shortcut in that you have one tool for running and bundling code, and you don't need to deal with as many OS-level nuances to do so. Docker and k8s are there for anyone who needs something beyond that.

> This is trivially solved by anonymous self-executing functions

That's your opinion. Just promise me you don't go on to say that JS is a bad language, because people keep saying that yet are opposed to reducing complexity they consider "trivial". If using IIFE for the mere purpose of accessing syntax makes more sense to you than making `await` syntax available, then I really don't know what to tell you. What exactly is the argument for not implementing this feature besides "all you have to do is type some extra characters", to loosely paraphrase you.

> I think that this is the strongest advantage, however I would argue that this is not a reason to start a completely new backend platform. Also, I think that it might be a disadvantage in some high performance scenarios because Promises are much, much slower than callbacks currently.

> I think that this is the strongest advantage, however I would argue that this is not a reason to start a completely new backend platform. Also, I think that it might be a disadvantage in some high performance scenarios because Promises are much, much slower than callbacks currently.

I honestly have to wonder if you are joking. This is exactly why people invent new backends, new libraries, and new languages.

My only response to your point about Promises is that perhaps one shouldn't be using JavaScript if Promises are that much of a bottleneck. What you're saying is totally valid, though.

As a glaring strawman if you expose eval to wasm it will not help you.

Deno's sandbox will allow you to crate a dedicated worker with no network/disk access to handle sensitive informations, or to force your application to use a specific worker as a proxy (by making it the only thing with network acess)

https://deno.com/deploy

I still find it strange that there is no mention of it in the post...

I think the point being made here is that it will be easier to create purpose-built runtimes that only provide needed bindings, making them more secure and possibly also more performant?

JS/TS as languages are here to stay, so let's give them the best possible ecosystem.

Then what are all these modules, if not a standard library? https://nodejs.org/api

What's a "standard" for you? Whatever definition, I think it implies there are > 1 implementations of it.

Node.js is based on CommonJS APIs, an initiative lead and implemented by earlier server-side JavaScript (SSJS) runtimes at the time such as v8cgi/TeaJs, Helma, etc. until Node.js dominated SSJS around 2011. Remember, SSJS is as old as the hills, starting 1996/7 with Netscape's LifeWire, and arguably has seen even longer use than Java as a mainstream server-side language.

Also not a "standard" in the above sense is TypeScript.

As to "standard library", the core packages on npmjs plus package.json are the standard library of Node.js on top of core Node.js APIs, and were developed in that spirit.

.NET BCL is the Base Class Library. Outside of a few classes in it that are fundamental to the runtime (e.g. Object, String, Array), it's not actually required for cross-language interop on .NET platforms. E.g. if you have two different C compilers both outputting CIL, they can interop just fine without any objects in the picture. WebAssembly interop is really more like that, and doesn't have the high-level object model layer that .NET also has (and which is used in practice).

Fact Check: False

LuaJIT is fastest than all JavaScript JIT implementations in existence.

And all Servo developers according to: https://paulrouget.com/bye_mozilla.html

> "A language empowering everyone, but especially folks who thought that systems programming wasn’t for them.”

No, they figured out a way to delete that problem.

VC money isn't a gift. It's a loan.

Chrome vs chromium etc

[0] https://deno.land/artwork

It is said that they can get away with having it as Public Domain because a key part of their business is SQLite's reliability which is asserted by their large and closed source test codebase.

                 Deno are in overlapy    
                                         
                     |                   
                     |                   
                     |     /---          
          /--- --    |   /-    \---      
      /---       \-- | /- Best      |    
     | Coders       \|-  coders      \   
     /  passionate /-|\--     in     |   
    |  about      -      \-  world    \  
     \ democratization -              |  
      | of           -\               -  
      \ technology -/  -\           -/   
       |---\     -/      -\       -/     
            ----           -\   -/       
                             --          

There is a case to be made for programmers being at least familiar with Unix utilities and shell scripting so that they can unlock the superpowers described in that anecdote.

However, I largely agree with your sentiment - I pretty much do all of my scripting in JavaScript and Python and would not be particularly happy to have to deal with a large bash script.

That was what propelled Atom and VSCode.

What you said is valid of course when you look at Slack and such, but you ommited most important cross-platform target.

Your app can run on Windows/Linux/Mac .. and the Web.

SwiftUI is new.

Flutter is new.

Both have taken birth recently and have huge investments and usage.

Are you sure? I started building a desktop application recently. As much as I abhor Electron and refuse to touch anything built on top of it, there basically wasn't any other choice due to the absolutely massive amounts of libraries written for the web. I threw a couple of them in and it saved me at least 90% of work compared to what I would have to do if I'd chosen Qt (or anything else native). Would I rather spend a week and have something to show to my client, or roll up my sleeves and re-implement everything myself (which would take about half a year before I'd have anything working at all)?

(For the record, I didn't downvote you. I consider it a shitty practice to downvote somebody for their opinion, without even replying.)

My take from reading the blog post was that the Deno Company's entire thesis is that the developer community will increasingly be moving away from these older abstractions and towards web-based abstractions, and Deno is positioning itself to fuel that migration. GP's comment addresses this directly; it seems rather on-topic to my reading.

... until the VCs change their mind or AWS uses our code to make more money than we do.