We originally released AppJet as the easiest way to get a new web app online and hosted, starting with print(“Hello world!”), and it has since expanded to support simple database-backed web apps. Amazingly, over 2,500 apps have been built to date using the AppJet site, many of them pushing the boundaries for our envisioned “simple” use cases.

We realized, however, that in its current form AppJet is not adequate for building more “serious” applications. For example, It would be difficult to implement all of Facebook on top of AppJet, using only 1 file of source code and 50MB of persistent storage.

Historically, many of the best developer tools have emerged from specific applications that required them. During development, the application and tool progressed symbiotically, each to the other’s benefit. So to help AppJet grow into a platform for more serious apps, we have been building a more serious app.

Very soon we are going to release our new, more serious web app to the world. It’s built and hosted entirely on the next version of AppJet, which we may or may not decide to call “JavaScript on Jets” .

The next step after releasing the app is going to be to release and open-source the new version of AppJet. We aren’t disclosing all the details yet, but you can be sure it will feature client and server JavaScript execution, loads of convenient libraries, a JavaScript database similar to the storage library you are familiar with, and many new power features for breaking up your app into multiple files of source code, modularizing control logic, database logic, and templates.

Even while we are adding these power features to AppJet, we are maintaining the simplicity of the current AppJet you know and love. We still want to enable quick apps that are 1 file of source code, and enable the developer to only add additional files and modules as needed.

We are also committed to maintaining AppJet in a Jar with the next version of the platform.

Stay tuned!

platform in a jar

appjet.jar contains all the software you need to host AppJet apps yourself, including the web server, database, and AppJet native libraries.

We have received feedback from some users who worry that apps written on appjet.com are locked in to AppJet hosting forever.  It was never part of our strategy to monopolize hosting of AppJet apps.  On hosting, we think we can compete fairly because our extremely efficient virtualization system gives us an edge.  In any case, lock-in is no longer an issue with AppJet.

This release raises other questions as well:  Is appjet.jar a useful product on its own (without the AppJet hosting and online IDE)?  Should we start an open-source project around this distribution so our users can help make AppJet better?  Would people be interested in building more “serious” apps using this, and with some improvement, could AppJet be preferable to other solutions such as PHP or Django?

We of course have our own ideas about these questions, but yours are much more interesting to us.  So what do you think?  Leave a comment on this blog post or in the forum.

This interactive tutorial has generated a small splash of press around the net, for example TechCrunch, Ajaxian, WebMonkey, programming.reddit.com, and news.ycombinator.com.

We’ve received an overwhelmingly positive response from beginners who are programming for the first time and writing interesting new apps.

Another response we’re hearing a lot that surprised us is “How come I’ve never heard of AppJet before?” This tells us that we have some work to do in terms of getting the word out. As we continue to spend most of our time developing AppJet the product, this reminds us that we need to remember to stick our heads up and tell people what we’ve been up to.

Things has been a bit crazy at AppJet as we’ve recently moved our headquarters! Our old headquarters were on the top floor of a skyscraper, so of course we called that the “AppJet Control Tower.”  Now we’re located in San Francisco’s “mission” district, and in the continuing spirit of bad airplane puns, we have thus christened it “AppJet Mission Control.”

We’ve been having a blast setting up our new workspace (and, well, less of a blast cleaning up and moving out of our old one).  We’ve got some super-exciting new features planned for the next couple weeks, but until then, we thought we’d post a few pictures from our move.

Aaron and David after a long night (yeah, sunrise) cleaning our old apartment:

David gleefully preparing his 30″ Apple Cinema Display:

Aaron hidden behind his three screens:

J.D. doing post-processing on these images:

David and his 5-column emacs setup:

Aaron gets work done:

J.D. reflected in the dark window:

Our mannequin keeps a watchful eye:

If you love AppJet and are in the area, let us know! We’d love to have you over sometime.

- J.D. and the AppJet Team

To build your own processing app, first look at processing-example.appjet.net. You can clone this app to create and publish your own processing scripts. That easy!

JavaScript is indeed the language of the future.

It’s been a while since we released any new features for AppJet. So what have we been doing? As you might have guessed from this forum post, we were working on a project to create a PHP version of AppJet. Depending on where you’re coming from, that probably sounds like blasphemy, lunacy, or a reasonable way to reach more developers. We’ve now come to the conclusion that JavaScript is actually the right language, and the existing appjet.com is the right site, to take AppJet into the future. We’d like to take this post to explain our thinking.

First, remember that the purpose of AppJet is to make it easier to build and host web apps. We chose JavaScript as our server-side language in part to reduce the number of languages a developer needs to learn. Unlike servers, browsers only speak one language (JavaScript), so you have to learn that anyway. Fortunately, JavaScript is an awesome language. Yay JavaScript!

But choosing JavaScript created two big problems for us. First, the JavaScript language is widely misunderstood. Many people equate “JavaScript” with “client-side DOM scripting.” When we tell these people that AppJet lets you write server-side logic using JavaScript, they hear, “AppJet lets you write server-side logic using client-side DOM scripting,” and this does not make sense to them.

To illustrate how deep this confusion is, back in February I was at MIT attending a dinner for finalists in the BattleCode Programming Competition. I explained AppJet to a group of smart MIT students, and explained how it lets you write a web app, including server logic, using JavaScript. I also explained how this creates a lot of confusion for people, because the JavaScript language is confused with client-side scripting, and therefore we were thinking of moving our language to PHP. And, I kid you not, a student from the table remarked, “Oh! With PHP you would be hosting server-side code as well?”.

The confusion of JavaScript with client-side DOM scripting also creates an unfortunate stigma for the JavaScript language because client-side DOM scripting is annoying, and incompatabilities abound among browser implementations. So people get the idea that the JavaScript language itself is annoying, which is wrong.

The other major problem with choosing JavaScript is that there’s no server-side JavaScript web framework with the characteristics we want. Helma is great (in fact we use it to serve the AppJet frontend), but it’s too heavyweight for single-file AppJet apps. So we created our own server-side JavaScript micro-framework. As we evolved the AppJet Framework to fit the needs of larger and more complex apps, we started reinventing things that other frameworks have already solved pretty well. So we had to ask ourselves whether it made sense to put our effort into building another web framework.

After much deliberation, we concluded that switching to PHP would solve these problems, and allow us to focus on the important things like eliminating the hassle of hosting, creating a great IDE that runs in the browser, and transparently scaling apps up or down depending on demand.

Or so we thought.

It turns out that PHP is a step backwards from our JavaScript micro-framework in a number of ways. First, the PHP language is less elegant and less powerful than JavaScript is. Second, PHP is heavily intertwined with Linux, Apache, and MySQL (the “LAMP” stack), and as a result, most books and articles about PHP assume that you’re running those systems. But in reality, the whole LAMP stack is really just a bunch of legacy systems connected through thin straws, and this makes it complicated to learn and use.

We taught a class at Stanford on programming web apps with PHP and MySQL, and we realized that it took three times as long to teach the the concepts necessary to build the same apps as with JavaScript-AppJet. Even if using PHP would appeal to the large community of PHP developers, it would also make web programming harder, not easier. We decided we would rather do the necessary preaching and education to advocate JavaScript to the world, so we’re sticking with JavaScript.

Thank you, our faithful AppJet users, for waiting patiently while we worked on the PHP project. You will be happy to know that we created a number of new technologies while working on PHP-AppJet that are directly applicable to the JavaScript AppJet, and we are now going to start upgrading appjet.com with them. For example, we have an entirely new version of the in-browser code editor that fixes all known bugs and feels as responsive as a desktop code editor. Also, we rewrote the app engine to be more efficient. We even started an ambitious project to expose the entire Java Standard Library via JavaScript in AppJet apps. This would let you do things like print((new java.util.Random()).nextInt()). And finally, we learned a lot about what’s good and what’s bad about programming web apps in PHP, so we can be sure not to repeat PHP’s mistakes.

Look forward to some new AppJet features in the near future, and in the meantime, happy hacking!

Sincerely,

The AppJet Team

It’s hard to launch something to the world. How do you know when it’s
good enough? We learned at Y Combinator that the real question is,
How soon can you launch? What needs to be done that’s keeping you
from launching today? The bottom line is that any task or feature for
which you postpone launch had better be worth it; what if you launch
and discover that the people most interested in your site don’t care
about that feature?

However, the fact that we’re launching means we feel that AppJet has a
core set of functionality that makes it already very useful,
especially for quick and simple web apps, where normally setting up
the hosting would take longer than writing the app.

We’re excited to introduce AppJet to the world. We’ve got big plans
for it, so think of this as just the beginning.