Hacker News Reader

Comment by charliesome | Hacker News Reader

> The original build system used ant, which was then followed by rake, which ran on Ruby. In 2010 the build system was ported to JavaScript and jake (a port of rake), which ran on top of narwhal (a CommonJS runtime) and the package manager tusk. This is the system we are still using today.

Sigh. No prizes for guessing what will happen in two years' time when node.js is no longer the shiny new hotness.

View on HN

> On the other hand, narwhal and tusk do not run on Windows and are no longer being maintained.

You can't blame them for not staying with narwhal. And I'm sure you are not suggesting that they should switch back to ant or rake.

Honestly, I don't understand the unnecessary snarkiness of some people on this site.

So I took a quick look at the Jakefile and it doesn't seem like it does a whole lot more than shelling out and a little bit of file manipulation.

I wonder if Cappuccino has considered using make. make is maintained. make works on Windows. make is unglamorous but it works and it has worked for decades.

IIRC, one reason we wrote a build system in JavaScript was the compiler itself ran in Rhino, and the startup time of the JVM/Rhino was ridiculously slow when shelling out to it for each source file (hundreds of times in a full build of Cappuccino). Having the rest of the build system and compiler running in the same process eliminated that latency.

And yes, we tried Nailgun (http://www.martiansoftware.com/nailgun/) but I don't recall why that didn't work out.

Perhaps there were better solutions, just pointing out it wasn't completely NIH syndrome.

* Make introduces non-platform-related dependencies (e.g., you now need a make binary, not available by default on Windows, and not needed by anything else in the JavaScript development toolchain).

* nmake, bsdmake, and gnumake are all slightly incompatible with each other if you want to do something smart.

Being able to work in JavaScript code is valuable to our users (and to the project itself). Learning make would be a significant barrier for many of them.

>Honestly, I don't understand the unnecessary snarkiness of some people on this site.

Reflexive negativity is a problem, pg is aware of it. Hiding comment karma score was one attempt at mitigating it, hopefully he's got some more ideas as well. Definitely one of those big problems, with the Internet in general, looking for a solution.

I don't really see any "reflexive negativity" in the original comment.

It's merely pointing out what seems to be a trend with this project and the build systems it uses. If there's any negativity involved, it's with how much time and effort (and donations...) the Cappuccino crew wastes with all of this repeated switching to the most-hyped software of the day.

The original comment is certainly not charitable in its assumptions. Why must it be assumed that the Cappuccino team is just trying to be fashionable? What I see is a natural evolution from less appropriate alternatives to more appropriate alternatives as they gain maturity. npm is now the standard package manager for the language, something that jake might have tried to be but never was. And although node might be very fashionable and popular right now, I don't think anyone sees that role changing within the JavaScript ecosystem.

If they hadn't switched people would be complaining that they use such an outdated system as jake.

If pragmatism was their main concern, then they would have been using make, shell scripts and the common UNIX commands from the very beginning. This would have given them support for Linux, Solaris, the *BSDs, Mac OS X and a number of other systems right away. Windows could've been supported with ease by using the various ports of those tools. Those tools are extremely capable and well-proven for creating reliable, cross-platform build scripts.

I'm not sure why people are recommending make. Apart from the fact that it makes perfect sense for a library written in JS to use a JS toolchain, tools like Rake and npm are far more portable than any of the Autotools toolchain ever was. OSX uses BSD make by default for god's sake, and installing autotools on windows is not nearly as easy as installing node and npm. After that, you've got hundreds (thousands?) of CommonJS libraries that you can leverage where you control the version, versus having files sprinkled with comments like "// curl version <7 didn't support the -p flag, needed for WinXP cygwin v.24" (not actual example, but I've worked on many C/C++ projects where this is the case).

Using make in no way means that you have to use the monstrosity that is Autotools.

People generally want to use what the community wants them to use. With C and C++, that is certainly make and shell scripts. With Java, that is Maven (or was when I was last there :). With Ruby, that is rake. With Python, that is distutils. With JavaScript, that is npm.

There are benefits when the entire community standardizes on something. I know I will frequently pass looking at a Python module that won't easily fit into my build system, which, conveniently, is the build system mostPython scripts use.

The fact that Cappuccino pre-dated the de facto standard should not be held against them.

We certainly wish node had come out about a year earlier. It would have saved us a lot of headaches. But at the time there was no serious alternative to narwhal.

Just for some context, Ant was originally used just because that was what we were used to in college. Ant is a pretty miserable tool I feel now, and quickly discovered back then (very hard to do anything imperative and writing plugins for new features is no walk in the park either). We later went to rake because (some people forget this now), but you couldn't really use JavaScript on the terminal in any practical way (Rhino was the only real option) -- and had you been able to there certainly did not exist a build system. Rake made the most sense to me back then, and I still really like that build system. Once we had a way to realistically run JS on the terminal (at a decent speed by getting JSC working), we literally did a line by line port of Rake -- so none of the existing build system had to be rebuilt, it just got faster and was able to interact with all the existing libraries for free. The reality of today is that everyone has node.js, if they have any sort of JS environment installed, so that is their desire to move to node.js. Now, I would be of the position of just doing the bare minimum to get the existing build system working on node as opposed to some from-scratch rewrite, but that is their prerogative. Regardless, this was not just moving to what was "hot" at the time.

"No prizes for guessing what will happen in two years' time when node.js is no longer the shiny new hotness"

Do you honestly think there will be anything out in the JavaScript world that will replace node.js within the next 2 years?

Please think before you snark.

There will be something, perhaps not even in the JS world, that will be the shiny new hotness. They seem to be fairly language agnostic when it comes to their build tools.

An evolution from not JS to JS for a JS library is not really language agnostic. I'm not sure you have an appropriate grasp of what the JS landscape looked like when we started Cappuccino.

I love your condescending tone.

The project began with a Java-based system to a Ruby one to a JavaScript one. I appreciate things weren't as developed back in the day, but it appears the project uses what's best, regardless of the language. That, to me, is the epitome of being language agnostic and it's not a bad thing.

Anybody looking into a package management solution should just use nix and be done with it.

Works on Linux, Mac, Windows, BSD, probably others.

Language-agnostic (and build-system agnostic) so if your project ends up depending on bindings to a specific version of libjpeg or some other C library, you won't be stuck. Likewise if you have perl/ruby glue scripts in your project (which is bound to happen), their dependencies can be properly modeled too.

Do you have the same control over JS library versions in NIX and you do in npm? I find it very unlikely...

A nix package specification can depend on a specific version/build of another package (such as a JS library), with the version being as specific as the md5 hash of its contents.

Ive gotten the Objective-J compiler and custom build system to run on Node.js. Node.js is much better than Narwhal, this is purely an engineering decision.

Reply on news.ycombinator.com