Tada! Here is SlimerJS!
Par Laurentj le lundi, juillet 15 2013, 11:55 - Projets - Lien permanent
Once upon a time, on the december 10th, 2012, I discovered CasperJS and PhantomJS and this was the beginning of a great history....
I was very impressed by this tools and I began to use it to do some tests on my PHP framework, Jelix [1].
But what is PhantomJS? This is a scriptable and an headless web browser.
It means that it is browser which you can interact with a web site, only through a javascript script.
No user interface, no window, no button. You write a script which call some functions like
open() to open a web page, sendEvent() to "click" or "type a key" on the web page and so on.
You can retrieve the content of the web page, you can take screenshots, listen all loading events etc.
At the end, with PhantomJS, you can do automatic processing like functionnal tests or network monitoring.
You already have many scripts to do many things, and one of them is CasperJS, which is a
testing framework.
The advantage of PhantomJS over similar tools like ZombieJS, is that it is powered by a well known and a true web engine. Here, this is Webkit (with JavascriptCore). It means that it has almost the same behavior of Safari (or Google chrome), and so you can test your web site as if you were into Safari or Chrome.
In this tweet discussion, Anthony, a friend at Mozilla, has pointed out to me that with PhantomJS, I could not test with Gecko, the rendering engine of Firefox. And Nicolas, the author of CasperJS (I already met him in the past in some conferences) confirmed to me that some of his users would like to use CasperJS to test their web sites with Firefox.
At the end ot the discussion, these following conclusions appears to me:
On a one side:
- Because PhantomJS is only built on top of Webkit, some web developers cannot launch their tests on Gecko although they would like to use these great tools to test their projects with Firefox-like browser.
- PhantomJS and CasperJS have a great success, and are more and more used by web developers. It's great but it as a negative side-effect from my point of view: it increases the "webkit monoculture". I began to contribute to the Mozilla project, ten years ago, by doing tech evangelism, (and before, I did web standards evangelism with Tristan Nitot and others passionnate). So, you understand that these last months, I was very annoyed by this growing "webkit monoculture". I think this is bad for the Web.
On the other side:
- The API of PhantomJS is not really complex, and there are not many API: it could be easy to implement a such API in a similar tool (well, it was I thought :)), even if some features would not be there, like the "headless" behavior, because Gecko needs a graphical interface to display web content.
- I played with Mozilla technologies (XUL, XulRunner, Gecko internals) for many years, in personal and professional projects.
So it was clear to me that something should be done. I was be able to create a PhantomJS-like tools base on Gecko. I could do a concrete thing to fight this webkit monoculture. Am I The One for this work? :-)
Ok, so, let's try, let's go. Two days later, I started the project. I found a name, SlimerJS, [2], I bought a domain name slimerjs.org, I opened a new project on Github, and I created the first commit.
I then developed SlimerJS during my spare time. I released two versions, SlimerJS 0.6 and SlimerJS 0.7. It was pretty usable if you did not search to have a full compatibility with PhantomJS. The goal for SlimerJS 0.8 was to be able to launch CasperJS. With its tests suites, I have fixed many compatibility issues, and implemented all needed API that was not implemented yet. I had also improved CasperJS so it "knows" SlimerJS, and it can react correctly to some specifics behaviors. The result is a full compatibility with CasperJS, a new version of CapserJS, 1.1 beta and of course SlimerJS 0.8, released 7 months after the first line of code !
These developments were not easy in fact. Webkit and Gecko have some different behaviors. I had to find some solutions to match behaviors of some PhantomJS API. But sometimes I couldn't, because there was no internal API in Gecko to do what I wanted (example: no possibility to indicate an exit code in Gecko), or because if I hack Gecko in some areas, it wouldn't match behaviors of Firefox, and this is not that I wanted in fact. I listed some differences I found during the development of SlimerJS.
However, even if it is not yet a true headless browser, SlimerJS has some advantages over PhantomJS, like using promises when opening a web page, the benefit of a better javascript engine (unfortunately, it seems that PhantomJS does not use V8), the strictly same rendering as in Firefox since SlimerJS uses XulRunner or Firefox itself etc.
Some few things are still missing, like configuration options, the webdriver mode, the http authentication feature etc. I plan to implement them in a future release. And if I have enough time and help (this will be a huge development!), I will hack Gecko to have a true headless mode, by trying to fix this bug in Gecko (Hello Mozilla, if you are interested... ;-) ).
Enjoy! download SlimerJS, follow its developments on twitter, ask your questions on the forum/mailing list, or even contribute!
Commentaires
This is really a great news! I played with it this week end, adding support to SlimerJS on one of my pet project (https://github.com/abe33/spectacula... ) that was already supporting PhantomJS.
It took me maybe 15mn to port the PhantomJS code to SlimerJS. The only problem I faced was that I decorated the String prototype with Object.defineProperty and the scripts in the page couldn't access the created getters (it was working fine in phantomjs), I guess it's sandbox related, but anyway it wasn't much effort to figure how to fix it.
Thanks for this awesome work!
>I guess it's sandbox related
Yes this is probably the case.
Salut Laurent,
Because Rik pushed the discussion on IRC, I started to wonder about testing environments. I have been a light user of Selenium/Webdriver with the python binding. Usually the features which are accessible are highly dependent on the driver implementations. But so far I have been satisfied with webdriver one of the reasons is that I can test more or less without too much code modifications test on different browsers in one shot.
The SlimerJS is interesting but *seems* to go from one silo (PhantomJS/webkit) to another silo (SlimerJS/gecko). What would it require to have something which is cross-platform. Is it a matter of improving the user experience of selenium webdriver? Adjusting PhantomJS to be plugged to *any* engines (but then replicating webdriver)?
It would be cool to know what are the issues we are trying to solve. So I started https://etherpad.mozilla.org/5iHD1O... to better understand the landscape and the needs. I'll write a summary blog post later on. Anyway thanks for starting that implementation because it has at least the merit to show some painful points for Web developers and to help them in the meantime with testing and Gecko.
@karl
PhantomJS implements webdriver. SlimerJS will do to. And an other side, PhantomJS and SlimerJS share the same API. So developers don't have to develop their script twice. So I don't see "a silo" here.
It seems that webdriver could be the future, because I saw the effort to standardize the webdriver protocol by a working group in the W3C. And I talk with David Burns today on IRC, about the possibility to use the webdriver implementation made by Mozilla, Marionette, used to test FirefoxOS app or other things.
Probably the webdriver protocol will be implemented directly into every browser later. It could be a good thing.
But for the moment, this is not the case, so the use of PhantomJS and SlimerJS is justified from my point of view (by using their JS API or by using their webdriver implementation). Moreover, PhantomJS (and SlimerJS later I hope), is headless. This is an important feature for continue integration systems, which are often install on server that have no graphical environment. And this feature allow to have a very fast browser. Having very fast tests brings a great confort for the web developer. To be honest, after using Selenium on some project, for me Selenium appears to be complicated to use and too slow.
> for me Selenium appears to be complicated to use and too slow.
+1, that's pretty much why I've started casperjs actually.
Plus, there's something I don't like about the Webdriver spec and the JSON wire protocol: it just abstracts the DOM environment too much for my own taste; when you're a JavaScript developer, you really care about testing *within* a live DOM environment. Relying on remote operations sent through HTTP commands is pretty cool but can hardly handle complex stuff as you would do by accessing and manipulating the DOM directly. Would you prefer using a browser console or curl to debug your js code? :)
But I hear concerns about multiplatform support and standardization, though I'd personally think there would be room for a more-phantomjs-like API standardization effort, or at least a more "close to the metal" one than what the WebDriver spec tries to provide.
@Niko.
hehe NiKo. "Would you prefer using a browser console or curl to debug your js code? :)" if you ask me… ;) curl, but that's because there are places we prefer to interact, are used to with the Web. But joke apart, it depends on the type of testing we are talking about. :)
That said I hear the concerns.
@Laurent,
I think you misunderstood what I was saying ;) Hopefully I started with *The SlimerJS is interesting* :D
The fact PhantomJS and SlimerJS shares the same API is *cool*. That still makes two frameworks to install (if I understood) and then a third one for chrome, and a fourth one for Opera, and another one for… etc. You see where I'm going. :) When developping for the Open Web, we want Web developer to not have to repeat things which should not be necessary. So for example, I was wondering what makes it hard to contribute directly to phantomJS and/or create a fork of it which abstracts the call to the "headless browser" so we can plug any browsers. So instead of having to use x framework, we use one for all the browsers.
Headless browsers are awesome in some circumstances and not that much in others. It depends which kind of tests. :)
As for webdriver/selenium, the most annoying thing so far is the discrepancies in between the browsers. So usually the bindings do not give exactly the same results depending on the driver. Things like screenshot is not implemented the same for example in Presto driver and Gecko driver. This is partly the goal of the webdriver spec to fix.