Most popular, I can agree. Fastest, & only one with industrial standardization process? Have they met Erlang?

edit: you have to be kidding me, downvoted to oblivion for an honest observation. Sorry I hurt javascript's feelings.

Well, I wish they would stop using it period, but at least in the browser it makes some sense.

Edit: to be clear, I have no beef with Typescript, Dart, Clojurescript, and the many other languages that compile into JS. It's JS itself I have issue with. I feel like it gives too much flexibility to young programmers to screw things up. There don't seem to be enough safeguards or training wheels. On large projects its my nightmare.

I know this might be hard to see, but Rust is actually in the same domain. It is also, among other things, enabling product/frontend/web engineers to build backend/native/browser-less applications.

I'd bet Rust will be more successful here, especially given its amazing ability to change itself and innovate.

Many developers, I think, don’t look past web-first abstraction layers.

I can’t tell you how many times I’ve seen CLI tools which are huge chunks of node wrapping a thin bash command. They are multiple files, orders of magnitude larger than they need to be, and require external dependencies because these developers are fixated on their proverbial hammer.

It uses comet-stream instead of WebSockets.

But it's fully "joint" parallel on all cores.

In my opinion, the best part of node is (or was) that it didn't adhere to the browser APIs. That brought in some fresh air, and gave us buffers, native bindings, streams etc.

Ryan and the team should be capturing some of the value produced by their creation. And because of Deno's a developer tool, it's actually capturing the far minor part of the whole value and enable a much bigger value creation!

Trying to sell something based on FUD is always a bad sign.

However, I personally would prefer Go or .NET Core for my backend any day. We need to wait and see where it's going ...

Good luck and success anyway!

My sense is that GPL3 gets a ton of criticism on HN, but isn't it the perfect defense against freeloaders?

* license the code for proprietary use in your stack * use GPL3 if you have a non-commercial use, and are willing to accept the requirement to open source your own code.

I don't understand why this option isn't used more by open source projects that want to be able to fund themselves.

Can anyone explain? (Even better if there are examples / case studies)

Also, it's nice that they're using Tokio for the HTTP server instead of a JS implementation (from what I understand). I want to see Deno near the top of the TechEmpower benchmarks.

Haha, this made me laugh hard, stopped reading

Every time I read something like this I realize how much in the minority I am. I am not a web developer. I have never written JavaScript before in my life. I hate working with “web-first abstractions”. I feel like it is just massive bloat on top of true native application. But given the popularity of things like electron, react-native, Node, and Deno I don’t speak for the majority.

And the thing is, I don’t know if I just learned web dev if I would love this new approach to software that is eating the world and I would “get it”. Or if it just exists because JavaScript developers don’t want to learn something new.

Oh I didn't know (or forgot about) this! Super interesting. I love that strategy.

That's competition at its best. Don't assert any control over someone else, but do keep a few secrets to yourself so people know to come to you for the best stuff.

Edit: There is more to it, of course. It is also entry into a somewhat exclusive network of future investors + customers if you choose your VCs wisely.

It doesn't work if you need extensive access to local hardware. But if you're mainly on the network anyway to operate, it's very frictionless and relatively lean.

With my last app, the network asset bundle is about 2MB, uses only ~11 MB on disk on my Mac and ~25MB RAM when running.

I don’t disagree with you about why people use Electron. There’s a positive feedback loop around ecosystem sizes. The bigger the platform the more devs use it the more tools they make the more libraries are made the more it’s the easiest way to do X the more applications are written for it the bigger the platform gets.

Anything you can offer to a large group of developers that lets them extend their existing high skill level to new domains where they would otherwise be novices is very likely to be adopted.

JS has warts, undoubtedly so. But I try to approach it like I would Clojure and it makes the experience much better for me. I think JS has the bones of a Lisp if you're willing to look for them. Sure it doesn't have macros or decent conditional expressions or immutability but using something like Ramda gets you some of the way there. And there are proposals for pattern matching and immutable data structures though they are fairly far off.

I think JS is at its worst when people try to code it as poor version of Java or C#. I have a bit of a love hate relationship with Typescript for this reason. Some aspects of its type system are great like being able to make a union out of anything, I wish OCaml had that. But I think denying Javascript's inherent dynamic nature is a mistake.

Overall I've learned to ignore its worst parts and just focus on what made it good from the start, being a weird cousin of Scheme that runs in the browser.

JavaScript consistently ranks as one of the most loved languages in Stack Overflow surveys...

I find plenty of counter-examples of this point on HN too - engineers who have worked across many different stacks and rank JS/TS as one of the best dev experiences they've had (there is one such comment in this comment tree)

Anecdotally, I feel as if pre-ES6 a lot of the complaints you read online were from users of the language. Nowadays, it's as if most of the complaints are from people who don't use it.

I think there is something to be said about refusing to learn anything but JS, as knowing different languages can be a boon for an engineer, but I believe it's an excellent tool to have in one's belt nowadays.

I’m okay writing JavaScript as long as I don’t have to spend all day every day writing it.

I love using it as a "one-off" scripting language which usually involves interaction with some sort of an existing codebase.

I'm also fairly confident in doing any sort of backend-centric work, in which existing components most likely exist as well (or at the very least something POC-esque to iterate on or scaffold from).

With that said I believe most of these difficulties stem from most of my experience being backend-centric roles, so when it comes time to implement a frontend from scratch, I become unsure of where to start. The sheer amount of technologies available and vast amount of flexibility is also very intimidating.

However I've been slowly but surely immersing myself in the stack(s), and have found that much like my experience with CSS the best way to learn is to simply do it-- making mistakes and learning from them in my exploratory learning.

I do appreciate what you said about build pipelines and feel much better about my current projects :-)

quick edit: I think my lack of experience in functional programming is another factor here, however Typescript's object orientated style is very attractive.

So let me make clear here, if I ever start a company based on open source principles and it looks like I am going to get squeezed out of business by Amazon if I keep sticking to those principles I will probably abandon those principles (unless I'm already a billionaire and have something really cool I want to work on anyway) because damned if I would let Amazon beat me. The chance of my abandoning those principles will correlate closely to how bad my finances will be after losing out to Amazon.

On the other hand if I build up a big enough company and start making money off of using open source technologies as a service for other technologists I hope I would support the open source projects from which I was benefiting.

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

As someone who uses Node but doesn't closely follow the steering/proposals side of things, I can't say I had this impression of that process..

Is Node really that bad compared to how JS/ES is innovated on in the browser?

There's a semi-joke that goes "all companies are software companies now" but there is a lot of truth to that..

It comes to down where a company wants to put its effort.

Do you want to own/operate/maintain all your infrastructure and services (and all the challenges that come with retaining scarce talent that is capable of that work), requiring you to substantially invest in an area that is not core to your business?

Or do you want to spend that money (and let's be real, less money too) to pay a trusted third party provider who will do a better job than you would anyways, because that's their area of expertise?

Then you can focus your (likely limited) resources on delivering value to your business instead.

So if you're up for it, you can still roll your own deployment infrastructure and tailor your builds as needed etc.. and support all of that internally.

Or you can pay Deno to handle it for you and you can focus on building your apps.

Really what I mean by 'standard' in this context is a batteries-included experience for most day-to-day programming problems.

I can appreciate the minimalist view where every project selects a core set of libraries for the given challenge. On the other hand, a core set of libraries that are good enough for most things just reduces decision fatigue, and makes it easier to just code.

Mozilla continues to be interested in Rust even though they did that, they’re a founding sponsor of the Rust Foundation, for example, and are continuing to use Rust even though they do not employ people to work on the language itself.

It's the same issue with Netlify, Vercel etc. where their edge is very different to say Akamai, Cloudflare or Fastly's edge.

edit: but at the same time now I realize why people are attracted to it, they are desirable features wether or not they actually make sense.

Not all jurisdictions of the world legally recognize the concept of 'public domain'.

It's essentially the route Java is taking with graal/truffle - allowing heterogeneous mix of languages to be compiled and optimized.

Why not allow typescript to use Fortran numeric libraries via wasm?

It compiles, and then caches the output I assume?

That's a really cool use case I hadn't thought of..

https://guides.rubyonrails.org/v4.2/command_line.html#custom... https://docs.djangoproject.com/en/3.1/howto/custom-managemen...

I guess though, the people in the Ruby / Django community are actually building projects and the node community are padding their resume with new npm packages.

I hope deno or dart can make the JS world better, but I suspect they will both end up just making it more fragmented. One thing I really like on flutter / dart is they do try to rate / otherwise rank / categorize support of their packages aside from stars https://pub.dev/packages?sort=popularity / downloads which are easy to manipulate. IMO deno should do this as well or let someone willing to takeover as the primary package manager https://deno.land/x/lodash@4.17.19

Golden phrase to describe a lot of folks. If I were to translate, it's behaving pleasantly and politely in order to justify poor decisions.

I cannot understand the benefit of this scheme honestly. I would have preferred they fix something npm is lacking, like adding the ability to sign packages

1. people will import packages willy-nilly and not think about what they are doing and it becomes harder to understand WHAT they imported (the why becomes more clear imo), I am aware that is very much so JS culture today but I also believe that to be harmful.

2. Having to parse all files to find deps takes time, obviously not a ton of time, but it takes time, it simply doesn't scale appropriately

Working in finance - I think personally that it is really important to make changing the dependency chain something everyone should be VERY aware of.

An example I shared few days ago here: https://news.ycombinator.com/item?id=26560464

https://deno.land/manual@v1.8.2/runtime/workers#specifying-w...

Because any app of a medium size and above will require access to all permissions. Also Deno had some obvious security vulnerabilities around symbolic links for example which really detracts from the supposed security goal.

> 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.

But you are going to need some kind of operating system image anyway due to other tools that will need to live with your app like log shipping, load balancers, DNS caches, firewalls, daemons, etc. So in the end you will need to describe this somewhere and why not also describe the dependencies of your apps at the same time.

> 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.

If using IIFE is so heavy that a new backend platform needs to be built I don't know what to tell you. In the apps I see, there is exactly one top level IIFE that is needed in the whole application.

> This is exactly why people invent new backends, new libraries, and new languages.

New libraries yes, new languages no. The util.promisify() already makes 90% of the cases work painlessly and some promise wrappers for existing core libraries already exist on top of that. Since core is moving to promises slowly anyways I fail to see how this advantage will carry on being one in the future.

> 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.

Yup, that's absolutely true. I would say that there is always an advantage in having leeway in a programming language between the convenient option and the fast option so that when something becomes a bottleneck you have easier options than porting it to another language. But of course this might not be the most common case.

You might write an smtp daemon that only delivers email on to another service via LMTP - thus without ability to write to (or read from, depending on configuration) the file system, for example.

Yes, you can accomplish this via containers, too - but it's nice to get as much out of process isolation as possible, not to mention it is likelier easier to test and debug the closer to the surface of the runtime limitations are implemented.

Having reusable code wrapped into packages is basic software engineering.

This is also an opinionated subject, and as with most things in life there is a balance somewhere in between the two extremes. However the NPM packages you refer to (and yes I have seen the <10 line offenders you refer to) are clearly at a stupid end of extremely useless shared code that amount to the most trivial stackoverflow JS examples.

In response to the sibling comment on duplication: all I can say is that it cuts both ways, deduplication to the extreme also has downsides: when someone changes that code you don't control, it now affects a large number of dependencies that the author may not care about. But even ignoring those issues and assuming you package-lock everything and never look back, extreme de-duplication in general can result in highly illegible code due to a lack of holistic view: whether it's achieved with thousands of tiny external packages or thousands of tiny 3 line functions in the same file - many have covered this topic in detail before, deduplication for deduplication sake never ends well, abstractions always have a cost.

If there is going to be a global object, then it might as well be the same one used in the browser, which everyone who writes JS is familiar with.

- we have the chance to define a new and better API, we should do it - you are already adopting something different

- I agree, but its not a selling point, these things are probably in containers already and my OS should be doing most of the work

- window: just no, call it global if you must. perpetuating ideas like this isn't good for anyone but the lazy.

- I think the cmd aspect of shipping a whole binary is cool for sure, but lets not conflate this as a "compiled language" its not. you are shipping a runtime and a scripting language together.

The first line on Wikipedia in the nodejs history section is "Node.js was written initially by Ryan Dahl in 2009".

You can make whatever point you want, but maybe try to do it without rewriting history, or changing the agreed-upon definition of "creator".

Don't think so. I have been using Node.js since 2010 and following the ecosystem. Node.js is the child of Ryan Dahl. Other than Ryan, perhaps Isaac Schlueter is the most influential person who developed the NPM as a separate project and later merged into Node. Ryan could have done it himself or embedded it in Node.js, but guessing from Deno he is not keen on a centralised package repository so could have let Isaac build NPM as a separate project.

From what I could observe, the overall API is still pretty much the same from 2010. What's changed is V8 getting updated to newer versions (and thereby supporting new ES features) and other performance optimizations. But no one can't deny or take away the creator credit from Ryan.

Deno makes it easy to import from temporary places. However, this wouldn't be solved by having a centralized registry or a package manager like npm.

Npm can install from git repos and registries other than npmjs.

Having a package on npm by its own doesn't make it any less malicious.

A solution would be to enforce registries you can import from and fail if it's outside that.

I write a lot of short JS files that aren't part of a big cohesive backend, and little things like top-level await make the code somewhat easier to read. Yes, you can just do an async IIFE, but that's just another thing for the eye to parse and feels quite vestigial.

EDIT: And since I can't respond to your other comment, I'll ask this here; what do you consider great and important about Deno that doesn't fall under the bullet-points I listed? I'm simply curious.

Though I admit it's not that fun for me to come in here to poopoo Deno.

Also, from your link:

"In Node this is done by checking node_modules into source control. In Deno this is done by pointing $DENO_DIR to some project-local directory at runtime, and similarly checking that into source control:"

I disagree with this. In my opinion, this is done by using a pull-through cache that caches every package developers request and so inherently has a cache of the packages that will go to production.

Is it possible to do this in deno today? I don't really get that sense.

Well, I started from the "full paranoia" mode where people would want it to be ad hoc and as decentralized as possible. It's very easy to imagine that there would still be trusted/trustable 3rd parties creating central proxies for stuff like this. Just as unpkg today provides one way to pull individual JS files from npm, you could imagine unpkg as an option for Deno. Similarly, there are lots of artifacts repositories with upstream pulling options already in the wild such as GitHub Artifacts or Azure Artifacts or jFrog Artifactory as three easy examples to mind (among many). It's not hard to imagine those artifact libraries also supporting Deno style URLs (in a similar manner to what unpkg does with npm) as Deno becomes more popular.

Ultimately it is likely to be a huge spectrum from people that want a JS proxy they entirely control/run/manage themselves, to those that want one they trust from a 3rd party, to those that are fine with whatever CDNs their libraries suggest. That's already a spectrum that exists in the npm world: people have private npm servers, people use npm artifact libraries like GitHub Artifacts, people use unpkg directly to pull in JS files from npm, people still go to Bootstrap or JQuery in 2021 and just copy and paste whatever CDN is mentioned in the "Getting Started" section of the appropriate docs. That spectrum is still likely to exist for Deno libraries, and while it might make it harder as a user/developer to choose which part of that spectrum is best for your own projects, Deno having little to no "out of the box" opinion on which part of the spectrum your project falls into (as opposed to Node defaulting to npm these days and the two ever more seemingly inseparable) isn't necessarily a bad thing for the ecosystem's health as a whole.

If we are using URL-based imports, the scope of security assurances are much broader: an SSL certificate doesn't say anything about whether the current owner of a domain was the owner at the time of a dependency being safe. There is no one authority who we can expect to take swift (or even slow) action to remove malicious packages from being available on the myriad hosting protocols that are accessible through an environment like Deno

I wish there was something like Docker Hub's automated builds in the Node world because the way NPM works right now, what comes from NPM is an unknown. The only thing you know is if you download a specific version once, you'll always get that same version again, unless it's invalidated. Otherwise, whatever the package author wants to upload and include, that's what you get and you can't know that what you're seeing in some Git commit is what's running in your application. I wish that was the state of the art.

This is the marketing line on the front page of the Deno project:

> A secure runtime for JavaScript and TypeScript.

They are using the same term "runtime" to describe JS as well as TS. All replies here by Deno team members use the language "Typescript support" but nobody here is saying TypeScript runtime.

https://deno.com/deploy/docs/pricing-and-limits

AWS sucks hairy balls at providing things that are simple for developers to use, so that could be their competitive advantage, but I'm just guessing here.

I mean Zoom has no right to exist because you can use Chime?

There is always room for better UX, better support, different approach etc.

Deno seems to be targeting cloudflare as a competitor for their service... But it's probable that AWS will release a cloudflare worker competitor themselves if deno continues with the MIT license.

We've simply incorporated the type-checking and transpiling steps into the deno cli, making it super simple to get going, no config needed.

> Firecracker runs attacker-provided native code directly on hardware, which means that hardware itself becomes an attack surface, one that is quite wide, not fully documented, and very hard to patch if problems arise. It's much easier to work around hardware bugs...

I see your point. I mean, Google wouldn't put as much effort as they are on gVisor if KVMs were the best possible answer.

That largely depends on your definitions of "beat" and "win". There are plenty of software infrastructure firms out there that Amazon has yet to smash into the ground.

Nature seems to think (and I agree) simply existing is winning.