Deno 1.9 | Hacker News Reader

Deno 1.9

deno.com

670 pointsmonstermachine236 comments

I'd love to use deno, but I really don't understand the point deno's module/package system.

The standard practice of deps.ts/dev_deps.ts as described in the docs[1] just seems absolutely asinine to me. Importing everything into one scope and then re-exporting from one file just seems like an awful hack.

What do you do if two libraries have functions with the same name? Do you namespace them yourself, or export an object under the name of the library (and therefore give up destructuring?)

The URL thing seems similarly cumbersome and unecessary. Is there something wrong with a configuration file that would map 'package names' to the urls to get them from?, and then import { foo } from "packagename"?

[1]https://deno.land/manual@v1.9.0/examples/manage_dependencies

The issue is that JavaScript (by extension TypeScript) doesn't have the concept of folders.

You can only import a single file per import statement.

Developers create "barrel" files that allow them to re-export all of the important stuff in a folder externally. This allows for namespacing

  // foo/index.ts
  export * from './foobar'


  // main.ts
  import * as foo from './foo/index'

  new foo.Foobar()

Or use destructured imports to help with static analysis tool that trace imports removing unused references from the final build

  // main.ts
  import { Foobar } from './foo/index'

Node has non standard behaviour where it appends `/index` to the import path if it's a folder allowing you to shorten imports to

  import {} from './foo'

Gotcha in ES6 import is that you need to import the default export specifically eg. import default as Foo, * as Bar

It would be much easier if it was one namespace like in Node.js require. eg. var Foo = await requires("foo", {fs: "/home/user"})

Node.js modules are pretty much perfect besides the security flaws.

Yeah I am sad that ES6 imports don't allow for easy namespacing.

You can get around this with a double barrel. In the outer barrel, export your individual things

   // index.barrel.js
   export * from './foo.js'

Then in your main barrel re-export them under a namespace

   // index.js
   export * as foobar from './index.barrel.js'

Then from you application you are forced to have a named import with the namespace defined

   // main.js
   import { foobar } from './foobar/index.js'
   
   foobar.foo()

You can submit a proposal to introduce namespacing to ES6 imports

I found most of the dependency woes to go away with import maps: https://deno.land/manual@v1.9.0/linking_to_external_code/imp...

it seems like libraries can't use import maps though, right? the final binary can provide that flag, but is there a way for library dependencies to specify their own import maps? the spec [1] has support for scoping, but I didn't see a way to integrate that with the Deno loader.

[1] https://github.com/WICG/import-maps#scoping-examples

Yeah, libraries can't use import maps because import maps are not extensible

It's almost like you need something to manage your packages to generate them.

oh damn, that's exactly what i've wanted.

Except you have to make them manually. They could've trivially built a thing that takes your npm package.json and converts it to an import map internally, but instead you gotta manage all that hassle yourself because they don't want to play nice with npm. /rant

This is probably one of the bigger issues holding me back from adopting Deno (at least for personal projects anyway). I'm sorry, I don't want to go back to early 2000s where we're copy pasting random links to script tags. Those days are over and for the better. NPM has proved pretty much undeniably that people prefer the simplicity of just typing in the name of something to install it, and import it. Does it have issues? Absolutely. I'd rather those issues be resolved than completely throwing away the concept though.

This feels to me a bit like if a new browser came around and said "DNS is the root of all evil" and only allowed you to directly type in the IP address of websites.

You can make all kinds of excuses, like "oh, but you can keep a list of your own!" or "hey, you can install this plugin that gives you DNS lookups back", but ultimately as a user I'm gonna say "No thanks, I'll keep using a browser that doesn't needlessly complicate my day."

I'm usually an early adopter for this kind of stuff, and I really like a lot about Deno, which is why this situation just makes me very sad.

This 100%. Every time it comes up I'm just saddened by the fact that they're so antagonistic towards the existing npm ecosystem, when those problems could be so easily solved and their userbase so easily expanded with some minor compatibility tooling that allows importing npm packages.

You do something like this

  export * as Oak from "https://deno.land/x/oak/mod.ts";
  export * as Postgres from "https://deno.land/x/postgres/mod.ts";

Then you do this:

  import { Oak, Postgres } from "./deps.ts";

> Do you namespace them yourself, or export an object under the name of the library (and therefore give up destructuring?)

I know you can do this, but then you can't do

    import { Function1, Function2 } from "oak";

You could do

    import { Oak } from "./deps.ts";
    const { Function1, Function2 } = Oak;

But that is still an awful workaround.

Perhaps you could do:

     import { Function1, Function2} from "https://deno.land/x/oak/mod.ts";

In the file that needs them? Though then you have a lot of redundant URLs everywhere and god knows how auto-imports could work.

Or perhaps you could do

    // deps/oak.ts

     export * from "https://deno.land/x/oak/mod.ts";

and then you'd do

    import { Function1, Function2 } from './deps/oak';

I am not a fan of any of these.

There are user land tools to manage dependencies for you. I cannot comment on the specifics because I haven't used them extensively but one example is deno-udd.

It updates your dependencies. https://github.com/hayd/deno-udd

There are one or two more feature rich ones. The need for deps.ts can be eliminated with management tools which work with your imports directly.

That's just a package manager!

If something like that is needed, then I think deno should attempt to come with something for managing dependencies.

Eventually, developer convinience will win, and everyone will settle on some sort of package manager for deno. It'd probably be for the best if deno made it official as, personally, I think this is heading towards a second NPM.

Not quite the same. It's a simple management tool which rewrites your imports to use the latest version from supported registries. Deno binary still handles all the resolution, fetching, caching and loading.

There are no plans to add such convenience in the binary because it would mean limiting places you can import from (cannot upgrade deps for unsupported registries). Deno binary will remain agnostic to where you import from.

Community will come up with something if it's a huge problem and settle eventually.

Wouldn’t this work?

import { Oak: {Function1, Function2} } from "./deps.ts";

This isn't valid syntax, no

This is a regression. This was possible with "require" and destructuring assignment.

I don't know why you are getting downvoted. I agree. The difference is that ES6 imports are meant to be more optimized and also can allow for async/top-level async modules. I believe part of the additions of ES6 modules made it harder to treat the right hand side like a complete object that can be destructured. In summary, it's not the syntax, it's the difference in feature richness between ES6 and CommonJS importing.

Yeah, I'm not saying that import was a mistake or even a good idea done in the wrong way. I use "import" whenever I can in my own code. It could be impossible to import only the particular things one needs, and that trusting tree-shaking is the best we can do. However, it very much seems like a first version to me, and that import statements could be made smart enough to destructure.

Yeah, was afraid it might be bad ES6. But this is Delo, so they can do whatever they want.

No they can't, Deno is JavaScript compliant

If dependencies are imports from URLs, how does one audit their dependencies?

If a server gets hacked those TS can be replaced with malicious versions.

In npm we at least know that a package is immutable once published, someone could publish a malicious version as a newer release but a current release.

Does demo generate some type of file that keeps a hash of all downloaded imports to verify against the next time those imports are downloaded?

Integrity checking & lock files https://deno.land/manual@v1.9.0/linking_to_external_code/int...

The same problem (and solution: package-lock.json or yarn.lock) exists in npm if you use semver version specifiers, or npm itself could be hacked, it’s just a bit more acute in Deno since it’s easy and common to load files from arbitrary hosts that don’t enforce immutable versions.

npm has a lot more to lose from being hacked than some random URL, I trust npm with my packages because they fix stuff when something like left-pad happens, the same is not true for every URL I'd have to import to build a deno package.

> In npm we at least know that a package is immutable once published, someone could publish a malicious version as a newer release but a current release.

This is only true as long as you trust NPM. If they were hacked or taken over by a malicious actor, packages could be modified unbeknownst to you.

No they could not. Because your package-lock.json contains integrity hashes that are verified during installation.

Only if you update dependencies, a fresh install would not have such integrity checks, so it's just as vulnerable as Deno hosts to such attacks

Not sure I’d use the local deps file. I really like just the import {..} from “https://xn--ivg. The version, everything, is up front and explicit.

The problem the deps.ts pattern solves is that your project has several dozen modules that all import a particular version of a dependency, and now you need to update them all to a new version of that dependency.

(If your project only has one module, then you don’t have this problem and don’t need this solution.)

Why not just use sed?

Why bother with DRY at all? Just sed all day to replace 24 instances of function foo().

Indeed, DRY is overrated, especially for trivial things like string constants.

How is DRY overrated? Making edits to a codebase shouldn't require any more tools than a text editor. I wouldn't want to live in a house that required powertools for every minor repair, it would be burdensome and indicate poor development practices.

Are you using a text editor that can't index your repo and do search-replace within? Vim and emacs both do this easily.

If you're not using an IDE, have you considered that by DRY-ing up constants, you're adding about 2-3 steps to even see what the value of a constant is?

Jump to the top of your file, figure out where the import is from, open the other file, then find constant name.

You also force your code reviewers to do this in e.g. GitHub, where there's no convenient 'jump to definition'.

IMHO, if your starting point is that you won't use sed, can't use a good IDE, and won't configure your editor nicely, then you're just creating a lot of unnecessary work for yourself, regardless of whether you're doing DRY.

Power tools are appropriate if you're building a house.

You're just going to wind up making changes where you don't need them that way. There's no guarantee that because the code looks the same it does the same. An IDE can't figure out what side-effects will happen.

By just letting your IDE make changes globally, you're running the risk of introducing bugs. By DRYng up your code, you know that the change you make will have the same result everywhere.

You could opt to improve upon the standard practice, right? I have only played with Demo a little, but the deps file seems only like a convention rather than a strict rule.

Why not instead create a deps directory, and keep in it one file per dependency? Inside each file, you re-export the library from URL.

This way you can import from files rather than URLs elsewhere in your code, and it should be clear which dependency is being imported from the file name itself.

That solution is great! But it sounds like something that could be automated or managed for me.

i like to have multiple deps files roughly grouped. this reduces not only the likelihood of name clashes but also gives a bit more structure and in addition when running in the browser its possible to handle bundling the dependencies separately by that grouping.

You realize Deno is founded by Ryan Dahl, who founded Node 12 years ago, don't you?

Perhaps you should be less quick to label anything about it "asinine" or even "awful hack".

With all respect to Ryan Dahl, I'm sure he'd disagree with the "asinine" characterization but would also disagree he's infallible - as evidenced by the creation of Deno after Node

I'm just saying Don't be so quick to judge. Be humble!

No one is infallible. That said, creating Deno after Node doesn't imply that Node was a fail or that Deno will be perfect. Obviously not.

Consider that someone really smart has reasons for doing (or trying to do) things a certain way. Be humble!

Node is a failure. It's standard library is written ad hoc. Riddled with catch 22s and monkey patches. The development style is just to bolt on more and more variables and branches, endlessly, without any cohesive style.

Example of the "common caterpillar" genus of node quirks and the awful antagonistic responses by the dev team: https://github.com/nodejs/node/issues/25857

Just take a look at a random stdlib source file: https://github.com/nodejs/node/blob/master/lib/readline.js

``` if (input && input.input) { // An options object was given output = input.output; completer = input.completer; terminal = input.terminal; history = input.history; historySize = input.historySize; signal = input.signal; ```

It's junior-level code writing all over the project. That is a failure in my mind, especially when I know the library backing my project has to import all that junk hidden from view.

See (wontfix) fs.promises.readFile is 40% slower than fs.readFile: https://news.ycombinator.com/item?id=26332774

Not to mention the awkward political nature. There is a BLM banner on their front page: https://nodejs.org .The founder of BLM, Patrisse Cullors, just bought 4 mansions, the last for $1.4 Million USD: https://news.yahoo.com/blm-official-calls-investigation-foun...

Node's dev team is not interesting in supporting the community. They are amateurs who are trying to be woke and add "top Node contributor" to their toolbelt of proverbial ego items. Prove me wrong.

Always snopes before you post! https://www.snopes.com/fact-check/patrisse-cullors-topanga-h...

The "mansion" is a 3br 2ba, real estate is just kind of expensive in LA. My Bay Area home is actually worth more than that, and I don't see why she shouldn't be allowed to make real estate investments or have a nice-ish house. There's no evidence any funds have been misappropriated, and if it comes to light I'll join you in complaining, but until then it just kinda sounds like an attempt to discredit BLM-the-movement by discrediting it's leaders and organization without any real evidence.

Snopes is a great source! /s https://www.dailymail.co.uk/news/article-4730092/Snopes-brin...

https://www.boston25news.com/news/trending-now/snopescom-cof...

https://en.wikipedia.org/wiki/Snopes

"Kids, say no to Snopes!"

Most support BLM the concept, few know anything of BLM the organization.

The movement has been co-opted by opportunists just like Al Sharpton did 10 years ago.

Police reform is an issue that everyone can get behind. But it's not as catchy and divisive.

I do! And I think node has a lot of flaws (Ryan seems to agree).

I do not understand why deno has gone for this route. It seems primed to produce a package manager eventually, and it seems like a bad idea to leave package manager creation down to whoever makes the first decent tool (which is mostly why npm is the standard for node.)

The often overlooked selling point of Deno that I find most compelling is the (re)use of web APIs. As a full-stack dev writing isomorphic code and libraries, dealing with ideosincracies of nodejs has been a pain.

When Node first released its biggest selling point was being able to reuse web APIs. It also filled in gaps for APIs that weren't standard in browsers. Then browsers started to add these APIs, and some of Node's implementations naturally diverged (aka the idiosyncrasies that you mention).

Deno has the advantage that they are starting from a clean slate without the burden of legacy APIs, but how long will that hold for?

JavaScript itself has gone through about a 10-year transition period from a toy language for writing quick scripts to a full-on general-purpose programming language. It didn't even have a module system when Node launched.

So I strongly doubt the next 10 years will be anywhere near as tumultuous as the past 10. It's very possible that right now is just a much better time to be establishing a JS runtime.

Part of me almost misses `browserify` -- the heady days of "Node modules are the One True Way", with all the constraints that implied. Got a lot done with it and related tooling back then!

CommonJS worked well enough for lots of things, and it was neat that it was so simple (no new syntax!)

But it had limitations, chiefly that imports/exports were not static. Things got imported at runtime when they got reached, etc. This meant that things like browserify were fudging the semantics in some ways, and it also made it impossible to properly do tree-shaking. The stricter semantics of ES modules are better IMO, despite the pain of transitioning.

You could argue that the apis in question are more mature now than when Node was first released.

Either way, if Deno is one day replaced by something else, say 'Done' to keep the naming convention, that won't refute the use everyone will have gotten out of Deno in the mean time, in the same way that Deno doesn't refute the use everyone has already gotten out of Node.

The selling point was being able to write server code in Javascript and potentially share code between UI and server.

Node never implemented any of the essential browser APIs like XMLHttpRequest or later fetch, localStorage, etc.

Nope, that’s why there’s a million node-fetch, isomorphic-fetch, etc variants

Indeed. I remember that, I have been using node since the very early days, and switched to it for precisely that reason--that I could use the same language through my web application. Nevertheless, when we did get those modern web API, Node was slow to change or adapt them, although, it's doing its best now.

In case of Deno, I hope they just stick to following the standards and changing with them. They might not, I cannot vouch for them. On the other hand, I was also skeptical about TypeScript following ECMAScript. I though at some point they'll get too much into conflict and MS will refuse to follow, but so far I've been proven wrong. And from the looks of it, TS even deprecates stuff that is likely to conflict with upcoming ES versions.

Overall this is true. And beyond that the TypeScript team is heavily involved in TC39, and quite a lot of TC39 proposals are specifically designed to be enhanced by TS. That said...

There are a few longstanding incompatibilities/footguns. And they’re likely to remain due to widespread use, even though most are controversial. Off the top of my head:

- access control annotations (`private` which is compile time only vs `#`). I’m on the fence on this one. I prefer the TS syntax, but obviously not the behavior.

- Enums. Everyone but me hates them. I use them extensively for personal/internal use but try not to force them on others.

- Decorators. This is the big bad ticking time bomb. Last I checked the TC39 proposal has diverged significantly from the TS implementation. And sure it’s marked “experimental” but it’s used a lot and almost guaranteed to be a future conflict. Putting that toothpaste back in the tube is gonna make a lot of people feel a lot of pain.

> enums [...] everybody but me hates them

Hmm, what did I miss, why do people hate them exactly?

> And sure it’s marked “experimental” but it’s used a lot and almost guaranteed to be a future conflict. Putting that toothpaste back in the tube is gonna make a lot of people feel a lot of pain.

Maybe I'm a bit masochist, but I can't say I feel a lot of compassion for people using experimental features in missing-critical production code.

>Maybe I'm a bit masochist, but I can't say I feel a lot of compassion for people using experimental features in missing-critical production code.

To be fair, decorators are an experimental feature in name only at this point. A lot of libraries force you to use it, including Microsoft's own tsyringe and the beyond popular TypeORM. NestJS is a reasonably popular framework that will codegen services with decorators in them. As the OP of this thread said, the toothpaste is out of the tube now.

Fair point.

the entire angular2+ ecosystem as well

> Hmm, what did I miss, why do people hate them exactly?

They operate in a weird gray-zone between being just compile-time types vs. an actual readonly object in the runtime. I don't think I've seen a use case for them yet that wouldn't have been better accomplished with a union type of string literals and using const string literals in the code.

Say all you need is a fixed set of strings that get reused everywhere. What is better accomplished by defining a union type AND consts literals rather vs creating a single string-based enum and using that everywhere? I feel like I'm misunderstanding...

You don't even need the const literals.

    type Color = "red" | "blue" | "green";

> Hmm, what did I miss, why do people hate them exactly?

In my experience, enums are far less type safe and convenient (usage in switch for instance, combined with a linter) than union types.

The thing is enum and union type have different use cases. Union type cannot be used to check against incoming data. It's a lightweight type level feature. There is no way for compiler to identify the unknown data object from the network. Enum is essentially an object in memory which can be used in this case.

There's the web APIs which are tested against https://github.com/web-platform-tests/wpt (albeit without full coverage), and there is ffi/plugins - for deno specific things like readFile.

I don't know the history of Node... but why would there need to be a diversion?

Because CJS's "require" is synchronous and was never implemented IN the browser... Deno is close to standards compliant syntax, so much closer to what's in the browser (TypeScript being a super-set). You can use most JS written for Deno in the browser without having to re-write or create odd shims.

There is a tremendous amount of overlap between the Web and Node API creators, but there has been push-back and slowness to adapt many of the Web APIs in Node by the same group. For example, the delays in adopting ECMAScript modules in node, or the lack of first-party API for fetch.

How do you actually go about writing isomorphic libraries for browser/deno? It seems like for frontend code you'll have some build system that resolves imports to node_modules, whereas deno code imports from e.g. deno.land. How do you write library code with dependencies that can support that and the other differences in the module systems?

Deno uses ES6 modules, which are supported by modern browsers. There’s no node_modules. https://deno.land/manual/examples/import_export

Yeah, I guess if you don't use typescript? But isn't that a lot of the appeal of deno? The browser can't import a TS module.

Just like you did in the browsers back in the day when you imported code from URLs with <script src="">, the "deno way" is supposed to follow browsers in these regards as well.

And you can always use `npm`, `node_modules` and `import maps`[0][1][2] to kind of mimic "nodejs way".

[0]: https://wicg.github.io/import-maps/

[1]: https://blog.logrocket.com/es-modules-in-browsers-with-impor...

[2]: https://deno.land/manual/linking_to_external_code/import_map...

Maybe there's a bundler/webpack plugin that supports deno's import system, so it just fetches whatever http urls/analyzes the import maps and turns it into a normal web bundle.

Deno’s import system is just the ecmascript import system. So, it works exactly the same way it does in the browser. Or with curl. Or whatever. You just supply a uri and get the resource at that location. Things like import maps are just a way to make that more convenient during development, but there’s no secret system for pulling these pieces together; it’s just the ecmascript module standard (that didn’t exist until more recently).

Yes there are plugins for this in pretty much every build tool and for Node. But they all have a bunch of caveats and mutual discrepancies.

Snowpack might be an option

Their companion CDN (and namesake umbrella parent company) is also a first class part of Snowpack.

However using CDNs in the browser has some big trade offs. Besides obvious concerns sending any data to consolidated third parties, it’s actually a performance detriment now that browsers are caching per origin.

Used to be, using a CDN got you more likely cache hits and better perf on N+1 requests. Now you definitely don’t get that plus you get the extra DNS lookup and whatever performance characteristics of that CDN.

There has always been an extra DNS lookup wirh a CDN. Thats even the point of the CDN since based on where you are, you will be served from a location as physically close to you as possible.

Where did you get the information from that CDNs arent as good as they used to be?

Safari and Chrome now use a combined cache strategy using the URL of the resource and the top level domain of the site loading that resource as the cache key.

For scenarios that were previously popular like using the jQuery CDN, you won't get the benefit of the user having jQuery in their cache from another website. You will however still get the proximity benefit you describe. CDNs are obviously still quite useful, just not for getting cache hits on popular libraries.

https://www.stefanjudis.com/notes/say-goodbye-to-resource-ca...

Yeah thats true - so you explicitly mean CDNs that serve a single thing only.

Using a CDN for your static files is just as fine as it always has been.

> Where did you get the information from that CDNs arent as good as they used to be?

The other comment addressed this, but to be clear. One of the common usage of external CDN resources is predicated on a performance benefit: if multiple sites use the same resource, it’s more likely to be cached already and much less likely to be impaired by the drawbacks (DNS hit, external network factors). But since browsers have shipped cache partitioning for very good privacy reasons (as other comment mentions, caches are prefixed by the requesting origin), you get no cache benefit and all of the detriment of a clear cache.

Essentially the only reason to use a CDN for third party resources now is if you can bet the CDN will perform better than your local, already DNS-resolved host.

What do you mean by reuse of web apis? I’m curious to read up on this feature.

Defaulting to browser based APIs when they exist (like a global 'window' element to access the DOM), rather than reinventing the wheel the way Node did. Although to be fair a lot of Node APIs predate their browser equivalents, and in a lot of ways the browser contains a 2.0 version of a lot of Node APIs.

I can't think of a single case of Node reinventing the wheel with their APIs. Like you said, they were all created to fill gaps in browser JS implementations. It's obviously going to be hard to reconcile the two as browsers themselves increase their API surface, but then Deno is going to run into the same problem eventually.

Node introduced the "global" object instead of using the existing "window" object the pre-existed in all browsers.

At least whe have "globalThis" now.

I think that depends on how much deno commits to following the web APIs with each release.

Actually, nodejs has really done a lot of catching up with deno in this regard. It just has to support both the “legacy” way and the “forward looking” way where deno does not.

node actually invented a lot of wheels. node was first with promises (a couple major iterations!), streams, uhh I dunno what else. file access (we're just getting that now in the browser after some old ill supported early attempts). modules.

the web reinvented many of these wheels.

Node didn’t introduce the Promise API. Although it definitely instigated it. Node, with its async IO model, was just littered with callbacks. There were a zillion different approaches to async APIs that could ease that. Promises were, well, the most promising. But years of iteration and competing standards came and went before Node adopted them as the preferred API. And they did so right along with browser vendors and web standardization bodies.

I was referring to node <0.1.30[1] which did have promises for a while. largely from jQuery deferred, which were ungood in a couple ways I don't remember. but also remarkably similar.

I still largely think kris kowal building the "Q" promise library is what made promises interesting, what surfaced the idea that we might want to first-class our completeablea/futures. I know kris had some specific inspirations but I forget what.

pains me somewhat to this day that promises ultimately became somewhat un-value like, that handlers don't get to see what it was resolving. all the chain/spawn discussion, the functional promise folk: they got rolled by those insisting we had to target only the lowest rings of the developership, and that allowing more potent systems was unacceptable. wish I could find those es-discusa threads, for the powerful sorrow of the afteath, what we are stuck with, in it's so lites form, haunts me. especially as we double back a decade latter & invent controllers & signals toanage our promises. which we would have had for free.

way off topic now. forgive me my late night ramblings.

[1] https://github.com/nodejs/node-v0.x-archive/blob/v0.1.30/Cha...

This. I started tinkering with node shortly after I heard Ryan introduce it at JSConf EU, and it was a very different world, not much for Node to draw from on the browser side, no modules, no promises, not even TypedArrays IIRC.

Things like ArrayBuffer/view, fetch(...) and worker threads being the same spec/interfaces as the browser implementations rather than homegrown stuff like Buffer, child_process and any number of npm wrappers around the http module in node.

Hopefully the story is the same in five years after Deno and browsers have both had time to evolve. Are there plans in place for tracking future updates to Web APIs in Deno?

I believe so. Recently Deno started running a subset of the Web Platform Tests to test compatibility.

See: https://deno.land/manual/contributing/web_platform_tests

Things like using UInt8Arrays instead of Node's homemade Buffer class, fetch, using WHATWG's implementation of Streams, Blob, WebWorker, etc.

Node's homemade Buffer class uses UInt8Arrays. https://nodejs.org/dist/latest-v15.x/docs/api/buffer.html#bu...

Not originally though: https://nodejs.org/dist/latest-v10.x/docs/api/buffer.html#bu...

I'm not so familiar with web development and don't quite understand where this fits in. I know I can run JS in my browser. I know I can run JS on a web server using node.js. I know I can compile Typescript to JS. So how does Deno fit in and what is the added value? Not trying to be negative, just curious.

Deno has a couple of very good selling points, the main one is that it allows to use JS web browser API's in the CLI, this includes things that range from the Fetch API[1], up to WebGPU even! all in the command line interface.

Besides this, it uses the same module system as the browsers do. The JS module system is in my opinion very well designed and intuitive. No need for AMD or CommonJS or Node require's.

Other good things about Deno is that it includes a lot of goodies by default. In that single binary you get in your command line interface:

- A very very decent and fast bundler (bundling in JS is a mess, the Deno is straightforward and needs no config and no hacks, which, surprisingly is unique in the JS bundling scene)

- Testing library

- TypeScript support (for those that like it)

- Documentation generator

- Linter

- Syntax modifier (like prettier)

- Official VS Code plugin

Unlike Node, it uses Rust to bridge the gap between the JS engine and the OS, and leverages on a lot of very cool Rust libraries.

I personally really like the `Deno compile` feature which outputs your code into a self-contained .exe which executes your script no need for separate tools.

If you want to do this with node, pkg exists.

https://github.com/vercel/pkg

Woah, is that a thing? Very cool.

Deno is by the original creator of Node.js and seeks to fix/change a few things about Node he regretted while adding first class support for a few things that were new since then like TS. It's also more security minded from the get-go. Not just in a "written in a memory safe language" way but it has a permissions system and strong built in ways to inspect/audit dependencies.

So it's not aiming to be revolutionarily different from Node, rather a second shot at Node.

> So how does Deno fit in and what is the added value?

I also had that question in my mind until I tried deno a couple of weeks ago. There are a few great things I've discovered that IMO makes it a great alternative to node.js:

- Deno + std library has a lot of batteries included. Have you tried creating a web browser project with node.js recently? Just adding a few basic dependecies to compile and bundle your code will leave you with node_modules having hundreds of other dependencies. With recent cases of malware slipping into npm dependencies tree, I'm a bit fearful of starting a new project and infecting my computer (not too crazy imagining that one of the developers of those hundreds of deps will be careless with their SSH keys). "deno bundle" basically solves that for me.

- I can't think of a reason why I would not use typescript these days. Not having to install tsc or create a tsconfig.json is a killer feature for me. Not to mention compiling ts with Deno feels really fast (maybe because they don't have to load the whole typescript compiler into the JS VM on every run?).

- As a consequence of Deno's fast startup + tsc support + great standard library + automatic dependency download, I've found a vastly superior alternative to python for writing quick and dirty scripts for automating various tasks. So for me Deno is not just for writing servers, it is also for using typescript as a script language for automating my desktop and server workflows.

These are just a few things that stand out for me, there's certainty more to Deno than it may initially appear.

* Running a linter without granting it write or net access

* Running a build tool with only file access to the source files

* Trying a cli script without granting it access to everything by just showing the help

In times where a linter has 10000 dependencies, I'm in desperate need of sandboxing.

People on hackernews are easy to judge companies when they leak customer data. But what if we the developers are actually the problem by executing megabytes of foreign code just with faith.

It's a Node.js alternative.

Deno glue code around V8 is written in Rust.

It tries to be as close to the browser API as possible, using ES-Modules instead of CommonJS and doesn't require a package manager.

Also, it compiles TypeScript automatically.

> Deno glue code around V8 is written in Rust.

The C++ V8 api is very reasonable to be used in a safe way. So i dont see this as a good point unless of course for people that wan to write some parts that need to be optimized in Rust.

Don't deal with NodeJs that much, but is a lot of node functionality in C++ modules? and if so they are presenting a lot of security bugs in a way that Rust might see appealing?

Because by not having direct access to the V8 api in its native language might limit you, the "glue coder", in the things you really can do.

> Deno glue code around V8 is written in Rust.

Maybe this is not the best way of putting it. They use Rust for all the system bits including networking, so it's not like they just wrote some JS to V8/C++ glue code in Rust.

Ok, but even if there's more Rust code in it, i think the expectations of the parent poster are unreal, as for safety, only if V8 VM were rewritten in Rust, and giving its a JIT VM sensitive portions of code would need to be in 'unsafe{}' anyway, so how much safer would it turn out to be even than?

Anyway in security terms it will probably turn out negligible as the percentage of code in safe Rust are probably low compared to the whole thing.

Than in memory usage, if it replicates Eletron,it would turned out almost the same, giving is not the C++ core the one that is most memory hungry.. is mostly the renderer process with WebKit and V8 executing big portions of javascript code in memory.

Giving if such a branch existed, it would use typescript which in turn is the same V8/javascript pipeline that is memory hungry.

So, addressing to the parent poster, i don't think it would change much in terms of security or memory pressure if compared to Electron.

Sometimes i think Rust give some people high expectations, that it would be very hard to actually replicate in real life experiences, giving software is much more complex and as in Deno, requires other core parts that cannot be realistically rewritten in Rust, and even if they could, while we can see how software written in Rust can be safer, it still needs to prove the claim for bigger, sensitive pieces of software that requires a lot of "unsafe" techniques to work like JIT's and OS's and therefore might not feel that much of a difference giving the size and complexity of the project.

Ryan Dahl has talked about why he chose Rust at various times. The original prototype was actually written in Go but was ported to Rust to avoid garbage-collection issues. The real reason for these languages over C++ was more about maintainability than type safety or speed. Ryan seems to be pretty happy with Rust so far which is a good sign but doesn't mean that there are direct benefits to users.

Deno is meant to be an improvement on the nodejs ecosystem. Ryan Dahl took everything that he learned from node and improved upon it with Deno. There are a series of features like native typescript support, having single executable, url imports, etc that are all very pleasant improvements. The idea is that it will make for a better developer experience.

deno supports typescript out of the box whereas to run typescript in nodejs you need to transpile down to javscript first. deno also has some security features enabled by default like not allowing network communication unless you explicitly enable it. so that prevents malicious packages from making network requests that you might not have noticed. thats a great feature because tons of javascript projects/tools dont need to send http requests so if your tool doednt require that then you can be confident that any dependency you use is not secretly spying on you.

Deno is designed to be a replacement for Node.js on the server. The introduction to the Deno Manual [1] provides a comparison.

[1]: https://deno.land/manual@v1.9.0/introduction

It's main selling point is security. With Deno you can provide permission to scripts using flags. Deno offers a sandbox security layer through permissions. List of the flags:

--allow-env allow environment access.

--allow-hrtime allow high resolution time measurement.

--allow-net=<allow-net> allow network access.

--allow-plugin allow loading plugins.

--allow-read=<allow-read> allow file system read access.

--allow-run allow running subprocesses.

--allow-write=<allow-write> allow file system write access.

--allow-all allow all permissions (same as -A)

What I dislike is that you provide these permissions for the whole process. I'd like it to be more that you can constrain and pass the permissions down to libraries like capabilities.

I agree. I hear a lot made of Deno's "security" but process flags don't really make me feel much more secure when I've had to enable most of them anyway. At that point they just start getting in the way and giving me a false sense of security.

My understanding is that the current security flags model isn't really meant to be the final solution. They wanted to ensure that the browser security model isn't simply dropped like it is in Node, but to improve it further they'll probably need outside help.

In the simplest terms, it is meant to be a replacement for Node.js.

Similarly, how does both Node.js and Deno compare to GraalJS? I've been reading about it and find the idea absolutely genius, but I'm sure it doesn't have nearly as much of a userbase as these.

They're kind of different things. Graal is an attempt to create a polyglot environment. For example, using Python and Javascript in the same environment. For example you might be working on an application where the web server managed by the web team is written in Node and your data scientist team uses Python scripts to deal with the data, but they need to run in the same environment. Graal lets you re-use that environment for both.

Node and Deno are dedicated runtimes to run Javascript using the V8 engine. Both provide a standard library of additional functionality to make them worthwhile beyond just browser code.

I made a video on Deno which gives a quick summary of its key features:

https://devtrends.io/videos/deno

As a primarily C++ dev who's been using nodejs on the side for about a couple years now - so forgive me if this is naive - but am I wrong in seeing Deno as a potential Electron replacement with standalone binary builds + webview?

If so, the introduction of interactive permission prompts is pretty cool.

I see a few comments from more experienced web developers that are quite negative about Deno that seem to generally be centred around the fact it offers very little compared to nodejs, and isn't worth the effort to learn.

Does it have potential as a safer, lightweight Electron alternative? Or are there better options than Deno in that regard?

> Does it have potential as a safer, lightweight Electron alternative? Or are there better options than Deno in that regard?

If they target this, the big chunk of code will still be the same ones on Electron, so i don't think it would get to be safer or lightweight as compared to Electron.

there's webgl, webgpu, and dom, but it's a headless dom (jsdom) not a webview.

I wouldn't be surprised to see packages developed for a webview but atm demo seems to target server side web platform compatibility... except rendering html!

I wouldn't be surprised to see some packages try to fill the gap, & deno has a much stronger basis for implementation than node (a rpc layer between rust & v8 defines the core character of the project, and an native addon that adds webview methods to the rpc would be natural in Deno, vs a hack in electron).

The most updated webview bindings I know of for deno: https://github.com/webview/webview_deno

It's likely you will find some hiccups in latest deno release because it uses rust plug-ins and they are getting overhauled at the moment. Maybe a few more months before getting stabilized.

I think it's not its main goal right now, but it could be and would be really interesting if it happened.

I'm not looking forward to when I lose all my productivity with Node.js because the industry collectively agrees to move on to Deno and rebuild or port things that have been working just fine for the past decade, but OK, here we go.

Maybe I should just hedge my bets and get on the train now even though I don't want to.

You don't ever lose productivity or knowledge on a tool when a new one comes out though. A new thing that people like becomes popular and people start using it, old one becomes less used but it doesn't dissapear.

You only really "switch" to a new tool if that's what you like the most, not because that's what people like now.

Welcome to software development, friend. The secret is it's all one big treadmill. You don't get paid for standing still.

Having come from the node ecosystem, I find deno pretty welcoming and familiar overall. I'm glad to see a design I think is better, over all - so long as development continues, it seems like it'll be worth the shift.

Deno's not too far off the mark if you know Node.

s/Node.js/perl

Don't worry, we've all been there.

Just realized that de-no is reverse of no-de

Actually, it's not :)

According to the official Deno releases it's:

"node".split("").sort().join("")

Which makes the pun even wittier.

I just created this account because I made the exact same comment 54 minutes ago to my co-worker and he was seeing this post. Mate, maybe we're linked souls or smth like that, what do you think? Could it be possible?

I have a question, how come people do not use Dart in place of this?

It runs on the server, it is a typed language, it's faster than v8 javascript (since that is part of the reason for it's existence to eek out more performance)

From what I've seen it can be distributed very as well, and your app is self contained ala Go.

---

So my question is, why don't more people use Dart where they would use a "Node + 'Typescript compiled to JS'" combination, which seems like it has a lot of headaches once your project grows in size

I have only seen Dart code in Flutter code bases, and my comment here might be the result of incomplete knowledge. However, from what I can see, Dart seems to resemble the Java way of doing things a lot. Specifically, the over-use of is-a inheritance.

Just scrolling through the list of examples in the Flutter samples directory illustrates this point.

https://github.com/flutter/samples

Use of inheritance seems to be the canonical way of doing things in Flutter and it seems to permeate the code base, both in the use of core Flutter APIs as well as associated library ecosystem. I find them rather hard to read and reason about. It's easy to be a bit confused on encountering a function in an object that inherited the function from a superclass 3 levels up in the hierarchy.

To be clear, I completely recognize that it's unfair of me to attribute to Dart (the language) issues/patterns I see with a library/framework ecosystem (Flutter). But this is mitigated by the fact that Flutter is by far what the lion's share of Dart code is written for today. Please correct me if I'm wrong.

The canonical way of doing things in Flutter is composition NOT inheritance. This is the whole point of Widgets. Inheritance is used in ways that generally make sense and don’t result in huge complex inheritance trees.

Dart has top-level, first-class functions that don't require wrapping everything in a class. It then proceeds to waste this by wrapping everything up into classes and hoping nobody will use inheritance.

Widgets are essentially data classes, simple wrappers for configuration information. They need to be classes because of the way the internals of the framework works. And no one is hoping you don’t use inheritance. The recommended style is very clear. You’re free to do things however you want but you have to take responsibility for doing things in a weird way.

Dart is an extremely limited language compared to TypeScript (it doesn't even have sum types), and has access to a much smaller ecosystem. Its runtime isn't much better either, like for example Go's or Haskell's is.

Deno has a partial implementation of Node's API, and even without it it's still the same underlying runtime concepts, so porting is easier than porting to another language like Dart.

If your team has invested a lot of time & energy into mastering the Javascript ecosystem (including things like Typescript), it makes sense to use the same language on the server side as well. Server machines are cheaper than good developers, especially if you can share resources between the backend & frontend.

As for Deno specifically, it's definitely closer to the "browser" way of doing things than Node is, which is super attractive. The main reason to stick with Node is the huge library ecosystem, but Node itself feels kinda weird & old, since the language has moved in a different direction while Node has remained stagnant (poor support for promises & ES modules, for instance).

Because Typescript eventually won that race? (The race to be a fine, typed and sane counterpart to Javascript).

Somehow Typescript convinced people from the Javascript side of the fence that they could mix both and eventually upgrade from it. While Dart also tried the same feat, it failed doing so.

Nowadays Dart is only being considered to anything because the team behind it are top-notch and implemented themselves a platform where Dart could be the king.

Giving their talent they were able to create a great platform, where they would made even more success if they used Javascript or Typescript as a development language. But giving they wanted to save all their years of work on Dart, and giving its not a bad technology per-se, it just had a adoption problem, Dart lives on Flutter.

If you want to use Flutter go for Dart, but picking Dart to anything outside Flutter will just alienate the developer crowd as giving even Typescript is some sort of a niche language in terms of adoption, nevermind forcing people to learn Dart.

> Because Typescript eventually won that race? (The race to be a fine, typed and sane counterpart to Javascript).

Dart is doing fine, I'm not sure what race you're talking about?

> If you want to use Flutter go for Dart, but picking Dart to anything outside Flutter will just alienate the developer crowd as giving even Typescript is some sort of a niche language in terms of adoption, nevermind forcing people to learn Dart

Dart is incredibly similar to Javascript/Typescript. You can learn it over a weekend + lookups in Google whenever you see a difference.

Your points are extremely weak.

Where you were in 2012?

Dart was heavily marketed as a Javascript successor by Google, this was even before ES5 changes, so Javascript was a even weaker language in terms of design, giving people were doing more and more full applications in the language.

The problem is, Javascript did a catch-up, and the Typescript technique of compiling to Javascript made it more appealing as a successor, not mentioning the design of the language (I know that Dart had this too, but having its own JIT it were more appealing in terms of speed back then).

Meanwhile Google abandoned the project that would allow the Dart VM and bindings to WebKit to coexist with V8. And now that only the Dart-to-JS path could be followed to develop for the Web, Typescript championed this path as it was the only way for them from the beggining.

So if you were following those events, you would know what sort of race i was talking about.

I agree with you that "Dart is doing fine", but is only doing so because of Flutter. As in, people learn Dart to target Flutter, not the other way around.

Im not implying that Dart is a bad language, or technology, because thats not true. Its only a problem of adoption, and it will have a hard time outside of the Flutter bubble.

If it were not for Flutter, Dart would continue is path to a slow death, not because its a bad language or technology, but because of how the events turned out to be, and a little bad luck.

Yeah for sure. People didn't want to change from JS to Dart because it's different and they can't adopt the libs they used.

It's absolutely a good language and doing well in Flutter and somewhat outside (I use it outside, but I might be one of the few here).

As is the dart type system compared to that of typescript.

How come more people don't use ReasonML in place of this? It runs as OCaml on the server, it is a typed language, it's faster than v8 JavaScript. Or F#? Not a fan of the functional? Then maybe Kotlin? Nim? No?

There are a ton of great languages out there, many arguably better than TS in many ways. But for a language to be popular, being great is not enough.

I'm not sure what it is that makes TS so popular, but I am pretty sure that you have to look past mere language qualities for it.

Well in this case, the Dart VM and V8 are a made by the same people. That's why I asked.

One major thing to consider when thinking about replacing JS with another language:

All JS already works inside TS so it's really easy to slowly transition your project over time between the two languages without losing any functionality or needing to take time off to make the transition.

In practice this means, new code can just be written with TS and any existing code updates can be made in TS. After that you can decide whether to even touch the remaining JS which still works.

Dart has nothing to offer over other languages, and a lot of deficiencies. Why not use Kotlin? It's like Dart, but has a much bigger ecosystem.

I'm curious, if anyone has lived through the experience: What is the migration story like to port an existing codebase from node.js to Deno?

Even trying this with some toy projects I have it is NOT easy or straightforward. The dependency management alone is different enough to make this almost impossible.

I think if you want to use Deno, it would have to be from the ground up or a complete rewrite.

Very painful due to the lack of support for importing npm packages.

You can import npm packages using esm and skypack.

import React from "https://esm.sh/react@17.0.2" should work.

For skypack, add ?dts flag at the end to get typescript typing support automatically.

Self hosting is an option too with above.

if you want more npm modules to work with deno, you can contribute to https://deno.land/std/node

This is good, but even with integrity hashes it makes me slightly uncomfortable to have a (relatively unknown) SaaS company stand between the original source on npm and us.

Self-hosting seems good, but how does one do that? I didn't see any docs on Skypack's site about self-hosting something that would work as a npm-to-deno-repackaging server.

Sorry, I was talking about esm.sh

https://github.com/postui/esm.sh

This is written in golang and can be self hosted.

> This is good, but even with integrity hashes it makes me slightly uncomfortable to have a (relatively unknown) SaaS company stand between the original source on npm and us.

I understand the worries but npm is a private SAAS company which was unknown at the time of node too. Things take time to sort out and become stable.

Unlike node, where npm defaults to npmjs - a private company which can go anytime. Deno doesn't make that choice for users. I believe that is the right step.

Trust what you need to and have an allow list.

Deno's interactive permission prompt is still easily bypassed by nicely asking terminal to confirm it:

https://github.com/denoland/deno/issues/9750#issuecomment-79...

Direct link to asciinema: https://asciinema.org/a/9rvK8ANJK0WnQc9nsrFKdC7ir

Regularly writing Typescript code both for frontend (React) and backend. Most is hosted on GCP.

What's the best path to hosting an API (Fastify-based) on GCP with Deno today?

> Therefore we have employed Hyper to build a new native HTTP/2 server API in Deno.

> The binding improves hello-world throughput by 48% when compared to the std/http pure TypeScript HTTP server.

Nice to read it about Hyper - one of my favorite Rust tools!

With HTTP 2 implemented in this version, gRPC might be possible in a near future.

What kind of improvement will this bring to the seasoned nodejs dev, that it will leverage the learning effort?

> What kind of improvement will this bring to the seasoned nodejs dev, that it will leverage the learning effort?

Not much right now, aside from 'native' Typescript support and not relying on NPM hell for everything. But as the project matures, it might be useful to take a look at it.

I personally hate having to rely on third party libraries for basic web-server functionalities, so a strong "official ecosystem" with batteries included is an interesting proposition.

On the deno.com homepage, if you click on CLI it takes you to https://deno.land/

If you then scroll to the bottom, the deno tag say "failing".

Just thought I'd share (in case the right people happen to read this).

What are the conditions for people feel the urge to migrate over to deno?

Currently, I don't see enough reasons to switch to deno for primary projects.

Having read multiple comments Deno looks to me like somethung I want to get into.

Is there somewhere a getting started with Deno guide, tackling setup of a d velopment environment and some typical use cases as examples?

How would e.g. a company like CloudFlare run Deno instead of v8 for it's serverless infrastructure?

> How would e.g. a company like CloudFlare run Deno instead of v8 for it's serverless infrastructure?

Raptor is an example project which does that: https://github.com/littledivy/raptor

deno_runtime crate provides high level abstractions which you can use to execute code for deno. It is used in the cli. You would still need to bring in your own transpiling layer for typescript support.

As for getting started, you can go through the manual: https://deno.land/manual

> How would e.g. a company like CloudFlare run Deno instead of v8 for it's serverless infrastructure?

They're both built on v8.

Are you a computer program? Your third sentence is much more sophisticated than your first two; they don't seem to have been written by the same human. And the two typos look somewhat inauthentic.

Have they resolved issues where many third party packages are not available for Deno? Like i don't see things such as MikroORM/Pino/Firebase-Admin on deno.land, and even things like AWS-SDK are out of date.

Pro tip: don't import those libs from deno.land/x. The runtime is agnostic to where you're pulling libs from, and that's by design. The AWS SDK v3 for example works great through the Skypack CDN, and you're pulling the canonical one, not simply a port maintained by a third party.

With deno you can import scripts from anywhere on the web you want, my personal favorite is jspm.dev which basically has all npm packages

I can't see what Deno even is.

Clicking the "deno" name at the top of the linked page takes me to another page that says just "cli" and "deploy". Great!

Clicking CLI (why?) reveals it is a Javascript runtime in Rust. OK, what does one do with that? We know Javascript runtimes come built into browsers. What would I do with one on its own? Anywhere I could run it, I could run code that actually does something, instead.

So I ... run it and use it to run somebody else's JS code? Whose? Or link it into something (what?) that I distribute, that runs somebody else's JS code? Whose? Is this a thing to bolt into an alternative browser, next to a CSS renderer, to compete with Chrome? Or into Chromium, in place of Google's JS engine?

I can guess at answers to these questions, but why make me guess?

> I can't see what Deno even is.

These are just release notes, for developers who already know what it is and want to see what's new.

Literally the top result on Google for "Deno":

https://deno.land/

Deno is a secure server side runtime for JavaScript and TypeScript. It is an alternative to Node.

Does the single executable distribution change anything? node/python/google-chrome are all single executable programs as far as the users are concerned.

Deno is a single executable as in you only download one file. Compared to a new python install, it needs all kinds of additional stuff to get up and running.

I wish deno files had a different file extension. Editor gets confused often switching between front end typescript and deno typescript.

For frontend TypeScript I assume you mean TypeScript that doesn't use JS modules but extensionless modules, the TypeScript folks sadly have decided to not bring compatibility here ATM.

I wonder what the general performance difference difference there is between the new Rust-based server and Express?

What exactly does deno promise when it comes to package management?

Not sure why this got downvoted, but I have the same question. Most of my projects run behind a corporate firewall, where our NPM repository is proxied. Will Deno eventually offer something?

As far as I understand, you can import packages from anywhere, which is obviously a major concern for anyone behind a corporate firewall

So probably Deno is something like that: console.log('Deno')

Or (node = 'Node', 'Node'.substr(2, 4) + 'Node'.substr(0, 2))

Can we stop implementing JS engines instead of resetting the router?

I feel like I have hit a point in my life where I don't want another framework to learn, and due to this I am not giving Deno a fair shake...

Does anyone have a short anecdote why I might bother to invest in yet another JS framework?

It isn't a framework, it's a runtime. You use it instead of Node, and the headlining feature is you can run TypeScript without a separate build step. The system APIs are different than Node's but those are analogous/easy to learn, and the language itself is still just JavaScript/TypeScript, so there isn't really much to learn.

With that said: I've used it for a couple projects because I'm really interested in its value-proposition, but so far I'm not impressed with the dev experience when it comes to editor integration. It brings its own language server because it has a few tiny caveats, and the language server doesn't work nearly as well as the official TypeScript one. Type changes sometimes don't propagate across files, auto-imports are lacking the file extension (which Deno requires, so you have to go and manually edit them all), etc. Given that frictionless TypeScript support is the major draw, this is a pretty serious issue for me.

I hope it gets there some day, but for me it isn't there yet.

Sorry you've had this experience -- the LSP is improving a lot with every release, this one included, try it out and let us know what you think. We really appreciate issues for the LSP on GH

Thanks- I should probably actually file bug reports :)

I am curious though: why roll your own? It seems like the only real differences are a) URLs/file extensions in the module names, and b) some type declarations for the system APIs (which I'd think just come down to some .d.ts files, not custom LSP logic). Microsoft's TypeScript language server is a wonder of engineering, and I doubt any small independent team would ever be able to go toe-to-toe with it. Seems like a waste to forego that if there's any possibility of utilizing it. A minimal fork maybe, if nothing else?

TypeScript does not actually have a native language server. TSC is just directly shoehorned into VS Code. It is very difficult to extend (we tried with the 1.x and 2.x branch of our extension). We needed to do a lot of trickery to get TSC to do what we want, and even then it would not always work. That solution also only worked on VS Code. Our new LSP works on all editors with LSP support. We are hoping that in the coming few weeks / months the Deno LSP will be just as featureful as TSC + Node in VS Code, and way more performant. We still have some ways to go, but we are slowly getting there.

This is only partially true. TypeScript does have tsserver built in, which is where the language server design originated from (just with a slightly different API). The VS Code TypeScript integration is a layer around that, not a custom implementation. There are also a couple other TypeScript language servers out there (which again simply wrap tsserver and translate the APIs) which work great.

Ah gotcha, that's unfortunate that they integrated it directly, though it explains a lot.

Well I'm glad to hear it's a priority. Best of luck, and I'll try to check in periodically and see how things are coming along! I would very much like to see this project succeed :)

There's a couple of reasons. Internally, there's quite a few things that we do in Rust that aren't actually taken care of by TypeScript -- Having our own LSP allows us to connect those bits (like the module graph resolver for example) directly to the internals of Deno, in-sync with the Deno version you have installed.

Deno also does more stuff than just providing Type definitions, embedding TypeScript and doing module resolution; it's a complete toolset -- there's things that we can cover having our own LSP that the TypeScript LSP can't. Linting, formatting, testing etc.

It's really weird that most responses to you are that Deno isn't a framework, as if changing the category the thing is in would somehow magically remove your choice fatigue, especially considering that the most likely interpretation of your fatigue would make the distinction between runtime and framework fairly meaningless in this case: they are both for practical purposes a set of APIs you must learn on top of an existing language you probably already know. Whether under the hood they are implemented as Rust bindings that require you to run your app in a specific binary, vs. being written in JS, probably doesn't matter, and if anything would make the endeavor more complicated and raise the bar necessary to convince you to learn it even more.

Either way, barring your work forcing you to learn something, or you running into a specific problem that requires you to learn something new, you should really treat frameworks/runtimes/languages/etc. the same as TV shows or comics, and I mean this in a very positive way. If you enjoy it and have the bandwidth for it, then of course pick up a new show or comic and invest some time into it! Especially if a trusted friend recommends it to you. It might introduce you to new ideas or give you a different perspective. And most importantly, you probably won't get as much as you would out of it if it doesn't seem exciting. You won't miss out on it if you decide to punt it until later, I promise you. This isn't some Thanksgiving Day sale, if in a year it's more popular than it is today, there'll only be better articles and tutorials that have been written, more bugs having been fixed, and more libraries already existing for it than today. And if it ended up not being that great, you probably won't hear about it in a year anymore, and you will have spent your time on a thing you do enjoy. So don't force it, if it seems cool to you or resonates with you for any reason, try it, otherwise, no big deal!

Maybe because there are way more JS frameworks than runtimes. It feels like dozens of frameworks pop up every day.

Yes but my point is that this doesn't address the OP's frustration: learning new APIs without a clear sense of what one is getting out of it. Many of Deno's fundamental features are basically framework features. Learning the Deno for-await API for answering HTTP requests is an identical experience to learning a framework that offers that API. "But Deno has fundamental performance improvements" -- Frameworks can also offer fundamental performance improvements. In fact, I can write a Rust-backed binary package for node.js and now we're really in a grey area.

The point is that "its a runtime not a framework" is not an answer as to why he should learn it or not. At least, not without attaching to it a meaningful explanation as to the benefits he'll get from it because its a runtime, but at that point, we're back where we started: just pitch him on what he'll get out of it, don't correct him on technical terminology.

Frameworks tend to dictate a certain way of doing things and introduce a pile of their own concepts and abstractions. Runtimes tend to be unopinionated. There's very little learning-fatigue around Deno, and there's almost no choice-fatigue since it's only the second mainstream (non-browser) JS runtime.

Perhaps in the general case, but Deno is probably as opinionated or more so than your average JS framework choice on node.js. And certainly more opinionated than a more "neutral" runtime change like when Microsoft made the Chakra-backed node.js. For example, choosing to go with Deno cuts you out of much of the npm ecosystem (either due to the specific module model, or simply because the fundamental APIs are different, which is why express won't run "out of the box" on Deno -- there had to be ports of express and koa, etc.), which certainly is a bigger side-effect than switching from React to Vue. It also, to its credit, bets big on Typescript, a very opinionated decision (and I'd argue a good one too!). It bets big on async/await (which is still somewhat contentious in the node.js community, but luckily fading). In other words, there's not a lot of information conveyed from "it's a runtime not a framework," at least not in this case, aside from technical aspects. And again, I think it is precisely worth pitching it on its opinions, like the browser-compatible APIs, etc.

Well, Deno's not really a framework, it's a runtime (like node.js). If you're writing Typescript, it makes that way easier. If you're doing lots of IO, it makes that easier (promises). If you want sandboxing, it has that (though if it's for server software, you should use firejail or Docker or something around it anyway).

does it interop with libs made for node.js and are on npm? e.g. using the official the AWS node.js library

It doesn't load libs from NPM directly, it has its own package management system based around URLs. Most JavaScript/TypeScript logic should port to it trivially, unless they use system APIs, in which case those will have to be converted to Deno's system APIs. But mostly that just comes down to "swap out function X for Y and rearrange the parameters a bit".

So in practice: it's super easy to port something, but most of the time you do actually have to port it, unfortunately.

The canonical answer is _maybe_. If your Node lib relies on Node built-ins, you won't be able to import it directly from GitHub for example. However, CDNs like Skypack and esm.sh do polyfill some of those to Deno. Your mileage may vary depending on the lib you're trying to import. Some will work better on one CDN, some on another -- you really just have to try it for yourself. A surprising amount of libs work without issues.

The AWS sdk v3 works really well from Skypack, check out our docs for our Deploy platform, it has an example with DynamoDB https://deno.com/deploy/docs/tutorial-dynamodb#write-the-app...

Can't comment on sibling, but https://www.skypack.dev/ lets you import many npm packages; I haven't tried the AWS library, though.

That looks pretty cool; it's unsurprising that there's an automated solution since the differences are so small and predictable

Edit: Does this do automated conversion? I can't actually tell

Yes, it's automated.

Deno isn't a framework, it's a node.js alternative. The best pitch I've heard is that it's written by the same guy who did node.js, with the intent to fix everything he thought he got wrong with node.js.

Good news.

Deno tries to be as close to the browser API as possible. So it's easier to learn than Node.js if you come from frontend development.

You're getting a lot of responses. I just want to say that I empathize with you.

I'm not at that point in my life where new technologies don't excite me. I'm still happy to learn new things. But I fully expect I'm going to get tired of the next wiz bang language, the next gee wow framework, the next hot stuff server. I get it.

There's still value in knowing what you know. I wish people didn't think so much otherwise.

It's not a framework, it's a JS runtime on top of v8 (like node).

short_anecdote: don't switch, it's not for you!

Is it technically a framework? I thought it was an entire alternative runtime to NodeJS.

Deno has first-class support for TypeScript. Refactoring code without types is not a pleasant experience.

Deno isn't a JS framework?

You mean it's a runtime, like Node.js? /s

I guess roughly a billion people were just as triggered as I was and now there are all these redundant "actshually" comments :D

That's a rather ignorant thing to say.

You are basically saying "I feel like I have hit a point in my life where I don't want to learn."

It doesn't matter if it's a framework, language, protocol, specification, book, way of coding, or anything else. Learning is how you gain knowledge and stopping ones desire to gain knowledge is never a "point in ones life". It's just being lazy.

Then why are you on here blathering about someone being ignorant when you are being "just as lazy" and not spending this time learning new$x.js instead of arguing on the internet?

Have some compassion/empathy for those of us that don't have the luxury to be able to constantly keep up with what gets churned out every day.

Who said anything about compassion/empathy?

There is a difference between saying I won't try and convivence me otherwise. Versus saying I can't I don't have the time.

OP is very clearly saying I won't, they have given no indication as to the fact they don't have time to learn.

Kind of a leap to go from not wanting to learn the JavaScript techology du jour to not wanting to learn anything.

I have been programming computers since 1988, so I have seen a lot of things come and go. Not often has there been a just relationship between quality and popularity.

Never has that been so stark as with Node.js. So many mistakes, mistakes that have been made before. Such a mind boggling lack of purpose. There has never been a need for Node.js - except to play with the cool kids that programme Javascript on the client, server, on any &&^^*!! thing!

I still do not see the need for Javascript anywhere but in a browser, and with Webassembly, most of the impressive things done in the browser do not need Javascript any more.

So my preference is for Javascript to quietly die out in a dignified exit stage left. But I am not always completely correct. So if you must, then use Deno. Node.js is simply awful. Deno is only useless. A vast improvement.

The third slide of Ryan Dahl's 2009 JSConf.eu presentation (https://www.youtube.com/watch?v=ztspvPYybIY) covers most of the reasons for why it was made: "I/O needs to be done differently". Evented I/O via event loops wasn't really that much of a thing back then, and many server-side web frameworks were simply sitting idle whilst waiting on I/O. Node changed this, and thereby enabled a kind of concurrency that was easy to achieve and there by default, often without the programmer really realizing it, because they didn't have to do anything too special to get it done other than write JavaScript with callbacks.

I don't think JavaScript was really the point of it.

(EDIT: but JavaScript having functions as a first-class citizen, and closures, makes it a very good candidate for something that leverages event loops for this kind of thing)

Do you have an actual experience with nodejs/deno?

There are many (server-side) things where javascript is not a good choice but "smart-proxies" or micro-service-orchestration kinds of things are definitely super-easy to do in nodejs.

I've also done many languages, like really, and I don't know any better for this task.

What's your choice BTW?

Often the worth of a language comes from its ecosystem. Node.js for now has perhaps the biggest ecosystem in history of computer languages and since Javascript is supported natively by browsers, well it makes the number of developers knowing Javascript quite substantial. It's no worse than Python, Perl or others.

I would argue that much of the Node ecosystem suffers from the same flaw as "millions of apps" advertised by Apple and Google on their mobile platform: most of it is useless one-liners, or abandonware.

Now, when you filter it all out, it's still not any worse than Python etc - but it's not any better, either.

And yet it is the most popular programming language in the world.. So maybe you're not exactly right. In the end it's not about what coders need it's what they want.

It's the most popular PL because it ships in every browser out there, and so you have to use it to do any front-end work. It doesn't really say anything about the quality of the language or its ecosystem.

I agree with you its quality but what i'm saying is that didn't matter.

And to counter on the browser bit, Rust/Go/C/etc can be compiled into Webassembly and yet its not thriving. Similarly on the backends Javascript is thriving too.

wasm is still a very niche thing in terms of scenarios that it can cover. Things will be very different once there's a full-fledged native wasm browser API that is at least equivalent in power to what JS gets today.

On the backends, it seems that the only reason why JS even made a foothold there is because it was on the front-end first, and because it had its performance optimized there (V8 etc) first. Node specifically pitched "same language for both front-end and back-end" back in the day.

JS is kind of like C - it just has an immense first mover advantage by now, to the point where it's very hard to move forward from it. I hope wasm will be the holy grail in that regard... eventually.

Node wasn't about bringing JS to the server. The purpose of Node was to bring asynchronous I/O to the web - and it absolutely crushed it.

Reply on news.ycombinator.com