We made the mistake of adopting GWT a while back and it's been nothing but headaches.
Now instead of the designers being able to directly design in HTML (which they all have a familiarity of), they're required to download our entire project, edit the layout classes, recompile, just to see their work.
We've tried to have the developers take the designers mockups and translate them into working code, but the app seems to lose that designer "touch" in the process.
Designers need to be able to work with a familiar canvas.
BTW, do desktop GUI apps have non-programmer designers?
Well, not non-programmers, but programmers who know the particular layout libraries of the platform better than the programmers writing the data access layer, for example. I'm not saying this is universally true, but when I worked for a larger team focuses on a single product, that's pretty much how it worked.
I was under the impression that part of the point of copying cocoa was that you can use the Cocoa IB to make Cappuccino UIs, also. I would be cool, but I might be wrong.
It may also be a better and more compact way to build "rich" web apps, but that remains to be seen.
As a designer, every time I've seen Obj-J, I've thought about it being possibly useful as a bridge in the other direction: as motivation to learn Cocoa and go from the web to desktop and iphone.
I've been interested in developing native OS X apps for a while but haven't had the time or inclination to pick up a set of skills that are parallel and disconnected from web development, so finally being able to develop in a similar language for multiple platforms is very enticing.
Personally, I wouldn't mind letting go of the html/css if I could get pixel perfect precision in a different manner (can you get do that with Cappuccino?) that would also translate across platforms. I don't care about recycling skill sets - it's not like I can 1) use stylesheets on native apps today, other than for gimmicky crap like Dashboard widgets, or 2) will forget the html/css that's been hammered into my brain over the years, especially since I'll still be using it for informational and content-centric websites as opposed to web apps.
I assume Cappucino is targeting the same type of next generation web applications.
I've pretty much had to do that already to work with Flash. That's been a pretty limiting sandbox - we've been hearing "next year is the year Flash finally goes big on mobile and desktop" for a few years now, even from my buddy at Adobe on the Flash Light team - so I'm much more motivated to pick up a parallel set of skills for something that would be actually useful in the present day for something other than web development.
I also wouldn't rule out Google rolling out something similar as well as they unify the widgets and windowing type stuff they've got from docs and spreadsheets (and Zenter for that matter).
Then again I've been in a text editor for the past seven years and have just recently started developing in Objective C (I'm about half way through "Cocoa Programming for Mac") and I must admit that I was impressed with the intuitive nature of building applications in Xcode and Interface Builder.
Random notice/question: Since V8 is increasing the efficiency of property references for JS objects via hidden class objects, does that mean that Cappuccino's message routing will gain a huge speed increase?
Man, I just love the circular nature of this: ex-Smalltalk developers wrote the JavaScript implementation which in turn, will run Smalltalk-like message passing.
I think this marks an evolution of web interfaces. I'm exited to see what people build using Cappuccino.
I don't think mimicking desktop UI's counts as "evolution".
Obviously, webapps should not copy desktop UIs entirely. But any evolution of web app UI toward better interaction is certainly good for everyone. And because desktop apps have had a lot of time to evolve efficient interaction controls, mimicking them shouldn't be a bad thing.
I tried Sproutcore, and while I'm impressed with what's been done so far it takes me several days of working on it to shift into Javascript/HTML/CSS mode from Obj-C. Hopefully with Cappuccino it'll be more like porting the app than rewriting the app.
[Edit to clarify]
Congratulations, 280 North! What a contribution.
http://www.sproutcore.com/2008/05/01/another-reason-not-to-c...
http://www.sproutcore.com/2008/04/22/emulating-cocoa-in-java...
While Cappuccino gives me the ability to dip into JavaScript if needed, it means I have to be proficient in Obj-J, JS, CSS, HTML, DOM, ...
That said, it is very impressive and I think competition for the "cocoa of the web" will improve both projects.
Sproutcore, on the other hand, really does need you to be an expert in all of those technologies, plus its own, plus ruby helpers to actually put anything on the screen.
I've not used Obj-J so I cannot say if I will like it as much as I like JS. The idea of cappuccino providing a cocoa for the web is great, I just wonder if it could have been done without requiring a "new" langauge
I look forward to experimenting with your framework though.
Kudos!
I'm wondering whether only desktop developers will use this, or if it will be reasonable for web developers more familiar with PHP/Python/Ruby & HTML/CSS to pick it up and run as well.
That argument doesn't really make sense, since you can run JavaScript / Objective-J on both the client and the server, but you can only run PHP on the server (though from what I understand you translate PHP to JavaScript?)
Objective-J runs on a number of JavaScript engines that can run on the server, including Rhino (check out the "objj" executable in the "Tools" package: http://cappuccino.org/download/). While we don't have a good web server solution yet, it's certainly a possibility.
But even once that is a reality, Cappuccino will be totally server agnostic, so it will work with whatever server side technology you are comfortable with (or stuck with)
It's a tremendous pain in the ass and a failure for Microsoft as far as I see it.
Just because they have a large amount of adoption doesn't mean they've done things the right way.
I'm not saying that ASP.Net doesn't have a huge level of adoption, because it does. I am saying that they are seeing the problems with the idea of web applications just like client-server apps.
To be 100% clear, I mean that the concept of developing a web application just like it's a client-server application is a failure. Not the Asp.Net stack which is very clearly not.
Official Cappuccino site: http://www.cappuccino.org/
Download link: http://cappuccino.org/download/
git clone git://github.com/280north/cappuccino.git
If I'm ever an angel, I'll probably have a "write a framework? here's your check" policy.
Was all the time spent building the framework worth it because they have new capabilities or was it NIH syndrome?
Frameworks are a tough thing to do as a business. People tend to flock to use mostly one. Learning a framework is a big decision, and a big time and money investment. A framework needs to be compelling to make anybody want to use it for serious stuff.
The key motivators are default, money and laziness. Let me give you an example:
- I know MFC because it's the default framework on Visual Studio - I use Django because it allows me to be lazier than if I use PHP. Also, I figure my python knowledge may make me money in the future - I use jquery because the availability of plugins means that I don't need to write those stuff myself - I plan to learn to use the iPhone SDK because there is money there
I don't want to use Lisp or Fortran or any of those smaller languages/frameworks because they offer me nothing.
I would only use your framework if it fulfilled on one of the criteria above. Right now, it's really not clear. Will it make my development work faster? Will the resulting applications be better? I can't tell, so instead of wasting 2 weeks finding out, I'd rather just close the page.
Is it data = [CPURLConnection sendSynchronousRequest:"http://myUrl"] ?
This is a Javascript wrapper, which means that browsers can execute it. Browsers can't execute Objective C.
I'm not sure why these people felt they needed a wrapper around Javascript, which already has it's own fairly dynamic object model, but meh.
[edit: elaborate a bit]
Or is it my lack of cultural awareness?
Even SproutCore is resorts to preprocessing code to get syntax enhancements, like their sc_super(whatever) which is converted to arguments.callee.base(this, whatever).
The fundamental difference between Cappuccino and NOLOH is that unlike Cappuccino, GWT, Silverlight, Java, Flash, etc, a NOLOH application is not a compiled application living on your local machine, which means you don't download the entire application, rather it's lightweight and on-demand. Because of this you can write things such as Amazon.com in NOLOH, as well as things like 280Slides, all while having a smaller footprint, but maintaining a unified application lifecycle. This also has other benefits such as being able to modify your application while it's running, as seen in the Hello World video. See http://www.noloh.com/#/section=features for more information.
There will be Python and Ruby versions of NOLOH in the near future.
I recommend you play around with NOLOH a bit more before making these statements. Please note that I wasn't belittling Cappucinno in any way, I was suggesting that if he was more comfortable with things like PHP, Python, etc, that NOLOH might be a better fit for him, rather than having the equivalent of a thick client application.