1. i clicked and failed to find any release. only a video and a mailing list.
2. only a beta will be released and you will have to pay 20$ to get it. To pay to debug their code? the offer is not that compelling.
let hope those are just glitch during the launch
The 280 North guys are the first to admit that CP isn't for every web app, but it serves a specific need exceptionally well. And, personally, I think its' application and adoption will only broaden.
I can't wait to part with my $20! They have to monetise somehow, and if this helps the next year of development - hell, make it $40!
i dunno what the tool worth and i dont plan to pay 20$ to find out if i need this tool.
i dont blame the product, just the moneytisation is broken. Ok to sell a tool, but first convinces potential buyers
We happily admit that a paid beta program is a bit of an experiment, but it's hardly unprecedented. See Mac OS X Public Beta for an example. We do not want to set up the false expectation that Atlas is free. It isn't.
That said, if you wanted to hit the ground running on Monday morning, launching on Sunday allows for the blogosphere to start talking about Atlas on Monday morning.
I can not continue this thread without appearing as a 280n hater and i didnt find a way to reach boucher directly.
Having a paid beta, means that people who haven't used Cappucino probably won't try it and it's a good thing because they would have been harder to support...
"To be fair, I give all the credit in the world to the NeXT guys, but charging $3500 for a microcomputer without a vast application library and that really has no broad adoption is just not worth it."
That said, here's how I see things.
(1) 280 North took a broken environment and tried to apply a not-entirely-broken substrate atop it. Is it going to be slow? Sure, but consider also that Javascript is inherently slow to begin with.
(Slow begets slower, blah blah, I don't want to hear it. I don't care.)
(2) It's a start, and when it comes to 280 North's business practices, I'd be willing to bet that there might very well be a standalone compiler for Objective-J at some point if enough people ask for it.
... if I don't beat them to it first. It's getting close to the point where I'm considering just hacking something together in OCaml to scratch my own itch in this vein.
(3) The 280 North guys are smart guys. They listen. Complain. Send them mail.
We are planning on getting a new compiler in 2010, and it will still do all those things. It will also be more robust, introduce some sorely needed new features, and with any luck be faster to boot.
With respect to point one, I'm not sure anyone commenting in this thread really understands the complexity of optimizing application performance in the browser. On an absolute level, message passing is slower than function calling. But taken in context, that's a small percentage of what happens in an application.
Cappuccino, because its an application framework, can make certain assumptions to dramatically improve performance. Assumptions that can not be made here and there by individual app developers. For example, coalescing DOM updates and drawing events on the run loop. Combining timers together to minimize overhead. Delegating events from the document level to prevent unnecessary build up of event handlers. On the tools front, we can strip some dead code from projects, automate spriting of all app resources, target different code paths to different browsers automatically, and a slew of other things. Performance is complicated.