Monday, November 17, 2008
Fixing the Web, Part I
We've made major progress on the web since 2005 and the rise of Ajax. JavaScript toolkits like JQuery, Dojo, and YUI have expanded what we can do with web browsers and increased our productivity, while dynamic high-profile web sites have legitimized using DHTML and Ajax. The rise of web browsers like Firefox, Safari, and Chrome have done a huge amount to help revive the web and web applications. Developers such as all of us in the Ajax community have shown that it's possible to do things with the web cross-browser that no one expected, including Comet, cross-browser vector graphics, and more.
However, even with all of the amazing work the last few years, the web has some very serious foundational issues that we need to solve or else it's game over. In the next year or two we will begin to hit the limit of what we can achieve with clever JavaScript tricks (I've literally made a career out of this browser black magic). As an industry we've put off having to solve some very serious issues. Unfortunately the bill is going to come due soon, and if we don't take action, solve these issues, and push the web in a new direction some other possibly much less open technology will take over the bulk of new development.
We need to do something about this. This blog post is part of a new, semi-regular series called Fixing the Web. The goal is to highlight these issues, identify potential solutions, and have a dialogue. I don't claim to have the answers for the situation we are in. However, I do know this -- if there is any community that potentially has what it takes to solve these issues I believe it's the Ajax and JavaScript communities, which is why this is a perfect place to have these discussions.
To start, I see four areas that are broken that must be fixed:
1) Make developing for the web much easier and more powerful. There are gaping holes in the web that need to be fixed. Examples include:
2) Solve the standards problem. The web standards process is broken. There is a real disconnect between developers needs and the W3C's standard setting process, creating a dangerous power and leadership vacuum. We need to come up with better mechanisms for creating standards, as well as organizations that can help manage them.
3) Solve the distribution problem. Both Gears and Yahoo BrowserPlus are attempting to address this area. There is just a sheer mass of inertia on the web. It doesn't matter if you have the most amazing standards, developer tools, etc. if they aren't in enough places to do anything. This problem can also be re-framed as 'Solve the Internet Explorer problem', because the other browsers are pretty damned good at getting things out there -- IE is the mass that blocks any positive forward web progress. IE 8 is a start, but at the end of the day it's not doing enough. This is also linked to how hard it is to do web development, since you have to be a wizard to know the potholes or do crazy workarounds.
4) Solve the innovation problem -- There is a saying in politics that you create ideas so that you can draw on them when there is a crises, such as we are seeing now. Much of the innovation on the web has surprisingly happened by Flash, with some by Silverlight lately -- when we get excited about being able to do video on the web, which is great, that's a pretty sad indictment of the open web 'owning' the future. We've got to have better mechanisms for stamping out potential futures and innovation that can then compete, the successful ones turning into standards. Mozilla has done a good job of this with the web "concept cars" type work they've been doing.
What do you see as the major areas we need to address? Expect to see the issues above, and others, discussed in future blog posts in this series.
[Disclaimer: I work for Google. However, this opinion piece is my own and does not represent an official stand of Googles]
However, even with all of the amazing work the last few years, the web has some very serious foundational issues that we need to solve or else it's game over. In the next year or two we will begin to hit the limit of what we can achieve with clever JavaScript tricks (I've literally made a career out of this browser black magic). As an industry we've put off having to solve some very serious issues. Unfortunately the bill is going to come due soon, and if we don't take action, solve these issues, and push the web in a new direction some other possibly much less open technology will take over the bulk of new development.
We need to do something about this. This blog post is part of a new, semi-regular series called Fixing the Web. The goal is to highlight these issues, identify potential solutions, and have a dialogue. I don't claim to have the answers for the situation we are in. However, I do know this -- if there is any community that potentially has what it takes to solve these issues I believe it's the Ajax and JavaScript communities, which is why this is a perfect place to have these discussions.
To start, I see four areas that are broken that must be fixed:
1) Make developing for the web much easier and more powerful. There are gaping holes in the web that need to be fixed. Examples include:
- Layout - layout needs to be _much_ easier. We need real, kick-ass, drop dead simple layout. You shouldn't have to be a CSS wizard to get multiple columns, for example.
- JavaScript++ - JavaScript needs to evolve for programming in the large and medium.
- Bling - Browser's need much better native multimedia support, real vector graphics, and _fast_ (really fast) animation
- Tooling - We need much better open web tooling support, such as IDEs.
2) Solve the standards problem. The web standards process is broken. There is a real disconnect between developers needs and the W3C's standard setting process, creating a dangerous power and leadership vacuum. We need to come up with better mechanisms for creating standards, as well as organizations that can help manage them.
3) Solve the distribution problem. Both Gears and Yahoo BrowserPlus are attempting to address this area. There is just a sheer mass of inertia on the web. It doesn't matter if you have the most amazing standards, developer tools, etc. if they aren't in enough places to do anything. This problem can also be re-framed as 'Solve the Internet Explorer problem', because the other browsers are pretty damned good at getting things out there -- IE is the mass that blocks any positive forward web progress. IE 8 is a start, but at the end of the day it's not doing enough. This is also linked to how hard it is to do web development, since you have to be a wizard to know the potholes or do crazy workarounds.
4) Solve the innovation problem -- There is a saying in politics that you create ideas so that you can draw on them when there is a crises, such as we are seeing now. Much of the innovation on the web has surprisingly happened by Flash, with some by Silverlight lately -- when we get excited about being able to do video on the web, which is great, that's a pretty sad indictment of the open web 'owning' the future. We've got to have better mechanisms for stamping out potential futures and innovation that can then compete, the successful ones turning into standards. Mozilla has done a good job of this with the web "concept cars" type work they've been doing.
What do you see as the major areas we need to address? Expect to see the issues above, and others, discussed in future blog posts in this series.
[Disclaimer: I work for Google. However, this opinion piece is my own and does not represent an official stand of Googles]
Labels: ajax, fixtheweb, open web
Thursday, April 10, 2008
An idea for Dojo from GWT land
Now that I'm at Google I've been getting a bit more exposed to GWT (the Google Web Toolkit). I used to dismiss it because I'm a JavaScript hacker and GWT is in Java-land, but I've been learning some interesting things about it that I think could help in Dojo-land if we adopted them.
Ray Cromwell rolled something called GQuery, which is basically JQuery inside of GWT. What is unique is you can do JQuery style selectors inside of Java. Dojo has this as well, with dojo.query, but what Ray is doing is crazy. Because GWT gets compiled, he can turn something like this:
"#foo"
into this:
document.getElementById("foo")
in the source. Here's Ray describing it:
"GQuery is progressing nicely. I implemented all of CSS3 selectors by following ExtJS's DomQuery implementation, only I added the ability to parse at runtime as well as via a generator at compile time. The compile time generator turns a CSS selector into 100% inlined code. That is, a selector like "#foo", will turn into "return document.getElementById("foo");", no parsing step involved. I've still got a bunch of optimizations to make, add support for XPath and native getElementsByClassName, but even now working with the library in GWT is very cool. I just started looking at DomAssistant as well, to incorporate (i.e. steal) the best algorithms from each."
One of the comments sums up the benefits of this nicely:
"You have an unfair advantage; since your selectors are compiled you can do any number of optimizations to them, and basically beat any other selector engine out there."
GWT itself does some interesting optimizations like this around what code is sent to specific browsers. I'm seeing numbers that blow me away, that because you can only send down the code needed for a specific browser you can really slim things down. For example, something like Dojo GFX has code paths for IE (VML), Firefox (SVG), and Safari (Canvas). If we could just send which one you need then the code would be 1/3 the size.
How can we get these kinds of benefits in Dojo? We already have a build time that runs through a JavaScript interpreter; can we start to do magic like this? The performance and size benefits I'm seeing in the GWT-world seem to indicate that it is useful.
Ray Cromwell rolled something called GQuery, which is basically JQuery inside of GWT. What is unique is you can do JQuery style selectors inside of Java. Dojo has this as well, with dojo.query, but what Ray is doing is crazy. Because GWT gets compiled, he can turn something like this:
"#foo"
into this:
document.getElementById("foo")
in the source. Here's Ray describing it:
"GQuery is progressing nicely. I implemented all of CSS3 selectors by following ExtJS's DomQuery implementation, only I added the ability to parse at runtime as well as via a generator at compile time. The compile time generator turns a CSS selector into 100% inlined code. That is, a selector like "#foo", will turn into "return document.getElementById("foo");", no parsing step involved. I've still got a bunch of optimizations to make, add support for XPath and native getElementsByClassName, but even now working with the library in GWT is very cool. I just started looking at DomAssistant as well, to incorporate (i.e. steal) the best algorithms from each."
One of the comments sums up the benefits of this nicely:
"You have an unfair advantage; since your selectors are compiled you can do any number of optimizations to them, and basically beat any other selector engine out there."
GWT itself does some interesting optimizations like this around what code is sent to specific browsers. I'm seeing numbers that blow me away, that because you can only send down the code needed for a specific browser you can really slim things down. For example, something like Dojo GFX has code paths for IE (VML), Firefox (SVG), and Safari (Canvas). If we could just send which one you need then the code would be 1/3 the size.
How can we get these kinds of benefits in Dojo? We already have a build time that runs through a JavaScript interpreter; can we start to do magic like this? The performance and size benefits I'm seeing in the GWT-world seem to indicate that it is useful.
Labels: ajax, dojo, gwt, jquery
Friday, April 04, 2008
window.crypto
I never knew there were crypto abilities in Gecko-based browsers. There is evidently a window.crypto object, which is accessible:
Mozilla defines a special JavaScript object to allow web pages access to certain cryptographic related services. These services are a balance between the functionality web pages need, and the requirement to protect users from malicious web sites. Most of these services are available via the JavaScript window object as window.crypto. For instance, to obtain a ten byte random number using the cryptographic engine, simply call:
var myrandom = window.crypto.random(10);
Services are provided to enable: smart card events, generating certificate requests, importing user certs, generating random numbers, logging out of your tokens, and signing text.
More details here.Labels: ajax, javascript
Thursday, March 27, 2008
And throw in the kitchen sink
Whow, this is just gross. I found out that SVG includes file upload and socket capability; if thats not bloat I don't know what is. I like SVG, but, um, file uploading and socket abilities in that spec? Its about vector graphics folks!
Labels: ajax
Sunday, March 16, 2008
Internet Explorer Binary Behaviors in .NET
Wow, I didn't realize that you could create Internet Explorer binary behaviors with .NET. Behaviors are a feature introduced in Internet Explorer that allows you to attach new behaviors to existing tags or create new ones (i.e. I could create an ADDRESSBOOK tag and give it new behavior inside of HTML). Binary behaviors further extend this and allow you to write them in languages like C++, so you can do arbitrary 2D graphics for example or deeper extensions. It used to be that you had to know C++, but I just stumbled across a tutorial from 2003 where you could do it with .NET, which is much easier.
Labels: ajax, browser, dhtml, gears, hackery, internet explorer
Thursday, November 08, 2007
Really Simple History 0.6 Beta
I'm really proud of the great work Brian Dillard has been doing on the Really Simple History library. Check out the new beta release he just put out.
Labels: ajax, dhtml, libraries, open source, really simple history, rsh
Friday, September 14, 2007
Really Simple History Finds New Home
Hi everyone! I'm excited to report that Brian Dillard is going to be the new maintainer of the Really Simple History library. Brian's a really sharp guy with a great background; RSH is one of my software babies and I wanted to make sure that it found a great new coder to help move it forward. The last year I've had to focus too much on my business and other open source responsibilities to give RSH the attention it deserves, especially since many people now depend on it, and Brian has a great list of ideas to bring it up to date to the latest round of browsers. Thanks Brian! I can't wait to see what you do with the library.
Labels: ajax, brian dillard, history, open source, rsh
Thursday, June 07, 2007
Moving On: Coworking, Really Simple History, and Flash Storage
Every so often I look back over the projects I'm doing and take stock. I have a little inner thermometer that I check in on from time to time, and if I'm feeling stressed out and not having fun anymore it gives me information and a clue that I need to revisit what I've been doing. When I feel this, I create a Not Do Do List and figure out stuff that I need to let go of. Lately, I've been feeling stressed out and not having as much fun, feeling like there is a monkey on my back, so I've been doing things like morning pages, meditation, visual journaling, and other stuff to see what I need to change.
On a deeper level, I've been looking over what I'm good at and what I'm not good at. It seems my natural role is as an inventor pragmatist. I initially create an idea that is different than what is out there, envisioning something wierd and different, then do the hard work of making it initially pragmatic and real to prove to the world that it should be taken seriously whereas before it was ignored. Then, about a year or two down the line, others show up who have other skills that I am not as good at but are very important at this stage, such as community building, event planning, and more. I'm really good at brainstorming an idea, prototyping it, and then taking it into the initial reality stage with working code that can be used in the real world, in real software. I'm good at release 1 and 1.5, but not as good at release 2 and release 3. I'm not good at organizing groups of people, creating events, or cranking on the same code base once the initial idea and implementation has been proven to the community. I used to beat myself up about this, but I've realized that I just have to focus on what I'm good at and create situations where others can help me at the things I'm not as good at.
I've realized there are a number of projects that I created that have moved beyond this initial phase and are now successful and standing on their own legs, and it's time for me to find new maintainers for them and let them go, put them on my personal Not To Do List so to speak. These are coworking, the Really Simple History library, and Flash-based client-side storage. I need to find new maintainers for some of these projects so I can focus more time and attention on Dojo Offline. Also remember that almost all of the time I spend on these projects is free-time that I don't get paid for, and I only have so many hours in the day to hack on cool new stuff.
Coworking
I created coworking about 2 years ago. I had been working for a startup, Rojo, and wanted to go into business for myself as a consultant. However, I somehow wanted the community and structure of a workplace with the independence and freedom of working for myself, so I created coworking. Coworking was a way for independent contractors and workers to have a common space to work from, rather than hacking from home, with a more community minded focus. I rented some funky space from a small non-profit called Spiral Muse and ran it for about 8 months. Through a nice coincidence the Spiral Muse space was where I met my sweetheart, Bekka Fink, at a party months before. We couldn't store permanent stuff at the space, so I had to setup folding card tables every morning when I got there then break them down at the end of the day. For the first month I had no one, and just went to the space and worked there by myself, going through the action of setting up the folding card tables and wondering if anyone would ever show up. Eventually I had a full house, with an eclectic group of folks: a screenplay writer, a computer researcher, an open source hacker rolling his own computer language, and others.
From time to time people would drop by who were interested in the idea of coworking but weren't able to join the Spiral Muse space. I would tell them "if you were to steal this idea and make it your own, what would you do?" They would then wander off, a seed planted.
I had to close the Spiral Muse space after about 8 months since it was hard to grow within it's small size and it was getting hard to staff it; during that time those folks who had dropped by to check out the space started banding together to create an even better space, one that was larger and open more days of the week. This was the Hat Factory space, in San Francisco.
Since then coworking has spread around the world, with spaces already in or forming in New York, Paris, and more. There is an active Google Group with hundreds of members and a very active wiki. Coworking has been covered by Business Week, the New York Post, and more. Chris Messina and Tara Hunt are now the most active leaders of the coworking movement and are instrumental in moving it forward, creating events, organizing, and more. I've stepped out of an organizing role in the coworking movement to focus on other projects and am no longer a member of a space.
Really Simple History
I created the Really Simple History (RSH) library about two years ago. It was one of the first libraries to effectively solve the history and bookmarking issues inherent with Ajax applications. I had two goals with RSH: one, to show that history and bookmarking were important in Ajax applications (most developers at the time thought you could just throw this feature out and ignore that you were working in a browser); and two, that you could achieve this in contemporary web browsers using various browser tricks.
Today, RSH is used by a huge number of websites to solve Ajax bookmarking and history issues; it is also integrated into alot of other open source projects. Members from the Yahoo YUI team and the Google GWT team have told me that the BSD-licensed Really Simple History code base and techniques were instrumental in their own history libraries. RSH has been written up in online articles and books, and is now used by developers in their daily practice. Respecting the back button and creating a bookmark mechanism are now accepted practices in the Ajax industry, so I don't need to beat that drum anymore.
Unfortunately, I have not been able to do any real work on RSH for about 1 1/2 years. Important work remains: doing better QA on Internet Explorer 7, using one of the various Safari history/bookmarking techniques that have been discovered, fixing some bugs that can occur in various edge cases, and more. My focus on Dojo Storage and Dojo Offline have not allowed me to do work on this library; I am constantly getting emails with bug fixes and inquiries, and I feel terrible that I haven't gotten a new release out the door for awhile.
I am looking for a new maintainer for the RSH library. I want to make sure I find someone who will treat it well because alot of folks depend on it, so if you are interested please email me (bkn3 AT AT columbia.edu) and give me your qualifications, open source experience, and where you plan on taking the library.
Flash-Based Client-Side Storage
I've been hacking on the offline web problem for a few years. I knew before I could work on offline access to an application's user-interface, though, I had to figure out how to store data permanently on the client-side, beyond the 4K cookie limit. About 2 1/2 years ago I started searching around for a way to do this, experimenting with giant bookmarklets and other wierd stuff to see if I could find a clever back door. I then realized I could use a hidden Flash applet to store megabytes of info.
I rolled a prototype of this Flash based storage called AMASS (Ajax Massive Storage System) to see if the idea was tenable, and it turned out to work well. I then rolled another version of it and refactored it into Dojo, and got it to work in Safari as well; I also did a bunch of (grotty/interesting) hacks to get it super-fast for storing large datasets.
Once Flash-based storage stabilized, I moved on to the other part of the offline problem, which is finding your user-interface when you are away from the network, and rolled Dojo Offline in partnership with SitePen. Of course, one month after we released Google released Google Gears, a similar offline solution, so we created a partnership with them to port the Dojo Offline APIs on top of Gears. I'm in the middle of coding that port now. The next release of Dojo Offline will include a Dojo SQL module to use SQL-based storage, and a new Dojo Storage provider that uses Gears to store its data. Dojo Offline will no longer be dependent on the Flash Dojo Storage provider or the Firefox 2 Dojo Storage provider, and I would like to find a new maintainer for those. My preference for client-side storage is now to use Dojo Storage in conjunction with Google Gears. There are a number of startup companies that are using the Flash storage provider, however, and many users have told me they want to keep it; there are a number of enterprises that are also using it. I will port the Flash Storage Provider to the new Dojo 0.9 release that is coming out soon, but moving forward I would only like to personally maintain the GearsStorageProvider and the public Dojo Storage API. There are a number of cool performance and bug fixes that folks would like to get into the Flash Storage Provider, and this would be a great way to get your feet wet with the Dojo project. Please email me (bkn3 AT AT columbia.edu) your qualifications, open source experience, and future plans for the Flash Storage Provider if you would like to take this on.
On a deeper level, I've been looking over what I'm good at and what I'm not good at. It seems my natural role is as an inventor pragmatist. I initially create an idea that is different than what is out there, envisioning something wierd and different, then do the hard work of making it initially pragmatic and real to prove to the world that it should be taken seriously whereas before it was ignored. Then, about a year or two down the line, others show up who have other skills that I am not as good at but are very important at this stage, such as community building, event planning, and more. I'm really good at brainstorming an idea, prototyping it, and then taking it into the initial reality stage with working code that can be used in the real world, in real software. I'm good at release 1 and 1.5, but not as good at release 2 and release 3. I'm not good at organizing groups of people, creating events, or cranking on the same code base once the initial idea and implementation has been proven to the community. I used to beat myself up about this, but I've realized that I just have to focus on what I'm good at and create situations where others can help me at the things I'm not as good at.
I've realized there are a number of projects that I created that have moved beyond this initial phase and are now successful and standing on their own legs, and it's time for me to find new maintainers for them and let them go, put them on my personal Not To Do List so to speak. These are coworking, the Really Simple History library, and Flash-based client-side storage. I need to find new maintainers for some of these projects so I can focus more time and attention on Dojo Offline. Also remember that almost all of the time I spend on these projects is free-time that I don't get paid for, and I only have so many hours in the day to hack on cool new stuff.
Coworking
I created coworking about 2 years ago. I had been working for a startup, Rojo, and wanted to go into business for myself as a consultant. However, I somehow wanted the community and structure of a workplace with the independence and freedom of working for myself, so I created coworking. Coworking was a way for independent contractors and workers to have a common space to work from, rather than hacking from home, with a more community minded focus. I rented some funky space from a small non-profit called Spiral Muse and ran it for about 8 months. Through a nice coincidence the Spiral Muse space was where I met my sweetheart, Bekka Fink, at a party months before. We couldn't store permanent stuff at the space, so I had to setup folding card tables every morning when I got there then break them down at the end of the day. For the first month I had no one, and just went to the space and worked there by myself, going through the action of setting up the folding card tables and wondering if anyone would ever show up. Eventually I had a full house, with an eclectic group of folks: a screenplay writer, a computer researcher, an open source hacker rolling his own computer language, and others.
From time to time people would drop by who were interested in the idea of coworking but weren't able to join the Spiral Muse space. I would tell them "if you were to steal this idea and make it your own, what would you do?" They would then wander off, a seed planted.
I had to close the Spiral Muse space after about 8 months since it was hard to grow within it's small size and it was getting hard to staff it; during that time those folks who had dropped by to check out the space started banding together to create an even better space, one that was larger and open more days of the week. This was the Hat Factory space, in San Francisco.
Since then coworking has spread around the world, with spaces already in or forming in New York, Paris, and more. There is an active Google Group with hundreds of members and a very active wiki. Coworking has been covered by Business Week, the New York Post, and more. Chris Messina and Tara Hunt are now the most active leaders of the coworking movement and are instrumental in moving it forward, creating events, organizing, and more. I've stepped out of an organizing role in the coworking movement to focus on other projects and am no longer a member of a space.
Really Simple History
I created the Really Simple History (RSH) library about two years ago. It was one of the first libraries to effectively solve the history and bookmarking issues inherent with Ajax applications. I had two goals with RSH: one, to show that history and bookmarking were important in Ajax applications (most developers at the time thought you could just throw this feature out and ignore that you were working in a browser); and two, that you could achieve this in contemporary web browsers using various browser tricks.
Today, RSH is used by a huge number of websites to solve Ajax bookmarking and history issues; it is also integrated into alot of other open source projects. Members from the Yahoo YUI team and the Google GWT team have told me that the BSD-licensed Really Simple History code base and techniques were instrumental in their own history libraries. RSH has been written up in online articles and books, and is now used by developers in their daily practice. Respecting the back button and creating a bookmark mechanism are now accepted practices in the Ajax industry, so I don't need to beat that drum anymore.
Unfortunately, I have not been able to do any real work on RSH for about 1 1/2 years. Important work remains: doing better QA on Internet Explorer 7, using one of the various Safari history/bookmarking techniques that have been discovered, fixing some bugs that can occur in various edge cases, and more. My focus on Dojo Storage and Dojo Offline have not allowed me to do work on this library; I am constantly getting emails with bug fixes and inquiries, and I feel terrible that I haven't gotten a new release out the door for awhile.
I am looking for a new maintainer for the RSH library. I want to make sure I find someone who will treat it well because alot of folks depend on it, so if you are interested please email me (bkn3 AT AT columbia.edu) and give me your qualifications, open source experience, and where you plan on taking the library.
Flash-Based Client-Side Storage
I've been hacking on the offline web problem for a few years. I knew before I could work on offline access to an application's user-interface, though, I had to figure out how to store data permanently on the client-side, beyond the 4K cookie limit. About 2 1/2 years ago I started searching around for a way to do this, experimenting with giant bookmarklets and other wierd stuff to see if I could find a clever back door. I then realized I could use a hidden Flash applet to store megabytes of info.
I rolled a prototype of this Flash based storage called AMASS (Ajax Massive Storage System) to see if the idea was tenable, and it turned out to work well. I then rolled another version of it and refactored it into Dojo, and got it to work in Safari as well; I also did a bunch of (grotty/interesting) hacks to get it super-fast for storing large datasets.
Once Flash-based storage stabilized, I moved on to the other part of the offline problem, which is finding your user-interface when you are away from the network, and rolled Dojo Offline in partnership with SitePen. Of course, one month after we released Google released Google Gears, a similar offline solution, so we created a partnership with them to port the Dojo Offline APIs on top of Gears. I'm in the middle of coding that port now. The next release of Dojo Offline will include a Dojo SQL module to use SQL-based storage, and a new Dojo Storage provider that uses Gears to store its data. Dojo Offline will no longer be dependent on the Flash Dojo Storage provider or the Firefox 2 Dojo Storage provider, and I would like to find a new maintainer for those. My preference for client-side storage is now to use Dojo Storage in conjunction with Google Gears. There are a number of startup companies that are using the Flash storage provider, however, and many users have told me they want to keep it; there are a number of enterprises that are also using it. I will port the Flash Storage Provider to the new Dojo 0.9 release that is coming out soon, but moving forward I would only like to personally maintain the GearsStorageProvider and the public Dojo Storage API. There are a number of cool performance and bug fixes that folks would like to get into the Flash Storage Provider, and this would be a great way to get your feet wet with the Dojo project. Please email me (bkn3 AT AT columbia.edu) your qualifications, open source experience, and future plans for the Flash Storage Provider if you would like to take this on.
Labels: ajax, coworking, dojo offline toolkit, dojo storage, flash, flash storage provider, personal, projects, rsh, storage
Monday, April 23, 2007
Dojo Offline Beta Released: Toolkit for Offline Web Apps
Today we released the Dojo Offline Toolkit. Dojo Offline is a free, open source toolkit that makes it easy for web applications to work offline. It consists of two pieces: a JavaScript library bundled with your web page and a small (~300K) cross-platform, cross-browser download that helps to cache your web application's user-interface for use offline.
This was such a crazy application for me to work on. I've been crunching away on the offline problem for years, throwing different things against the wall to see what would stick: AMASS, Dojo Storage, early offline work using Dojo Storage and browser caching tricks, and now Dojo Offline. This project was a serious coding stretch for me; it involved using 6 different languages, 3 of which I don't even know (Perl, NSIS, Bash Shell Scripting) and one in which I'm frankly not very good at (C). Here's the languages it took for me to get this out the door:
This project almost didn't happen multiple times -- there were many times in which I thought it would be impossible and got pretty close to giving up, but the thought of not delivering kept me going. What we have up is a beta -- there are bugs and glitches for some edge cases, but the functionality is there and the core use cases work well. We now just have to drive the beta forward and keep iterating to press the bugs out across more and more tested PCs. Very special thanks to SitePen (Dylan Schiemann and Carrie Sackett in particular) -- without their support the Dojo Offline Toolkit would never have happened.
I'm really going to need the help of the wider community to pitch this tent. Dojo Offline is really just a scrappy open source project, and like any low-to-the-ground open source project it's resource constrained. What we really need is one or two more really good C-programmers. With that the sky would be the limit.
Ok, now I'm going to go sleep for a very long time :)
This was such a crazy application for me to work on. I've been crunching away on the offline problem for years, throwing different things against the wall to see what would stick: AMASS, Dojo Storage, early offline work using Dojo Storage and browser caching tricks, and now Dojo Offline. This project was a serious coding stretch for me; it involved using 6 different languages, 3 of which I don't even know (Perl, NSIS, Bash Shell Scripting) and one in which I'm frankly not very good at (C). Here's the languages it took for me to get this out the door:
- JavaScript - for Dojo Offline JavaScript library bundled with web page
- C - for local proxy
- Java - for server-side portion of Moxie demo app, using servlets and MySQL to create a full syncing example
- Perl - for Mac OS X installer
- Bash Shell Scripting - for Mac OS X installer
- Nullsoft Scriptable Install Script - for Windows installer
This project almost didn't happen multiple times -- there were many times in which I thought it would be impossible and got pretty close to giving up, but the thought of not delivering kept me going. What we have up is a beta -- there are bugs and glitches for some edge cases, but the functionality is there and the core use cases work well. We now just have to drive the beta forward and keep iterating to press the bugs out across more and more tested PCs. Very special thanks to SitePen (Dylan Schiemann and Carrie Sackett in particular) -- without their support the Dojo Offline Toolkit would never have happened.
I'm really going to need the help of the wider community to pitch this tent. Dojo Offline is really just a scrappy open source project, and like any low-to-the-ground open source project it's resource constrained. What we really need is one or two more really good C-programmers. With that the sky would be the limit.
Ok, now I'm going to go sleep for a very long time :)
Labels: ajax, dojo offline toolkit, open source
Subscribe to Posts [Atom]
