Live data from Hacker News

Deno 1.9

deno.com

161–170 of 245 posts

Re: Deno 1.9

#162

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.

s/Node.js/perl

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

Re: Deno 1.9

#163
post #159
post #88

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 obj…

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 tho…

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.

Re: Deno 1.9

#164
post #78
post #56

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 clien…

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 e…

I'd say v8 being nicely engineered and happening to be a JS engine made it natural as well

Re: Deno 1.9

#165
post #39

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.

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

--allow-plugin allow loading plugins.

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

--allow-run allow running subprocesses.

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

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

Re: Deno 1.9

#167
post #55

Earlier quoted context omitted.

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 fo…

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!

Re: Deno 1.9

#168
post #107

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…

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.

Re: Deno 1.9

#169
post #107

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…

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.

Post reply on HN