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.
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 :)
I've always been a bit annoyed that there are two major realms of javascript projects -- Node and "the browser" -- and while most browser JS can be easily run inside Node with a couple libraries for DOM stuff if needed, porting Node stuff to the browser is usually an afterthought.
This all seems like a lot of wasted energy on the part of developer communities, which could be alleviated by all JS developers just developing for the "least common denominator" (the browser) and using various shims to use features only available in Node or other JS environments besides the plain old browser.
This would not only cut out a lot ecosystem cruft and make development-in-the-browser more realistic, it also makes it commonplace to give the browser superpowers…Look for example at browserver, which sets up an http server inside the browser, but because the browser cannot actually accept http requests, uses websockets to talk to a proxy Node server that can.
So I want to ask, what are the real technical constraints of a web browser's javascript environment versus Node?
I thought Node was just "a javascript environment, plus http server and local filesystem, minus the DOM and the chrome". Are there technical reasons why developers could not potentially move to the approach I described above, developing for the browser JS environment (does this have an official name?) and using shims for Node?
Code that runs on the client usually have very different goals from the code that runs on the server. However when it makes sense to use some libarary's features in both environments there are a lot of them that are defined using a universal AMD form which makes them platform independent (e.g. Q).
The major difference between both environments is that one is subject to rigorous security policies and restrictions (browser) while the other isin't. The browser is also an untrustable environment for security-related operations such as enforcing security permissions.
I'll also add #jfriend00 comment in here since I believe it's also very relevant a exposes other differences:
The biggest practical difference is that you have to design a browser
application to work in an installed base of existing browsers
including older versions (lowest common denominator). When deploying a
node application, you get to select the ONE version of node that you
want to develop for and deploy with. This allows node developers to
use the latest greatest features in node which won't be available
across the general browser population for years. #jfriend00
Projects like browserver are interesting and I am all for experimental development, but are they truly useful in practice? Libraries should be designed for the environment in which they are truly useful. There are no benefits in making all libraries available in both environments. Not only that it will generally result in an increased code complexity, some features will sometimes not be shimmable resulting in an inconsistent API between platforms.
Here are some of the differences between these two environments:
Node.js has built-in libraries for HTTP and socket communication with which it can create a web server and thus be a replacement for other types of servers such as. Apache or Nginx
Node.js does not have browser APIs related to DOM, CSS, performance, document, as well as all APIs associated with the "window" object. Precisely because of the lack of a window object, the global object was renamed "global".
Node.js has full access to the system like any other source application. This means it can read and write directly to or from the file system, it can also have unlimited network access, and it can execute software...
Since the development of JavaScript is moving very fast, browsers often lag behind the implementation of new features of JavaScript, so you need to use an older version of JavaScript in the Browser, but this does not apply to Node.js, you can use it all modern ES6-7-8-9 JavaScript if your version of Node.js supports it.
Although within ES6 there is a syntax for working with modules (import/export syntax), it has only recently been added to node.js as an experimental option. Node.js mainly uses CommonJS syntax to work with modules.
I've realized I need a full-fledged browser automation tool for testing user interactions with our JavaScript widget library. I was using qunit, starting with unit testing and then I unwisely started incorporating more and more functional tests. That was a bad idea: trying to simulate a lot of user actions with JavaScript. The timing issues have gotten out of control and have made the suite too brittle. Now I spend more time fixing the tests, then I do developing.
Is it possible to find a browser automation tool that works in:
Windows XP: IE6,7,8, FF3
OSX: Safari, FF3
?
I've looked into SeleniumIDE and RC, but there seems to be some IE8 problems.
I've also seen some things about Google's WebDriver, which confusingly seems to work with Selenium.
Our organziation has licenses for IBM's Rational Functional Tester, but I don' think that will work on the MAC.
The idea is to try to run tests on all the browsers our organization supports. Doable? Are my requirements unrealistic? Any recommendations as far as software to try?
Thanks!
I would recommend using Selenium but I say that as a Selenium Committer.
Selenium works on any browser that supports JavaScript since the framework has been written in JavaScript. This means if your browser on any OS supports JavaScript it will run in Selenium. That documentation it out of date, you can see that since it is talking about IE8b1 and IE9 preview is out now.
Selenium and WebDriver (which isn't a Google thing since it started at ThoughtWorks) are currently being merged as they both have their strengths and weaknesses. The current merged work will be called Selenium 2 and you can start using the alpha release now at http://code.google.com/p/selenium/. It will still work on any OS as that is still the main driving force behind the work being done.
Selenium IDE only works on Firefox because it is a Firefox add on.
I personally would avoid Rational Functional Tester because it has a lot of weaknesses that its not even worth contemplating.
If you start with Selenium there are some tutorials on my site at http://www.theautomatedtester.co.uk
Try Sahi (http://sahi.co.in/) It works across browsers and operating systems. It has a powerful recorder, and great APIs for object identification. It supports HTTPS, proxy tunneling etc. and has drivers in sahi script, java and ruby. It also has parallel playback inbuilt. It is 5 yr old mature project hosted on SourceForge, with releases almost every month.
It automatically waits for AJAX and page loads, and does not use XPaths for object identification. It also handles sites with dynamic ids.
Selenium is probably your best bet out of the tools you mentioned. What are the issues it has with IE8? You might want to check out HttpUnit to see if that meets your needs, also.
Selenium RC is a great tool if you invest the time to use it. With significant modifications to the existing library I've gotten it to fulfill all of my front end testing needs.
The confusion you are having about Webdriver is understandable. Selenium 2 is in development and will be a merge of Webdriver and Selenium. Check out: http://www.youtube.com/watch?v=RQD4EzWI4qk to get more detail.
The only browser that I have found to be unusable with Selenium is IE6. IE7 and IE8 work fine as does Firefox (which I have modified to include firebug for debugging purposes).
I'm in the same boat. It is a difficult problem to solve. Windmill and Selenium are the 2 best I've found. Though they both have issues. Selenium can only record scripts in Firefox and I haven't managed to get the proxy chaining to work as advertised. Windmill you can record in any browser and you can supposedly tweak the proxy to put extra logic in there, but the js mechanism for recording across page loads has been in my experience very brittle at least on the app I have to test.
I don't think anyone can get it quite right as long as there is more than one browser that needs to be supported.
Maybe have a look at SIKULI. It's a different paradigm but, depending on what you want to test exactly, it may do the job and will work with any browser, on any platform.
Have a look at their official blog for some examples of interactions with web applications.
So I wrote some of my more problematic tests in Selenium RC, using the Python driver. It was a better experience than writing the same tests in pure JavaScript, but I still had some of the same issues.
Testing something like an ajax autocomplete widget, meant forking some of the code depending on IE, or Firefox, and I still can't get typeKeys or a combination of type with typeKeys to work in Safari.
So, I am not sure if having cross browser clean, extensive ui tests is a bit unrealistic.
Should I try webdriver/Selenium 2? Would that make things better, or is that product not ready for prime time yet? How's the Python binding for that? I don't know Java, but I would learn some if need be.
Javascript is widely used to create apps in the web. How about desktop, etc? Gnome Shell is made of it. I'm just curious if there's a way or something which allows devs to access Gnome/Clutter graphics libraries?
The three best options that I know of are Rhino (using Swing, or other Java graphics frameworks), Seed, and Gjs.
Seed and Gjs are both Gnome projects that bind the GTK+ and Gnome libraries to JavaScript. Seed uses the JavaScriptCore runtime from WebKit and Gjs uses Mozilla's Spidermonkey engine. Gnome Shell is using Gjs.
Another option that, as far as I know, is still pretty immature is Gom. Instead of just a JavaScript binding for GTK+, it has an HTML-like DOM interface.
There are various ways to do this. Besides Rhino, V8/node.js is one of them.
Yes using Rhino although it looks like a convolated path...
Check this recent post by Alan Knowles.
I dont know much about the Gnome/Clutter graphics access, But several SSJS (Server-side_JavaScript) available that can work on Linux environments.
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.