Duktape: an embeddable JavaScript engine

http://duktape.org/

by bpierre • 12 years ago

445 129 12 years ago

duktape.org

valarauca12• 12 years ago

Just yesterday I was looking for a simple C based javascript engine. Thank you.

robert_tweed• 12 years ago

Here's a C++ one:

https://code.google.com/p/tiny-js/

I started using it for a small side-project but had to put it on hold because of issues elsewhere in the stack.

From a cursory glance at things, Duktape looks way more advanced, and being written in pure C should make it much easier to embed. I'll definitely give it a try when I have time to look at that project again.

That said, the TinyJS code is extremely simple, so it makes a potentially good starting point for extending, if you want something JS-like rather than a pure JavaScript engine.

valarauca12• 12 years ago

I'm not a huge fan of C++. And that's primarily out of ignorance, I stick with C and leave all the strange syntax wizardy, templates, metatypes to other people.

Also the portability of Duktape impressed me. I was able to get a test up and compiled in cygwin within a few minutes.

mempko2• 12 years ago

seems the C interface is modelled after Lua. Is there any inspiration there?

macournoyer• 12 years ago

Pretty sure. The instruction layout is also inspired by Lua: https://github.com/svaarala/duktape/blob/master/src/duk_js_b...

Here's Lua: https://github.com/lua/lua/blob/master/src/lopcodes.h#L13-L2...

weeksie• 12 years ago

I immediately thought of Lua as well. A fine choice, Lua has the best C FFI I've ever worked with. I love everything about this.

cheez2• 12 years ago

Does Lua work well with multiple threads?

bodyfour• 12 years ago

Yes, very much so. If you've embedded lua before it's very easy to do the same with duktape. A few conventions are different -- for instance stack indicies are 0-based instead of 1-based (mirroring the difference in JS vs Lua) and some of the strategies for interfacing with native-code objects is different (JS prototypes aren't exact analogues to Lua metatables, etc)

svaarala5• 12 years ago

Absolutely, the original motivation was to have a Lua-like implementation for Javascript.

creationix8• 12 years ago

And thank you! I've wanted this for years, but haven't yet gotten up the courage to actually tackle it. ES5.1 is big and ES6 is massive.

Aldo_MX2• 12 years ago

I really want to applaud your effort. Are you accepting donations?

drew-r• 12 years ago

Any C# bindings?

arethuza• 12 years ago

I've used Jint (a JavaScript interpreter written in C#) in a couple of projects:

https://jint.codeplex.com/

dark12222000• 12 years ago

We need to have Node bindings so we can javascript in our javascript.

pedalpete• 12 years ago

It's been done http://dukluv.io/

creationix8• 12 years ago

Actually dukluv is the other way. It's a re-implementation of of a node-like environment using duktape instead of V8. I think the original question here was to write a node addon that allowed you to run arbitrary code in a duktape sandbox.

ColinWright• 12 years ago

It would be nice if the title gave a clue about the content. I know the mods are busy, but perhaps it could be changed to something like:

    Duktape: an embeddable Javascript engine,
             with a focus on portability and
             compact footprint.

Without that, the title is effectively click-bait, requiring a click just to find out what it's about.

Edit: I see it's changed - thank you mods, or contributor.

pselbert• 12 years ago

Absolutely. The lack of context prevented me from clicking on the link at all. Thanks for providing a description.

mrinterweb4• 12 years ago

Out of sheer curiosity, I wonder if duktape can run node? If so, I would think it to be possible to repackage node libraries as ruby gems. Not saying this would be a good idea, I am just wondering if it would be possible.

troels2• 12 years ago

Ruby gems? How'd you figure that?

BillinghamJ• 12 years ago

You can very easily expose C/C++ libraries to Ruby. Totally native too - not hacking it together.

mrinterweb4• 12 years ago

Ruby gems can be written using C extensions.

mcantelon• 12 years ago

Node = V8 + libuv, so they'd likely have to integrate with libuv.

tlrobinson• 12 years ago

Not Node.js-compatible, but there are libuv bindings: https://github.com/creationix/dukluv

bigtunacan• 12 years ago

I'm not sure this is a good idea either; but if it's possible we need to do it just because we can!

checker• 12 years ago

sheer - nothing other than; unmitigated (used for emphasis).

shear - cut the wool off (a sheep or other animal).

mrinterweb4• 12 years ago

Thank you checker. Attention to spelling detail is not one of my strong suits.

byroot2• 12 years ago

It's already done often, especially for frontend gems. See execjs [0].

[0] https://github.com/sstephenson/execjs

mrinterweb4• 12 years ago

I'm surprised I haven't heard to that gem. I would assume that adding Duktape as another supported runtime to execjs would be possible.

creationix8• 12 years ago

If anyone is wanting a node.js like experience with duktape, I've been working on libuv bindings for duktape.

https://github.com/creationix/dukluv

vvpan• 12 years ago

I want to use it for the name alone

creationix8• 12 years ago

http://dukluv.io/

swah5• 12 years ago

IMO the killer app today is compiling React server-side, and fast! I'd use that in Go...

xanderjanz2• 12 years ago

Sounds like you're looking for Rendr.

swah5• 12 years ago

Not everyone wants to use Node...

reverius42• 12 years ago

No need for Rendr if you're using React -- React is easy to server-side render on its own (assuming you're already using node on the server).

grosskur• 12 years ago

There's also otto, a JavaScript interpreter written in Go:

https://github.com/robertkrimen/otto

Here's an example Go app using otto for React server-side rendering:

https://github.com/101loops/go-reactjs

swah5• 12 years ago

Its great but still too slow for that.

chrischen• 12 years ago

Is this going to be much more efficient than embedding v8 in php?

creationix8• 12 years ago

It a couple orders of magnatude slower, but smaller than V8. I love the low overhead and have been using duktape for some time.

donpdonp• 12 years ago

How does duktape compare to v8? I've been happy with the ruby gem 'therubyracer' to evaluate javascript inside a ruby app. Method calls work both ways Ruby<->JS, etc.

haberman3• 12 years ago

Very, very cool.

I've lamented for a while that, while JS engines are flourishing from a speed perspective, there has never been one as small or embeddable as Lua.

Now we have JS as embeddable as Lua, and nearly as small (it probably can't be quite as small because Lua is a simpler language).

Now the only thing Lua has on JS, implementation-wise, is an implementation that is very small/embeddable and very fast (LuaJIT). LuaJIT is also about as small as a JIT-compiled interpreter can be.

But it looks like Tessel is working on filling that gap as we speak -- they are working on targeting LuaJIT for their JavaScript implementation http://blog.technical.io/post/102381339917/a-new-engine-for-...

munificent4• 12 years ago

Now the only thing Lua has on JS, implementation-wise, is an implementation that is very small/embeddable and very fast (LuaJIT).

Well, and a simpler, more regular syntax. Simpler semantics. Real coroutines. Tail call elimination. Multiple returns. Better iteration syntax and protocol. Better lexical scope. Operator overloading. A well-established FFI. No weird variable hoisting, nasty implicit conversions, semicolon insertion, etc.

But, sure, aside from those things, Lua doesn't have anything on JS as a language. (Of course, as an ecosystem, JS is miles ahead.)

klibertp• 12 years ago

Your parent explicitly stated that he's talking about JS implementations and not about the language. All you've said may be true, but it's completely off-topic and has no relation to the parent post at all.

EDIT: typos.

haberman3• 12 years ago

as a language

I said "implementation-wise" (it's even in the snippet you quoted).

hajile• 12 years ago

Those are all very important comparisons (and I would add that both Lua and JS got the global by default thing wrong0. I would note that ES6 requires proper tail calls and that trampolining can accomplish tail call elimination (tail call elimination is different than proper tail calls).

The major issue to me is time. I know quite a few languages, but have only mastered a couple. JS is everywhere and the browser makes sure this will be the case for a long time.

The issue is that these advantages do not outweigh the ubiquitous nature of JavaScript. If I already need to learn all of those JS quirks, why learn Lua too?

10098• 12 years ago

I wanted to reply exactly that but then noticed that op is talking about implementations, not the language itself.

I'd still prefer programming in lua to programming in javascript where possible. Honestly, the only advantage of javascript outside the browser are the hordes of people who already sort-of know it (and often don't want to learn anything else).

ihnorton• 12 years ago

Thanks for the interesting link. If I am reading it correctly, they are planning to do the thing that Mike Pall tells people not to do: target LuaJIT bytecode [1]. I'm very curious to see how that will work out.

[1] http://www.reddit.com/r/programming/comments/badl2/luajit_2_...

pygy_• 12 years ago

I wonder if they'll beat castl [0], which compiles JS to goto-enabled Lua (Lua 5.2+ and LuaJIT).

Targeting the bytecode directly will not buy much, it is very close to Lua itself, semantically. The LuaJIT parser and bytecode compiler are also wicked fast.

Furthermore, IIRC, the JIT works best with idiomatic Lua code, compiled to "kosher" bytecode by LuaJIT itself.

We'll see how it turns out.

————————————————————————————————

0. https://github.com/PaulBernier/castl

copx3• 12 years ago

Pall is thinking about how to create the most efficient implementation here and of course compiling to LuaJIT bytecode is not optimal there. However compiling to JVM bytecode is not optimal for any language except Java either, yet everyone and their dog does it.

Accepting sub-optimal performance in exchange for getting a JIT, garbage collector etc. for free seems like a good deal in many cases. Note that Pall estimates a development time of multiple years (!) for the optimal solution.

copx3• 12 years ago

I love LuaJIT but I am starting to feel seriously uncomfortable about its memory limitations.

64-bit LuaJIT can only use memory allocated within the first 2 GB. Mainstream desktop systems consume more and more memory so by the time you fire up your LuaJIT app there might be (next to) no memory left within that range.

32-bit LuaJIT can use the first 4 GB but again sooner or later desktop systems will leave little there too + 32-bit code is already deprecated technology on the desktop.

Makes me damn sad really. Unfortunately making LuaJIT capable of using the full address space requires a major rewrite.. one which will likely never happen. LuaJIT's author has moved on to other projects and LuaJIT is now in maintenance mode, getting nothing but small fixes.

Seriously if you are a Mike Pall-grade elite low-level hacker (I am talking to all four of you ;) ) would you please continue LuaJIT development?

bjterry• 12 years ago

How does system memory usage stop Lua from addressing memory in its own address space? That doesn't at all fit with my understanding of how virtual memory works in modern operating systems.

barrkel2• 12 years ago

If you control the application that is embedding LuaJIT, you should be able to reserve (but not commit) that address space early on in the application startup.

Other applications won't affect your own process's address space.

david-given2• 12 years ago

IIRC, he's said that even if the pointer model gets extended, the garbage collector's not up to scanning more than 2GB efficiently so your programs will run like a slug.

Also, it's worth remembering that the 2GB limit only applies to Lua objects. Objects allocated through the FFI API aren't limited by this. So any pure data structures which don't contain Lua object pointers can be allocated with simple malloc(). It'll be loads faster that way, too.

SCHiM• 12 years ago

You've got to love it when a library is at that point where ease-of-use and features perfectly intercept.

This library is great:

On the simplicity side:

Only include two files, no linking, no shared objects, no cruft.

On the feature side:

The functions are simple, the usage-pattern is familiar (alloc, use, free) and the code is fast (written in C, which _almost_ makes it fast by default).

Great library, will probably use it when I need to write some more scrapers in the future.

munificent4• 12 years ago

the code is fast (written in C, which _almost_ makes it fast by default).

I hate to be that guy, but [Citation Needed].

Most language implementations are written in C and most language implementations are quite slow, once you include the giant slew of hobby, toy, and less successful languages. Remember, Ruby, Python, and early versions of JS interpreters were all written in C too and are or were dog slow!

Duktape does have a section on performance[1], but it's basically just a guide to things you have to do to not make it extra slow. I didn't see any reported benchmarks.

This doesn't mean Duktape is bad. Simple+slow is a perfectly good trade-off for many real-world uses. Embedded scripting languages tend to spend most of their time in the FFI, not executing code, so perf doesn't matter as much as maintainability.

But it's really dubious to just say, "well, it's written in C so it's probably great." It's using ref-counting and linear scanning or hash table lookup for property look-up. Perf is likely not great.

Just as a point of comparison, my little hobby language[2] is also written in very simple C, but it's carefully designed to be fast too. Property look-up and method calls are just pointer + known offset. GC is tracing. Because of this (and other stuff), perf actually is good[3], typically better than Python and Lua and on par with Ruby. (With the usual caveat that all benchmarks are bad. :) )

[1] http://duktape.org/guide.html#performance

[2] https://github.com/munificent/wren

[3] https://github.com/munificent/wren/blob/master/doc/site/perf...

coldtea2• 12 years ago

Most language implementations are written in C and most language implementations are quite slow

That's not a fair comparison. Speed is relative. Compare them to implementations written in other languages.

cdnsteve• 12 years ago

Could someone clarify why you'd want to have a JavaScript engine in your C/C++ Project?

Is the idea if you have a desktop app executable wrapper and you could include this engine to start building desktop apps in JavaScript?

I don't think I have a clear understanding of this type of use case or how this will be used, please share.

The only thing I can think of is you could use this JS engine allow folks to code in JS, instead of C/C++, that actually interface with C/C++ APIs? Examples anyone?

Torn• 12 years ago

I guess it would allow you to ship the core of your software compiled as C/C++, and then system-integrators/sysadmins/hackers would script against your APIs in a higher-level language. No need to recompile or for users to see your source code.

Embeddable, small-footprint JS allowing the masses to script things with sounds pretty useful!

dag11• 12 years ago

One application is to make a plugin system for your app. Lua is often used this way.

ender7• 12 years ago

There are lots of reasons to want some form of scripting language embedded inside a C++ project. This is the primary use case for Lua, especially in game development. For example

- In a game, write quest logic in the scriptable language so that game devs can tinker with quest design without recompiling the game binary.

- "plugins" (usually UI plugins of some kind). Games like Elder Scrolls Online and World of Warcraft allow for 3rd parties to write UI extensions in Lua.

- Any other logic that you want to run and frequently modify without modifying the binary.

There are other great uses-cases that I can't think of right now, hopefully others can help.

kristiandupont• 12 years ago

Another one could be:

- You already have working JS code that you don't want to rewrite for a new platform

Tiktaalik• 12 years ago

Scripting in game development is also very helpful for programmers when bug fixing. I've had the situation where a game designer told me about some bug in an elaborate mission, and instead of playing through the entire mission to recreate the one thing that breaks, I could quickly with a few lines script the small scenario necessary to create the bug. (eg. spawn a car, attach car to road, make the car drive through the intersection, hit crash)

benihana• 12 years ago

I love this. There are a ton of web developers out there who know JavaScript, and there are a ton of scripting systems written in Lua. It makes a lot of sense to add support for putting (what I'm assuming is) the most widely distributed programming language on earth in your C/C++ app.

zackmorris• 12 years ago

A big one for me is networking (using other high level languages as well). It frees you from having to worry about buffer overflows and other exploits, as long as you deal with all untrusted data in the sandbox and only pass your resulting data between the high and low level languages as something like UTF-8.

It also greatly simplifies logic because you can do pattern matching and filtering (similar to Erlang) more concisely than in C.

I think that coroutines are on the verge of replacing callback hell so we'll start to see patterns from Go begin to show up in other languages, perhaps embedded in this way. The browsers dragged their feet for years by not implementing generators and yield (in ECMAScript 6) and set javascript back immeasurably, so being able to go around them with embedded libraries will be huge.

In a more generic sense, since 10% of a program causes 90% of the slowdown, there is little speedup to be gained by using C in the real world, especially if it's mostly using system calls that are already optimized. Some examples of this are how a high level language like php has succeeded in the server world even though it's not particular fast or elegant, and how Objective-C is often still slow even though it's low level (because programmers sometimes do too much with their "bare hands" rather than building upon heavily optimized libraries like C++'s Boost). I think this explains the rapid adoption of Swift, which is basically another high level language in place of a more painful low level one but providing similar performance.

angersock2• 12 years ago

So, what is C good at?

Low-level (like, just about assembly, maybe slightly higher) workloads that require high performance or are annoying to do any other language.

What is C++ good at?

All of the stuff C can do, but also bolting on a weirder type system, generics, metaprogramming, and a whole bunch of other stuff. It's fast, but rapidly becomes a festering tumor of functionality.

It's a katamari of design features, and even though it exposes a lot of awesome high-level abstractions the fact that it still allows working at the C level prevents it from being compelling.

What about JS?

Javascript is dynamically typed, which is terrible in many ways but bloody useful for quickly getting shit done. It is a functional language with prototypical inheritance, and so naturally lends itself to high-level programming...with regexes and functions as first-class objects, and a really pretty simple type system.

It sucks at high-performance stuff, but it allows for a lot of clever and very brief code.

So, if you want high-performance and the power of high-level abstractions, it makes sense to use C and JS--each a fairly small language well-suited to its problem domain. C++ would require too much annoying work on both sides of the problem.

A good workload for this would be: in-game scripting, network message transforms, simple command-line utilities, game engine writing, numerical library writing, asynchronous IO processing..basically, any application where you can easily separate out the low-level primitives from a flexible high-level solution description.

Then again, for all of what I'd said, I think you might as well just be using Erlang or Elxiir. :)

_dps• 12 years ago

katamari of design features

Did you coin this phrase? It's a fascinating, evocative, and quite possibly accurate description of many of the systems I find most frustrating. In any case, thank you for bringing a smile to my face today :)

ww520• 12 years ago

A embedded script engine is good for fast development, fast modification, fast experiment, and adding some app-specific DSL. E.g. in a C++ game, changing some rules or some config would take a re-compile of the project, deployment, and restart. Moving the game logic, rule, map layout, asset, config, etc, to the embedded script engine would allow immediate changes via reloading of the script while the game is running.

For embedding, you need some small language with small runtime. Something like Scheme/Lisp/Lua would work. Something like Python is not suitable. Lua is popular in the gaming scene because of its small size and its well designed architecture for embedding. Looks like Javascript is getting there.

eropple• 12 years ago

Something like Python is not suitable.

This is a wild overgeneralization. Civ4 used Python as its embedded scripting layer to great success.

(Me, I just use C# as a scripting layer inside of a C# application. On desktops, the content C# is compiled or read from cache at runtime, but on other platforms I can include the scripting libraries as project references and have them incorporated into stuff like Mono's AOT linker. http://github.com/eropple/exor )

Pxtl• 12 years ago

It's handy for creating DSLs. For example, I'll point to SpringRTS, an open-source RTS gaming engine.

There are three concerns that make an embedded language good:

1) Lockstep multiplayer. Each player has a full copy of the gamestate on their client. Every action performed against the gamestate is done in sync on every machine in a deterministic fashion and order. This means that any custom code must be written with preserving sync in mind - something as simple as rand call on the clients would break sync. So Lua allows the engine developers to properly restrict the users to only use libraries and language constructs that will respect the sync (it fails at this, but it's a goal and Lua helps with that).

2) Code from peers. Users develop code for other users - widgets that help on the user-interface and games for each other to play. A sandboxed environment is a must.

3) Graceful failure. If a widget fails it doesn't bring down the whole engine with a segfault.

m_mueller• 12 years ago

The main one for me is portability to mobile devices. I've recently built a web project with python/flask where the meat of the logic was done in serverside JS in V8. This needed to be offline capable on mobile, so when the time for that came we only had to port the Flask shell and DB logic to Obj-C while the renderer / update mechanism etc. would just work in JavascriptCore.

swah5• 12 years ago

Its a common design pattern: http://c2.com/cgi/wiki?AlternateHardAndSoftLayers

regecks• 12 years ago

A bit disappointed at its heavy use of macros, makes it a fair bit harder to link to from other languages (just sat down to write bindings for this, and realized it'll involve a lot of rewriting).

Disappointed mainly because the fact of no platform dependencies and two simple files would have made it a very very convenient library even from non-C.

yoklov• 12 years ago

The macro usage might look daunting but most of it is pretty typical for libraries without platform dependancies (lots of compiler dependant config and shims for missing libraries).

Look for "BEGIN PUBLIC API" for the stuff you'd have to wrap. Stop at "END PUBLIC API". Nothing there should be that weird looking.

mkevac• 12 years ago

Nothing to see here. Come along. Just one guy that wrote whole JS interpreter in his free time. Holy shit!

en4bz• 12 years ago

Why would I choose this over SpiderMonkey/V8?

creationix8• 12 years ago

It's worlds smaller and easier to work with.

Integrating duktape into my project was literally just including the C file. It added just a couple hundred KB of overhead.

Compare that to SM or V8 that require massive custom build systems and use up to 10mb of ram for a simple repl.

errordeveloper2• 12 years ago

Well, not exactly, Espruino is way smaller. However, Duktape is fully-compliant ECMAScript interpreter.

RyJones• 12 years ago

We use Duktape at AllSeen Alliance (disclaimer: I work there) to put JavaScript bindings on small devices.

https://git.allseenalliance.org/cgit/core/alljoyn-js.git/sum...

errordeveloper2• 12 years ago

It's pretty cool indeed what you guys are doing with it, although currently there are not as many MCUs where Duktape fits... The STM32F4 Discovery board that AllJoyn+Duktape targets, is the same one Java Embedded also runs on, IIRC. From my knowledge the STM32F4's are some of the fatter micros currently on the market.

jamesu• 12 years ago

I checked out duktape a while ago and found the documentation quite impressive. Although it didn't seem to have too many examples regarding how to embed into a typical app (with class hierarchy, etc).

Also like a lot of these other "lua alternatives", it's interesting to note development seems to be driven mostly by one guy... which if you want to use it in a project brings up the question: "What if they get hit by a bus?".

creationix8• 12 years ago

A lot of these one-man projects aren't because nobody else in the world can work on them. It's usually because everyone else is busy working on something else.

If I ended up having to maintain duktape I'm confident I could understand and improve the code with a little rampup time. This isn't rocket science. The hardest problem is finding time and funding. If a company depends on the project they have incentive to provide those things.

stevekemp• 12 years ago

The documentation was indeed very very well-written.

I suspect if you're familiar with Lua then you'll be almost immediately at home, although people new to both might struggle with the idea of stack-offsets/indexes.

analog31• 12 years ago

Maybe I'm asking a dumb question, but does this mean I can stick JS onto a microcontroller of my choice, just by wrapping it in a C program? I wonder how big it is when compiled.

Edit: I see the requirements are right there.

svaarala5• 12 years ago

Around 200kB of code (flash), and around 25kB of RAM after startup, with low memory optimizations in the master branch (for the upcoming Duktape 1.1 release). This doesn't include User Javascript, just what Duktape needs to start up.

You can run Duktape with 128kB RAM, and to some extent with 96kB, see e.g.: http://www.slideshare.net/seoyounghwang77/js-onmicrocontroll...

achalkley• 12 years ago

I'd like to see this running on an Arduino :)

mmastrac• 12 years ago

I thought about this, but at least the atmega328p has nowhere near enough RAM for it. The Arduino Mega's chip is still a bit small (ref this comment [1])

[1] https://news.ycombinator.com/item?id=8702610

svaarala5• 12 years ago

These amount of flash/RAM are probably not realistic for a compliant engine. For instance, the Duktape regexp engine alone takes around 10kB flash compiled.

Luckily Javascript has a great ecosystem, so there are non-compliant subset engines targeting tiny devices. What other (higher level) language scales this way? :)

chj• 12 years ago

Duktape seems to be based on the same principle of sqlite3. Distributed as one big c file. Really cool.

Another note: Try to do fib(33) in duk, it takes 9s, while lua interpreted mode takes under 2s. So no doubt it's still got a long way to go in terms of performance.

svaarala5• 12 years ago

Very little performance work has been done so far. Most of the effort has been in E5 compliance and more recently to support low memory environments (96-128 kB system RAM) better. But there's going to be performance work early next year.

asimjalis• 12 years ago

Are there any tools to create a single binary from JavaScript (using Duktape or some other embeddable JS engine)? I am thinking about the deployment scenario here. In its current form Duktape shipping a binary and a JS file separately. Is there a way to “compile” the JS file into the C file and produce a single binary?

chii3• 12 years ago

it's pretty trivial to do that - just define a macro and use it to insert the contents of a .js file into the .c file, and use it as a string like in the sample program.

joev_• 12 years ago

Obligatory:

http://jsfiddle.net/jrxvw1yd/

Compiled through emscripten to build a JS interpreter in a browser... at only 1.5MB!

Animats• 12 years ago

This is a useful little piece of code, but it has risks if users are allowed to insert Javascript in something running elsewhere. That might happen if you're writing a multiplayer game where users can add content. Or using it in a browser-like environment. How much power does that Javascript have? How well is it sandboxed? What about buffer overflows?

kornakiewicz• 12 years ago

Question I got to ask: why? Maybe my understanding is wrong, but it's look like including car's spare wheel to a space shuttle.

pmontra• 12 years ago

It serves a different purpose, but speaking of tiny JavaScript interpreters there is also the one for the Espruino boards. Last time I checked it was said to be 95% compatible, but I don't now against which specification. Probably it's OK for most tiny applications anyway.

Source code at https://github.com/espruino/Espruino

Espruino boards at http://www.espruino.com/

user_id2• 12 years ago

Just when you were asking yourself "how can I avoid any future responsibility for maintaining this code and meeting my customers' usecase, while having industry support for my lack of responsibility?"

Why not just embed an API and call it SQL.

brent_noorda• 12 years ago

Very happy to see this effort. Until about 2004 my little company licensed an embeddable javascript engine written in C. For the past decade I've continued to provide free support and advice for the old customers, but haven't been able to point them to any new engines with a good API, customizability, small footprint, and licensing to replace our old Nombas engine. From the guide and API duktape looks like it might be the one! Thanks, Sami et al.

mamod• 12 years ago

I've been using duktape for some while now and it's totally amazing, for the wonder minds about why using duktape instead of V8 or SM here's some of my list

First of all duktape written in C not C++ I hope this is a good point for you as it was for me :)

Not everyone seeks speed, for me, simplicity and ease of use beats speed any given day, after all I'm not after complex computations and fib that loops for ever :) one file to include and pretty sure it well compile in many platforms to get a full working Ecmascript E5/E5.1 how awesome!

Compilation time, don't know about current SM compilation time but I tried once to compile V8 and I still feel sorry for doing that to my poor old machine :)

Memory management, I'm not sure how, but duktape's GC is amazing.

Last and the most appealing point for me "unfortunately no one mentioned that yet" is documentations, I don't mean just api, please visit duktape.org and see how beautiful well written everything there, Sami "the author" put a great effort not just to write duktape but it's documentation too, api, usage, comments, specifications, examples ... and best of all it was clear and very easy to follow.

The only thing I hope is more people join to help Sami maintain the project, currently the man is very active and responsive, but I think the project will expand in the next few weeks with more and more users, so I guess he will need some help then :)

Duktape: an embeddable JavaScript engine

Related Stories