From Node to Deno

https://dev.to/aralroca/from-node-to-deno-5gpn

by aralroca • 6 years ago

182 97 6 years ago

k__• 6 years ago

Desktop apps build on Electron should be a good fit for Deno, because Denos API is more like a Browser API than like the Node API.

tuukkah• 6 years ago

Is there a decent browser (or other GUI framework) in Deno though? It has a wrapper for zserge/webview but I haven't used a webview in ages.

cultofmetatron• 6 years ago

even better if deno bases their web renderer on servo since the deno runtime is rust and servo is rust. Would be great for getting some diversity back in the browser stack.

milutinovici• 6 years ago

The one big thing missing is an ORM. And making those things is notoriously difficult. Hopefully something will turn up

littlestymaar2• 6 years ago

Since the underlying DB driver exists, you could probably fork one existing node one, or even submit a pull-request for demo support in your favorite node ORM.

will_raw• 6 years ago

Curious, Why do you think it will be "notoriously" difficult?

ralusek2• 6 years ago

If something is notoriously difficult, it isn't up to what one individual thinks. That's what makes it notorious.

jdxcode3• 6 years ago

Are ORMs even that great? In my experience they invariably end up just being a messy abstraction to work around.

hn_throwaway_999• 6 years ago

The idea that ORMs are a net-positive is definitely an open question. After 20+ years I'm certainly of the opinion they're not. I recently discovered Slonik (only for postgres, hope there is eventually a port for MySQL and others) and I'm a huge fan of the overall approach and the API. This blog post from the creator explains: https://medium.com/@gajus/stop-using-knex-js-and-earn-30-bf4...

derision2• 6 years ago

I've used a number of ORMs in the past and have not had a great experience, but recently have been using Eloquent with laravel and it's really great

seanwilson2• 6 years ago

The idea that ORMs are a net-positive is definitely an open question.

If it's still being debated, isn't that a good indication that there's no perfect solution for every use case?

ORMs are likely more straightforward when you know you're not going to need to do anything advanced, but get in the way when you need fine grained control for example.

ashtonkem• 6 years ago

While I agree that there are certainly places where ORMs are net negative for the developer, for a language ecosystem having one is net positive.

Lots of app developers need simple and easy to setup database access so that they can focus on the parts of their app that matters. Not having an ORM means that a decent chunk of them will move on to another language/ecosystem that has the libraries they want.

tstrimple• 6 years ago

Sometimes all you really need are simple CRUD operations against a data store for a particular app. Most ORM fill that roll quite well in my opinion. They are also great for rapid prototyping. I think where people run into problems is trying to shoehorn every data operation through the ORM layer, especially for more complicated data storage requirements. That being said, working with knex was a miserable experience.

ralusek2• 6 years ago

Thanks for doing this. I have a few questions regarding packages/dependencies, and TypeScript in general.

I tried installing Deno, and I tried including a package, and immediately the TypeScript typechecking in my IDE (VSCode) failed, of course. The IDE doesn't know what to do with a URL as a dependency. Is this something Deno will be able to handle?

The next question is that TypeScript packages I have written in the past use `baseUrl` and `paths` in their own configs to allow for absolute import paths. When I look at third-party Deno repositories, I didn't see any that were building out to JS/declaration files, and were instead just meant to be included as the original TypeScript source code. Won't this break things like absolute import paths and other behaviors of the dependency's own tsconfig file, or does this work fine with Deno/TS?

brlewis2• 6 years ago

https://stackoverflow.com/questions/54794933/how-to-pull-typ...

Looks like there's a plug-in. Can't research much now, but I hope there's something like that for emacs tide.

brlewis2• 6 years ago

I think for emacs/tide I'll just be able to follow the instructions for Atom here: https://github.com/justjavac/typescript-deno-plugin

aralroca• 6 years ago

For VSCode there is recommended this:

* https://marketplace.visualstudio.com/items?itemName=axetroy....

adrianhel2• 6 years ago

It's an unstable feature, but you can use import maps with Deno.

hn_throwaway_999• 6 years ago

I'm really curious about whether people think Deno will succeed. Node certainly has its warts, but I feel like with recent improvements in the JS language and Typescript that Deno doesn't really solve problems people have nowadays. I don't think the decoupling from NPM and the dependency management approach (or lack thereof) is really a thing that most developers want. NPM certainly had a bunch of "dumpster fires" for years IMO (lock files mess, signed code mess, etc.) but I feel most of those pain points have largely been addressed.

I downloaded Deno and tried it out, but at this point I'm just left thinking it doesn't really add anything for me that I need.

xkapastel• 6 years ago

This is puzzling to me because I had the opposite reaction: among other things, Deno solves an incredibly important problem with Node, which is the complicated configuration used with most projects. Deno can perform, out of the box, many of the things you'd need to configure Webpack + Typescript to do:

    SUBCOMMANDS:                                                      
        bundle         Bundle module and dependencies into single file                         
        cache          Cache the dependencies                                                  
        completions    Generate shell completions     
        doc            Show documentation for a module                                         
        eval           Eval script                       
        fmt            Format source files                                       
        help           Prints this message or the help of the given subcommand(s)
        info           Show info about cache or info related to source file
        install        Install script as an executable
        repl           Read Eval Print Loop
        run            Run a program given a filename or url to the module
        test           Run tests
        types          Print runtime TypeScript declarations
        upgrade        Upgrade deno executable to given version

What would it take to get Node to do all of that? Which documentation tool would you choose, and how would you configure it? Testing? Bundling? Formatting?

hn_throwaway_999• 6 years ago

Totally agree with all that, but I also think it's one of those things that most devs hit the pain point for once, and then have a standard template project they use for everything going forward. I.e. I have all my webpack/tsc/eslint/prettier/jest boilerplate set up once, so now it's not really an issue for me.

I also think this is a problem area where the Romejs project is taking a better approach: simplify and fix the toolchain, instead of replacing the entire runtime.

harikb• 6 years ago

If anyone remembers, this is similar to the “Turbo Gears” vs “Django” of Python world. Turbo Gears allowed me to choose the best of each component - but pretty soon one ends up having to upgrade or migrate to the new-best-sub-component on a weeekly/monthly basis. django helped avoided a lot of headache by defaulting a decent, but not necessarily the best tool, and sort of “won” in the end.

For some reason, we continue to replay this fight in each and every language and environment.

satvikpendem2• 6 years ago

Static compilation of JS into a binary is also being worked on (albeit slowly) with `deno compile`[0]. This is the feature I'm most looking forward to personally, goodbye JS slowness.

[0] https://github.com/denoland/deno/issues/986

jariel4• 6 years ago

None of those are very important.

When node appeared, it was a 'huge thing' because you could run JS consistently on the server-side, with some kind of packaging scheme.

Most of the things you listed aren't going to be useful to most, even when they are, they are small things that can be managed otherwise. Though admittedly, everyone will runt into at least one of those issues.

For a large, complex deployment, there's no obvious reason at all to shift to Deno.

We'll have to wait and see how it works out for those who want to try it for fun.

Snelius2• 6 years ago

And why it can't be added to the node? Why we need the brand new incompatible engine for that

macintux• 6 years ago

I can say that the word “sandbox” immediately raises the interest level among security folk.

dingdingdang• 6 years ago

The big deal here is security by default as enforced by the runtime (deno) itself - there is afaik none other doing anything remotely as cool anywhere. It in effect makes it super safe to run code since you have to explicitly allow the various levels of system access.

Also makes the system fundamentally unattractive to malware authors whereas installing modules via node.js is like leaving your front door open and taking a chartered holiday while hoping for the best.

jfkebwjsbx• 6 years ago

there is afaik none other doing anything remotely as cool anywhere

Any operating system with "capabilities", "namespaces", "privileges", etc.

That includes Linux, Windows and many others.

jariel4• 6 years ago

Most folks running Node.js instances have control over all of the software they are running and 'security' in this sense just isn't a huge concern. Obviously, more security is alwasy better all things being equal, but it's not the big issue with Node.js.

It seems that Deno is probably a nicer, overall version of Node, and if we were 10 years ago, undoubtedly, we would chose Deno. But we're not, we have massive installed bases and operating capabilities, so the choice is less obvious.

crabmusket2• 6 years ago

The developments in WASI's security model are very interesting - see this post: https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...

cozuya• 6 years ago

It will succeed if it handily wins side by side benchmarks, its that simple.

oweiler• 6 years ago

I doubt it. For a lot of use cases node is fast enough.

jariel4• 6 years ago

No, performance is not the issue most of the time.

For most systems, the raw performance of the JS just is not a bottleneck.

nicoburns• 6 years ago

I'm not seeing enough in Deno that would tempt me to drop compatibility with the Node ecosystem. What I really want is actual Node.js with native TypeScript support.

Snelius2• 6 years ago

I think the best is a TS to binary right away :)

crabmusket2• 6 years ago

I am actually really interested to see if something like Deno can take over in programming education.[1]

Deno's extremely simple import semantics and built-in tooling could make it a great environment for a learner. They won't have to be exposed to package management, they can just click a URL in their source code and see the exact source code they just imported.

All the stuff that professional developers can do and might want to do for themselves (setting up testing frameworks, pinning transitive dependency versions) is kind of out of scope for educational use. Unless that education is specifically targeted at "how to do modern JS development within this specific ecosystem".

The ease of bringing TypeScript into your Deno programs may make it easier to start "graduating" to static typing as part of the curriculum, without being like "okay, that was Python! Next up: Java!"

[1]: Say what you want about JavaScript, I don't see that modern JS is significantly worse than Python for learning to program (having watched a couple of students go through Python courses). All languages have their warts.

truth_seeker4• 6 years ago

Few things comes to my mind if you are moving from NodeJS to Deno:

1. Deno lacks the library eco system which is required to build a production level app today. I am not saying it cant be done. Just think of the different third party service integration modern application has to do, their maintainance and testing by individual vendors or open source contributors ! Blogs mentions few DB driver libraries, i highly doubt they are as mature.

2. Deno's security model overly hyped at least i see it this way. In last few version of NodeJS, many security flaws have been addressed, see their changelog if you dont believe me. But most importantly, security flaws with native JS is handled by V8 which is common to both NodeJS and Deno. On top of that, most of the libraries and frameworks in NodeJS during their various releases sorted out many security issues in their code. If someone is still doubtful they can use eslint-plugins for sanity and security checks in their JS files. Adopting Typescript also helps if you cant live without types.

3. Learning curve to adopt new SDK for Socket API, File API, System call API etc. I don't think NodeJS falls short significantly anywhere, in fact it provides more and those APIs have been relatively more battle tested over the years.

4. Irrespective of using NodeJS or Deno, following a BDD/TDD practices to ensure sound test coverage of your business use logic still remain the most promising tool to make, break and refactor your codebase.

nitsky2• 6 years ago

Regarding point 3, Deno's APIs use language features that were unavailable when node was written, including promises and async iterators. That is a big improvement IMO.

truth_seeker4• 6 years ago

You can easily PROMISIFY the low level callback style NodeJS SDK APIs using in-built utilities.

https://nodejs.org/dist/latest-v8.x/docs/api/util.html#util_...

It was introduced in NodeJS 8.x release. The latest LTS version is 12.x

thosakwe• 6 years ago

Solely addressing #1 here, and this may come off harsh, but I think it's ridiculous to expect Deno to match the library ecosystem of Node on day 1. That's just literally impossible, but whenever a new language or runtime is released, it manages to become the most prominent question/concern.

It also is something of a moot point anyways, because people pushing something into production already are probably not using something so new. Early adopters don't care about how mature the ecosystem is; part of the appeal of being an early adopter is helping to build that ecosystem...

tosserup478• 6 years ago

Well, you should scratch language there. kotlin did manage to start with the huge ecosystem of Java without hassle

mcintyre1994• 6 years ago

There's no way it's going to match everything, but regarding number 1 - it does look like you can drop in some node modules. A small example, but one that surprised me - React works. So you can do React with SSR with nothing else, eg. this demo is a pretty refreshing one to see how few moving pieces there are. https://github.com/brianleroux/arc-example-deno-ssr . It's just imported as `import { React, ReactDOM } from 'https://unpkg.com/es-react'`

truth_seeker4• 6 years ago

By no means i am demotivating anyone. I have just enumerated the minimum possible evaluation criteria and current state of development. This is what i often do at my workplace as an Architect.

If someone is eager to try out new possibilities in Deno and their application use cases intersect well with what Deno has to offer, then by all means it's a good decision.

ljackman3• 6 years ago

It looks like a good evolutionary improvement over Node.js. However, I have a concern about its security claims. Perhaps someone on the project can allay these concerns.

My brief skimming of its site indicates that its security model is based around the ability to disable, say, network access for whole Deno programs. However, does it allow starting up with network access, allowing a subset of the program to handle it, and then dropping those rights for the rest of the program, _especially_ subdependencies?

I can't see any mention of a more fine-grained approach: https://deno.land/manual/getting_started/permissions

A modern Node.js web service will have hundreds, if not thousands, of indirect dependencies. Some network access will be required for at least the Express routing, or an equivalent.

For a Deno equivalent, this would amount to enabling network access for all hundreds of those subdependencies, not reproducing the isolation in capability-based security such as WebAssembly nanoprocesses.

Have I missed something here? That doesn't seem like much of an improvement over Node.js except for very small and contained programs. Yes, Deno's dropping of centralised package repositories and package.json might alleviate this problem _somewhat_, but the same fundamental issue seems to remain.

surajrmal2• 6 years ago

Yes this is supported: https://deno.land/manual/examples/permissions

surajrmal2• 6 years ago

Yes, this is supported: https://deno.land/manual/examples/permissions

ljackman3• 6 years ago

That's a good start, supporting the dropping of privileges after performing something on startup.

What about keeping the network allowed in the layer handling, say, inbound HTTP connections, but blocking it in the data access layer or purely computational component?

From what I can see, this doesn't work with global boolean flags in the runtime, instead requiring isolated tasks with whitelisted capabilities passed in, some form of "immutable, set-once, dynamically-scoped capability flags", or something like that.

The problem with the global boolean flag approach is that if any part of a service needs it constantly, the entire program gets it, even obscure subdependencies for generating colour pickers.

Don't get me wrong, it's an incremental improvement over's Node.js blase approach. It's also quite niche to see languages support this feature. E was one of them. There was another newer Python-like language with this too, starting with an `M`, but its name escapes me.

I'd recommend Deno's developers look at E a bit more before committing too much to the platform boolean flag approach. Or I've misunderstood their approach and it actually does more than I'm giving it credit for.

hota_mazi• 6 years ago

This looks pretty hackish.

What would be really useful is if only sections of code can be delineated as requiring certain permissions. This way, it's much easier to see what parts of the code do what and also to make sure that users only get prompted for such permissions when the code actually runs.

sramam2• 6 years ago

Permissions are a whitelist.

While the grant is a blanket grant to a program and all dependencies, typically, a well behaved program will seek a limited scope of permissions. Like "https://my-program.com", "https://preferred-analytics.com" etc.

This prevents dependencies from using call back locations that are outside the permitted list, preventing much of the nefarious activity they can dream up.

If a dependency needs access to specific resources, it can advertise this fact and the parent module can in turn request this from the user.

Importantly, the user is explicitly aware of these & controls it in an absolute sense, at run time.

ljackman3• 6 years ago

The whitelisting looks great. Even with the remaining concerns I raised in the other comment, the ability to whitelist only allowed domains for network connections is a massive step up security-wise, even if they are allowed for the entire program (until revoked globally).

hn_throwaway_999• 6 years ago

Importantly, the user is explicitly aware of these & controls it in an absolute sense, at run time.

I mean, I guess I see value there for the use case of "I want to download a script to run locally on my machine" type of thing, but for the most common use of Node, i.e. I'm running a server process, does this really even matter?

LunaSea• 6 years ago

The file system module's permissions are however still vulnerable to symlinks for example:

https://github.com/denoland/deno/issues/2318

BenoitEssiambre• 6 years ago

Also, "promise first" seems to be premature to me. You could have simpler, more stateless async/await without promises: https://www.npmjs.com/package/casync

dzonga• 6 years ago

and the great migration begins. but when you look at other backend ecosystems e.g php, ruby on rails they're still getting shit done. even though people might say those languages/frameworks might be slow or insecure. stability is what's lacking in the JS ecosystem. glad I do my backends in flask now

Roboprog• 6 years ago

Maybe it would be OK if all the Typescript people went Away to Deno and the few of us left who just want to run plain JS on Node, could, in peace.

... As long as there is enough interest still in Node to maintain it. Hopefully, there is still interest in running the same language as browsers do, without additional dependencies.

Personally, I would prefer Clojurescript to TS, but not strongly enough to want to be tied to its fate.

dang• 6 years ago

The other major threads so far:

https://news.ycombinator.com/item?id=23172483

https://news.ycombinator.com/item?id=23093737

https://news.ycombinator.com/item?id=22102656

https://news.ycombinator.com/item?id=20373430

https://news.ycombinator.com/item?id=17183241

Let me know if I've missed any.

DrFell• 6 years ago

Using JavaScript outside a browser by running the V8 JavaScript browser engine on the server is a bit of a gimmick, but enough people can't bother to be a polyglot, and it's not that crazy.

But, once you are writing code in TS, then transpiling that to JS, then running that in V8 on a server, you have taken a big step into the Rube Goldberg dimension.

thelazydogsback• 6 years ago

What Node is missing due to it's design is parallel (not just async-on-a-single-thread) processing using either green or OS threads without the overhead of serialization to web-workers or a cluster. Last time I checked, Deno didn't have a story there.

From Node to Deno

Related Stories