Is AppJet the next big web framework?
blog.vezquex.com
blog.vezquex.com
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.
Could you elaborate on that more? Why will this platform be _the_ platform of the future?
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?
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.
Why?
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.
{I'm not baiting, I'm actually asking}
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.
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.
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).
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.
A framework, on the other hand, assists in the development of an application, typically independent of the platform it runs on.
In computing, a platform describes some sort of hardware architecture or software framework (including application frameworks), that allows software to run.
It is like comparing Windows and TCP/IP.
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.
Server executed JavaScript may have a future in web development, but I don't see AppJet being it.
Is there anyone who has used helma extensively can comment on this?
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.
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.