.NET JavaScript Engines

Coordinator
Nov 24, 2013 at 4:36 AM
Edited Nov 24, 2013 at 8:13 PM
This discussion is just to document the research on potential replacements for Javascript.NET (aka Noesis.Javascript). The criteria that I've been measuring them on are:
  • Performance
  • Accuracy
  • Signing
  • API quality
  • CPU support
  • File size
I'll fill in more details as I measure their performance.

Javascript.NET

https://javascriptdotnet.codeplex.com/
This wrapper for V8 is the current JavaScript engine used in JSLint.NET.

Metrics

  • Performance: The fastest of the lot. Once a JavaScript context is spun up, it can run JSLint over and over again at milliseconds a piece.
  • Accuracy: Excellent. It's V8 after all.
  • Signing: Not signed. Likely impossible to sign due to the native libraries it depends on.
  • API quality: A bit clunky in places, but gets the job done.
  • CPU support: Normally you must select either x86 or x64 as a target, but it's possible to support Any CPU by manually switching between assemblies at runtime.
  • File size: 9MB total, or 4.5MB per CPU flavor :(

Summary

How did they so consistently stuff up the casing of "Javascript"? Embarrassing!

This engine has performed great for JSLint.NET thus far, but the fact that it hasn't been actively developed for years is worrying. The file size requirement sucks, as does the amount of manual work required to switch between CPU flavors. This library will never be signed.
Coordinator
Nov 24, 2013 at 6:14 AM
Edited Nov 24, 2013 at 7:15 AM

Jurassic

https://jurassic.codeplex.com/
This engine was written from-the-ground-up in C#.

Metrics

  • Performance: Sadly the worst of the lot. In 32bit mode, it took 150% - 200% of the time the V8 based engines used. 400%-plus of the time in 64bit mode.
  • Accuracy: Mostly good, but the JSON implementation did not escape quotes properly in some situations, resulting in data that could not be deserialized on the .NET side.
  • Signing: Not signed.
  • API quality: Despite the strange lack of IDisposable, or a way to terminate a ScriptEngine process, it's pretty much the nicest API to write to out of the bunch.
  • CPU support: Any CPU.
  • File size: Under 200KB!

Summary

The file size, CPU support and nice API are tempting. The lack of signing can be easily fixed since the source is available. But the performance and JSON accuracy problems are untenable.
Coordinator
Nov 24, 2013 at 7:12 AM
Edited Nov 24, 2013 at 7:17 AM

MsieJavaScriptEngine

https://github.com/Taritsyn/MsieJavaScriptEngine
An IActiveScript implementer that provides access to Microsoft's newer Chakra JavaScript engine.

Metrics

  • Performance: N/A
  • Accuracy: N/A
  • Signing: Signed
  • API quality: Seems workable.
  • CPU support: Any CPU.
  • File size: 40KB!!!

Summary

Unable to test it because the parser didn't like jslint.js. Specifically, it considered JSLint's use of "continue" property a syntax error (legal in ES5). Obviously JSLint.com runs in IE9, so the browser must be using a different parser than the one that is available to the tool. I've raised an issue about it.

If it did work, and assuming performance was acceptable, it would be a silver bullet.
Coordinator
Nov 24, 2013 at 7:30 AM

ClearScript

https://clearscript.codeplex.com/
A Microsoft supported suite of scripting engines including V8 JavaScript, VBScript and JScript.

Metrics

  • Performance: Very good on top of V8. About 10-20% slower than Javascript.NET though, likely due to the richer .NET interop.
  • Accuracy: Excellent. No problems found.
  • Signing: Not signed. Likely impossible to sign due to the C++ libraries it depends on.
  • API quality: Mostly good, but it's not possible to add primitives directly as global variables like you can on other engines. Primitives must be wrapped in objects first, added as global variables, then accessed as properties of those variables on the JavaScript side.
  • CPU support: Any CPU. Does the work of dynamically switching between x86 and x64 dependencies for you.
  • File size: 9MB, or 4.5MB per CPU flavor :(

Summary

It's an actively developed and well supported tool. Nice to use a product in the Microsoft namespace. Other than the automatic CPU flavor switching, unfortunately it really doesn't add much for JSLint.NET's purposes that Javascript.NET doesn't already provide. The slightly slower performance doesn't help.