John Resig’s processing.js is a port of processing to client-side JavaScript. Processing is a simple way to make cool visualizations and animations. AppJet is all about JavaScript, and we realized that our IDE is immediately useful as the easiest way to try out processing.js and to publish your own processing apps at your-domain.appjet.net.

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!

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!