
Node.js Compiler – Compiling your Node.js application into a single executable - pmq20
https://github.com/pmq20/node-compiler
======
vortico
52 MB and 32 MB for macOS and Windows, respectively, for anyone looking for
the important numbers.

~~~
TheRealPomax
how does that compare to the numbers for pkg, that Zeit just released and was
on HN a few days ago?
[https://github.com/zeit/pkg](https://github.com/zeit/pkg)

~~~
akras14
About the same 30MB for a hello world application.

------
slgg
Just wanted to mention a similar project, which was recently announced by
Zeit, called "pkg": [https://github.com/zeit/pkg](https://github.com/zeit/pkg)

------
drinchev
I'm really happy with the effort of "compiling" NodeJS to native binary.

What I'm looking forward to is lightweight electron that will allow us to use
the native browser-engine for each platform.

QT/GTK for Linux, WebkitView for macOS, Edge for Windows.

Hope the effort of node-compiler, zeit/pkg will be beneficial for the future
of desktop apps.

~~~
statictype
One major advantage of Electron is not having to deal with browser
compatibility issues - you write your code against exactly one runtime (sure,
you may need platform specific flags for things - but no risk of the runtime
changing/breaking after you deploy)

Leveraging existing OS engine will reduce file size but at the cost of not
having a stable and known platform that your code will run on.

~~~
drinchev
These days fixing those issues should not be a big deal.

Having all those polyfills / babel / webpack tools you can be quite safe about
your app.

Nevertheless having a nice test suite also makes a benefit.

------
ricardobeat
The comparison table fails to mention one _huge_ advantage zeit/pkg has: it is
able to generate executables for all three platforms from any _one_ of them,
no need to setup three dev or build environments.

------
voltagex_
Cool tidbit found via this: there's a FUSE driver for SquashFS!

[https://github.com/pmq20/squashfuse/](https://github.com/pmq20/squashfuse/)

------
icf80
50 MB executable?

~~~
mrweasel
Is that honestly a problem? Most Java applications I encounter is much larger
than that.

50MB is nothing and if it enables you do have a single standalone binary that
you're easily able to deploy I'd say it's worth the extra disk use.

~~~
piaste
I thought that was a totally reasonable file size too, until I looked up
Docker image sizes for node:

[https://hub.docker.com/r/library/node/tags/](https://hub.docker.com/r/library/node/tags/)

Regular images are ~260MB and "slim" images are 85MB, but Alpine-based images
are a paltry 18MB.

So it seems _something_ in the Node.js compiler is ballooning up the size of
the code, by a factor of about three. I wonder what.

~~~
tracker1
It really depends on version of node, and the modules used. I'm more inclined
to want to see what can be done as a minimal electron... or seeing electron go
the adobe air route, and have a shared (continuous updating) base, but that
could prove problematic as binary modules (namely sqlite) are common.

------
franciscop
I am wondering if using some of the front-end techniques for back-end would be
beneficial. Tree-shaking, minimization and gzip would probably help with the
binary file size. But as we go there, maybe some more advanced things like the
closure[1] compiler or prepack[2] would make it faster.

[1] [http://www.syntaxsuccess.com/viewarticle/closure-compiler-
vs...](http://www.syntaxsuccess.com/viewarticle/closure-compiler-vs-uglifyjs)

[2] [https://prepack.io/](https://prepack.io/)

~~~
mbel
> But as we go there, maybe some more advanced things like the closure[1]
> compiler or prepack[2] would make it faster.

And then one could probably go even deeper in search of performance and
instead of compiling JS to JS, compile it to C or even straight to native CPU
assembly.

~~~
andars
AOT compilation of js is probably not worthwhile.

------
vmasto
How is this different than zeit's recently released pkg?

[https://github.com/zeit/pkg](https://github.com/zeit/pkg)

~~~
mstade
The readme says this:

> Pkg hacked fs.* API's dynamically in order to access in-package files,
> whereas Node.js Compiler leaves them alone and instead works on a deeper
> level via libsquash. Pkg uses JSON to store in-package files while Node.js
> Compiler uses the more sophisticated and widely used SquashFS as its data
> structure.

~~~
michaelmior
More sophisticated is not a great way to suggest something ks better. That
said, I could image this probably does give better performance if you have a
lot of I/O with files in the package.

~~~
jazoom
Maybe they weren't saying that is necessarily better?

~~~
mstade
Yeah I didn't read it that way either, just a matter of factly "here are the
differences" – that section probably could be expanded and clarified.

------
notsohuman
it would be awesome if someone creates a compiler for javaScript.

~~~
notsohuman
I mean an actual compiler rather which is much more optimized than node
environment rather than just making things into executables

~~~
ComodoHacker
V8 includes JIT compiler. Could it really be "much more" optimized?

~~~
perbu
If you look at Hiphop vs. HHVM there is certainly a significant performance
upside in taking advantage of clangs or gccs ability to produce efficient
code.

I'm not sure why Facebook decided to stop maintaining hiphop. Perhaps
manageability wasn't great.

------
z3t4
Is there any reason to compile your JavaScript except obfuscating the code !?
It will most likely run slower, because of no runtime optimizations.

~~~
ricardobeat
There is no real compilation going on here, V8 is bundled in the executable.

------
sandGorgon
squashfs ? maybe docker is a better alternative - especially with the new 1.13
experimental feature "\--squash"

[https://blog.docker.com/2017/01/whats-new-in-
docker-1-13/](https://blog.docker.com/2017/01/whats-new-in-docker-1-13/)

------
frik

      First install the prerequisites:
    
      SquashFS Tools 4.3
      Python 2.6 or 2.7
      Visual Studio 2015 Update 3, all editions including the 
      Community edition (remember to select "Common Tools for 
      Visual C++ 2015" feature during installation).
    

Why not just Node.js and Git for Windows as requirements? Python 2 and a
specific VS version, really? Is using npm command to get further packages too
uncool?

~~~
forgotpw1123
This is risky to say but... NPM is a bad package manager. I could blab about
why forever but tons of other people already have. I've never used a popular
language with a package manager as bad as npm.

~~~
sillysaurus3
It's not risky to say. It's risky to do a shallow critique with no solid
analysis. I would personally enjoy hearing a critique of why npm is bad in
comparison to other package managers.

As someone who has spent a lot of time with npm (not even as a webdev), it
appears to solve all of my common use cases while also dealing impressively
well with various versions of specific dependencies. (Like, A depends on
B@0.0.1, C depends on B@0.0.2, etc.)

~~~
forgotpw1123
There's a ton of annoying little stuff (like doing nothing to prevent path
names too long for your filesystem) that could be forgiven for being young,
but the big problems are in its architecture.

Node module syntax is non standard and can't be tree shaken, with a little
more forethought it could have been designed to support static analysis and
they wouldn't have needed to reinvent the module syntax for ES6. You can't
reliably tell if a piece of code is using a given package until you run it.

The dependency resolution sucks. It's better now that they finally made it so
nested dependencies aren't duplicated, but why the hell do I have to run a
manual dedupe command to do so? What that tells me is that npm doesn't
actually track dependencies, its hardly more than a fancy file downloading
tool.

The repository curation sucks. I'm not sure if you've used Python's package
manager, or Java's, or C#'s, or Perls, but npm has zero package curation and
is filled to the brim with garbage compared to the others. I have published
packages for C# and Java and the semantics are well defined and reasonable,
you even cryptographcally sign your code and the system checks to make sure
you upload documentation etc... In the case of java, which has the best system
I've seen, they even use something similar to DNS validation to make sure you
control package namespace.

The above point is the absolute worst thing about npm and drawfs the other
problems. Let me give an example by pasting the package publishing guidelines
for Maven(Java) vs npm:

Publishing an npm package: >Use npm publish to publish the package. >Note that
everything in the directory will be included unless it is ignored by a local
.gitignore or .npmignore file as described in npm-developers. >Also _make sure
there isn 't already a package with the same name, owned by somebody else._
>Test: Go to
[https://npmjs.com/package/<package>](https://npmjs.com/package/<package>).
You should see the information for your new package.

I had to condense the Java guidelines but it's roughly this: create JIRA
account apply for access review requirements verify namespace ownership
generate crypto keys package coordinates/versioning project description URL
and license info developer info SCM info package deployment generate binaries
revolve package dependencies crypto sign package generate documentation online
verification

Sounds like a lot of work right? It takes a few hours to setup and verify your
domain/keys the first time but after that all of these steps are automated.
The signing/building/doc generation/ deployment is totally automated. Npm is a
toy in comparison.

from their docs: Why Do We Have Requirements? In order to ensure a minimum
level of quality of the components available in the Central Repository, we
have established a number of requirements your deployment components have to
meet. This allows your users to find all the relevant details about the
components from the metadata provided in the Central Repository. The following
sections will detail these requirements.

Left-pad is a perfect example of why npm sucks. Nuget, Maven, Phython, and
CPAN would have never let something that stupid happen.

~~~
feduzi
> Left-pad is a perfect example of why npm sucks. Nuget, Maven, Phython, and
> CPAN would have never let something that stupid happen.

O RLY?

* [https://mvnrepository.com/artifact/coldnew/left-pad/1.0.0](https://mvnrepository.com/artifact/coldnew/left-pad/1.0.0)

* [https://www.nuget.org/packages/left-pad/](https://www.nuget.org/packages/left-pad/)

* [https://pypi.python.org/pypi/left-pad/](https://pypi.python.org/pypi/left-pad/)

* [http://search.cpan.org/~dagolden/LeftPad-0.003/lib/LeftPad.p...](http://search.cpan.org/~dagolden/LeftPad-0.003/lib/LeftPad.pm) (LeftPad - Why should Node.js have all the fun? - comments on the package)

\-- UPDATE

About package removal...

* [http://stackoverflow.com/questions/20403387/how-to-remove-a-...](http://stackoverflow.com/questions/20403387/how-to-remove-a-package-from-pypi)

~~~
forgotpw1123
All of those left-pad libraries are a jest, it's trivial to do padding in
those languages. I was wrong about Python and removing packages but on Nuget
and Maven you can't, its not allowed.

I think it's worth noting that with Java at least, besides not allowing
package removal, the namespace is tied to a unique identifier with ownership
verification, so the cause of the left-pad fiasco (kik wanting his namespace)
is extremely unlikely to happen in the first place.

~~~
oliverkyss
If the curation process allows joke packages to pass through, it is completely
useless. Looks like the only difference from npm is extra bureaucracy then.

