The AppJet Blog

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!

JavaScript is indeed the language of the future.

Dear AppJet Community,

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

As of today, we’re officially launched! That means anyone can come to
the site, read about our framework, use the IDE, and create an account
to publish an app.

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.

To keep track of the detailed changed we make to the AppJet site and software, we have started The AppJet ChangeLog. It’s an AppJet app itself!

We are proud to be sponsors of MIT’s BattleCode programming competition. When David and I were undergrads, we won this competition, and it was one of the funnest things we did at MIT. (Quick synopsis: contestants write software to control virtual robots that battle each other in a videogame simulation).

This weekend was the first time we let real users play with AppJet software. MIT has an annual event called Splash, where thousands of high-school students come to MIT for a weekend to take short classes on hundreds of different topics, taught by the MIT community.

We taught a beginner course on web app programming using AppJet. The goal of AppJet is to make programming web apps easier, so we figured if high school students could use it, then we were doing a pretty good job.

Side note: AppJet is not just for beginners. Easy does not imply power-limited. For instance, JavaScript is easy to learn, and with its higher-order functions and lexical closures, it’s a pretty advanced language.

150 students signed up for our class. We gave them the AppJet basics and then let them go and build apps. I was very impressed with the programs they came up with.

First came the kind of apps you would expect high school students to start with.

• i-am-1337-h4×0r.appjet.com

Then things got more interesting when they experimented with dynamic content.

• boredom-buster-2.appjet.com
• funhouse.appjet.com

Next blossomed a genre of question/answer apps.

• jimmy.appjet.com
• philipanswers.appjet.com
• my-trivia.appjet.com

And a genre of discussion-board apps.

• scarab.appjet.com
• pfa3.appjet.com
• roswell.appjet.com

One particularly impressive program was a simple yet useful app that puts Google in an iframe and lets you take notes on your searches, store them persistently, and organize them:

• notes.appjet.com

You might notice that many of the above apps are similar to one another. That is because the source code to an AppJet app is public, and you can easily “clone” an app to create a derivative work. In fact, we keep track of the entire family tree of apps: every new apps starts as the clone of an existing one, with the exception of hello-world, which was the first.

All in all, we have over 400 apps running on our system after the weekend. Granted, most of them are only slight modifications to hello-world and receive very little traffic, but we think this release is a major first step toward making it easier to get a web app online.