I went along last night to the London Mozilla Labs meetup, where Dion, Ben, and Joe delivered a presentation on Bespin. These are my notes from the event.
Goals
Bespin - initially an experiment, now interested to see how far it can go as a coding environment (among other things).
“The editor of our dreams”:
Accessible from anywhere
Simple to use, like Textmate - for people who don’t want to muck around with low-level details, too much time in version control
Wicked fast - many editors look okay initially but don’t scale well with large files and fast editing
Rock-solid real-time collaboration - like SubEthaEdit - watch people in our time, e.g. follow someone like Brendan Eich as he codes (given that it’s already open source). One of the meta-goals here is to lower the barriers for open-source development.
Integrated command-line, like Vi
“Self-hosted” environment - like Emacs. As a programmer, can get into its guts. And can do this kind of thing in real-time - modify the model as it runs (c.f. Eclipse - must re-compile)
Demo
Dion demos interacting with the Bespin editor. (Always good to see how the creators eat their own dogfood.) Ben points out it’s fast, thanks to Canvas. Some demos of the command-line, its extensibility, and collaboration features.
Collaboration
Moz hired Joe Walker of Comet/DWR fame a month ago. Joe explains collaboration goals.
Typical scenario - two coders working simultaneously, perhaps chatting over skype.
From Neil Fraser (worked on Google Docs stuff around this) - designed as a “little version control system” - sends out diffs and patches it (see Mobwrite. Bizzarely, the bottleneck is not the network or the patch, but the diff. And exarcebated by the fact that typing faster - doing more work - necessitates more diffing.
Joe shows debug messages in Firebug console - showing diff info going to and from the server
Extra Features
Code nav - heatmap showing all of code and what’s been edited. recently. Example of a mashup component you can build.
e.g. IBM coder turned it into a Java compiler - by compiling the Java on the server. Used Bespin’s server API. Likewise, the editor is also a distinct component - can use the editor for other (non-IDE) application - e.g. a wiki project using Bespin’s editor to edit the wiki. Likewise, the command line is separate. And there’s the underlying core, Thunderhead.
Ben further emphasises it’s not just a rich client-side editor - server-side code analysis with the RESTful API.
Upcoming Features
Big things:
Collaboration
VCS integration - integrate with Mercurial, etc etc
Ubiquity Integration
Server Side Javascript - can have different server implementations, could be Ruby etc, and want to implement one in JS
Smaller:
Some nice commands
Plan “follow me!”
Syntax highlighting
Design concepts
Templates (”create project Rails”)
Editor functionality
… many more - need people to help with it (engaging with the community and supporting contributions in an open-sourcey way is a big theme in this talk)
Fin
They leave us with a clip of Dave Thomas @ RubyConf asking if it’s weird to love your software tools, and answering that you have to love your tools. Fair play!
Questions and Answers
Q. Distributed Version Control - will bespin support it? Bespin designed for two basic use cases (a) standard thing - check in to repo etc (b) bespin.mozilla.com - SAAS type model.
Q. What data structure is being used for patch sets? Because a decent structure would make VCS possible. Mobwrite - Neil Fraser’s project behind Google Docs - so using that format, but we might expect it to change in the future.
Q. (me) Eating your own dogfood Dogfooding by end of month, when VCS lands or using Appcelerator Titanium to run off local file system.
Q. (about integration with Ubiqutiy I think?) Ubiquity as the runtime and Bespin for authoring. Initially, separate to Ubiquity and then normalised commands with Ubiquity. Now just starting to share components like parser. Next phase, access to virtually all of Ubiquity and will work even without Moz browsers. And the other way round - running Ubiquity commands inside Bespin.
Q. With the collaboration engine, can you do more than code creation, e.g. drawing or spreadsheets? Using Mobwrite, the engine behind Google Docs’ collaboration - Mobwrite’s restricted to text - as long as there are changes to some structure (ie it can be serialised), it’s possible.
Q. Codes and tests in the cloud - should be great for continuous integration There are various people already implementing the Bespin server API for other things too. With the code out in the cloud, very possible to do all sorts of things with the code. John Resig (also Moz) is also interested in this area - also wrt manual tests that are downloaded to various people’s browsers and run locally. Maybe could even be automated using the aggregate crowd while the browser isn’t doing anything else. Another project is Test Pilot (usability testing).
(On a related note, I mentioned later on it would be interesting to couple the code with real-time user data, e.g. a heatmap overlay on the code showing how much resources each segment used during real-world use.)
Q. Hyperlinking in code? Could you create ~implicit links, e.g. to other parts of the code? Don’t have hyperlinks because it’s canvas! But will be able to implement these things - would be done as a syntax highlighter extension.
Q. Firstly, the name? Secondly, the offline capability - can I just run it directly off the local file system. With Appcelerator Titanium, would feel like a real desktop app while offline, but can still access the cloud when connected. (No-one answered the name question ;)
Q. Mashups in the browser - loads of scope for in-editor mashups, will it be part of the editor framework Right now, editor has an event bus - events like “he’s opened the file, he’s hit a key”, so can set up events for this kind of thing. It’s all based on an asynchronous model, so very possible.
Q. Will there be user testing - to see what people really want? There’s a huge list in Bugzilla for these kinds of things. This is a tech preview, missing a ton of functionality. Already improved, but a lot more to do.
Q. Vim or Emacs macros - which will be first? Have implemented Elisp and Javascript, so it’s only a matter of time. (cunningly avoided expressing a preference :)
Q. Functional reactive programming (FRP) - Flapjax demonstrates the idea in JS - for pubsub. Would it be possible to extend the current pubsub framework into a FRP framework - avoids bugs around order . Would be good to see something like that.
Q. Are you “re-inventing the web” with this stuff, i.e. finding that canvas doesn’t support it? Yes, do have to reinvent a lot of things - people coming together to discuss these things - ARIA etc. Very focused on accessibility. Two ways to do it - (a) hacks like the cut-and-paste to mirror what’s happening; (b) longer-term - drive the browsers forward.
Aside - Bespin currently leaks memory. Browsers are now runtimes, so want to build a tool for memory tracking. (a) Log each garbage collection. (b) Graphical view of the heap. After that, tool after that is meta - a directory of all the tools out there.
Q. On a much smaller scale, could it be used as a textarea? Yes, Firefox engineers were keen to look at that.
Q. How much implemented in Javascript? Very much the trend in Moz. cf. Aza Raskin’s recent post on doing an extension in Javascript (*cough* Chrome *cough*). All the XUL stuff was necessary at the time. Javascript’s not the bottleneck anymore.
Q. The name? (as was previously asked) So with that, let’s wrap up.
My colleague Fred has also posted his impressions.
This was my favourite presentation of the year. Ben and I have given a lot of talks together, and to spice things up we created the presentation randomizer, a simple Ajax app that would sound a buzzer at random times. Why did we do this? When the buzzer went, we would have to instantly change presenter. “Who’s line is it anyway?” for geeks.
The presentation was recorded by Adobe, and Ted Patrick just pushed it live:
The Ajax revolution is complete: Sophisticated JavaScript user interfaces are nearly ubiquitous. Yet, the innovations in the Ajax community continue. Dion and Ben set the stage for the Ajax Experience by discussing the latest developments, including multithreaded JavaScript technology-powered UIs, robust offline storage, choosing the right Ajax/JavaScript technology framework, Ajax outside of the browser, and more.
Thanks again to the entire community that came out to The Ajax Experience. Without you, we wouldn’t have this opportunity.
At our Ajax Experience keynote this year, Dion and I coded up a simple little program that buzzed at random intervals every 10-120 seconds. Whenever it buzzed, one of us had to stop talking and the other would have to pick up right where the other guy left off. It definitely kept things fresh.
Quite a few folks asked us to release the code. It’s quite trivial; check it out.
We used SoundManager2 to play the buzzer sound; the rest is straight-forward.
First, we have his interactive learning area where the presentation is just a JavaScript application that you can play with. Double click on the code, make a change, and save away!
The talk goes into the innards of the language that we are know, love, or at least deal with:
Defining Functions
Named Functions
Functions as Objects
Context
Instantiation
Flexible Arguments
Closures
Temporary Scope
Function Prototypes
Instance Type
Inheritance
Built-in Prototypes
Enforcing Function Context
Bonus: Function Length
The goal of all of this, is that after going through the presentation you should understand the following:
Dean Edwards, Brendan Eich, Christian Heillmann, Jake Archibald, Joe Walker (chair)
I've captured at least some of what was said here ;).
What is the Open Web to you and why is it important (or otherwise)?
(general agreement that it's good thing, as we'd expect :)
Christian - What if open formats don't have the reach? e.g. ogg vorbis.
One JS file can't depend on another without wrapping all the code in a function. How should this be solved? An "include" function in ES4?
Brendan - "include" could make UI lock up. Can do it with (html 5) web workers (speculative parsing).
Should you pick just one library/framewrk to use, a handful, or have an open policy to use anything at any time? How do you evaluate which one(s) to use?
Christian - would be good to see comparison sites like cmsmatrix.org, not just which one is 20 milliseconds faster than the other. (MM - I tried to create something like this, but it could be bigger in both dimensions.)
Discussion about the "glow" library created by BBC, discussed by Jake Archibald yesterday. Okay to release unpolished product to open source as an individual or small company, but harder when it carries the name of a big organisation like BBC.
What kind of build scripts/engines do you recommend to concatenate multiple scripts into one?
Jokes about copy-paste and batch scripts.
Christian - It's 2008 - we should be using minifier, etc. More structured approach to releasing.
What recent tools or techniques do you use to speed up or improve your development process? Do you have any quick tips?
Jake - More developers :) HTML editor - Komodo edit. Debug - Firebug in FF, Developer toolbar and windows script debugger in IE
Christian - Moving to a Mac made developing far better, and partly due to Textmate. And Javascript bundle that runs JSLint over your code. Firebug.
Brendan - Distributed version control systems have been good. Textmate's good, but I'm an old Vi/Unix hacker.
Dean - Recently disabled Firebug to speed up development - causes bugs, reports misleading line numbers, etc. Went back to error console which gives you the correct line number. (Joe - it's getting better now.) Microsoft script debugger is actually quite good.
Christian - Firefox still the coolest browser for developers, but with all the tools, have to keep turning off greasemonkey scripts etc.
Does Cappucino / Objective-J have a future? What are their benefits and detriments?
Dean - More problems in the browser
Brendan - GWT guys are realists, acknowledge their abstractions leak. But OTOH they've made Ajax development accessible to Java developers who otherwise wouldn't do it.
Brendan (asked about what he'd do if he could change the language in the browser) - You'd get a lot of demand for Python and Ruby, Python's probably the more mature.
Brendan - Flex originally intended to make web app development like windows development. (Questions this approach). Pity we don't have things like JQuery for desktop apps.
What's the biggest missing bit of functionality from modern web browsers?
Christan - Big problem is we're stuck with old browsers.
Jake - Large companies lock down IE6.
Poll of audience - many people work for companies where the average user still runs IE6.
How to prevent? 37signals, Apple, Facebook have all written apps that don't target IE6. Christian-mainstream media could help, e.g. recent article saying users rarely get viruses via FF. Facebook also recommends FF and Safari along with IE.
Christian - Chrome is targeted at regular users, not developers - so IE market share might reduce. Brendan - Chrome might, good if they do, but difficult to see how to make a major change.
Jake - Apple get away with a lot of evil that if MS did the same thing they would be beaten for. e.g. Apple ships with a browser, just like MS.
Back to the question - what would you want:
Dean - standardised behaviour extensions for CSS
Jake - constants in CSS
Joe - vector graphics engine - canvas everywhere
Christian - web forms - e.g. calendar control
Jake - CSS - multiple background images
Christian - better layout (discussing boxes and vertical centering). Right now, we're as hacky as we were with tables.
Christian - better video and audio support (Jake - Flash alrady does this well, would rather see effort spent on other things).
Steve does his thing, and goes in glorious directions, such as how we end up with a scriptable back end, how the JVM matters as a host for these things, SchemeScript, how defineProperty gets around the for .. in issues, "Who likes to write their own giant deterministic finite automata to do string matching? Heh. It's weird — nobody raised their hand.", obj = {run: function() { print('hi') }}, RnR (Rhino's not Ruby), "And Scala's interesting because it actually takes a functional static type system and it layers... it merges it with Java's object-oriented type system, to produce.... Frankenstein's Monster.", and man it just keeps going and going.
As much a talk about languages as a whole.... and a lot of fun.
Some good stuff came out from my employer. First, we have the Gears 0.3 release which includes support for Firefox 3! I have been using it for awhile, and it has been great. The team wanted to get it out before the Firefox 3 launch (planned for June 17th). A plugin like Gears can get deep into browser internals, so it is a challenge to keep up to date as APIs change in beta releases, so it is great to be out there now and I we will take a close look at the final release!
Ben and I gave a presentation at JavaOne on what's new with Ajax. Since this was JavaOne, we skewed a little more than we normally would to Java topics, and one of them was using the new Java Plugin, that has great new features such as being able to take a running applet out of the web page, and having it continue to live after shutting down the browser. Java is running out of process here, which also helps the "Java crashing the entire browser" problem.
Anyway, back to our demo. For some context, last year at JavaOne had us performing Guitar Hero on stage, so we knew that we had to use a gaming console in some way. This year it had to be the Wii, but instead of using the console, we decided to just use the controllers.
Wouldn't it be cool to control a Web page using the controllers? We thought so, and we set to it. You can talk to the Wiimotes via Bluetooth, so we needed a stack that would allow us to do just that. Java has a bluetooth stack. We could get an applet to talk to the Java stack. Hmm.
It actually took quite some time to test out the various stacks out there. In the end we went with a native system called Wiiuse that a lot of Wii hackers use. There is a wrapper library called Wiiusej that gave us exactly what we needed.
A quick test later and we had an application that was talking between the remote and the program. It turns out that the main controller sees a series of IR lights that are in the Wii sensor bar, and this allows you to simulate the system with any decent IR source. In the presentation room the big lights that shine on stage were strong enough to act as a sensor bar so we won't even have to use it. We can just point out to the crowd.
Anyway, back to the application. We then wrote a Java class that acts as a state machine for what the remote is doing. It understands the movements, which buttons are pushed, how fast you are moving the device. With this data we could build a simple darts game. With the state machine Java code, and an Applet wrapper that exposed the information, we were ready to get to the Ajax side of the house.
We painted a darts board onto the screen and then had JavaScript start polling the Applet for information via JSObject (As simple as: document.nameofapplet.pollmethod()). This turned out to be more stable than talking the other way, even though it meant we were polling instead of being entirely event driven. When the JavaScript code polled the applet it would pass back a data structure with the data for the coordinates of the remote, and whether the dart had been fired (button A to fire, button B to reload). We would move the dart image on the screen as you move the remote, and when fired we kicked off an animation to fire the dart at the board.
At first, it was all too simple. You setup the shot and it would get the right area every time. Not a fun game. We then decided to add some simple physics to the Ajax game. We took into account the velocity of the throw (if weak it would fall down) and how straight your shot was. If you wiggle around, the dart will not be accurate.
Anyway, this was a lot of fun, and shows that as much as we mock Java applets, if we forget about using them as fancy blink tags, and instead think of them as more extension points, maybe there is life for them.
The video below shows you a demo of the application, the source code with an explanation, and more details.
John Resig got in front of the camera, and the projector, as he gives us his thoughts on the state, and future of Ajax.
He starts out by discussing jQuery Core, and the features in the near term (1.2.4), short term (1.3) and beyond. He then delves into the UI side of the house with jQuery UI 1.5. He segues from jQuery to the future of browsers and JavaScript in general.
Ryan Stewart of Adobe and I got to give a joint talk this morning that covered Adobe AIR, Gears, and how you can build offline and desktop applications right now.
Obviously, Ryan gave an overview of AIR, and I did the same for Gears. We also discussed reasons to be excited about Web development, some of the ideas that are out there in the community, and how AIR and Gears can be seen as complementary.
We had some requests to put the slides online, so here they are below. I know it is hard to peruse slides without the talk over, but just think of it as a fun exercise to wonder what we said :)
Gareth Rushgrove has been talking a lot about API design; a true art amid the science of CSci. He gave a presentation at the highland fling (our own Christian Heilmann was there too) and starts out by walking through thoughts on the various ways that we (or robots, or rabbits) interact with the Web.
Then he gets on to the API design where he takes a look at some of the popular ones (e.g. Flickr, Twitter) and tries to find some general truths:
I covered the basics of JavaScript - targeted to a Computer Science major (in the case of the students at NU, they learn Scheme and Java so I emphasized the subject matter to that audience). I did a fast run-through of the whole language, covering the main points, and move on to a quick inspection of jQuery and the DOM - closing with some Q&A. The subject matter of JavaScript 2 (and 1.6-1.8) came up a couple times so discussion of that was interspersed throughout. There were a bunch of jQuery users in the audience and it was great to get to hear their feedback.
Andrew Dupont, Thomas Fuchs, John Resig, Alex Russell, Sam Stephenson. These were the folks that gathered at SXSW to talk about the "Secrets of JavaScript Libraries" in a panel that was full to the brim (as was the browser wars one the day before).
The slides are now up, and the podcast is forthcoming:
The group covered:
JavaScript the language
Cross browser coding
Events
DOM Traversal
HTML Style
Animations
Distribution
HTML Insertion
I hope that SXSW ramps up a little on the technical talks next year.
In this two part screencast, Jochen Krause and I talk about the Eclipse Rich Ajax Platform, or RAP for short. RAP is a front-end framework that uses the Eclipse RCP programming model to create Ajax front-ends in Java. In the first part, Jochen gives us an overview of RAP and how it fits into the overall Eclipse runtime and then shows a few demos of using RAP in the second part.
The scope of the presentation is to show how to speed things up right now, not in the future.
Optimizing Symbol Resolution
How to speed up in a late binding world. Discusses the scope chain from vars to the DOM itself, and how to make sure that you don't keep running around the chain.
JavaScript Code Inefficiencies
To make string manipulation more effience in IE:
Use local vars
Cache strings from IE objects
Use Array.join for concatenation
(I prefict that array.join will stick around even when it isn't faster, just like the equivilent in Java land).
Some other thoughts:
Don't use eval unless you really have too. Instead of parameterized code
SWITCH is costly for large sets, consider a hash table wrapped in a try/catch
WITH is costly due to symbol lookups everywhere, use manual iterators
Don't use your own get/set accessors
IE Performance Considerations
DOM is expensive in IE, especially due to the generic nature of the platform. Also watch out for layout improvements such as hover CSS style.
HTTP Performance
Simplify and reduce:
Script in on JS file
Styles in one CSS file
Fewer, smaller, unscaled images
Simplify layout
Use HTTP compression (lots of detail on cache control)
Tools and Techniques
Developer Toolbar
Fiddler: HTTP traffic watching
Ajax View: New from MS Research. On the fly rewrite the JavaScript and add instrumentation code.
, Canvas
