We do think AppJet will be the platform/framework of the future, but in the present it's a little early to compare the AppJet Framework with PHP, RoR, Django, etc.
AppJet was designed to be easy and make it possible to write cool little web apps with a small amount of code and a small amount of knowledge. From this perspective, it becomes obvious why we chose JavaScript as the server language: it reduces the number of languages you need to learn by a factor of 2.
I think it's succeeding at what it does. There are lots of cool apps in the app directory, and most are <500 lines of code in a single file. Many of these apps are written by high school students who learned programming with AppJet. Some of my favorite include {pxl,outliner,files,wikijet,agglodex,dict,livescore}.appjet.net.
We are working on improving the AppJet Framework to be good for large apps. We're also working a lot on our platform. (mrtron makes a good point about platform vs. framework elsewhere in this thread). One day, we'll tell the hacker news community that we think AppJet is a suitable replacement for PHP, Django, RoR, or whatever you're building your startup on. But we're not there yet.
In the meantime, if you want to hack up a simple database-backed web app without worrying about hosting or setting up SQL or anything, AppJet is your platform. Or if you want to learn programming with a platform that will let you do a lot knowing only a little, AppJet is your platform.
The short answer is that we see problems with all the existing ones, and we think we can do better. The longer answer will be the subject of blog posts as we roll out milestones along the way.
Why would I choose AppJet over, say, Google App Engine?
I haven't used either, but they seem to advertise similar use cases. As you point out, AppJet lets me use just one programming language, whereas App Engine you're going to be using Python on the backend, Javascript in the browser. Google has a proven track record in scalability.
Are there other important differences between them?
I think it's extremely likely that JavaScript will be absolutely pervasive in applications in the coming years. I don't know whether AppJet is the One True JavaScript framework, the way Ruby on Rails has been pervasive for Ruby, but it's excellent business sense. AppJet, as long as it is a closed platform running in one place, will remain a niche player--and, based on the apps that have been built to date, it will be a "small app" niche, which probably isn't going to lead to windfall profits in the near future.
But, if they open it up, and people agree it is awesome on a scale similar to RoR and Django, it'll grow their niche into something quite huge. They'll get a few competitors out of the bargain, but having a huge industry to fight over is better than having a tiny industry all to yourself. Heroku, even though they have far less exclusivity for their platform (deploying RoR can be done at many hosting providers), seems to be growing at a much more rapid clip than AppJet...and I believe Heroku actually launched later, but my history might be off a bit.
Anyway, I wish them luck. I'd love to see server-side JavaScript becoming more pervasive. It's a quite nice language.
The two reasons javascript is not widespread on the server are:
1. limited database access libraries, there are no standard libraries for talking to mysql/postgres/oracle/sybase/mssql
2. lack of namespace support in the language itself, which means that you can't rely on external code to not step on your variables.
Also there's a minor usability issue with using the same code in two different environments; the server side and the client-side are not the same and confusing the two can introduce whole new classes of bugs and security holes. Not that anyone here would ever lose track of where the file they were working on was supposed be run.
Definitely agree on point 1, though I think it might work itself out in surprising ways. CouchDB speaks JSON natively, for example.
On 2, there are solutions to this problem based on closures, and basic politeness (YUI uses the YAHOO. prefix, while ExtJS uses Ext., and they can co-exist in one browser). It's not perfect. I'd like to see Perl-style package name spaces, or similar--nothing obtuse like the new PHP namespace support--just very concise and simple but powerful. I, personally, don't think Java style encapsulation and object border defense is all that important...but maybe enterprise users will (though Perl does OK in the stodgy banking and finance world, so it shouldn't be too scary for them).
Because it has already become a common tongue, and with rich web apps becoming the norm, it'll only increase.. It's the language pretty much everyone building web apps knows. I work predominantly in Perl (and in the past in Python), and I've tinkered with other languages. But, throughout all of that, at least for the past five years, JavaScript has been part of the job.
Imagine the meeting wherein a handful of developers are tasked with choosing a language and platform for a new app. Say, four people...one likes Ruby, one likes Python, one likes PHP, and the last likes Perl (and they all agree that Java and C# are too damned verbose). Which language wins? Well, they all know JavaScript, because every web developer knows JavaScript, and they think jQuery is pretty swish...assume there's a high quality server-side environment, of course.
Obviously, it's not a foregone conclusion that JavaScript will move into a position of strength on the server. It requires too many pieces to fall into place (good implementation, good libraries, good integration with web servers, etc.) for anyone to call it a done deal. But I think it'd be foolish to bet strongly against it happening.
Why hasn't it happened yet. JS has been around for a while. Web developers's have known it for a while. Why now? Because of Appjet or whoever else will fill that role? Or because 'rich web apps' have reached that point?
A lot of people didn't really like JS much because of the negative association with crappy implementations in browsers. Also, truth be told, to me it's not a very exciting language - I suspect that a lot of other people interested in 'cutting edge' type of things felt the same way, and the 'staid, solid, enterprisey' crowd was pretty happy with Java, which leaves something of a gap.
JS has been around for a while. Web developers's have known it for a while.
Have they? What was the biggest JavaScript application you deployed five years ago? For me, it was maybe 5k, and did nothing more than some basic form validation and content hiding effects. And now? Well, our biggest will be including almost all of ExtJS which is I think about 400k, compressed. jQuery is ~60k, compressed. Our use of JavaScript is definitely not declining. Is yours?
I think it's only in the past two years that the work of the JS library developers have proven that large JavaScript apps are plausible. They've also smoothed over most of the browser compatibility issues--which are no small part of the historic tendency to avoid doing any heavy lifting in JavaScript. Browsers are also getting better about those issues. That standardization plus quality libraries has made it more reasonable to "write once, run anywhere" with heavy JavaScript usage. Despite the cynicism with which the phrase is usually uttered, it is still a very valuable trait in a language.
I don't think AppJet has played any role in JavaScript history to date...but they might, as they're very smart fellows. Far more important players include Yahoo, Google, Microsoft, Mozilla, Adobe, and the Open Source library developers. And, of course, a few other YC alumni have been major contributors to the JavaScript juggernaut: John Resig of jQuery fame had a YC-backed startup before joining Mozilla Foundation, and Blake Ross and Joe Hewitt started YC-backed Parakey.
Anyway, it's not that I think JavaScript is perfectly suited for all tasks--or better suited for any particular task than X language. I just think it is well enough suited for most tasks (including a few for which Ruby, Python, Perl, Haskell, Lisp, etc. never will likely be at all suitable for...like the client-side of rich web apps), and the friction of switching between multiple languages, and the interoperation cost and complexity, is high enough, that JavaScript could pretty easily become the de facto standard language for web apps. And, since most of us can agree that nearly all end user apps will eventually be web apps, that means most apps.
Again, I really wouldn't want to bet against it. I'm glad I happen to find JavaScript to be a very pretty language. It has some rough spots, but overall, I don't mind working with it. It's biggest problems, I find, are caused by the DOM and its not quite comfortable connection to JavaScript.
I always find the confusion between platform and framework annoying.
"web platforms have to be free and open. LAMP is the reigning king. Ruby on Rails and Django are the up-and-coming challengers."
LAMP is Linux/Apache/Mysql/PHP, which is a platform. Django/RoR are frameworks for their respective languages, and still use Linux/Apache/Mysql or similar.
In computing, a platform describes some sort of hardware architecture or software framework (including application frameworks), that allows software to run.
edit: Isn't a good part of a framework below your application logic?
1. Nobody likes javascript. We use it because it's there, but nobody LIKES it
2. A serious lack of sexy. AppJet makes an app that is targeted at hardcore nerds. And then markets it to beginners. Let me tell you somefink - even beginner programmers want to be hardcore. They don't want 'easy' stuff. You want 'quick' or you want 'cool', but not easy.
3. No platform with eyeballs and revenue potential
4. It's a frickin closed eco-system. Each new framework or way of doing things I learn takes a huge amount of my time and effort. The value of that time and effort to me is MASSIVE. No seriously, this is like me paying you $10.000. If you want me to buy a premium product from you that costs that much, then I want to feel pampered. I want a return on this investment. AppJet has no return! No money, no credibility, no Resume relevant qualifications.
5. If AppJet becomes open source, then it needs to offer me a very clear advantage over my current django+python combo. And unless the owners learn how to market to the geeks, this is not going to happen.
My conclusion: Your marketing is very wrong. Either sell to nerds or sell to internet marketers. But not this middle ground with no real defined target.
I'm going to go ahead and say no. AppJet has been around a year and is nearly invisible. The most popular app on AppJet gets a massive 1300 weekly users and is completely worthless (http://appjet.com/app/799084449/source).
Server executed JavaScript may have a future in web development, but I don't see AppJet being it.
I don't know. I'd find it annoying to build a large application in javascript, but I suppose it could be done. There are some attractive alternatives like GAE and Heroku. That said, cloud services are a hot area, and there are plenty of new tools that Appjet could leverage, like S3 and couchdb.
I'd find it annoying to build a large application in javascript
Why?
It's a pretty darned powerful language. ExtJS and YUI have shown that it can work for quite large projects in an OO manner, and jQuery has shown that it can be made exceedingly concise and pretty. It's missing a lot of niceties for working with the system, which is a big negative (and one of the same reasons that Lisp, Scheme, and Smalltalk haven't had as big an impact as more recent attempts at dynamic languages like Perl, Python, and Ruby have had), but I assume that as the non-browser implementations become more popular, those problems will be addressed.
I think, when all is said and done, if the committees don't manage to kill what's great about JavaScript (by, for example, bolting on more Java-style OO), it could grow to be more popular than all other dynamic languages combined. Not that I'll be switching from Perl to JavaScript for server-side work any time soon, of course.
I recall an add-on for Scheme where you could call Unix command line utilities and tie them together with pipes, and it all just looked like your run of the mill Scheme code.
Also, there was a project to enable writing Unix style command line utilities in Smalltalk. They got the image down to ridiculous small sizes, like 45k!
There's nothing about Javascript that would preclude "working with the system." Usually the biggest barrier is the culture of the development community. Really, Smalltalk never completely quit being an OS.
AppJet was designed to be easy and make it possible to write cool little web apps with a small amount of code and a small amount of knowledge. From this perspective, it becomes obvious why we chose JavaScript as the server language: it reduces the number of languages you need to learn by a factor of 2.
I think it's succeeding at what it does. There are lots of cool apps in the app directory, and most are <500 lines of code in a single file. Many of these apps are written by high school students who learned programming with AppJet. Some of my favorite include {pxl,outliner,files,wikijet,agglodex,dict,livescore}.appjet.net.
We are working on improving the AppJet Framework to be good for large apps. We're also working a lot on our platform. (mrtron makes a good point about platform vs. framework elsewhere in this thread). One day, we'll tell the hacker news community that we think AppJet is a suitable replacement for PHP, Django, RoR, or whatever you're building your startup on. But we're not there yet.
In the meantime, if you want to hack up a simple database-backed web app without worrying about hosting or setting up SQL or anything, AppJet is your platform. Or if you want to learn programming with a platform that will let you do a lot knowing only a little, AppJet is your platform.