
Server-side JavaScript development and hosting - shawndumas
http://www.akshell.com/#
======
mwill
Here's the HN submission from last year:
<http://news.ycombinator.com/item?id=1261786>

Not sure how much the product has changed since then. Straight off it doesn't
use node.js (In the older thread he mentions it's because it's asynchronous
thus not simplistic enough), which strikes me as an odd choice (Maybe it made
more sense when node.js was younger).

I would absolutely use this as often as possible if it used node.js, it would
make an awesome jsfiddle for server side code.

~~~
olegp
I agree about the need to migrate over to Node.

Separately from Akshell I'm working on Common Node
(<http://olegp.github.com/common-node/>) which uses node-fibers to implement a
number of (synchronous) CommonJS proposals. This now allows for a Rails like,
synchronous framework to be built for Node and RingoJS.

If it makes sense in the future, I might also port some of the Akshell
libraries to run on top of Common Node.

~~~
tlrobinson
I love the idea of node-fibers and Common Node. What are the drawbacks you've
run into so far?

The Node community seems pretty resistant to alternative concurrency models
like fibers, etc, which I think is unfortunate.

~~~
olegp
From a technical point of view:

\- no real issues with performance or usage (see benchmarks section in the
README, that being said Common Node isn't in production anywhere yet), Common
Node runs at about 70% throughput (in req/s) of plain Node and uses around 10%
more memory in high throughput benchmarks; comparing Node and CommonJS
implementations like for like is difficult though, since for example Node
doesn't clear its Buffers

\- Node's insistence on reserving the "fs" module name & removal of
exports.paths has been a slight issue - it means the users either have to set
NODE_PATH manually or need to run apps via the bin/common-node wrapper script
to retain compatibility with other CommonJS platforms

From a community point of view:

\- as you say, people are pretty resistant & I spend a fair amount of time one
on one trying to convince (ex) front end Node.js developers why a sync
programming style isn't "magic" and is easier to work with; hoping to remedy
that by doing a few talks at various events over the next few months and might
write a blog post or two

\- lack of clear CommonJS proposals for Sockets and Subprocesses

\- the whole sync ServerJS scene is very fragmented - it would be nice to have
a project like commonjs-utils or a subset of narwhal which implemented the JS
only modules (like base64 etc.) and became the de facto standard lib that they
would all use rather than reinventing the wheel and making it impossible to
write portable webapps

------
albertsun
Wow. It's really impressive how responsive the interface is and how much it
feels like a native IDE.

~~~
tlrobinson
Built using Cappuccino :)

~~~
olegp
Given how relatively little attention Akshell received prior to the new IDE,
I'd say Cappuccino is the main reason for all the attention it's getting. So
thank you!

Anton has written a post in Russian on his experiences with Cappuccino:
[http://translate.google.com/translate?sl=ru&tl=en&js...](http://translate.google.com/translate?sl=ru&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fhabrahabr.ru%2Fblogs%2Fwebdev%2F114749%2F)

I've actually translated the first part to English and am hoping to publish it
on DailyJS in the near future.

------
olegp
Here's what happened the last time Akshell was on the HN front page:
<http://blog.akshell.com/hn-effect/>

------
wccrawford
Interesting, but 2 problems for me:

1) No prices listed. I don't like getting into something and then finding out
the prices aren't acceptable.

2) No Coffeescript. Okay, technically anything that runs Javascript is good
for Coffeescript, but it would be nice if the integrated editor would deal
with it, too.

~~~
olegp
We haven't decided on the price points yet, but there is also no lock in as
the server code is being open sourced. You will be able to self host.

We use the Ace editor, which supports Coffeescript.

~~~
wccrawford
You should really do something about #2. You're missing a huge movement simply
because you haven't mentioned the word 'Coffeescript' anywhere I could find. I
just went back and looked to make sure I didn't miss it. So if it's there,
it's really not in the right places.

~~~
olegp
You're right. There's a pretty big movement of compile to JS languages
(<http://altjs.org/>), we should mention that somewhere.

------
sktrdie
Interesting. They're using V8 but I don't think they're using Node.js... they
seem to have a custom made solution on top of V8.

------
wavephorm
Although IDE-as-a-service is probably eventually going to be commonplace, it's
going to be a tough sell today. Developing web apps, especially apps that back
a mobile application, is hard enough as it is.

~~~
olegp
IDE and platform as a service offerings should make mobile development easier,
not harder. If you're developing locally you need to somehow keep an open port
via your NAT so that your mobile (web?) app and third party services can
access it. With Akshell that URL is publicly available from the get go.

------
Kof
I have a problem with akshell, just in 5 minutes of looking at it I have 1001
concern. I just want to list a few of them:

1\. I am not sure the world need such a system which has javascript
environment, database and online IDE in one place. Its kind of trying to do a
lot of things but doesn't get anything of them really right. There are much
better solutions for each out of there, f.e. managed node hosting from
nodejitsu or online IDE from cloud9.

2\. it seems to be an own C++ environment written around of V8. It is written
by a very small group of people, or only one? It can not be such battle tested
and good like nodejs is.

3\. APIs are not well written, this guys have to learn from nodejs.

4\. Coding conventions used in main js lib I can see directly in the shell are
ugly ... well everybody can see its done by C coder, but its not the point.

5\. Code quality and structure of this ak lib are bad ... thousands of classes
in one file.

6\. Global functions, extended native prototypes, not fully commonjs spec
conform modules implementation. Well fuck, why? Didn't we learn in last 10
years that a spec is important, extending native prototypes is bad for the
most cases?

6\. Using a relational database is bad enough, but there is no way to use any
other database? Come on!, nosql is here!!! Why not to use mongodb, couchdb
etc. or at least to provide a choice.

7\. Test coverage of the default lib must be a joke. Such important stuff
should be completely test driven developed.

8\. Once again, the API is really bad !!! I just don't know where to start
from … I can't do this here.

I hope I didn't hurt somebodys feelings too much.

~~~
olegp
Thank you for your feedback, it's really useful. I'll answer some of these,
maybe Anton will pipe in as well.

1\. There are benefits to having the platform and IDE tightly integrated such
as it lowers the barrier to entry, allows for faster roll out of new features
that require an interface between the two etc. Probably the biggest one is
that it allows one to take social coding to the next level by showing not only
how many followers a given package has, but also showing whether it passed
unit tests, how many productions apps rely on it etc.

2\. This is answered in a separate thread below.

5\. Agree that the ak lib needs to split up into more modules and packages.

6\. You can use any other database as a service offering you want (e.g.
MongoHQ, IrisCouch etc.). There's a TCP socket class and a CommonJS compatible
HttpClient module that you can use to talk to them:
<https://github.com/olegp/ak-httpclient>

