Why not Lua?
By design, Lua has a lot in common to Javascript. According to the Compute Language Benchmark Game Lua is faster than Javascript/V8 (Lua is slower, but LuaJIT is faster) and much more memory efficient. Lua is also believed to be easier to be embedded. However, the most important reason that I gave up Lua in the end is the lack regex which I heavily rely on. Other minor reasons include:
- I prefer “{}” over “begin–end”.
- Javascript is more popular.
- Coupled with HTML+CSS, Javascript can be used to develop GUI.
Why Javascript shell?
In comparison to Lua and most other general-purpose languages, Javascript itself is useless for my purposes: processing text files. This is because Javascript is unable to open a file on the filesystem. One has to extend Javascript at the level of Javascript engine.
Why v8?
A great complication to extend Javascript is caused by the variety of Javascript engines which are all incompatible with each other in APIs. I choose v8 mainly because of its efficiency and independency:
- SpiderMonkey is inefficient
- TraceMonkey and JaegerMonkey are bloatware (over 70MB tar-ball to download)
- Tamarin is believed to be slower than SpiderMonkey according to wiki.
- Rhino is written in Java and is probably as slow as SpiderMonkey.
- SquirrelFish/Nitro are integrated too closely with WebKit.
V8 is not perfect. It is poorly documented, lacks examples and important features (e.g. calling a destructor when an object is out of the scope). Nonetheless, v8 is generally well designed. It is speedy, standalone and not bloated (about 2.6MB compressed without testsuite and so on). It is much younger than Lua after all. I should not ask for too much.
Why not node.js, v8cgi or Narwhal?
These are all great Javascript shells. I am not satisfied with them because they provide too much I do not need, but lack key features I need most. As I said, the component I desperately need is the ability to read a file. While these implementations all support file reading, node.js uses unbuffered I/O and only supports fread() like calls; v8cgi and Narwhal, which both follow the commonJS spec, only offers an API to read the entire file into the memory.
What does K8 offer?
For now, very little: a File object with next() and close() methods. Nonetheless, K8 does file processing in the right way. The File object is a buffered file stream which can be both uncompressed or zlib/gzip compressed. It offers the most useful API next() which reads the next line or token. This simple object opens a variety of new applications to me.
The k8.js Javascript library
As I have just started to write Javascript, I have to build my own toolbox as most javascript libraries deal with web applications. This k8.js is a start. It implements getopt(), a few matrix operations and a FASTA/Q format parser. Probably more will come if I continue to write Javascript.
Get K8
For people who are interested (I guess none, though), it is available at github.
Attractive Chaos 
Is K8 dead? Why?
Yes, it is dead, because I have switched my focus to Luajit, which is more lightweight, more stable and more tuned for general purposes than V8. It is a pain to work with V8 due to its complex and undocumented C++ APIs.
Thanks!
“I prefer “{}” over “begin–end”.”
That seems almost like a trifle, compared to the way how much Javascript’s scoping sucks compared to Lua’s systematic variable bindings.
To me, “{}” has a lot of advantages. Arguably it is easier to identify to eyes, easier to type. For a text editor, auto-indention and brackets matching works more accurately than “begin/do/then-end”.
Javascript scoping indeed sucks, but this has nothing to do with “{}”.
[…] a weekend two years ago, I wrote a Javascript shell, K8, based on Google’s V8 Javascript engine. It aimed to provide basic […]