Hi I am Dionysios Synodinos and we are here at Qcon San Francisco talking to Dion Almaer and Ben Galbraith about development tools for the open web. Recently Mozilla announced the creation of a new group The developer's Tools Lab, that will focus on the research and development of developer tools for the open web. You have both joined Mozilla full time to lead this group. First of all I would like you to tell us what is the open web for you and why do you think it is so important. Does it include technologies like Flash, Flex, Silverlight or Java Effects? Or is it only JavaScript and HTML?

Ben: Yes, we have given this a lot of thought, because the term open web means a lot of different things to a lot of different people. For us open web means that applications, web applications are free to run on any platform using any browser that you as a user care to run. And Mozilla as a company is really focused on keeping that definition of open web alive. The sort of night mare scenarios is that in two or three years your bank has decides that it wants to have its experience in a proprietary technology let's just say Silverlight for the sake of argument and you have to run Internet Explorer 9,8 or 7 whatever happens to be, and that is the only way you do what you want to do on the web.

And it is not so theoretical, a few years ago we actually saw with IE 5 where some experiences, some properties required the use of IE5 which implied Windows. So we want to make sure that never happens. So, that's what we mean by open web and we are really focused on making sure that the web technologies like HTML and CSS these standards that comprise the open web are attractive and enticing enough to developers that developers go down that path and they are tempted into these proprietary stacks, that could lead to a closed web situation. So to us that's really what the open web means. We are really sort of excited about expanding that a little bit too. We are really interested in driving more classes of applications to the web, than we have seen previously. Do you want to talk a little bit about that point of expanding the role of applications?

Dion: Sure. We can talk about that and you mentioned Flash and Silverlight, and we think they are great technologies and Ben was talking about how we want the open web to be excited enough to develop as we don't have to win just like as a pity vote for developers, like "Well this thing is pretty bad, but you know". We don't want to be locked in by Microsoft, we wanted to be compelling but for us yes Flash and Silverlight that's not open, that's one vendor that has full control of everything that is going on, and I think what is exciting and what I am really excited about, us being from Mozilla, is because we are in a place where we don't have particular agendas other than keeping things open.

As you kind of go through history a little bit, you see this points where vendors and developers come together and we create something that is compelling for both Visual Basic or something where it makes sense, is productive, but then over time that vendor might get very different agendas, very different thoughts on what they want to be doing as a company, so even when for a particular instance you could be aligned on something, you are not guaranteed anything at that point, so we want to really stay away for that lock in so that we can have this evolving system that is the web, continue to evolve over time. And then do you want to talk back about the expansion idea?

Ben: Yes, so one of the things that is exciting is the emergence of Ajax, is something called Greasemonkey. And Greasemonkey is this technology that lets you take arbitrary JavaScript and inject it into your web browser, that lets you modify running applications in ways you never intended. And as soon as that use case emerged, that got a lot of us thinking about this idea of tinkering with your application, and for example if you go to Gmail, Google has embraced this idea of exposing parts of the Gmail JavaScript runtime object graphs and they have stabilized it so that people can go through and modify that stuff.

As we have seen this model, applications that are tinkerable we have really started to get excited about having all of our applications, running this web applications, that's the one piece that sort of has taken this over and say "Even though WPF and Cocoa and all this Desktop technologies can produce compelling user interfaces, this tinerability is really powerful". And then as time has gone on we have seen sort of augmentations of web applications, building on top of these and other principles. For example there is a technology called Fluid, on the Mac that fits in this category called single site browsers that lets you take a website and run it as a stand alone application so that the technologies like Fluid, Mozilla has one called Prism, Adobe has one called Air, the idea is that you can point this application at a single URL and it becomes a full fledged application that you can launch from your application directory that you can alt-tab to, it's not just another browser instance.

What is interesting is that you can inject this Greasemonkey scripts into this single side application and modify it in interesting ways, but it is exciting because the single site browser engines let you gain access to proprietary operating system functionality, functionality that is normally not exposed to the browser sandbox. And just a few minutes ago we were preaching the importance of openness and standards and now I am excited about proprietary object models as opposed to individual single side browser pieces.

The idea is that all of a sudden web developers have access to the Desktop and that is a world that we are really excited about because as web developers have always been this kind of cliff and the Iphone is a great example of what I mean by cliff because you can develop an Iphone web application and as you know you can make a web application on IPhone look almost like a native application up until you want to access certain pieces of data functionality, at which point it's not that there is this sort of new extension API you need to learn, you have to learn Cocoa, you have to learn a whole new set of tools, you have to figure out how to ...

It's a huge cliff that you drop of as a developer and we are excited to see the boundaries of this cliff extend and we are seeing this with Safari, where Safari has actually injected new proprietary JavaScript API into Mobile Webkit that lets you access more and more native pieces of the Iphone inside of this environment this means that as a web developer you can use your familiar HTML, JavaScript, CSS to create near native like applications and not just on the Iphone we are excited to see this pattern emerge across Desktop environments to the point that we are really excited to see a world where developers don't have this cliff at all, where the same technologies that you use to create web applications you can use to create Desktop applications, mobile applications and you can be enormously productive, and you just have these new extension APIs and they seam these environments to drive this applications with Canvas in HTML 5, and with some of the prototypes of the 3D canvas we have seen for Opera and Mozilla, and with a host of other new features added to this set of technologies that we have been looking at.

We're seeing a lot of the gaps being filled in as well, because traditionally you would look at a web app and you would say "That could be good for static interfaces or business interfaces but you could never build X or Y or Z". But now we see those edge cases that you wouldn't traditionally use for web applications, start to erode and we are really starting to ask ourselves especially with the emergence of hyper fast JavaScripting interpreters in recent months, we are on the boundaries, when would you actually not want to use web technologies?

Dion: Before we would ask, who would build an email client on the web? That is going to be really slow, this really nice mapping client on the web. Who does ITunes on the web right now? That can be hard but what can we do to make it so that the next Itunes could be on the web and kind of step through and knock down these boundaries. I worked with a team, when I was working at Google and that was one of the big things that they were trying to do, like knock down these little bits of functionality that makes that cliff, so, all of a sudden you could take the same skills that everyone has on the web and they can use them to build these different platforms, that's going to be exciting to see. Who knew that this was going to happen when we started the Java and Ajax stuff, these little DHTML hacks would be good.

Ben: Yes, to all the work we have done on Ajax, we never advocated this expansion of the hacks that has emerged, it has definitely been organic and has been through the community and we are just watching and we are really excited of the direction we have seen. We have kind of extruded a lot out of your question.

Some believe that the best thing about the open web is its diversity and polyphony. You have different organizations developing and promoting different technologies that blend together to provide the final product. There are others though who believe that this only leads to a necessary fragmentation of the web, as a platform, a side effect of which is the lack of proper tooling. What is your view on that matter?

Ben: Do you want me to take the first crack of it? Do you want it? This is a debate as large as technology. I mean even in govern democracy you got Stalin kept the trains running on time,, there are tremendous efficiencies to be gained from this despotic hegemony. For example if you look at the .Net environment you got a language dictator for C#, actually I don't know if you have anyone who claims to own VB, but you got a strong centralized leadership with a strong cohesive vision and they tell you how to write your application, if you look at that ecosystem, it's bizarre if you are a Java guy because they don't want third parties to come in and own parts of the road map.

They want Microsoft to pronounce how it shall be and they get enormous efficiencies from that model and you can't really knock it out of hand, it's a good model. At the same time democracy, polyphonies as you called them, these ecosystems of cooperatives are notoriously inefficient. And as old Java hands, the JSP has enormous efficiency problems, there is a book out that a lot of people cite called "The paradox of choice" the talks about all the inefficiencies. For example is a Java project how many times have you set down and you got to spend days to sort how many different tiers you have and then weeks to find out what the different solutions to find how to treat those tiers and then months to do the actual evaluation.

Dion: Whenever we throw out logging frameworks and you pull your hair out.

Ben: We just want to come out of the chute and say "This is a large issue for societies across all categories of life, whether you want freedom or whether you want efficiency and it's difficult to have both". And having said that we are excited to explore the hybridization of those two polars and our view is that we want to work from Mozilla with a lot of other players in the space, so the open source players, commercial vendors, to provide guidance and vision to the development community as a whole. So that developers have less confusion about how to proceed with application development. We really want to produce a world were either using the proprietary stacks or even using the open web developers can point to a single location that says "This is how you build software. This is how you solve these problems.

These are the range of options you could choose from, which is distinct from media of the closed stacks, but at least these are some let's call them menus or stacks that you could choose from, that can make you productive. And so we want to provide that leadership and vision and provide a central place for people to be able to really understand how to be productive. We don't want to create a dictatorship, but we also don't want the chaos that is so often associated with these things. Dion: Organized chaos. It's so evolutionary, by having all these vendors come in and new companies all the time and having a platform for them to make many on the web platform, then we are going to get shoot-offs of new ideas that take off, that wouldn't happen in an environment where there is just a few players kind of patting each other on the back and doing something that is based on them. The other thing is that we want to actually help solve problems so, this week Adobe actually, showed people that like to write on Flash and things like that, they did the sneak peak look at a technology called MirrorMirror that takes a web page, and shows you side by side how it renders, different browsers on different operating systems.

And they say "Oh look the pattern is wrong in this browser, and it even allows you to onion peel it on top, so you can really see what is going on", that is really cool and we should be able to have that as an API with different tools can use it and then we can stop ... intelligence to be able to say "Yes, what's the ... images and then work out and say ok, they did this padding has a different default, has changed it". So we need to have this as a constant pin point is cross browser, the number one pin point, so we do need tools to come in and help us out there.

Ben: We think the tools are certainly viable in this open market you don't see the same economics, but the open web has a resource that of immense value and that is the open source community at-large. And we feel like we haven't as a community done enough to leverage the potential of open source, so you will be seeing us over the next few months, do things to try and unlock the potential of the open web. So we hope to counter the efficiencies that tools have with having this single source vendor with the efficiencies and the enormous power base you can get from working with the open source community. That's funny I was just reading about the Oxford English dictionary which I think is probably the world's first open source project of any kind because it was built on the backs of thousands and thousands of of volunteers who actually go through providing definitions and send in the raw data as volunteers to a central editorship community and to produce the defining work of the English language. And it really is an interesting story of the power of open source, in doing things that as single company you can't do.

Dion: Get that the Wikipedia battle is going on.

Ben: They do, except it's protracted for long periods of time.

Many developers feel that the traditional tools like the dominant IDEs because they were initially conceived in the pre-web 2.0 era, are fundamentally incapable of properly assisting the design of highly interactive feature-rich web applications like the ones we are developing these days. Do you think we need a major paradigm shift in the tools we use, or the current tooling will be adequate for a long time to come with a proper minor updates of course.

Dion: I think you can get a lot of mileage out of the current tools, a lot of people are doing great work with vi and emacs, and tools that have been around for a long time. I don't expect that to really change and we are seeing people taking a lot more time to add more web features in like we used to be like, web meant designers that's with things like Dreamweaver where you do web-pagy stuff and developers, were more like "I am a Java developer, I am a .Net developer" and there were like heavy coding tools, that you worked with. And then you look at those tools and they added web views and more Web capabilities and that became one of the more dominant thing that you did in those languages like Java but the tools also had the ability to do interesting things with other very rich worlds like Swing apps in Java or things like that.

So I think the current tools can evolve and do really important things. I really like the smooth tool approach and find a lot of tools that can interact with each other to do specific things, others think there is a lot of mileage there, I think we can get things out of the kind of mash-up model. It's not like here is one tool and that is the answer and I also think it would be interesting just as we are talking about having email being a web application just like once before you never see that, as we have all these clouds out there maybe there is an opportunity to do development in the cloud itself. So I think that's with the new tools.

Ben: I think the formal observation is that these ideas have been doing have been specializing in the type of development the web 2.0 so to speak has just now caught up with. If you look at how a web 2.0 application works that's exactly as Dion mentioned the Swing application works, the SWM application works, winforms application works, this idea of having the state machine use a network to go out and get additional data on demand. So it's actually sort of the inverse, sort of tools that had to go off and sort of specialize in this weird hyperlink document world, and now it is coming back to a programming language that has access to a rich set of functionalities and then goes of and does operations across the network and time to so it's a great thing. The sort of interesting question is what's ahead of the entire industry?

What's coming for not just Web 2.0 but conventional desktop environments as well, because right now we are seeing Microsoft invest in the expression set of tools, Adobe has what they call Flash Catalyst which used to be known as Thermo and then Sun has a similar vision for Java Effects. This vision is a shift in how visual interfaces are created. Where as right now the developer has the power these vendors envision a world where the designer has power. There should be an application the designer actually designs the real artifacts that are running in the production application, and has a tool chain that lets the designer become a peer to the developer in this world.

It is unclear if that is really going to take off in the short term, the medium to long term it probably will, and so the big question is "What do the tools look like in that world? How do we let developers, designers rather, truly roundtrip with their artifacts without stepping on developers? How do they gain that discipline?" That is an interesting question. So tools in general need to evolve based on this world of really rich user experiences that almost everyone is pushing, but as far as conventional tools, web 2.0 I don't think there is a big after to tell you the truth.

One of the most important tools for web applications is probably the firebug plugin from the Firefox browser, which has been imitated in most other browsers, since it was first released. How do you think this similar tools compared to firebug and what things would you like to see getting incorporated in this category of tools?

Dion: I think the tools you get now with Safari, the inspectors, Opera's new DragonFly tools and IE has developer's tools built in are kind of getting comparable to firebug which is great to see because a lot of the time when you come down to testing something it can work totally fine obviously in Firefox and fail in IE. You need to go to that code. So I think they are catching up. Firebug, created by Joe Hewitt, is an amazing thing, something like true everyone as developers to Firefox and was really important for the entire platform, he has then gone off to great work with Facebook, with Iphone applications and now it is only recently that a couple of people from Mozilla kind of stepped up with the project with Firebug someone at IBM and a bunch of people created this new Firebug working group and effort is really being put into, for me which is the most important things like stabilizing and all that kind of stuff.

It's tough to come in and do all this work and not introduce leaks and things like this. So that is the first thing I really want to see out of Firebug is stabilizing it. But already in the 1.03 you have this net panel and if you are someone like Steve Sanders who really has to measure all stuff gives you very very accurate very rich results. And what if you could see and we have seen something: you load up your page and as it is rendering it shows you what has been painted-n at a different time period. So that you can see that "Oh actually when I do this optimization this top page gets painted beforehand whereas before we thought of things like loading the page, and the loading the page as a whole doesn't make sense anymore with Ajax interactions. So getting the tools to really understand that and again Steve is doing work with something he calls episodes, really time these interactions.

And getting that to work across the different tools so we can suck them into those different tools and really see what's going on. I think there is a ton of stuff that we are going to see going to Firebug someone tinkering to be able to go through, I am on my web page, just a simple Amazon.com home page; Right now I often used it to implement design, I go and I change things in CSS it would be great if I could just hit save and then it goes back to the server and saves it. Not necessarily easy depending on what you are doing, but there is interest in work being done over there and so again I think there is lot of work that can be done across all these developer tools. To be clear what we want to do in our group is definitely not Firefox specific. The tools that we want to work on are across different browsers. We are not a Firefox tools group, we are a web tools group. But Firefox is obviously a fantastic thing that Mozilla has held us responsible to help out the development community and I can't wait to get more involved.

Ben: I am also excited to see the tools go a level they haven't gone yet technically as far as closer to the metal closer to the platform. With Java we have got very mature tools that give us powerful introspection of the memory situation, the application can give you performance and insights, and as you try and repeat that with the web stack it is kind of a nightmare, it's a good way to look at your current memory situation, what we might call a heap in a Java oriented app is a user heap for memory allocation. There is no deep understanding on how the garbage collectors work on different platforms, there is certainly no insight on what is happening in the given time reason in the Java world, I am used to an introspection of different spaces, or the young generation, the old generation, and keeping an eye on that.

That is a black box. And as we build bigger and larger applications, that's got to change. In Java we would talk about the theory of perhaps running multiple applications at the same JVM instance and "What does it mean? And how do we optimize for our future world?" and with JavaScript of course we do that all the time every day. And we have far less sophisticated tools, so it's kind of scary. So there is the memory class of tools and then in performance, with JavaScript there is a ton of synchronous and asynchronous calls that are blended and there is not really well defined which are which and we have no way of profiling the asynchronous calls at all, which is really really scary, the sort of nonblocking calls.

And as we do more with things like canvas you know it's actually really important to optimize the draw of performance at your scene and if you have absolutely no way to profile that in a reliable way other than just eyeballs that is a really bad place to be because these are all asynchronous they are all send to an underlying implementation that does the drawing. So, Dion is excited a lot about the web side of the tooling and I am excited to those who go sort of a little to the middle and that is tough because as Dion mentioned we are looking at sort of cross browser tools and so we are not specifically focused on making Firefox do that although of course we will be in Mozilla and we will be working to make that happen, it's not a specific charter. But that is what I really want to see over the next few years, enable this new class of really robust really large scale client side JavaScript applications, we have to have these tools for that to be viable.

With HTML 5 there will be several new features that developers will want to use providing of course that the browsers will implement them. Which features do you see more valuable and how good do you think contemporary tools can handle this challenge?

Dion: There is a huge slew of features in HTML 5 and I see them trickle out Ben has talked a lot about Canvas, which is already available in a lot of browsers and people working hard to get it into IE using different methods. So I kind of see it as this one side which is the work that was done originally in HTML 5, where Ian Hixon chose to use Google, went out and mined the Google indexes to see how people are actually using HTML. So he would see that on 30% of the sites out there people would use a class equals footer so maybe we should give them a semantic way of saying that. X percent of their time they are trying to do menu system and all that.

So he mined the real web and then extracted out a whole slew of new tags and a lot of richer things, so you could have the menu tags which could be native menus in the system, a lot more performant than this JavaScript menu handlers that we have right now. So theres that whole slew of things and as far of using it that's going to be the constant debate of one browser that you implement so that you finally get it going, and if people can build these shims, that allow you to use this and then if you are on another browser it kind of changes the whole gum structure and it still works. That's going to be really important I think for the uptake.

There are so many little things that are no brainer in that, to say input type equals email and have it validate the email for you, type equals day and have it say "Have a nice day" drop-down compared with this little ... you just really wished that you had in the code platform and now are just going to be available for developers and I think these little things are going to be used absolutely everywhere. Then you have got the API side of things, where you got things like web workers, which is like the workers with the ideas, that allows you to go run JavaScript in a separate place. People at this conference have been talking about Erlang and Scrum and things like that, on the web traditionally we haven't had a way to run things off of the UI thread. And one of the big things that Ajax has given us was to help us with responses so we can write things like Gmail.

But to really get there and to have these things working offline, has these applications get richer like Ben has been talking about, with Webwork you can run this JavaScript outside the UI thread. So these whole slew of api's being able to post messages between iframes and tabs and different things that have been going on working out access control cross domain, you can kind of keep zooming in to the HTML file spec and there has to be something that you can look at and this is tiny little feature and you say "Oh man, how have I not been able to use this before?" so I am incredibly excited about finally rev-ing this platform and I can't wait to be able to use this stuff, video, audio tags all those stuff. It's going to be available.

Ben: I see it as a very long term play, and that is really what is most important, to see over the long haul this is the standard we are going to incorporate audio, video, advanced graphics into the browser and even if it takes until 2015 or an arbitrary time into the future for all the browsers to incorporate at a level that is satisfactory with comparable fidelity, as long as this standard exists we can take tools like Flash and even Silverlight or Java and add that feature as a plug in and bridge to it, in browsers that don't have it and as long as we have that standard and at least we know the code into an ApI will emerge and that is what is really important.

If we look at our mission which is to keep the web open to things like audio and video are really important because that is what pulls proprietary plug ins into a large number of websites, and I don't really care if Flash is used to view a video today as long as that video could be viewed on other platforms tomorrow, when the player emerges. Now if the video is served out as sort of an opaque Flash movie, and there is no way to get it through another video player that is a problem. But if there is a Flash video player embedded in the page then streams some sort of an mpeg movie, mpeg encoded movie that's great because some other player can be substituted in just as easily.

So I am really excited to see HTML 5 to facilitate those use cases, to look at where we are going over a long period of time, carve out those standards and say "You know, we may not have implementations any time soon, but at least the standards are here and they are viable and we can plug in the gap in the meantime with tools like I have mentioned and even things like Google Gears which is just to plug those gaps. So HTML 5 is exciting in that respect, I think even though will lead to fragmentation on the short term, if you look at the browser implementation schedules on the long term, we really hope it will serve to keep the web open.

Dion: Video is important and a lot of people say "Well you can do video in Flash right now, why do we need to add that?". What is interesting is that when you stop to see if this demos that are using the native video tag were it's native into the browser you could run CSS on that video or you could steer it and move it around, and all of that stuff works with all of the other pieces. And I think that is what is going to be important. So we can have that and the actual implementation is in Flash for a while, that's fine, but it is like "Can we get it as native as possible and really understanding the browser as a whole, not just a little rectangular box that does something else and not spooling off these new plug in processes every time you want to do one of these things.

The last months and years there has been much consideration about the evolution of JavaScript and HTML, mostly about JavaScript. Where do you think these two technologies should be heading and how important will good tooling be for their evolution?

Ben: We talked a bit about HTML let's pass that one for now as I think we have covered that. I do want to say that it's not that we don't like Flash or the proprietary technologies, we actually like them quite a bit the scenario that we really want to protect against is just like with Flash for example is like with Sun. Sun is a company that sort of watch and implode, as time goes on, we love that company a great deal but just to set context for where this video was watched, this week with green design, the VP of software, we have seen lower level of success and people ... so if you have big investments in Java, you sort of get a little worried right now because the future is uncertain.

And so with Adobe, you never know what is going to happen in the future. Right now they are great participants in the web community, we have a great relationship with them, we just want to make sure that in six or seven years if you are running Linux you can view the content you want to run, without any concerns about the help of one particular player. Probably we are done but I just wanted to say we have no bias against these guys we really like them but that is sort of our mission. With JavaScript we have seen a lot of controversy over the last few years, over the future of JavaScript in fact the Ajax experience, the conference that we hold every so often to talk about Ajax issues, some of the biggest fireworks have been generated while we were debating this topic.

The language probably should evolve it's a little scary because as soon as you start evolving the language you got to worry about different browser issues and with Chrome entering the market and the new mobile browsers, we are really starting to see user agent fragmentation being an issue. For a while Internet Explorer and Firefox were the things you had to worry about, now the list is five or six that you really need to take into account. That's a real problem for developers that's not a plus, in fact as you talk to a lot of developers, that is not a plus, in fact you would expect them to embrace Google Chrome to a degree because of the promise to a potentially eroding the Internet Explorer base but most all we talked to really are not happy about Chrome at all.

They say this is yet one more browser to support. So significantly evolving JavaScript is a double edge sword. On the one hand the language was kind of a hack that escaped through out the door and Brendan Eich God bless Brendan Eich, every time he speaks at a conference, as he talks about where he wants to see JavaScript go, you kind of see the frustration that he has of being judged and critiqued and having to watch this little project he did evolve over ten year and basically be frozen. So having it evolve would be good, there are a number of problems in the language that would be great to address, but we do have that issue that if we evolve the language all of a sudden, we have to worry about bridge compilers back to the old ones and so on and so forth.

I want to focus on the tooling aspect of your question, because that's the piece that I find personally most interesting. Dynamic languages don't have great tools today. A lot of people talk to us with the past with Smalltalk and how Smalltalk had some great tools at some point. Unfortunately those tools don't exist today for JavaScript. And so we are really intrigued about the possibility of having great JavaScript tools and what we mean by that is if you look at how tools work today for JavaScript it's usually cheap lexicographical tricks for suggestions, like you kind of do pattern matching and you are kind of guessing that you are at this point, kind of guess that these functions may be available to you at this point in time, but nothing aggressively models the object graph to be able to tell you with certainty like we have for static languages where you can do modeling across the code base.

And one of the reasons why you can't so it is simply in order to model the graph, intermediate to a large scale project you need a whole lot of memory and a whole lot of processor time, on a Desktop. But what if the modeling of your code occurred in a cloud in a distributed environment across the team Now if you are one developer working on a huge code base, the relationship of computing may not work out, but if you are a team of five to ten developers, you have a medium to large scale code base and you can amortize the computation of your code calculation, across multiple team members, maybe that is feasible.

So Dion mentioned a bit about having an environment that lets you work on your code in the cloud, what if you had this analysis of your code happening in the cloud, would that change the economics of computation such that we actually could analyze the dynamic code base and actually run through the graph, a much richer, more ambiguous graph and give you the types of syntactic sugars or helpers I should say that were used for static languages? I am really interested in seeing if that is possible and we may or may not go in that direction but that is something I would like to see emerge from some source.

Dion: Going back to the language thing I really like JavaScript as it is. The whole ES4 thing, JavaScript 2 thing seems like a huge change for me, I think that the option with static type is interesting but I didn'nt think it was actually as important as people would see up front.

Dion: Generators, that is good. But we have seen the new VMs come out that are wicked fast, so that kind of dispelled the whole you need static languages for speed argument in my opinion. We started having things like you look at the specs and it is like you have got name spaces packages and programming units. It's like how could a new person understand that? I would love to have a way where I could input code where I could script source equals. There is a few things about the language that I would like to change. But I think when people say they don't like JavaScript what they normally mean is they don't like the DOM and they don't like some of the APIs.

And JavaScript as a language is actually really well done, and I am kind of amazed that Brandon was able to produce this thing in a ridiculously short time and it has been able to live this long and become deployed on almost every machine in the world. I am actually quite happy that we are at theharmony stage where it's slowly adding things to the language, it's almost similar to the argument that has been held here, yesterday in the session on the state of Java like: do you want Java to be all things to everyone? Or do you want to allow other languages to the platform? I come out to take these different gaps. And that is a healthy debate.

What is the current state of Mozilla developer tools lab and what should be expected in the near future?

Ben: We have been spending a lot of time trying to understand what developers consider the bottle neck to be in the open web. We have our ideas but it is important to us that whatever we do reflects community priorities and not just our crazy visions. So we have been doing a lot of that, we will continue to do a lot of that. We had some very specific plans for 2009 we can't go into too much details yet because we are still trying to be non-commital as we shop things around but I think the initials that we are most interested in right now and this may change, but we first want to create a central source of information for open web developers, we want to create a hub where the community can get together, where you can get to centralized documentation, because right now the documentation for creating an application is horribly fragmented, for example the use case that we use is Prototype if you are a developer and you want to use the popular JavaScript library Prototype to get something done, well Prototype's documentation describes its augmentations to the existing JavaScript APIs that are hosted in different browsers which are mildly divergent across browsers.

And so if you want to create an application using Prototype you got to look at the Prototype docs, you got to look at the IE docs, at the Firefox docs, Safari docs and they are all different formatted documentation, Apple is the hardest to find, and it is really a bear to get simple things done. So we want to solve that problem, we want to centralize documentation, we want to create a community hub and we got a few other ideas for what such a community should do. So you would probably see something in that area emerge from us.

And then as we talked about tooling gaps, we are working with different players in the community and the community itself to identify what specific tools are missing. And we really want to see those tools emerge in 2009 so we will be directly working on new tools and working with others to facilitate the emergence of tools, being sort of cagy as to what specific tools there might be but it would be kind of premature for us to go into that I think right now.

Dion: But what I am really excited about being at Mozilla is how open the company is it doesn't feel like a company sometimes, it feels like this community. When we first started and went to the first weekly company meeting, and it was live on air and anyone could watch it. That was the company meeting. And as people who like to do things like this and come and discuss things with developers as soon as we really get going, we can then come out and say here is something we have been thinking about.

And get it out there and develop the whole thing obviously open source but totally transparent out in the open, really being part of the community as Ben said, it's not about us building this Mozilla set of tools that we throw over the wall it's more like collectively working on what do we really need and how about you would do better this and we do better this and this is how we integrate and I was thinking about how Mozilla would do things it's all these pieces with very open obviously with APIs to them that other tools can use. So we can share all this stuff in new and interesting ways. I am really excited to really get going there and get some tools out to developers and hear what you guys need.