This works with xjs, the server side JavaScript framework Peter is building. We are seeing a spur in these types of libraries as people do more on the server-side.
Opera has posted what looks like a great new Web debugging tool Opera Dragonfly which is released in alpha.
Debug JavaScript, inspect CSS and the DOM, and view any errors – Opera Dragonfly makes developing using Opera easier than ever, both on your computer and mobile phone.
Shawn Lauriat has a nice write-up that tells the story:
It offers most of the familiar tools for DOM inspection (along with a nice DOM editing capability), error logging (with the same granularity as before wrapped in a more polished UI), a JavaScript debugger that rivals WebKit's Drosera, a JavaScript thread logger, and a lot more that I haven't explored yet.
Time will tell whether Dragonfly can get enough developers to use Opera and keep them there, and how much the developers behind the new developer tools listen to the community in the coming iterations, but so far this looks extremely promising.
Features
Reach breaking point step by step: Opera Dragonfly's fully featured JavaScript debugger makes building sophisticated Ajax applications easier than ever. Step through your code line by line, setting break points along the way. This allows you to make sure your application and scripts are acting as you designed them.
Redefine your style: Its not just the DOM you can inspect. Check out what CSS rules apply to which element, and what rules are inherited or set by browser defaults. Overridden rules are highlighted so you can see what styles are or aren't applied. Support for editing CSS rules will be added in an upcoming version.
Spot your errors: An improved error console allows you to see, filter and log any errors in your scripts, pointing to the exact position the error occurred. Use this in combination with the other tools to hunt down and fix your site’s bugs.
Debug the DOM: View source isn’t much use if you use DOM Scripting to alter the DOM. Opera Dragonfly allows you to inspect the updated DOM and all it's properties. Support for editing the DOM will be added in an upcoming version.
The features that are not there yet, but are upcoming, include support for editing of CSS, JavaScript and the DOM, a single window mode, improved JavaScript thread handling, XHR and HTTP monitoring, improved keyboard navigation, and translation into a number of languages.
Roman Strobl has just published a screencast of the new JavaScript editor in NetBeans 6.1. The demo is around 5 minutes and highlights many of the editing features.
I'd like to dwell on the type inference part a bit. Around four minutes into the demo, Roman shows that NetBeans figures out the types of expressions, including those involving function calls. In his example, all the types happened to be Strings so it may look like a lucky coincidence. It's not! Here's some code fragments showing in more detail what's going on.
He goes on to walk step by step through the completion points discussing how the IDE can get the information that it does.
It is great to see this great support for dynamic languages, as we are accustomed too on the static side.
Vishal Shah has put together TPHP, which stands for "The Perfect Home Page". It is just an HTML page with a bunch of JavaScript in it, that acts as a command line to a lot of things.
You can type in special codes to do smart things like search wikipedia, access domain tools, or what have you.
Of course, this is primitive compared to something like Enso, which was made open source when the team went to Mozilla. It is also now running on Mac and Linux, and it has the feeling that it could be a nice companion to the browser as a command line.
It seems a little funny to have an Ajax app announcing that it now works on Mac, but there is good reason:
This week, we are releasing WaveMaker for the Mac (OS 10.5 Leopard to be specific) and Safari. Although the Mac is a visual platform, it has always been behind on WYSIWYG development tools. With Wavemaker, the Mac is leaping back in front.
He then indulges himself in a pro-Mac explanation that goes like this:
Ajax platform of choice: Safari is lightning fast and leads the pack in standards-compliance. I can't remember the last time I saw any web app demoed on Internet Explorer, and if Firefox ever gets ported to Safari, Firefox will be in trouble.
Video platform of choice: we just went through a 3 week death-march to create a new screencast for WaveMaker. Of that time, about 8 hours was spent creating content - the rest of the time was spent wrestling with the brain-dead video software we were using on the PC (Camtasia). In contrast, my 12 year old niece just created a 30 minute class presentation using i-movie. Enough said.
The Incredible shrinking desktop: with more and more compelling web applications, I find myself spending less and less time working within my Windows desktop.
The disaster that is Vista: given that I have to relearn the whole user interface to move from XP to Vista, I might as well relearn an interface that actually makes sense.
That cool backlit logo on the Mac laptop: let's face it - the knowledge that you will look good in a coffee shop probably sells more laptops these days than Ghz or RAM stats.
Jon Brisbin is a Java programmer doing iPhone development, and decided to scratch his own itch for a better iPhone remote debugger, creating iPhoneDebug:
The iPhone Debug Consle is meant to give greater visibility and interactivity on your iPhone/iPod Touch while doing development. I grew frustrated having to go through the "include console.log statement then reload" method of debugging. I wanted something similar to Firebug's fantastic console and debugger.
I grew frustrated with trying to debug my iPhone/iPod Touch apps because I had no interactivity with the page. I couldn't interrogate variable values or CSS values unless I put in a console.log statement and reloaded the page. This is far from ideal.
In trying to find something that would fit my needs, I came across Joe Hewitt's iPhone/Firebug integration, but I wanted something more robust and that worked without firebug and requiring "console.log" in the desktop browser.
I'm a Java programmer, so naturally I thought of using COMET and Jetty to pass messages between a desktop browser and the iPhone. A couple days later, I had a workable solution. It lets you log things in your mobile JavaScript to a desktop console, but the biggest plus for my situation is that I can send JavaScript to the iPhone to be executed there, with the results logged back to my desktop console. Just like in Firebug, I can call methods, retrieve CSS values, and all manner of debugging activities I've grown used to doing while building apps with Firebug. There is also rudimentary UP and DOWN arrow command retrieval on the prompt.
Here it is in action, getting commands from the console:
Thierry Parent has released a new version of TraceTool, his open source tracer program, with a JavaScript client.
The javascript TraceTool API is a cross browser (tested under Internet Explorer 6, Internet Explorer 7, Firefox 2 and Opera for mobile) and cross domain tracing solution (maybe the first one). The viewer can be installed on any windows PC (localHost for example) while you are displaying a page from another server. Debuging a Web page from your mobile is very easy. Just configure the TraceTool JavaScript client to use the viewer on the network.
To allow sending traces to another server as the original page (Cross domain communication), the API does not use Ajax (Single domain) but dynamic script creation. Traces are encoded and passed in parameter to the viewer. Large trace messages are split into multiple scripts.
With this API , you can send simple traces, objects , dump, call stack, manipulate traces (sub traces, delete, append,...) and more.
An ideal complement to firebug and a great enhancement to IE debugging with one API for Java, JavaScript, .Net, Delphi, C++ and ActiveX.
Over on the Google Open Source blog I got to post about a new tool by Lindsey Simon that takes your CSS and spits out versions ready for the RTL world (or vice versa if you are a developer elsewhere that wants an English version..... which may be more common?).
CSSJanus is CSS parser utility designed to aid the conversion of a website's layout from left-to-right (LTR) to right-to-left (RTL). The script was born out of a need to convert CSS for RTL languages when tables are not being used for layout (since tables will automatically reorder TD's in RTL). CSSJanus will change most of the obvious CSS property names and their values as well as some not-so-obvious ones (cursor, background-position %, etc...). The script is designed to offer flexibility to account for cases when you do not want to change certain rules which exist to account for bidirectional text display bugs, as well as situations where you may or may not want to flip annotations inside of the background url string. CSSJanus itself is not always enough to make a website that works in a LTR language context work in a RTL language all the way, but it is a start.
Here is Lindsey talking about it, and showing how it works.
WaveMaker has just released a new version of its open source Visual Ajax Studio v3.1.1. It is similar to TIBCO GI, but built on top of Dojo with JavaScript output that is very terse and even looks like something you may have written (which is rare indeed for a tool).
Studio lets users create database- and web service-driven Ajax web applications using a wysiwyg visual designer. WaveMaker helps users create simple applications without any scripting knowledge, while developers can easily add Javascript, HTML, CSS, and Java code to create complex application behavior.
Studio is a web-based application that leverages the Dojo Toolkit to create pages containing widgets and Dojo Dijits. Users drag and drop to create complex page layouts containing the Dojo grid, Dijit based forms, Google Gadgets, and a variety of other included widgets. Developers can even author their own widgets and include them directly in the designer.
A Java-based backend provides access to database, web, and user created services. Applications are deployed in a standard WAR container for use on a variety of Java application servers. For ease of use, Tomcat is included with the installer. It's also possible for Ajax developers to use their own backend with Studio generated web pages.
Wavemaker Visual Ajax Studio is available under the open source AGPL version 3 license as well as a commercial license. Download Wavemaker Visual Ajax Studio at wavemaker.com.
When you reload the page, a window will open that contains a list of the scripts as they are loaded, the uncompressed collection of code, and the code compressed with Packer. You save the compressed code on your server and turn on production mode:
Scripts load in the same order across all browsers (last-in first-out), which is nice, considering document.write by default works differently in Opera.
Another aspect we're excited about is that Include makes it so you'll never have to write a custom server-side compression script again. Since the scripts to compress are determined at runtime, you can easily compress large libraries with conditional plugins, like TinyMCE.
Instead of duplicating that logic in a server-side script, you can choose your plugins, turn on compress mode, and you've got your compressed code. To demonstrate this, we ported TinyMCE and plugins to use Include.
Include is open-source with an MIT license. I hope you find it as useful as we have.
When you start a new JavaScript library, how do you layout the source files, the tests, the distribution files? Do you have support scripts to generate distributions from source files? Run your JavaScript unit tests? Generators to create new unit test HTML files?
This is why Dr. Nic created newjs, a Ruby script that sets you up to do the right thing by your pet project. No longer will you crack open a .js file and slice and dice your JavaScript willy nilly. Instead, you will use newjs to:
Setup your directory structure for src, tests, documentation, distribution
Start building unit tests using unittest.js
Generate test files
Run unit tests and get nice HTML output
Package up your src for distribution
Create a website for your project (wait. is this maven???? ;)
He talks about a new site, inursite.com that does one thing:
The premise is simple; enter a few of your sites and inursite will visit them once a day and run a markup validation service over the page. You then get a feed of the pass or failure status. It’s simple but brilliant. For example, I have this very site added to the service. If I put some invalid markup in this post, tomorrow morning I’ll get an item in my feedreader telling me of my mistake. I’ll get that every day until I fix the problem.
This green/red (pass/fail) type approach to simple tests is what I find most powerful about continuous integration systems like Cruise Control.
Gareth also has some ideas for improvement:
Has all the CSS been compressed using something like CSSTidy.
Has all the javascript been compressed using something like JSMin.
Does any Javascript pass the harsh taskmaster that is JSLint.
If my markup a little bloated? Maybe I could set a maximum size for the markup and get a fail is I go over that.
Ditto CSS file size.
Ditt Javascript.
Ditto images.
If pages have associated feeds, then validate them as well according to the relevant specification (probably RSS or Atom).
How many HTTP Requests does it take to load the whole page, including all the relevant assets.
How many hosts are required to load the whole page? I’d like to be able to set a maximum number and get a fail if I go over that.
Is the page gzipped on the server.
And just to keep this topical, does the page have either the IE8 meta element or the associated HTTP header set to a particular value.
This sounds like setting up YSlow to run in a continous manner.
Paolo Severini, a Microsoft employee in Dublin, has build a JavaScript Memory Leak Detector that detects leaks with knowledge of the difference between IE 6 and IE 7.
How does it work?
Like any IE Band, the JavaScript Memory Leak Detector is a COM in-process DLL loaded in the Internet Explorer process. The fact of living inside the IE process allows it to easily intercept some of the API calls made by the IE code. In this case, we are interested in intercepting every call that creates a Jscript engine.
The Jscript engine is a COM object, and it is instantiated by Trident (mshtml.dll) with a call to CoCreateInstance(). Therefore, the first operation made by the tool will be to intercept the calls to CoCreateInstance made by the mshtml module. There are a few ways to implement this API hooking; in this case the simple technique of overwriting the module Import Table in memory works perfectly. (See Robbins' "Debugging Applications" for more details).
At this point we can substitute our own Jscript engine in place of the real engine. By implementing all the ActiveScript interfaces exposed by a Jscript engine and delegating all the calls to an instance of the real Jscript engine, the tool can transparently intercept all the interactions between Trident and Javascript and still have Internet Explorer to run correctly.
Now, a Jscript engine by itself has no notions of Internet Explorer and its DOM objects. It is IE that registers the root (window) object to the engine and loads into the engine all the scripts contained or loaded by a HTML document. Since we are intercepting all the calls to Jscript, we can thus have a reference to all the DOM objects that are passed to or used by a Javascript function.
The technique to do this is a bit tricky. A DOM object is passed to (and accessed by) Jscript through an IDispatch interface; so for each new object that we meet we create a fake COM object that works as interceptor (or wrapper), exposing IDispatch and delegating the calls to the real (contained) IDispatch object.
Every time a method or property is called to a DOM element by JavaScript, the call is actually made to our wrapper and then delegated to the real object. The wrapper can analyse the method in/out parameters and return value, looking for other IDispatch pointers that represent new DOM objects. If it finds a new IDispatch pointer not yet met, we know that this object will now be visible to the JavaScript code, and we need to build another wrapper and pass it to JavaScript in its place. In the end, every JavaScript function will access DOM objects only through these wrappers and the tool will have complete control over the script execution.
We all talk about Firebug, which is a fantastic tool for debugging, but there are some others out there. WebKit comes with Drosera, which until now has been hard to get going on Windows (you could build from source).
Our JavaScript debugger Drosera is available in the Windows nightlies, and I would love to get some help testing and finding issues. Drosera will not work with the Safari beta, but should automatically connect to the nightly it's downloaded with. Simply use the run-drosera script that's now included. I'm excited to bring Drosera to Windows and I hope it becomes a go-to tool for your Windows JS investigating, testing, and development.
Do you care? Are you on Windows and have been jealous of the Apple debugging love?
, Utility
