
What the Hell Is a Deno? - harrylucas
https://breadth.substack.com/p/what-the-hell-is-a-deno
======
dvt
> Javascript is great. But... in saying that it has a few quirks and can work
> in some unexpected ways.

Typescript has just as many[1] (in fact more, as it's a superset) quirks than
Javascript. I like using it (and it makes JS type-safe-ish), but it's not
really some kind of paradigm shift.

Not sure how I feel about import maps. They are quite literally the same thing
as package.json. In fact, converting between the two takes about 20 lines of
code[2]. I'd bet my bottom dollar that everyone's going to use them, which is
going to lead to exactly the same types of problems as Node.

[1] [https://blog.asana.com/2020/01/typescript-
quirks/](https://blog.asana.com/2020/01/typescript-quirks/)

[2] [https://github.com/WICG/import-
maps/issues/60](https://github.com/WICG/import-maps/issues/60)

~~~
torb-xyz
Frankly I find TypeScript with strict mode turned on to be a safer and saner
than C# and Java because of explicitly nullable types alone. I _never_ get
null pointer exceptions in my own TypeScript code. Combined with fairly strict
ESLint you get something that catches a lot of problems at compile time.

Of course it's still far cry from being as safe as for example Rust.

And yeah the inconsistency of JavaScript/TypeScript can be frustrating for
sure. I think my dream language is one that is simply TypeScript cleaned up to
be made consistent and sheds a lot the features and retains a simple core.

~~~
pjmlp
C# 8 has support for non nullable references.

For lower C# versions and Java you can get your strict mode turned on via
static analysis tools.

I have been using Sonar on CI/CD builds since 2008. Static analysis errors
break the build, plain and simple.

Also quite convenient for writing sane C and C++ code by the way.

------
fearingreprisal
For me this is a case of "too little, too late". I've been burned too much
over the years by the Node ecosystem to risk investing any further interest in
it now, even if it has marginally improved.

I have worked extensively with Typescript, which I consider to be the minimum
viable solution within the Node ecosystem. Typescript shouldn't even be seen
as a 'nice-to-have. It should be seen as a required remedy for some of the
mistakes of a terribly engineered language. Javascript should never have been
considered a serious language for back-end development. Node.js to me seems
like someone's 'Frankenstein's monster'-esque experiment that escaped its
captivity and wreaked wide-scale havoc on the surrounding world.

~~~
hombre_fatal
This doesn't make sense to me.

Javascript is a breath of fresh air after writing async code in almost every
other ecosystem from Go to Java to Python to Swift. Pretty much any async code
snippet in those languages can be improved by porting it to Javascript.

Async/await + the ubiquitous Promise make it my go-to choice for writing
anything networked. Especially over the other popular dynamically typed
languages.

~~~
brabel
If you think async/await is the holy grail of networking, you're up for a
surprise in the next few years.

The problem with async/await:
[http://journal.stuffwithstuff.com/2015/02/01/what-color-
is-y...](http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-
function/)

A solution proposed by none other than Java (available as an experimental
feature in JDK 15):
[http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h...](http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html)

This seems to me to obsolete async/await, quite honestly.

~~~
hombre_fatal
Don't fall into the trap of thinking that just because you've found a blog
post that could enumerate the downsides of something that the alternatives
don't have the same trade-offs.

I've responded to that ancient blog post many times on HN by now. Since you
must think that blog post is pretty good criticism of async/await, here's a
little challenge for you: which language do you think doesn't have an
equivalent of the "red vs blue" problem? :)

~~~
brabel
> Don't fall into the trap of thinking that just because you've found a blog
> post that could enumerate the downsides of something that the alternatives
> don't have the same trade-offs.

I've been using async/await for a long time and I thought it was great, but
since I started using JDK15 virtual Threads, I feel like it's way superior in
every way. If you have some trade offs you would like to mention, please do.

> which language do you think doesn't have an equivalent of the "red vs blue"
> problem?

Any language that distinguishes between async and non-async functions will
have this problem. I believe one language that works around that is Erlang, as
Erlang seems to do everything async (but it's not visible to users, but I am
not sure). The proposed Java virtual Threads solve that problem as well. You
should open your mind to new ways of doing things, this is by no way a solved
problem as you so strongly seem to believe.

------
osrec
I like the concept of Deno, and especially love the shift away from NPM. NPM
was probably the main reason I never fully embraced node.js. I truly hated the
bloat of the modules folder, and the impending fragility the dependencies
would bring.

I like the idea of a standard library. This will hopefully only improve with
time. It sort of brings the ease of use factor of PHP to a server side
JavaScript environment.

I'll be watching Deno very closely these next few months!

~~~
tannhaeuser
The set of core libraries like express (fka connect) + dependencies _is_ the
stdlib. It was developed in early node.js days as part of CommonJS, which was
an initiative for a portable/modular server-side JavaScript runtime with many
implementations besides node.js (RingoJS, Narwhal, Helma, TeaJs/v8cgi). The
existence of a community-driven lib effort, the portable nature of JavaScript,
and the existence of choice was the entire reason I even looked into node.js.

~~~
jfkebwjsbx
Other languages had all that, plus a better standard library, plus a type
system, for years before Node was a thing.

Node got popular because it enabled frontend devs that only knew JavaScript to
move easily to backend, not any technical reason.

------
sholladay
I am the author of Pogo, a web server framework for Deno that has friendly
APIs and is secure by default. It supports React out of the box and has the
best documentation of all the frameworks.

GitHub: [https://github.com/sholladay/pogo](https://github.com/sholladay/pogo)

Video tutorial:
[https://www.youtube.com/watch?v=Fe4XdAiqaxI](https://www.youtube.com/watch?v=Fe4XdAiqaxI)

~~~
bufferoverflow
> _" and is secure by default"_

Extraordinary claims require extraordinary evidence.

~~~
sholladay
I think you misunderstood me. I simply meant that the default configuration
optimizes for security. For example, Deno and other frameworks listen on
`0.0.0.0` by default, which is convenient for development but is not worth the
security concerns, in my opinion. Instead, Pogo uses `localhost` unless you
explicitly override that setting, meaning much less risk of accidentally
exposing your server publicly. This is not some revolutionary feature, it's
just attention to detail that I think you'll notice cumulatively.

Additionally, I would like to pay for a thorough security review when we have
more features and users. I doubt any of the other frameworks will do that as
it's extremely rare in OSS. Of course, that means very little until it
actually happens. But know that my intention is to deliver the first Deno
framework that I would personally feel comfortable using in production.

------
CalmStorm
Deno's sandbox security is somewhat similar to Mandatory Access Control (MAC)
implemented by SELinux and AppArmor. But it looks like not as fine-grained as
MAC. In the example:

deno run --allow-net myWebserver.ts

With SELinux, one can specify the port range and network interface that the
application is allowed to access. It also provides audit log that can be
examined by the admin. Maybe there is no need to reinvent the wheel but just
use some form of MAC if you really care about security.

~~~
jessaustin
Am I wrong in thinking that this example specifically does _not_ protect
against the threat posed immediately preceding it? As in, one is running a
script that foolishly imports a nefarious package that uploads tasty
environmental variables to an evil server, which it can do when network access
is not controlled. Well, what if myWebserver.ts imports that package? A more
fine-grained approach that limited network access by source file might be
valuable.

~~~
wwweston
> A more fine-grained approach that limited network access by source file
> might be valuable.

This is what I think I'd like to see as well. The most common case isn't that
I don't trust the _program_ I'm running, it's that the level of trust for my
dependencies plus their dependencies is essentially opaque.

------
danenania
Deno definitely looks interesting!

All the examples I’ve seen so far are using the ‘deno’ command to run .ts or
.js scripts. Can it also package standalone binaries like go/rust—-to make a
cli tool, for instance? If so, how do permissions work in that scenario? Does
the user need to grant permissions on every invocation or is there some way to
whitelist a script/binary?

~~~
rahulete
Packaging to standalone executable is being worked on
[https://github.com/denoland/deno/issues/986](https://github.com/denoland/deno/issues/986)

~~~
danenania
Nice! Will be interesting to see how permissions work in that case.

------
irjustin
My gripe with npm was the lack of a lock file.

\- Yarn helped solve that, but because of its backwards compatibility to
node_modules, you could not have different versions sitting side-by-side.

\- Node_modules could have a different version installed vs lock file and no
one would know without looking.

It seems Deno is able to solve the side-by-side versions and distributing the
'lock' to the file itself. The Deno team is trying to create a 'map' file to
consolidate the 'distributed version' issue.

Sadly, Ruby's Bundler has solved this for years and while I love TypeScript,
I'm always saddened by the state of package management in the Node space.

I'm not saying Bundler perfect, but its basis with canonical lock and ability
to have side-by-side versions allows me not to think about that issue.

~~~
frankpf
> \- Yarn helped solve that, but because of its backwards compatibility to
> node_modules, you could not have different versions sitting side-by-side.

> \- Node_modules could have a different version installed vs lock file and no
> one would know without looking.

> Sadly, Ruby's Bundler has solved this for years [...]

I don't understand your first point. Different projects can use different
versions since the modules are installed locally (inside the `node_modules`
directory). And nested modules can also have different dependency versions,
e.g.:

    
    
        A
        => depends on B @ 1.0
        => depends on C, and C can depend on B @ 2.0
    

Regarding your second point, I haven't ever seen that happen in practice and
IIUC it's mostly a property of the the fact that `require 'bundler/setup'`
checks your dependency versions, and you could implement something similar for
JS (e.g. traverse node_modules directories recursively checking if the
versions declared in the package.json of dependencies match the ones in your
root lockfile).

Since we're on the topic of Ruby and JS, Ruby's module system is probably one
of the worst I've ever seen and JS one of the best.

In Ruby, just like in Python, everything in a file is public by default and
the only way to make things private, AFAIK, is using Module#private_constant,
and that only works for methods/inner classes/things in a class scope.

And, unlike Python's import, require is side-effectful! If you have file a.rb
that requires b.rb, and b.rb requires c.rb, everything in c.rb will be visible
in a.rb. This is terrible.

JS's module system is one of the best IMO (better than haskell, python, java,
etc):

\- simple mental model: a file is a module

\- everything in a module is private by default, you have to explicitly mark
things with `export` to make them public

\- You can either qualify imports or explicitly import individual functions,
so it's always possible to find out where something is defined by simply
looking at a file. Most languages fail here. This is useful for beginners and
in places where you don't have an IDE available, like GitHub

~~~
irjustin
> Different projects can use different versions since the modules are
> installed locally (inside the `node_modules` directory)

I'm speaking about within the same project. It's not hard to have problems
over time when node upgrades (for example[0]) or to get a different version
than expected.

Any project that's lived long enough runs into some sort of version mis-match
where the solution is `rm -rf node_modules`.

Deleting and reinstalling the package folder as a regular fix is symptomatic
of a deeper package issue.

Deno solves parts of this by giving module versions their own explicit folder.
I'm concerned if it still stores the package locally that you can still run
into a deno version mismatch.

.rbenv + Bundler's folder structure has been
`.rbenv/versions/2.6.5/lib/ruby/gems/2.6.0/gems/mime-types-3.3`

The version of ruby and the version of the gem are explicit allowing
separation.

Again, far from perfect, but this keeps out so many problems.

> Since we're on the topic of Ruby and JS, Ruby's module system is probably
> one of the worst I've ever seen and JS one of the best.

This thread is about package management. While fair criticism, it's too
sideways.

[0] [https://stackoverflow.com/questions/46384591/node-was-
compil...](https://stackoverflow.com/questions/46384591/node-was-compiled-
against-a-different-node-js-version-using-node-module-versio)

~~~
frankpf
Your original point was:

> you could not have different versions sitting side-by-side.

bundler can't do that either. You can't depend on both rails 5 and rails 6 in
a single package. Most languages can't do that.

> Any project that's lived long enough runs into some sort of version mis-
> match where the solution is `rm -rf node_modules`.

I agree, but that's not the only solution, as I've said you could write
something similar to require "bundler/setup" in JS that does version checking.

> The version of ruby and the version of the gem are explicit allowing
> separation.

You can specify the node version in your package.json.

EDIT: on the version checking point, I agree that this is a deficiency of npm.
It probably should ship something similar to bundler/setup by default and
encourage users to do

    
    
       require('npm/validatePackageVersions') # or import 'npm/...' in es6
    

in their top level code.

I was just pointing out that this is not a fundamental limitation of npm, and
it should be fairly easy to implement in user-level code

~~~
irjustin
> bundler can't do that either. You can't depend on both rails 5 and rails 6
> in a single package. Most languages can't do that.

You're right. Originally I was speaking about package versions which deno does
solve, but then I brought in node versions w/o explicitly stating so.

That's managed/wrapped at rbenv's level which I hope deno can come up with a
way to solve it. But looking at deno briefly, it appears the packages are
still stored locally which leaves the deno version mismatch a possibility
still.

------
pacoverdi
I assume that permissions are given at application level, not at module/import
level?

This means that if I write an application that requires filesystem access and
has external dependencies, I'm essentially giving them access to the
filesystem even if they don't need it.

These dependencies could silently check whether they have permissions and do
something fishy only if that is the case.

It would be nice to be able to import dependencies in a nested sandbox but I
guess it is not a simple problem.

~~~
SCdF
I haven't looked into it, but TFA suggests you can do it call by call.

~~~
pacoverdi
Well I'm not sure. The doc says:

 _Access to security sensitive areas or functions requires the use of
permissions to be granted to a deno process on the command line._ [1]

The only other mention of permissions in documentation is that a program may
query or revoke permissions.

[1]
[https://deno.land/manual/getting_started/permissions](https://deno.land/manual/getting_started/permissions)
[2]
[https://deno.land/manual/examples/permissions](https://deno.land/manual/examples/permissions)

EDIT: formatting

------
memexy
Deno is on my list of tools to play with. It's sandboxing capabilities are the
main selling point for me because it will allow executing semi-trusted/un-
trusted code on private data sets. If I know that the code can't access the
network or do anything fancy with the file system then I can treat the
untrusted code as a pure function and know that the output will only depend on
the input. This is a very desirable property and I'm looking forward to the
type of code and data sharing it will enable.

~~~
jfkebwjsbx
Sandboxing has been possible for many years before Deno. Running untrusted
code is not popular for good reasons.

~~~
memexy
I'm aware but Deno allows more programmers to take advantage of those
capabilities in a way that will make sense to them which will lead to more and
better applications. I think every programmer intuitively understands what
network and filesystem access means. Deno has made sandboxing much more
approachable and since those capabilities are front and center instead of some
hidden feature more people will take advantage of them to structure their
applications.

------
aabbcc1241
The example on permission isn't great. It said the library you used cannot
access your database password from env and send it over the internet unless
you allow so.

When you're putting database password in the env, most likely you need to
permit env var and network access for your database client library. Then at
the same time, the library in example can do that malicious thing.

The problem here is, deno request the permission per process, not per library
import

~~~
andolanra
One thing you can do is explicitly _revoke_ permissions. This allows you to
start the program with more permissions and then give them up as the tasks
that required them are done, e.g. allowing environment variable access at the
beginning and then revoking it before you start a server:
[https://deno.land/manual/examples/permissions](https://deno.land/manual/examples/permissions)

It's not as fine-grained as allowing libraries specific permissions, but it
gets you part of the way there.

------
mrpopo
> Both the browser and node.js use the same engine - the V8 engine.

RIP every other engine, I guess?

~~~
akdor1154
> RIP every other engine, I guess?

In practice, pretty much :(

~~~
applecrazy
React Native uses JavaScriptCore, the JS engine for WebKit, at runtime.

~~~
statictype
Only on iOS right? Or is it embedded everywhere?

~~~
soylentgraham
Embedded in IOS & OSX, but one of the few that's easy to get a build of (or
compile) in Linux, Windows, Android

Chakra also easily builds on osx, ios, embedded in windows.

V8 is a PITA to build & get a build of. (Wish it wasn't)

------
leeoniya
do permissions in deno propagate to all dependencies recursively? like, if i
grant filesystem access to a top-level script, did all its imports just
inherit that permission, too?

if so, i can see this type of system being mostly worthless.

~~~
etaioinshrdlu
Yes... it would actually be quiet amazing to have different libraries in
different sandboxes with defined communication channels.

The browser actually does something quite a bit like this with iframes.
Iframes are sandboxed and can only communicate through postMessage. There's
more to it but at a simple level it looks like this.

Chrome nowadays even runs iframes in a separate process! Finally...
[https://www.chromium.org/developers/design-documents/oop-
ifr...](https://www.chromium.org/developers/design-documents/oop-iframes)

This is actually quite impressive because it presents a decent illusion to JS
that all frames are running under the same thread.

~~~
memexy
You could implement this by fine grained imports and subprocess execution.
Node.js actually has a very nice sub-process communication API:
[https://nodejs.org/api/child_process.html#child_process_subp...](https://nodejs.org/api/child_process.html#child_process_subprocess_channel).

At some point I remember writing some gpg wrappers with Node.js and I remember
the subprocess API being one of the more pleasant ones to work with. In the
case of more stringent Deno process sandboxing, the parent process would spawn
another Deno process with a smaller set of capabilities.

~~~
Pozzuh
Deno uses the web standard Worker API to implement sub processes. They are
also working on fine-grained permissions for these workers [1].

[1]
[https://github.com/denoland/deno/issues/4867](https://github.com/denoland/deno/issues/4867)

~~~
memexy
Good to know and even better than my proposed solution then. If the language
supports it directly then there is no need to write sub-process shims for
managing permissions.

------
marcodave
Some random comments: \- good to see native TS support

\- Would be nice to see a builtin maven/gradle-like standard build system,
which IMHO not having it in node.js was a major let down for me. Sure, you
have gulp/grunt, but having to write repetitive code (which can be buggy!) for
running a compiler/test/packager? With another set of plugins? just give me
some standard tool and let me call the equivalent of "mvn package", which will
compile/test/package my application with sane defaults.

\- the dependencies-as-URL is going to be hit hard as soon as some big fish
corporation wants to use Deno for some in-house projects. What if those corps
disallow calling [https://deno.land/my/dep](https://deno.land/my/dep) and
pretend to use internal repo? now all 3rd party dependencies won't work unless
manually modified to use the internal corp repo.

\- I predict that the --allow-this --allow-that will evolve in a
SecurityManager-like complexity, that only the early enthusiasts will
understand, and the rest will simply put the equivalent of "\--allow-all" and
let the ops deal with security issues

~~~
0-O-0
Build systems are generally required for frontend code and that's a bit out of
scope for a project like this. Even if it wasn't - frontend landscape is wild
and everchanging - arriving at sensible, useful defaults would be very hard.

------
esperent
Node with a hat and fake moustache.

------
ldeangelis
One point that was not mentioned: Deno is distributed as a single binary.
Combined with the security options, I think it's a great feature for small
scripts in an enterprise context.

------
thawaway1837
The security stuff for NodeJS is really frustrating. If anything, NodeJS is
more secure than something like the JVM or C++. If I include a 3rd party
package in the JVM, I have absolutely no guarantee that it will work well,
much like in Node. In fact, in Node, I can actually read the source code and
see what the package is, running is doing. In nearly every other environment,
you may simply have access to a binary, with maybe some interface info.

So why do people not throw the same kind of fit about nearly every other
programming environment as they do for Node/NPM? And frankly why do those
other environemnts not have the ridiculous security breaches we have seen in
Node/NPM land?

The real problem with Node/NPM i suspect is a lack of a standard library.
Simply having a standard library would have greatly reduced dependency and
package hell. Further, a standard library would mean people would be more
willing to write a little more code rather than include a new dependency.

~~~
jfkebwjsbx
Because in those languages:

. dependencies are carefully considered by users

. dependencies are not added recursively

. dependencies try to be dependency-free themselves to assist with the
previous point

. dependencies are not blindly nor automatically updated

. dependencies solve important domain problems, they are not trivial one-line-
functions

. dependencies are typically developed and tested by a known team or company,
which you trust, not just someone random

. binaries can be signed

. support contracts are a thing

. etc etc etc...

~~~
lol636363
This is 100% true especially stupid libraries that are someone's class
project. And JavaScript developers are so used to dependency hell that one of
my developer imported 3rd party package for date formatting.

~~~
com2kid
JS's built in date formatting/handling is terrible and often do what needs to
be one.

MomentJS may be a giant import, but it _works_ an it works really well.

~~~
jakobloekke
It’s the closest thing we have to a useful standard library. Date handling in
js without a library is a code smell.

~~~
lol636363
I am confused, are you using MomentJS for fancy output like 3 days ago etc or
for simple output like 5/31/2020? I can see how it is useful in former case
but seems overkill in later case.

~~~
runarberg
Safari is lacking in support (again) but we have `Intl.RelativeTimeFormat`[1]

    
    
        new Intl.RelativeTimeFormat("default").format(-3, "day")
    

1: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/Intl/RelativeTimeFormat/RelativeTimeFormat)

------
randombytes6869
Deno is the Java-fication of JS. I'm sure there will be Node-like tide of "JS
is better than Java now that we have X" even though Deno brings JS closer than
ever to Java. Despite being cynical, I don't think its a bad thing. Java does
a lot of things right.

Deno -> Java

Runtime security options -> Security Manager.

URL based packages with simple HTTP-> Maven works same way.

Bigger standard library -> Java's is huge.

Types -> Java, yes.

Single executable -> Fatjars.

All the features mentioned in this article have been in Java over a decade.
Its relieving to see a JS runtime that finally gives in to enterprise
niceties. Us Java devs like to crap on JS for reasons besides being "boomers".
The features Deno brings were all real reasons to use Java instead of JS up
until this point.

Now if they would only fix threading, I would consider Deno/JS a real
contender for backend dev

~~~
SPBS
Funny, I thought it was the Go-fication of JavaScript. Look at the
'contributing' section of their stdlib: "deno_std is a loose port of Go's
standard library. When in doubt, simply port Go's source code, documentation,
and tests. There are many times when the nature of JavaScript, TypeScript, or
Deno itself justifies diverging from Go, but if possible we want to leverage
the energy that went into building Go. We generally welcome direct ports of
Go's code."

~~~
randombytes6869
For Deno this seems like a very good choice. Pick the good parts from Go and
reuse them. I applaud Deno for going its own way with the module system
though... That's been a hot topic in Go for a very long time

------
sktrdie
I love how Browsers & Deno have shown how we can do dependency management
using urls containing code (ESM). This is a huge step forward.

This makes me think, is file-based code-split strategy enough?

What if we'd put code (not data) behind GraphQL and request only the actual
piece of code we need to use?

import { foo } from '[https://graphql/](https://graphql/){ give: { me: { foo
}}}'

~~~
brabel
Just `import { foo } from '[https://graphql/'`](https://graphql/'`) is enough
for that.

------
growlist
I'm interested to read the content but find the writing style and the visual
layout make it difficult.

------
rvz
Node => Deno => Done.

One can simply say, 'Deno is like Node but done right'.

~~~
bitwize
Deno : Node :: Deltarune : Undertale

~~~
mtm7
* This comment fills you with determination.

------
boromi
Is the goal to have this also work for electron executables?

------
battery_cowboy
> This site requires JavaScript to run correctly. Please turn on JavaScript or
> unblock scripts

FYI, I read the whole article without JS fine, thanks for making the site work
without it even if it says it doesn't.

------
AtlasBarfed
The author already inflicted one of the worst "worse is better" victories I
can think of in the history of computing.

Now he's fighting his own monstrosity.

~~~
harrylucas
Author of the artcile (me) or Author of Deno?

~~~
ericol
I think he means Ryan Dahl

Anecdotally, there are several languages (French, "Argentinian" Spanish to
name a couple) where it's common to re arrange the syllables of the words
backward-ish (More often than not for slang - argot for France, lunfardo in
Argentina - uses).

~~~
aixi
What do you mean by your last sentence? The sentence makes complete sense and
is not backwards translated to spanish

~~~
ericol
Hey sorry if that was not easy to understand, I was referring to the name of
the thing. "Deno" is the same as "Node" with the syllables arranged backwards.

------
warent
This comment is a meta-critique on the blog itself. I've noticed a recent
trend arising on the web of applying a text shadow to code to make it seem
like it's glowing. I don't know where people started thinking this was a good
idea but I hope it doesn't gain too much traction. When I saw it in this blog,
I blinked and rubbed my eyes because I actually thought my vision was
blurring...

Another nitpick which may be totally invalid and I'm open to being educated on
this. It seems odd (i.e. inaccurate) that, at the end, the myProgram.bundle.js
is being called an "executable binary." It's just minified JavaScript. Is it a
binary because it has been minified and optimized, or is all JavaScript
suddenly considered "binary?"

~~~
marcodave
I'm guessing that "binary" can be interpreted as "blob of unreadable mess when
opened in a text editor"

