I am interested in getting started with CommonJS.
With JavaScript frameworks getting faster all the time, and parsing engines and compilers making JavaScript incredibly quick, it is surprising that a project such as CommonJS has not been initiated sooner.
What steps are involved in getting a test project up and running with what has been created so far?
It really depends on what you're actually looking to do. Persevere, for example, is a JSON database that is built on top of Rhino but is capable of working with CommonJS modules and is being built up around JSGI (the web server interface) going forward.
Narwhal is a fairly robust library of JavaScript and is specifically looking to track the CommonJS standard as it evolves. Narwhal runs on top of Rhino by default, but you can also install JavaScriptCore (and possibly v8) as additional "engines". JSC is very fast.
There are various web frameworks available (including Helma NG).
Node.js has been getting a lot of attention as a fast, v8-based, event-driven network services stack for JS. Node recently changed to use CommonJS modules.
SproutCore has a branch ("tiki") that is built on CommonJS modules. I, personally, am using that now for Bespin of which the client side is entirely CommonJS modules. (Ironically, the server side is currently in Python, but we do have plans to migrate to CommonJS on the server as well.)
The thing to remember about CommonJS is that it's an API spec. It's possible for there to be many implementations. Thus far, the only part of the spec that is widely supported are the modules... the rest is still baking, but coming along nicely.
CommonJS is not yet to the level of interop of, say, CPython/Jython/IronPython, but it certainly has that potential going forward.
What steps are involved in getting a
test project up and running with what
has been created so far?
I found the Narhwal quick start to be the fastest way to get up and running.
Have you tried starting here?
What are you stuck on?
It's gelling. You're early, unless you like living on the edge.
By the way, your wikipedia link has links to the projects that use CommonJS. You had the answer before you got here.
I just started using Node.js at home. It works and seems great.
The only issue I've encountered so far is that Windows support seems somewhat distant.
I believe Rhino works with Windows since it's a Javascript interpreter written in Java, but that also means it's slower than the Javascript-C implementations like V8. I don't think Rhino itself implements the CommonJS specification, but you can run something like Narwahl on top of it - as was mentioned by Kevin and Jeff.
I just did a quick job of installing Rhino, Ant (to build Rhino) and trying to get Narwhal running with Windows, but wasn't successful.
I suggest trying Node.js on a Linux box since that was my environment and it worked flawlessly.
Related
I'm working with a team on a TypeScript librabry called Classical.js, and we would very much like the core module of this library to be JavaScript environment agnostic. In my mind, that means it should not only function correctly cross-browser, but also as a dependency in a node.js project.
First of all, am I missing any major JavaScript environments in my test matrix that I should be aware of?
Unfortunately no one on the team develops with node. Therefore we're not quite sure what APIs to avoid (obviously the DOM) to ensure compatibility. Are there are a standard set of GOTCHAs that node developers run into when using code that has only been tested in the browser?
One discrepancy that we did (hopefully) account for the name of the global scope, which, if memory serves me correctly, is represented by an object named global in node and window in the browser. These are the sort of GOTCHAs that we are looking for.
I think you have an important issue here, one that that's currently underexposed: you want to create an isomorphic library, and you want to know which libraries you depend on are isomorphic. I think it would be a good thing when isomorphic modules would be clearly marked as such in for example npm.
There is a nice blog on this topic here: http://nerds.airbnb.com/isomorphic-javascript-future-web-apps/
Basically, isomorphic libraries should only use functionality build in JavaScript the language itself (ES3, ES5, ES6, ...).
You should avoid anything related to the DOM (window, document, navigator, ...), as this is only available inside a browser environment.
Many core modules of node.js cannot be used in a browser (like file system, os, process, network, streams, etc). For many core modules there are browser safe versions available (for example for crypto and http). Browserify uses these versions when bundling a node.js app for use in the browser.
There are a lot of JavaScript engines out in the wild, implemented in all kind of languages like C, Java, Python, etc. Also running directly on hardware like Espruino. These engines may not be 100% compliant with the language specs. For example, I encountered one day that the JS engine in Java (I think it was Rhino) didn't like a variable to have the name boolean. In these cases I would argue that these engines should get better compliancy rather than you having to work around their bugs/limitations.
Anyway, there is an easy way to test whether your library is isomorphic: try to run it in both node.js and the 5 biggest browsers :)
Currently, I am using PhantomJS for running Javascript unit tests in QUnit and Sinon framework on our build server.
But, PhantomJS uses JavaScriptCore with JIT compiler as its Javascript engine. Instead, I want to use the V8 engine, which is used in Google Chrome, or Chakra, which is used in IE. I want to do this because I want to check platform compatibility for the code.
Are there any popular test runners like PhantomJS, which use these engines?
The closest I can think of is Zombie.js, which is a headless browser written in Javascript that runs under Node.js.
It's not a genuine browser in the way that Phantom is, so there are things you won't be able to do with it that you can do with Phantom, but since it uses Node.js, it obviously does use the V8 engine, so it fulfils your criteria.
But if you really want to test in all the browser's various engines, your other option is, of course, to use a real browser. You don't have to have a visible UI for it; use a tool like Selenium or Sahi, which can launch and run the browser from a script, and have it run in a VM; you don't ever need to even look at it. It may not be as quick as using Phantom, but it will be a genuine test, which is clearly what you're really interested in.
[EDIT]
Worth adding a note to this answer because I recently found out about SlimerJS, which is an open source project aiming to produce a PhantomJS-compatible browser that uses the Gecko engine. Again, this isn't exactly what was asked for in the question, but it is in the spirit of it; it's great to have another tool available to make cross-platform testing easier.
Here's the situation:
We're a Microsoft shop using Visual Studio / TFS etc.
We have a build server that nightly performs builds for us and runs various tests to ensure nothing has been broken during the day
We're now doing more and more JavaScript and this is likely to continue.
None of our JavaScript is currently tested because as I've looked around I've found the JavaScript testing world is in a state of flux. There are lots of offerings which I've read about and I'm not sure which path to take. I found this question quite helpful in terms of just raw info:
JavaScript unit test tools for TDD
Ideally I'd like to use something which integrates nicely into Visual Studio and our TFS build server. Most of the JavaScript testing options do not seem to support this.
I found this article: (but I'm not too keen on using jscript for testing)
http://stephenwalther.com/blog/archive/2010/12/20/integrating-javascript-unit-tests-with-visual-studio.aspx
And I found this - which looks quite promising:
http://chutzpah.codeplex.com/
So what I'm wondering is, is there any consensus yet? Are people adopting one tool over another, is any approach gaining critical mass yet? I'm keen to make use of something which is clearly working for a lot of people already.
Is it worthwhile me sticking it out for a JavaScript testing framework that plays nice with Visual Studio / TFS or should I look to use one of the non Microsoft friendly offerings instead?
All insights appreciated!
I wouldn't got that far and state that I'm moving away from developing in MS environment.
I think Visual Studio is a great tool. Working a little with Eclipse & XCode, for PhoneGap development even gave me another perspective as to how Visual Studio really rocks.
Regarding JavaScript, there are many enhancements in Visual Studio 2012, but integral solution for Unit Testing is not yet part of it.
After being involved in some JavaScript heavy projects, also felt the need for Unit Testing, so started with In-Browser tests with QUnit and Sinon.JS.
I went out there to find the right stack to meet my expectations:
Seamless integration with Visual Studio.
So we can run tests without leaving the IDE.
Headless testing.
Against multiple browsers at the same time if possible.
Support for AMD (Asynchronous Module Definition) / Require.JS.
Support for Async Tests.
Documented libraries & Tools.
Free Tools are preferred.
Eventually find my perfect combination for Headless testing from inside the IDE with JS-Test-Driver.
I've written a 3 parts series on my blog:
Part I - Expectations & the selected Stack
Part II - Setting up the environment for Headless tests
Part III - Testing AMD/Require.JS Modules
You can find the last part here, with links to first 2 posts:
http://www.upstruct.net/2013/02/javascript-unit-testing-in-visual-part-3.html
Been using this combination in several projects, and got a very good feedback from the teams so far.
Let me know if it suits you...
I've been looking around for the same answer but am now wondering if I should move away from developing in an MS environment altogether. As more and more of what I do is on the client side, Visual Studio seems less relevant. Funnily enough though, since I've been playing with Eclipse I've had the same problem - lack of JS testing plugins! So I'm not sure there's a consensus outside of MS development. I think part of this is a reluctance of seasoned developers of C# / Java to use JS but rather they want to use a strongly typed language which compiles (using tools like GWT and Script Sharp). The result is confusion about what comprises best practice. But since the tools for JS seem to be improving I'm somewhat reluctantly coming to the conclusion that JS should be the first point for coding rather than adding another layer of abstraction. Thus I'm resigned to using their available tools - QUnit for the moment is my choise.
In 2021 it seems that Microsoft is recommending we use a NodeJS app to run our JavaScript Unit Tests. Visual Studio's test window can now see tests we write in that project even when the overall project is in C#:
https://learn.microsoft.com/en-us/visualstudio/javascript/unit-testing-javascript-with-visual-studio?view=vs-2019&tabs=mocha
One of the testing library combos (unit testing / mocking / assertions) recommended is using Mocha / Sinon / Chai. For this flavor there's a useful tutorial located here:
https://scotch.io/tutorials/how-to-test-nodejs-apps-using-mocha-chai-and-sinonjs
In my application, I allow users to write plugins using JavaScript. I embed V8 for that purpose. The problem is that developers can't use things like HTTP, Sockets, Streams, Timers, Threading, Crypotography, Unit tests, et cetra.
I searched Stack Overflow and I found node.js. The problem with it is that you can actually create HTTP servers, and start processes and more things that I do not want to allow. In addition, node.js has its own environment (./node script.js) and you can't embed it. And it doesn't support Windows - I need it to be fully cross platform. If those problems can be solved, it will be awesome :) But I'm open to other frameworks too.
Any ideas?
Thank you!
There is CommonJS, which defines a "standard" and a few implementations available of that standard - one of which is node.js.
But from what I can see, it's still fairly immature and there aren't many "complete" implementations.
In the end, I built my own library.
In terms of quick dynamically typed languages, I'm really starting to like Javascript, as I use it a lot for web projects, especially because it uses the same syntax as Actionscript (flash).
It would be an ideal language for shell scripting, making it easier to move code from the front and back end of a site, and less of the strange syntax of python.
Is there a good, javascript interpreter that is easy to install (I know there's one based on java, but that would mean installing all the java stuff to use),
I personally use SpiderMonkey, but here's an extensive list of ECMAScript shells
Example spidermonkey install and use on Ubuntu:
$ sudo apt-get install spidermonkey
$ js myfile.js
output
$ js
js> var f = function(){};
js> f();
Of course, in Windows, the JavaScript interpreter is shipped with the OS.
Just run cscript or wscript against any .js file.
There are four big javascript interpreters currently. V8, Squirrelfish, Spidermonkey and Rhino. I think more important than performance is how well it integrates into existing infrastructure, and I guess Rhino with its bridge to Java wins here.
Try jslibs, a scripting-focused standalone JS runtime and set of libraries that uses SpiderMonkey (the Gecko JS engine).
On the 'easy to translate' theme, there's also Lua.
It's somewhat similar to Javascript, but more 'orthogonal' (closer to functional roots).
The heavy orientation to 'pure' programming theory has made it really small and fast. It's the fastest scripting language around, and the JIT runs circles around the new JavaScript JITs that are starting to appear.
Also, since it was originally thought as an extension language, it has a very nice and clean interface to C, making it very easy to create bindings to any C library you might want to access.
Google's V8 can be used as a standalone interpreter. Configuring with scons sample=shell will build an executable named shell, that can be called like so: ./shell file.js.
You'll need some server-side JavaScript interpreter. Check out the following blog post. Something such as Rhino might be useful for you.
You might try toying around with SquirrelFish or v8, both should be runnable on the command line.
FYI, there is a built-in one already on modern windows platforms. You need to use JScript, but it's close enough. Same environment also allows for VBScript. To run a program you can execute something like:
cscript foo.js
The windows system API is a bit weird and frustrating if you expect the same flexibility as with basic JS objects, but they do have thorough documentation if you can handle digging through the MSDN pages and seeing all the examples in VBScript.
Not sure what's available for Linux/Mac in terms of js shell.
Well, for safety reasons, javascript had not been provided with file access right by design. So as a scripting language, it's a bit limited.
But still, if you really want to, spider monkey is your best option. Here is a tuto :
http://developer.mozilla.org/en/Introduction_to_the_JavaScript_shell
Node.JS. It's great. Has many modules. you can do all your file scripting with Node.
In my years I've found most Javascript developers find it quite easy to transfer over to PHP and vice versa - it isn't a direct answer to your question, although if you're working in ActionScript and JavaScript then you're best to stick with something like PHP (if you're not willing to move to Java, and stick with the ECMA base)