Server-side JavaScript development and hosting(akshell.com)
akshell.com
Server-side JavaScript development and hosting
http://www.akshell.com/#
7 comments
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.
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.
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.
The Node community seems pretty resistant to alternative concurrency models like fibers, etc, which I think is unfortunate.
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
- 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
Wow. It's really impressive how responsive the interface is and how much it feels like a native IDE.
Built using Cappuccino :)
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...
I've actually translated the first part to English and am hoping to publish it on DailyJS in the near future.
Anton has written a post in Russian on his experiences with Cappuccino: http://translate.google.com/translate?sl=ru&tl=en&js...
I've actually translated the first part to English and am hoping to publish it on DailyJS in the near future.
Here's what happened the last time Akshell was on the HN front page: http://blog.akshell.com/hn-effect/
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.
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.
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.
We use the Ace editor, which supports Coffeescript.
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.
You're right. There's a pretty big movement of compile to JS languages (http://altjs.org/), we should mention that somewhere.
I agree, I would use this thing if it supported coffeescript.
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.
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.
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.
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.
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.
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
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
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.