Nice! Thank you for contributing to the improvement of the web.
Me
· 1 year ago
OMG! This is SO cool!!!!
Rahul Dave
· 1 year ago
Is there any notion of speeding up by moving the objective-J interpretation cycle to the server and mixing downloading of media with bytecode interpretation on the client as is done by YARV on the server and HotRuby in the browser.. http://hotruby.yukoba.jp/
Kevin Driedger
· 1 year ago
Thanks for all the hard work in getting this release together. I'd like to hear more of the story on how you decided on the syntax of Objective-J and what you're next thoughts are for extending the language. I hope you're plans are to keep it small and simple!
Adam Lett
· 1 year ago
Awesome. And what great luck for you guys that Google just announced Chrome, which really seems like the browser Cappuccino was meant to run on. I wish you great luck
- Adam
Mason
· 1 year ago
The amount of love I feel for you right now cannot be expressed in words.
Thank you for all your hard work. I'm excited to dive head-first into this stuff.
fintler
· 1 year ago
This is really sweet guys. WYSIWYG editors for the web are gonna start looking like Interface Builder now. :)
tlrobinson
· 1 year ago
@Rahul Dave:
We have the option of doing the preprocessing ahead of time one the server, which is typically done for frameworks and deployed applications.
We aren't compiling all the way down to some form of bytecode, but rather preprocessing at a higher level to turn Objective-J constructs into standard JavaScript constructs. For example, the message send operator [object message] gets turned into a JavaScript function call to objj_msgSend()
tlrobinson
· 1 year ago
@Kevin Driedger: At some point we'll be posting a series of blog entries describing our rational behind the things we've done
As far as the language goes, right now we're mostly sticking with the features Objective-C has. Objective-J is already fairly close to Objective-C 1.0, and has some of the features of 2.0 (like, uh, garbage collection, which we get for free from JavaScript, of course)
We'd love to hear what other people would like to see, and of course we'd love to get improvements from you guys too.
Luis Masanti
· 1 year ago
As far as I understand, Objective-J and Capuccino will allow me to "program a web app as if I'm doing a GNUstep [a.k.a. Mac/iPhone] application"?
Devon
· 1 year ago
I heard on Macbreak Weekly you have some internal UI design tools. Is there any info on the release of those?
tlrobinson
· 1 year ago
@Luis:
That's the basic idea (technically Cocoa, GNUstep, Cocotron and Cappuccino are implementations of OpenSTEP). Granted some things translate to the web better than others, so you have to keep that in mind.
Gareth Townsend
· 1 year ago
Awesome! I've been hanging out for this since WWDC.
Jon-Erik
· 1 year ago
I'm very excited about this, and have already begun playing around. I've been using both Cocoa and GNUStep for quite a while now, and I've been dreaming of being able to do this.
Now, here's the thing... does this implement NIB files, and if so, can we build them in XCode? If not, is there going to be some kind of tool like Interface Builder to "draw" the applications so that we can focus on the logic?
Even better--are there any plans to implement something like CoreData so that we can REALLY just focus on the logic?
That's a fine how-do-you-do, I know, after delivering this wonderful product. I'm just thinking how easy it is to start writing useful programs using XCode... and how amazing it could be if the web could do that.
Michael
· 1 year ago
As I am just about to start building a web app and need to decide the approach to take, can anyone give me (or point me to) comparison information between Objective-J/Cappuccino and Sproutcore? One major difference is the license (LGPL vs. MIT), and the LGPL may actually be a deal-breaker for my super-paranoid company's lawyers, but what about from a functional perspective?
Johan Kool
· 1 year ago
This looks very promising and extremely powerful. It is very nice to be able to use my knowledge of Cocoa now too for web applications. I am certain this will come in handy at some point for me. I look forward to further tutorials and sample code, though it looks quite straightforward so far.
Alex MacCaw
· 1 year ago
Very cool. Please could you consider releasing it under a different and less restrictive license (like MIT) as this can be a deal breaker for a lot of people (look at the palava surrounding ext's licenses).
Ask Solem
· 1 year ago
Nice work!
Why are you translating to _objj_msgSend() instead of directly to javascript? Wouldn't the js engines have a hard time optimizing the code for what it is? I understand why you would use msgSend in C, but js already has this.
boucher
· 1 year ago
objj_msgSend gives us all of the benefits of a dynamic runtime. For example, it allows us to implement Ruby's method_missing feature. it also allows for cool Objective-C features like method swizzling (swapping the implementation of a method in a class dynamically at run time)
oomu
· 1 year ago
@michael
the LGPL gives you the same concrete right than MIT to use the final product (cappucino) with your proprietary products.
You just can't appropriate yourself cappucino, modifying it and release it again AS a proprietary product. (you can't do "cappucino++ the proprietary version so much better")
but you can use it besides your commercial proprietary web applications with no problems. As you can use a LGPL cocoa frameworks inside a proprietary software without breaking the LGPL (or your own eula, because the LGPL authorize you to do that).
and lgpl is lawyer knowledge
webkit is lgpl, did it stopped nokia ? no. everything is fine, no need to worry. the licence is used and known as much than MIT or BSD.
Calvin
· 1 year ago
I love the idea of it. Have you look into using Google's V8 for maybe those that still want to compile it before running it in the browser. I am not sure what it would take to do it but since you mention it will work in Chrome, then it would be neat to see it compile ahead of time. Just a thought.
Greg Patrick
· 1 year ago
One of my thesis students pointed me to this site, and I have to say that I'm impressed with what I see. This is just what I need for some applications that I've been planning.
Great job!!!
Aron
· 1 year ago
Brilliant!
Kevin
· 1 year ago
Since I don't yet know Obj-C and am just now learning the syntax, I have a newbie Obj-J question. Is there a forum, or some appropriate place for me to go with my newbie questions?
thanks in advance, 280 Slides is brilliant and it's exciting to learn the framework you used to develop it.
boucher
· 1 year ago
Kevin, you should feel free to check out our IRC channel, or post your question to our mailing list. Both can be found on this page: http://cappuccino.org/discuss/list.php
Andrew Dupont
· 1 year ago
Guys, I am truly blown away by 280 Slides and I think Objective-J is quite an achievement. I must disagree, though, that the ES4 proposal focused on the wrong things.
First of all, it did include classical inheritance (but media support and webcam access are "browser glue" issues outside the scope of the language spec). And most developers I talked to decried the introduction of classes, fearing that JavaScript was mutating into Java. Some voices — most notably Doug Crockford of Yahoo! and Dustin Diaz of Google — wanted an ES3.1 with incremental improvements (such as the "let" keyword you dislike) and bug fixes.
I will agree that ES4 was guilty of biting off more than it could chew, but I think it was going in the right direction to begin with. I'll further agree that we could use richer APIs from the browser environment, but that's to be addressed by HTML5 and the WebIDL initiative. HTML5 itself is a petri dish for the "add, then standardize" model of XMLHttpRequest and the CANVAS tag.
This only proves, though, that developers have varied gripes about their tools and will come up with varied solutions. Glad to see Cappuccino is officially out; I'll be sure to take a closer look this weekend.
John
· 1 year ago
Good Job, I love your examples, now Im going to check which one is easier to develop with, SC or Cappucino.
Adrian
· 1 year ago
Is there any way I can help you for this project? This is ABSOLUTELY AMAZING I'm I'll be using it in my next project. Don't hesitate to e-mail me if you need a hand!
boucher
· 1 year ago
Adrian, come join us on our mailing list and in the IRC channel. We're happy to have people helping out each other, and working on improvements to the cappuccino code base. I'll be writing up lists of projects people can work on in the code too, so you may want to check out the source on github and get familiar!
thibaut
· 1 year ago
It's wonderfull to see this, we waited for it a long time, finally, it's here, but what about sproutcore ?
Donnie
· 1 year ago
Just wondering what your take is on building a proprietary application. The code is sitting there fresh for anyone to view. While you are still covered by copyright of course, I am wondering how Ojective-J and Cappuccino communities would address this? Or would you even?
boucher
· 1 year ago
Donnie,
This is something that everyone developing JavaScript for the web faces. There's really no panacea, but most people have resorted to minification and obfuscation to offer a little defense. While I'm not sure its strictly necessary, I would love to see some of these existing tools adapted to work with Objective-J.
Nosredna
· 1 year ago
>>I love the idea of it. Have you look into using Google’s V8 for maybe those that still want to compile it before running it in the browser. I am not sure what it would take to do it but since you mention it will work in Chrome, then it would be neat to see it compile ahead of time. Just a thought.
That doesn't make any sense. Chrome needs JavaScript source to run just as any other browser does. It can't run compiled JavaScript.
Now, if Obj-J could be translated to ActionScript, then you'd have some sort of bytecode running in Flash.
sxs
· 1 year ago
Hi there,
nice things!
I'm just playing arround. And now I wanna make some "server calls". I tried this:
var aRequest = [CPURLRequest requestWithURL:"http://foo.bar.com/?ajax=givemesomejson"]; var connection = [CPURLConnection connectionWithRequest: aRequest delegate: self]; [connection start];
I implemented the delegates and the didFailWithError one is triggered.
Now I see that i have to pass a CPURL object to [CPURLRequest requestWithURL:].
But I can't find any documentation about to make a propper CPURL-object, nor I find something in the source (as far as iI understand it ;-)
boucher
· 1 year ago
you don't need a CPURL, the request is just fine. You also don't need the [connection start]. This is a bug int he documentation -- the connection is automatically started.
Of course, XMLHTTPRequests must follow the same origin policy -- are you making a request to your same domain? Have you examined what the error passed to didFailWithError: is? May help debug the problem. Try hitting us up in our irc channel irc.freenode.net#cappuccino
chris
· 1 year ago
having some tutorial or just some simple examples for server interaction would be great...
e.g. reading and editing a SQL table -> generate the XML file on the server and write a PHP handler for the updates, what about the list in cappuccino
probably it's just me but I think that giving such an example would be helpful for quite a few people...
Martijn
· 1 year ago
This is really cool, I can see this getting pretty huge. Especially now Chrome and Firefox 3.1 are promising massive Javascript performance gains.. your timing couldn't be better!
One question, how is the source code protected? I mean, all the source code is downloaded to the clients machine ... For example, I could write a spider and download all the files that comprise your Slides application! Not that I will do that :-) But this is a problem I think ...
Mohit Aggarwal
· 1 year ago
Hi,
Congrats for this brilliant release. I really liked your mission statement and wish you good luck for future improvements. I am very excited about Cappuccino and know, if picked up; it will change the way web applications are programmed.
All Comments
http://hotruby.yukoba.jp/
- Adam
Thank you for all your hard work. I'm excited to dive head-first into this stuff.
We have the option of doing the preprocessing ahead of time one the server, which is typically done for frameworks and deployed applications.
We aren't compiling all the way down to some form of bytecode, but rather preprocessing at a higher level to turn Objective-J constructs into standard JavaScript constructs. For example, the message send operator [object message] gets turned into a JavaScript function call to objj_msgSend()
As far as the language goes, right now we're mostly sticking with the features Objective-C has. Objective-J is already fairly close to Objective-C 1.0, and has some of the features of 2.0 (like, uh, garbage collection, which we get for free from JavaScript, of course)
We'd love to hear what other people would like to see, and of course we'd love to get improvements from you guys too.
That's the basic idea (technically Cocoa, GNUstep, Cocotron and Cappuccino are implementations of OpenSTEP). Granted some things translate to the web better than others, so you have to keep that in mind.
Now, here's the thing... does this implement NIB files, and if so, can we build them in XCode? If not, is there going to be some kind of tool like Interface Builder to "draw" the applications so that we can focus on the logic?
Even better--are there any plans to implement something like CoreData so that we can REALLY just focus on the logic?
That's a fine how-do-you-do, I know, after delivering this wonderful product. I'm just thinking how easy it is to start writing useful programs using XCode... and how amazing it could be if the web could do that.
Why are you translating to _objj_msgSend() instead of directly to javascript? Wouldn't the js engines have a hard time optimizing the code for what it is? I understand why you would use msgSend in C, but js already has this.
the LGPL gives you the same concrete right than MIT to use the final product (cappucino) with your proprietary products.
You just can't appropriate yourself cappucino, modifying it and release it again AS a proprietary product. (you can't do "cappucino++ the proprietary version so much better")
but you can use it besides your commercial proprietary web applications with no problems. As you can use a LGPL cocoa frameworks inside a proprietary software without breaking the LGPL (or your own eula, because the LGPL authorize you to do that).
and lgpl is lawyer knowledge
webkit is lgpl, did it stopped nokia ? no. everything is fine, no need to worry. the licence is used and known as much than MIT or BSD.
Great job!!!
thanks in advance, 280 Slides is brilliant and it's exciting to learn the framework you used to develop it.
First of all, it did include classical inheritance (but media support and webcam access are "browser glue" issues outside the scope of the language spec). And most developers I talked to decried the introduction of classes, fearing that JavaScript was mutating into Java. Some voices — most notably Doug Crockford of Yahoo! and Dustin Diaz of Google — wanted an ES3.1 with incremental improvements (such as the "let" keyword you dislike) and bug fixes.
I will agree that ES4 was guilty of biting off more than it could chew, but I think it was going in the right direction to begin with. I'll further agree that we could use richer APIs from the browser environment, but that's to be addressed by HTML5 and the WebIDL initiative. HTML5 itself is a petri dish for the "add, then standardize" model of XMLHttpRequest and the CANVAS tag.
This only proves, though, that developers have varied gripes about their tools and will come up with varied solutions. Glad to see Cappuccino is officially out; I'll be sure to take a closer look this weekend.
This is something that everyone developing JavaScript for the web faces. There's really no panacea, but most people have resorted to minification and obfuscation to offer a little defense. While I'm not sure its strictly necessary, I would love to see some of these existing tools adapted to work with Objective-J.
That doesn't make any sense. Chrome needs JavaScript source to run just as any other browser does. It can't run compiled JavaScript.
Now, if Obj-J could be translated to ActionScript, then you'd have some sort of bytecode running in Flash.
nice things!
I'm just playing arround. And now I wanna make some "server calls". I tried this:
var aRequest = [CPURLRequest requestWithURL:"http://foo.bar.com/?ajax=givemesomejson"];
var connection = [CPURLConnection connectionWithRequest: aRequest delegate: self];
[connection start];
I implemented the delegates and the didFailWithError one is triggered.
Now I see that i have to pass a CPURL object to [CPURLRequest requestWithURL:].
But I can't find any documentation about to make a propper CPURL-object, nor I find something in the source (as far as iI understand it ;-)
Of course, XMLHTTPRequests must follow the same origin policy -- are you making a request to your same domain? Have you examined what the error passed to didFailWithError: is? May help debug the problem. Try hitting us up in our irc channel irc.freenode.net#cappuccino
e.g. reading and editing a SQL table
-> generate the XML file on the server and write a PHP handler for the updates, what about the list in cappuccino
probably it's just me but I think that giving such an example would be helpful for quite a few people...
one comment about your dictionary implementation:
http://openspecies.blogspot.com/2008/08/collect...
use Json to serialize and unserialize your plist
One question, how is the source code protected? I mean, all the source code is downloaded to the clients machine ... For example, I could write a spider and download all the files that comprise your Slides application! Not that I will do that :-) But this is a problem I think ...
Congrats for this brilliant release. I really liked your mission statement and wish you good luck for future improvements. I am very excited about Cappuccino and know, if picked up; it will change the way web applications are programmed.