

Is AppJet the next big web framework? - Raphael
http://blog.vezquex.com/2008/08/is-appjet-next-big-web-framework.html

======
aaroniba
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.

~~~
chrisbroadfoot
_We do think AppJet will be the platform/framework of the future_

Could you elaborate on that more? Why will this platform be _the_ platform of
the future?

~~~
aaroniba
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.

------
SwellJoe
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.

~~~
olefoo
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.

~~~
SwellJoe
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).

------
mrtron
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.

~~~
Hexstream
A platform is an "environment" you build a system on, so a framework is also a
platform...

~~~
ed
No, a platform consists of everything _below_ your application logic. Think
hardware, i/o abstractions, etc.

A framework, on the other hand, assists in the development of an application,
typically independent of the platform it runs on.

~~~
Hexstream
There are multiple possible definitions of "platform", it just happens that I
use a more inclusive one while you use a more restrictive one. According to
<http://en.wikipedia.org/wiki/Platform_%28computing%29>:

    
    
      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?

~~~
mrtron
Comparing LAMP to Django/RoR is comparing apples to oranges.

It is like comparing Windows and TCP/IP.

~~~
Raphael
True. But there isn't one dominant PHP framework and a lot of people don't use
a formal one or just kind of roll their own.

------
maxklein
Nah it won't. AppJet fails on many levels

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.

------
jonknee
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.

------
morbidkk
how is it different from the helma? I found helma(helma.org) quite mature.
Compare <http://appjet.com/learn-to-program/lessons/lor> to
<http://helma.org/docs/guide/framework/>

Is there anyone who has used helma extensively can comment on this?

------
marketer
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.

~~~
SwellJoe
_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.

~~~
stcredzero
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.

~~~
SwellJoe
Agreed on all counts. Culture definitely plays a big role, perhaps the biggest
role.

------
falsestprophet
Not while they insert a 'Powered by AppJet' tag on every page

~~~
netcan
I don't think you have to. <http://appjet.com/docs/faq>

------
mpstaton
good press Aaron!

