The Changelog: Software Development, Open Source - Ajax.org frameworks (Interview)

Episode Date: March 8, 2010

Adam and Wynn caught up with Ruben Daniels and Rik Arends from Ajax.org and talked about APF and O3, their frameworks for both browser and server based JavaScript applications.

Welcome to The Changelog, episode 0.1.6. I'm Adam Stachowiak. And I'm Winn Nevelin, and we cover what's new and fresh in the world of open source. If you're catching us on iTunes, we're also on the web at thechangelog.com. Or for a real-time view of open source, tail.thechangelog.com. Yep, you can also check us out on github.com as well. Go to forward slash explore, and you'll see us there. You'll see some training repos, some featured repos from our blog, and all the podcasts from here on out, all the way up to 0.1.6.

And if you are down with Twitter and you want to follow us, you can go to twitter.com forward slash changelog show. Sorry we couldn't snag the changelog, but somebody out there is cool enough. I also happen to tweet at Adam, S-T-A-C. That's Adam Stack. And I'm Penguin, P-E-N-G-W-Y-N-N. Looking forward to South by Southwest next week. Yeah, swinging on Friday in the old, potentially like a little compact car,

maybe a midsize for cool enough. Austin's a cool town. I can't wait to see. It seems like everybody in the industry turns out for South by Southwest. Everybody I'm talking to, like I swear everybody I'm talking to is going to be there. Yeah, the problem is trying to figure out what parties to hit because there's two or three cool ones at the same time. It's just a matter of knowing which one's the most hip at that time, I guess.

I think if you're a Gowalla user, though, you might have a leg up. Yeah, go to Gowalla, ford.gowalla.com. That is ford.com. And you'll see all of the parties there. And I believe if you check in at these parties and meetups that you may be registered to win something, but I'm not sure about that. I've actually been using Gual lately. I've been enjoying the fun part of dropping things and picking things up

and becoming a founder of places. It's been kind of fun. Yeah, it's pretty cool that they have their API out there now too. So you can do some cool things with spots. I've seen some Google mashups with Google Maps that show all the icons there on the map. Goala did a good job. Those guys were

I guess part of Icon Buffet before the Goala app. With memory serves and just everything is just well crafted in that particular app. Speaking of Goala, you did some sniffing of their API with Charles Proxy, right? You talked about that with Leah Culver back in, what was that, episode 0.1.4? I think it was 5.

I think it was just the last episode, wasn't it? Was it? Yeah, I'd sniffed out some of the API before it was released using Charles Proxy, which is pretty cool. It's very similar to HTTP Client from our buddy iTod, Todd Ditchendorf. It allows you to sniff HTTP requests. I guess if we're talking about conferences, we should probably mention the fact that we are going to be at Red Dirt Rubiconf, and

maybe JSConf out in D.C. Yeah, I'll be at Red Dirt in May, and then hopefully JSConf is in April. I'll be out at Chirp in San Francisco, and then we're trying to get the logistics together to get out to DC for JSConf. Yeah, DC.

And if you are going to be there, if you plan to be there, certainly let us know that you're going to be there. But if we do go there, we might do something pretty fun. So we're kind of excited about being there. Yeah, looking forward to a lot of things happening in the JavaScript community, including the interview this week. Ajax.org, we talked to Ruben Daniels and Rick Ahrens from Ajax.org. They've got a cool new client and server framework for doing some next-generation JavaScript items in the browser and on the server.

Pretty cool stuff. Yeah. Well, we've got an awesome interview lined up. You want to just head to it, or you got anything else to say? Let's get to it. All right. All right. We're joined today by Ruben Daniels and Rick Ahrens from Ajax.org.

Ruben, why don't you go first and introduce yourself to the audience and what you do at Ajax.org. Right. Well, my name is Ruben Daniels. We started Ajax.org about five years ago, just before the term Ajax was coined. And it was basically a follow-up on a hobby project, which I had been doing for about four years, five years from then, trying to create a user interface for the web. So the web upcoming, I noticed that you could really create nice user interfaces in the browser,

get away from the desktop, and we wanted to create a business around that. I met Rick five years before that at the university, and together we just jumped to that and started the company to innovate the web in that way. I'm the CEO of Ajax.org and I'm sort of the JavaScript guy in the company. From starters, of course, now there are many people working for us. We're at 15 people. And I try to do more of the management and the strategy side,

but still get my hands wet with some JavaScript coding. Cool. Thanks, Ruben. Rick, what's your role at Ajax.org? Well, I'm the CTO. I have a slightly different background. I also started at university with physics where I met Ruben. Then I went off in a different direction with media, web media technology. So I was mostly a C++ developer and I wrote browser plug-ins for video editing

and doing all sorts of projection stuff on big screens for Tiesto and web stuff for Coca-Cola. So I did a lot with trying to push the browser to do things it didn't do back then. And I also did a lot of UI development in C++ and eventually realized that I was just building a browser so that I should probably just use one instead of trying to recreate it. So my angle is much more on C++ and making the browser do things that it doesn't do right now. So I'm also the architect of the O3 stuff within Ajax.org, working with our team of C++ guys

to really push the possibilities of the browser but also server-side JavaScript to the next level. I also program a lot of JavaScript nowadays since I'm also working with Ruben on the APF platform. I did the charting engine that you can see on our homepage. Also live market parser, just a bit the quirky parts of APF that I work on. So that's what I do now.

So you guys have the two platforms. You have the APF platform and you have O3. What are the two? They're essentially two sides of a coin of building web applications from our perspective. The one side is the JavaScript side, no plugins, no C++ anywhere, just pure running in the latest browser HTML5 type of application.

However, as you build web apps and you realize that the browser or the server is not really doing everything that you need it to, you also have the need to extend functionality. We started with O3 a couple of years ago, just about the time Gears was, I think Gears was not there yet, but the general concept of making the browser do new things, which is HTML5, it's the essence of right now. So we try to push a project for that to bridge the gap essentially between pure JavaScript applications and desktop applications or even server-side applications. So in the future

we see that the JavaScript platform will be the UI platform that will work on all mobiles, desktop web browsers, and we'll use O3 to push innovation of the browser platform and add little bits that we need to make incremental features of web applications available, like local file access or reading out sensors of some device or on the server talking to a MySQL API, which is running all on the same JavaScript core. So it's essentially the filler around the platform. So we can do the things that all the normal desktop applications already can do.

So Ajax.org is a pure JavaScript application framework, and it's got a couple of APIs, a markup API and a JSON API. Do those go, are they complementary or are they either or? Well, what we found, for a long time, we only had the XML API. So you would write markup within your HTML document to instantiate the elements. But we found that in certain cases, and this is also the feedback we got from the community, you want to program the UI. And so we wanted to offer both means.

They're basically identical, so you can do exactly the same things with the XML API as you can with the JSON API. It will just instantiate the UI objects and add them to the HTML DOM, basically. Yeah, I think it's a matter of taste. So there are a lot of people who like markup, and there's a lot of people who are used to writing JavaScript. So now they can use the same system from both preferences. So let's talk a bit about how you would implement either API. Is it just a JavaScript framework source reference you add to the page, and then either code the JavaScript API or add an additional markup to your page? What you basically would do is you just create an HTML document

and you start writing the markup. The JavaScript will parse the HTML document and will display the components at a position in the HTML that you positioned the markup elements in. For the JSON API, you do the same. You probably put a handler on the load event and just write a JSON

as you want in a similar way. And are both APIs skinnable or just the market API? They have exactly the same functionalities. They will apply the skin. They will even create, because we implemented

the W3C DOM spec and the event spec as well. So you can just use append child, set attributes, et cetera, on the nodes, and it doesn't matter whether you created them using the JSON API or the XML API. They're absolutely identical. Can developers add their own skins? Yeah. We offer a couple of skins skins and we're working hard on

on creating more with some designers as well um but the skins are no more than just an xml definition in which you have some css and some html this is a unique feature about the skinning engine because you can define your own html for the elements for the ui components that you want and it gives you a lot of freedom. For instance, a list component can be just a normal list, top-down, but it can also be a thumbnail list, and the only difference between both is the skin. So you have a lot of control on how your widgets will look like. Yeah, from a slightly more technical angle,

it means that we don't generate the HTML from the widget. We generate the extra HTML, the eventual HTML that ends up in the browser by using the skin template to instance it. So that's an extra layer of abstraction between the widget and the style, which is very, very powerful. It might be helpful for the listeners to maybe draw some comparisons to some other more well-known frameworks. So how does Ajax.org stack up against SproutCore or some of the other frameworks that are kind of in the similar space? I'm not that familiar with SproutCore myself. I did look at XT and XGS and Dojo and some other frameworks. When we compare ourselves, we usually take different frameworks

to compare ourselves to, which are the MXML framework from Adobe Flex and the XAML framework from Microsoft, because they have a very declarative way to describe the UI, which means that you tell the system what you want to do but not how to do it, which

is very different from just coding JavaScript. And I think that both XGS, Dojo, and several of these other frameworks really let you just write a JavaScript. And there's a big advantage of not having a literal way of telling the system how to do it, but just telling the system what to do, especially for a user interface, because it helps you just focus on the problem you're solving rather than how to solve it, if you understand what I mean. It puts an abstraction layer away from the developer and gives the developer a focus on what he needs to build for the customer. Yeah, let me put a slightly different angle on it. If you look at HTML, HTML is a declarative way of putting a layout or a page format into your browser view.

Now, that has advantages. Using HTML to describe a document and CSS to style it creates a very compressed way of representing the document you look at the document and you see you know as a in the source you see what it is supposed to be almost because it is just one top-down view now if you would create that same HTML document using a JavaScript API, but just inserting nodes and essentially doing the whole DOM tree, it's far less maintainable. It's much more difficult to see what it does. And it's also because the code flow is not predictable in that way, you know,

it can jump all around, call functions, do these kinds of things, that it can be very unpredictable what that UI will be. So if you take the declarative approach for defining an application UI, you can stand on the shoulders of HTML and use that same approach to define your application and have the same clarity in looking at what the application will look like or do. And I think that also there are two other strong points about the Ajax.org platform which are different from these other frameworks and they're data binding and property binding.

These technologies basically allow you to describe how to transform, for instance, data that you load into a tree with just two or three tags rather than writing the loops yourself to convert the data into a visual representation. And this is very powerful because it allows you to tweak your UI and load the data from different sources without much troubles and without a lot of code, one or two lines really. The property binding is also very powerful. We got that concept from the Flex framework where you describe one property of a component by using another and maybe a formula and the binding between those are created automatically for you so you're not no longer writing events you can still write events and write a javascript for them to to describe the dynamic between components but you don't have to

so this makes it also a lot more easier to see instantly what what a component does and how it's connected to other components. Yeah, let me say a little bit more about data binding. The thing Rubenskip was the fact that the binding is live. That means that if you would write a tree using JavaScript and put data in it, you'd write a loop to put all the data in the tree. Now, as soon as the data changes, or you change something with that tree widget, I don't know, drag and drop something, you'll have to find a way to programmatically sync the data with your UI. And that used to

take a lot of code and a lot of effort to make that work and work bug free. Now with data binding, as soon as you've set up these binding rules between the data and the UI, they remain as a bidirectional binding. So as soon as the data changes, reloads, or you get a new, some other widget changes it, the tree automatically updates. If you drag and drop something in the tree, the data automatically updates. I think that's also very, very powerful in data binding. Yeah, and the change as a developer is, you know,

it's a different way of thinking about your application because suddenly you have these two things, the UI and the data, bound to each other. And as a programmer, you don't have to think about, oh, I want to do this with my UI. No, you only think, okay, I want to do this with my data. So there's only one point where you change what you want within the application, which is your data and everything else changes with that. So that's the UI. And the nice thing about this is that when you share a piece of data between several applications, let's say there are five users using the same application

at the same time and they want to change their data, then the data change is not only represented in your UI, but the Ajax Adore platform takes care of also sending it to the other clients looking at the same data. So the users will see that change also represented in their UI. So you have the instant collaborative features that we've also seen in Google Wave. So you mentioned sharing code. Do you have any sort of package management where you can share code across projects in this way? Sharing code is another concern.

What I was talking about was really sharing data. So you have a centralized data store where people basically have a view on that central data. We have a package system for the framework itself, so you can, based on your project, create as tiny as possible version of the platform that you include in your project. I don't know if that's exactly what you meant. On the other hand, we're working on an IDE, an online IDE, where people can basically create projects and share code in that way. So we look at what this does then.

What kind of application is the true sweet spot for what you're developing? What kind of applications are you really driving for? Is it like a Google Wave? I think applications that can really benefit from integrated widgets combined with collaborative data features like data binding and these kinds of things are in business applications, finance, a lot of applications where you need a data grid. You need essentially more complex data than three buttons and a slider to represent what your application does. So the benefit of HX.org platform really starts essentially when your application and data management becomes part of your problem set that you have to solve as a developer. And I think that's also what sets us apart from other frameworks for the previous question, is that as soon as you reach a certain complexity and you notice that you need solutions for synchronizing data,

for locking data, for all these types of things that the HX.org platform adds a lot of benefits. So I don't necessarily know if there's a sweet spot for this. Finance sounds like one of the areas where you need a lot of these features. But in general, most applications... I'm thinking like maybe the stock market, like stock market data grids or big old dashboards and stuff like that that have constant updates. Yeah, exactly.

So I think that would be one of the first areas. Yeah, but you can see more possibilities as well because, for instance, we're building now a social network site on this technology. We've built a product search site, a content management system, but even smaller apps like an hours registration application, mobile apps. I mean we really believe that HTML5 on a mobile device will be the future. And to make that happen, what you will see is that more and more complex applications will go to a mobile device, either a phone or the iPad or devices like that. And I have some very complex applications on my iPhone, and those type of applications could really benefit from a framework like Ajax Store Platform. So let's switch gears and talk about O3 for a moment.

Why don't you give the guys an overview of O3 and what it aims to solve? All right. So O3 started out as essentially a way to stop having to write the same component over and over again. And by component, I've written lots of plugins that do, for instance, video compositing or video editing, computer vision. station that you can move your hands in front of the camera and it would recognize movement or audio systems that you could you know play music with with all sorts of fancy interfaces so there's a lot of components that you write that you need to have accessible in the browser environment and by the browser environment i i not don't necessarily want to restrict it to the browser, but also server side, essentially anything that runs JavaScript. So one of the problems that I ran into with that is that it's very difficult to maintain C++ components in a healthy way so that when there are new operating systems or new browsers, that you can still use these APIs. I mean, how difficult that is, I think, is also portrayed by the Gears story. If you look at Gears, they set out to extend the browser with essentially the new HTML5 APIs.

And in order for companies to say, all right, so let's take gears and let's use this in a real product, in a real application, the infrastructure to allow this, to allow these updates, to allow this dependency on actually using this, I think has now also been voided by essentially Google abandoning the project and not having it available anymore. So O3 is essentially a focus on trying to make these components have a longer life. So as a developer, you can actually start using them in an application, and you don't have to be worried, you know, will the version change in the next version of Firefox or can I not use it anymore in three or four years? Because as soon as you start applying innovation for customers or even your hobby projects, it's kind of sad that, you know,

stuff that you write on the web that uses these things generally has a lifetime of about maybe one to two years and then you can't even show it anymore unless you made a youtube video out of it so that is the angle of o3 have a component system that allows us first of all scratch your own it so allows us to make components and later on other people as well, to enhance these features to innovate the web. And as time went on and the HTML5 push came along, you can also see that this is a main focus of many people, to have these cool new features like a camera API or the video tag be available to developers.

And as we developed O3 further into a very, very flexible system so that you can just write a component in C with a very simple API, and all of a sudden you can use it from the browser or from server-side JavaScript or from a site-specific browser. So what are the large buckets of functionality for O3? I'm looking on the website and I see file access and DB access. So what are the large pieces of functionality that you've currently built into O3? Okay, so you have to start with the basics. So we started with a file API, a socket API, an image API, which was very important for us, with a canvas API on top of it.

So we could do server-side chart rendering or features like that. but still in the basic stage where we're adding essentially a common JS-like basic library that you can use from your JavaScript environment. But we're really aching to start doing the more advanced things like putting a webcam on the image object or doing some real-time barcode analysis so you can really start to have fun with this API as well. And you mentioned using this on the server. So is it geared towards playing nice with things like Node.js and other server-side JavaScript frameworks?

Yeah, Node.js is not necessarily a framework, but more of essentially an all-in-one JavaScript server with its own components. O3 is essentially a component platform, so having it be usable from its V8 engine that it's using, it will most likely be similar to Node.js in many respects of using it as a server-side JavaScript engine except that the components that you write for O3 you can also use on any other JavaScript environment as well. So common JS could be very easily ported to run on O3. Promises will be implemented as well. So code that runs on Node will have a high probability of running as well on O3 server-side JavaScript.

And your site mentions both a plug-in and a site-specific browser approach to getting O3 in the browser. So talk a bit for the SSB vision. Is that a separate download, or would it work with other SSBs that are currently on the market? The SSB is really essentially what it says. It is a site-specific browser. So it's currently a very small executable that offers the same APIs as the browser plug-in or a server-side JavaScript. And it uses the browser that's installed on the system. So for Windows, that means that it uses IE, and for Mac, that it means that it uses the installed Safari as a component.

But we're also working on making a full WebKit build so that the browser that is used in the SSP is the same on all platforms. And I think that's very close to Air or Accelerator. I noticed the demo, moving back over to the Ajax.org framework for a moment, noticed the demo on the homepages using the Canvas object. What are you guys doing in an Internet Explorer to pull that off? Yeah, we're essentially still using VML because that's the only vector API that's available in IE, except we're using a bit of trickery to make it acceptably fast for this use case of rendering charts and things like that. the optimization boils down to just don't change anything in the DOM tree unless you absolutely have to.

And make sure that all the calculations that you do to calculate these paths are the most optimal JavaScript that you could write. And that allows us to do properly fast interactive charts in IE as well. But I would love it if I had a fast canvas. So in your opinion, are we entering an era with JavaScript where we can do with JavaScript what we used to do in Flash? Do you see Flash dying? I don't see Flash dying, at least not until something significantly changes in the HTML5 route and the market penetration of all these new features. Because after all is said and done, it's all a matter about the installed base that you can reach with that specific feature.

And Flash still has the upper hand on many, many areas, such as that it has a video codec that they've agreed about, and that the JavaScript API is very tightly bound to the render engine. That allows you to do, I don't know if anybody saw the 100,000 particle thing in Flash. Well, that is something that you can do if you tightly bound your JavaScript engine to your render engine. And I think for the browser to do that will require some architectural changes or at least a focus on that aspect of becoming as fast as Flash.

So I really hope that that penetration of features can be achieved. And that's also one of the goals with O3 that we took up in that if you can make HTML5 at least cross-browser compatible until it has reached this penetration level, then even by providing it through a plugin, can at least speed that process up, hopefully for developers to be able to use those features in a HTML5 way and not have to resort to Flash. Gotcha. And we have the platform, APF platform, and we have O3. What kind of licenses are attached to those

and where can our listeners find the source at? Well, the APF platform is LGPL'd and O3 is GPL'd at this point. The APF platform is an AJAX.org platform is available through Subversion and O3 is available on GitHub.

We're very soon moving AJAX.org platform to GitHub as well. And you can find the links all on Ajax.org slash hash download. Maybe this should have been mentioned when we first started the call, but I actually met up with you guys at the exhibit, the first night of Future of Web Apps down in Miami recently. You guys had a fabulous booth there, great demonstrations of what you guys are doing.

But at that demonstration, I asked you if you guys would be interested in hosting a mirror of uh of apf on github is that still true no definitely we're actually uh planning on just moving the entire main uh repo to github okay it's uh it's just uh it's uh take some some logistical work to actually get that there. We have nightly builds and all these type of things. But yeah, no, that's definitely in the plan. I think within one or two months, we'll be moving that to GitHub. So basically what you're saying is that all Ajax.org projects will be on GitHub?

The two main ones, yeah. I think that we also have a couple of people working on a GWT implementation, and I think they're running that on Google Code, but that's just because GWT is very much a Google-based community. But other than that, we'll be using GitHub as our main repo.

We're talking about GitHub and the community there. What type of open source projects are on both of your radar? You guys can go one at a time, but just in general, what's on your radar in terms of open source? What do you want to play with? What's fun out there that you really want to get your hands on? Yeah, that's a difficult question because as a platform developer, we're, of course, incredibly busy trying to push all this technology out for even for ourselves to use.

But yeah, one of the database systems that I've just done a social network prototype with is CouchDB. I thought it was very, very interesting to see a new approach to a database after all these years of MySQL. And especially the MapReduce algorithm. I think Couch is a great way for people to get accustomed to this kind of quirky parallel algorithm that you don't necessarily use at all in any other environment unless you're working at Google or something like that. So yeah, I think it's a very, very interesting project. The focus of it is kind of hard to get. So when would you want to use MySQL and when would you want to use Couch? That takes a bit of experimenting.

But generally, the idea is that if you have an offline database, that you have to sync with an online database, essentially using a local database store. That couch is very well suited for that. And also for, yeah, essentially databases where you need a lot of summing over large data sets that you update with views often. But there's a lot of technicalities behind it. Other open source projects, we keep track of a lot, but mostly in terms of looking what's out there

and seeing what their focus is sometimes. What kind of tools do you use to keep track of open source projects? focus is sometimes seeing also... What kind of tools do you use to keep track of open source projects? Well, essentially so far, Twitter, sometimes Reddit programming, I think, is for me a

major source of looking what's going on, because anything that's peaking the radar usually shows up at Reddit programming. Especially a lot of functional languages, which is very interesting for scalability aspects. I guess you should probably add the changelog.com to your list too, right? Absolutely.

Selfless plug, sorry. How about you, Ruben? Well, I check out things that come by I'm very interested in the whole common JS movement see a lot of activity there Narwhal is one of the things that I'm looking at and

I haven't played around with it yet but it seems very interesting and they have a lot of modules already ready so that's something that I maybe want to try to run on O3 as well. So, yeah, that's it for me. Yeah, and of course there's Node.js, which is, of course, a very, very nice way to solve scalability with JavaScript on a server. Because we're also looking at how to integrate with it conceptually,

but also mostly to see what problems they solve and how they solve it. And I think that's also because we're also moving towards server-side JavaScript with our APIs, with the component API in O3, we have to also look at how to make it easy for developers to write server-side JavaScript. And I think Node has a very, very interesting approach with the promises. I haven't seen the promise concept being used to such an extent that you could write essentially chained code that was purely event-based. And I think it's a great approach, but there's also possibilities to simplify it.

And that's what we're currently researching, if we can take an approach with server-side JavaScript that would essentially allow people to write blocking code top-down, except that it's secretly not blocking in the back end. So you would get the same effect of scalability, but just with this little bit more simplicity for the developer. I don't know if it's going to work out, but for those kinds of projects, we also really look at what they do right

and what you could improve or use in our own approach to server-side JavaScript. You guys are both from the Netherlands or in the Netherlands? Where are you guys based? We're both from the Netherlands. I was born in a town called Haarlem, which is about eight kilometers from Amsterdam, and lived all my life in the Netherlands. And where's your team based now?

Amsterdam. Amsterdam. Okay. So talk a bit for a moment about the Amsterdam development scene. I see a lot of talent coming out of the Netherlands and just wanted to know how you see the development landscape over there. I think the development landscape here is very much similar to other big cities around the world, essentially where there's a lot of production web development. So essentially, you know, making sites for the local big companies,

making web applications and solutions that are very much focused on one market, like, you know, CRMs for supermarkets or that would be one of those types of verticals. There's always a lot of companies that are doing that. And we had also a couple of nice dot-com style applications here in Amsterdam like eBuddy. We built the first Ajax MSN client for them. But yeah, also TomTom.

And you do notice that in the developer scene that's web or JavaScript related, that these companies have a lot of impact here and everybody knows them. So I think it's fairly healthy, but we could do with some more Silicon Valley style spirit here, I think it's fairly healthy, but we could do with some more Silicon Valley-style spirit here, I think. That's awesome. I think that just locally,

every good JavaScript programmer knows each other. It's maybe one node away from the network, but it's a tight group of people that just go out for beers and meet up. One of our colleagues, Mike DeBoer, he just started the Amsterdam JS together with some other guys. And yeah, many people from TomTom, like Rick said, showed up and a couple of others. But it's a tight group of JavaScript developers here that hang out together and try to innovate and make new stuff happen on the web. Perfect. That's nice. I wait to my next question. So you guys were at JSConf in Europe, and we're going to be at JSConf here shortly in D.C.

Any upcoming events you guys plan to be at? I know at FOA, you were there with a booth and you were demonstrating what, uh, what your platform is and your technologies and stuff. What, any upcoming events you plan to be at that you can let us know about? Well,

um, we're going to, to Sweden to an event there. Um, I have to say that I don't remember the name right now. Um, and, and, um, I have to say that I don't remember the name right now. And we're not planning on going to too many events right now. I think we started going to events about half a year ago, really trying to connect to the group of developers

that we're catering to with our tooling and finding out, okay, what's necessary, what's missing, what do people want with them. And I think we have a very clear picture now, especially concerning the IDE, what it should do, which problems it should solve, what would be the right business model, how open would it need to be. And for us, right now, it's a time of building it, just really focusing on getting that technology out rather than going out and marketing ourselves in that sense.

So I think for the coming few months, we'll be finishing that, creating an IDE, and then after that, we'll show that online. You mentioned the IDE, and I know I saw a little bit of what you guys are working on, but we probably don't have time to go too deep into it here at all, but do you have any upcoming plans for a screencast on what the IDE is and a page on your site that kind of describes what it is? Definitely. We hope in one, one and a half months to actually have a working version, one that is included in the distribution of the iDistribute.org platform itself, In one, one and a half months, you actually have a working version, one that is included in the distribution of the Azure Cloud Platform itself.

So you can just start an application, the index.html or the Hello World, and start drawing your UI. It has a Firebook-like interface because, of course, it's all markup. So you can actually browse through the markup, see the elements, change them, run time and then save it back to your original file and there will be definitely a screencast but there will also be just a package where you can

download it and use it right out of the box basically. And make sure you let us know when you post that too or whenever you're getting near we'll definitely help you get the word out. Thanks. It will do. Well,

Ruben, Rick, we certainly appreciate your time. The, uh, both frameworks look fun. I can't wait to kick the tires on these and, uh, just thanks again for joining us.

Thank you for listening to this edition of The Change Log. Point your browser to tail.thechangelog.com to find out what's going on right now in open source. Also, be sure to head to github.com forward slash explore to catch up on trending and feature repos, as well as the latest episodes of The Change Log. of the changelog. Outro Music