32 ms·
WebAppKit - create web applications using Cocoa
- GrooveStomp 15y agoCool. Anything similar for *nix and Windows? I'm fairly certain you can embed WebKit in GTK - in fact, I think that's functionality exposed by the API. I'm not sure to what extent it's supported with other language bindings, though.
- mbreese 15y agoI'm fairly certain that this isn't related to WebKit at all... just similar names.
- GrooveStomp 15y agoNaturally, I didn't read enough and then commented something that makes little sense in context. Thanks mbreese!
- cpr 15y agoBoy, I really don't know. I've actually enjoyed using Objective-C and Cocoa when used for Mac OS/iOS development (the dynamicity of Smalltalk data structures with the control flow of C), but I don't think I'd ever voluntarily choose it outside that context. Too verbose, too fragile.
- mvzink 15y agoFragile? Compared to what? Not going to argue with verbose though, and I also wouldn't choose it for web apps.
- cpr 15y agoIt's C, for heaven's sake. ;) Compared to any dynamic / memory-safe language in history. Oh, I don't know--Perl, Python, Ruby, Javascript, Lisp, Haskell, oh, and Java, I s'pose.
- mvzink 15y agoI can't bring myself to think of C as being fragile. Fragile is exactly the word I use for Perl, Python, Ruby, and Javascript. Lisp and Haskell, and maybe Java, are the only ones on your list I would say are more robust than C or Objective-C. I guess it's a difference of opinion, or maybe just bad experiences with other people's code. Besides that, you mention dynamic-ness and memory-safety: these are exactly the two places where Objective-C is miles ahead of C! I don't even know what to say.
- stephth 15y agoObjective-c could be a good fit for web development, unlike c++ it's dynamic, unlike ruby it's fast, and it's runtime and libraries are solid (its verbosity is a downer). and I say could, because it's crippled by the fact that half of its strength - the full runtime and libraries - is proprietary, closed source and platform specific. It puzzles me that Apple cripples its adoption this way. Yes, I'm aware of CFLite, cocotron and GNUstep, I don't think any of these solve the problem.
- kenferry 15y agoWhat do you think is different about Mac OS/iOS context vs others that makes Cocoa's approach more or less appropriate?
- statictype 15y agoI'm not convinced that Cocoa and Objective-C are the best approach for anything. The only reason I use them is because they're what you have to use to make good apps on OSX/iOS. There are debates on both sides when it comes to things like ruby-vs-python-vs-node or rails/django/aspmvc and reasonable people can take opposing views on those. I don't see much of a case for Objective-C/Cocoa being a better language and platform than any of the others except for the fact that it's the only one we've got. (And yes, maybe I'm being unreasonable on this)
- kenferry 15y agoAny chance of being able to distill concrete reasons why other environments are better?
- statictype 15y agoThe verbosity of the Objective-C language (and related Cocoa libraries) and manual memory management are the biggest reasons. It's not a bad environment and has a certain weird elegance to it, but I would venture that very few people would use it if not for the fact that it's the defacto development environment for doing OSX/iOS development.
- chetan51 15y agoI'd love to see a good implementation of the opposite -- creating Cocoa apps using web technologies.
- mhd 15y agoLike Appcelerator's Titanium? [1] Doesn't exactly create very "classic" Cocoa apps, but considering the App Store, Lion etc, that seems to be the way that Mac Apps are going anyway, i.e. looking like you were born on the web or on an ipad won't hurt your sales that much, if at all. (Not too fond of that myself, but well…) Look at Wunderlist as one example[2]. [1]: http://www.appcelerator.com/products/titanium-desktop-application-development/ http://www.appcelerator.com/products/titanium-desktop-applic... [2]: http://www.6wunderkinder.com/wunderlist/ http://www.6wunderkinder.com/wunderlist/
- willyt 15y agoMacruby?
- okal 15y agoIsn't this what Cappuccino[1] already does with Objective-J? 1. http://cappuccino.org http://cappuccino.org
- zemariamm 15y agoNot really , Cappuccino focus consists in bringing the whole Cocoa/Objective-C style to front-end development (actually you can run Objective-J on the server too). On the other hand, WebAppKit goal seems to be using Objective-C in the backend
- okal 15y agoThanks for the clarification. Didn't read it as closely as I should have. >(actually you can run Objective-J on the server too) Node, I assume?
- chc 15y agoThere's an existing framework along the same lines called FrothKit: http://www.frothkit.org/ http://www.frothkit.org/ The difference seems to be that WebAppKit is new while FrothKit is more mature but not actively developed anymore.
- deleted 15y ago[deleted]
- SeoxyS 15y agoOhhhh, yes! This sounds awesome, I've been meaning to write something like this myself. Essentially, a node.js equivalent, but for Cocoa. Of course, I'm way too lazy to add that to my work-load, but I'm very glad somebody did. Now, if only I could use this in an Amazon EC2 environment. I guess with OS X Server supporting virtualization now with Lion, it might be a possibility?
- jonknee 15y agoHow is this similar to node.js? This looks just like a MVC framework that happens to be in Obj-C.
- SeoxyS 15y agoI'm thinking about the fact that neither JavaScript on V8, nor Cocoa are equipped with HTTP networking. So the framework supplies that part. A big part of node, when used for a web app, is that it supplies an HTTP server. Same with this.
- btrask 15y agoCocoa (and CoreFoundation) actually make it pretty trivial to write HTTP servers already. I was completely surprised by how painless it was when I did it recently. Not quite as easy as Node.js, but on the same order of magnitude, IMHO. (Edit) Here's an article that describes the basics: http://macdevcenter.com/pub/a/mac/2006/11/14/how-to-write-a-cocoa-web-server.html http://macdevcenter.com/pub/a/mac/2006/11/14/how-to-write-a-...
- SeoxyS 15y agoYeah, I've done that before. It's not too bad, but there's still a lot of boilerplate that could be made away with.
- ReneeKline 15y agoI paid $32.68 for a XBOX 360 and my mom got a 17 inch Toshiba laptop for $94.83 being delivered to our house tomorrow by FedEX. I will never again pay expensive retail prices at stores. I even sold a 46 inch HDTV to my boss for $650 and it only cost me $52.78 to get. Here is the website we using to get all this stuff, GrabCent.com
- pavlov 15y agoIsn't this basically what WebObjects did back in 1995? (WebObjects used to be written in Objective-C, but Apple switched it to Java sometime during the server-side Java boom in the late '90s.)
- SeoxyS 15y agoYes, that's essentially what WebObjects was. However, WebObjects today is a mess, and it's written in Java. Also, we have a ton of conventions today, with regards to MVC development, REST APIs, etc. that we did not have in '95. Which means that therefore WebObjects is not suited to modern web development. The only company still using WebObjects in production today is Apple.
- dxq 15y agoYour statement that Apple is the only company still using WO has no basis in fact. There is even an annual conference[1] for WO developers, in which Apple has zero involvement. [1] http://www.wocommunity.org/wowodc11/ http://www.wocommunity.org/wowodc11/
- SeoxyS 15y agoYou're right… let me rephrase. The only significant company.
- shinratdr 15y ago> The only company still using WebObjects in production today is Apple. What about Web Help Desk? http://www.webhelpdesk.com/ http://www.webhelpdesk.com/
- jad 15y agoGenuine question: what is the appeal here? I write iOS apps for a living, and appreciate what Objective-C and (especially) Cocoa have to offer, but why would anyone choose to use Objective-C when there are so many other great alternatives available? To consider just one example of the pain Objective-C developers like me have to deal with on a daily basis, why would I want to write: NSDictionary *d = [NSDictionary dictionaryWithObjectsAndKeys: [NSNumber numberWithInteger:1], @"foo", [NSNumber numberWithInteger:2], @"bar", nil]; when most other mainstream web programming languages allow me to write something like: d = { "foo" => 1, "bar" => 2 }
- msbarnett 15y agoRelative runtime speed or compatibility with an existing Objective-C code base that you want to easily call from your web app are two possibilities that spring to mind. This isn't to say that conciseness of expression isn't a useful attribute, but I don't think it's so utterly critical to web development that the any tool suited for the job must provide such things as concise dictionary syntax. You use the best tool for the situation, and I can at least conceive of situations in which I might care about the benefits that come with using Objective-C et al more than I care about how verbose dictionary initialization is.
- jad 15y ago> I can at least conceive of situations in which I might care about the benefits that come with using Objective-C et al than I care about how verbose dictionary initialization is. Fair enough. I'm interested to hear more about what these situations are. For what it's worth, my point isn't limited to dictionary initialization. That example, though, does represent a lot of what makes Objective-C painful for me. That list also includes its extreme verbosity; the need to box and unbox native types when storing them in containers (or passing them to performSelector: and friends, and other uses); the necessity of separating header and implementation files; requiring forward declarations of methods to avoid compiler warnings; simply adding an ivar as a property requires touching code in a minimum of 3 different locations, and potentially across 2 files (@property statement, @synthesize statement, call to release in dealloc (until ARC), and, pre-iOS 4.0, actually declaring the ivar in the class definition); and, of course, manual memory management, which includes worrying about fairly esoteric edge cases like retain cycles. None of these things are hard, including memory management. But it is code that has to be written, and more code means more bugs. In almost all other mainstream web languages, the computer takes care of these things for you, as it should. Tack onto all of that the fact that if you're running Objective-C/Cocoa as a web app, you're probably on your own in terms of finding solutions to problems from the community online -- at least compared to mainstream languages -- and it feels to me like it's hard to justify the tradeoff unless you have a very specific need.
- wallflower 15y agoLove it or hate it, CoreData came directly from WebObjects' Enterprise Objects framework. http://developer.apple.com/legacy/mac/library/documentation/WebObjects/Enterprise_Objects/EnterpriseObjects.pdf http://developer.apple.com/legacy/mac/library/documentation/...
- obtino 15y agoIf anyone's interested, an alternative to this is GNUstepWeb: http://en.wikipedia.org/wiki/GNUstepWeb http://en.wikipedia.org/wiki/GNUstepWeb
- jchrisa 15y agoThis looks like it will play nice with Mobile Couchbase.
- kluivers 15y agoWhile I do like the thought of using CoreData and code I've written for other apps on the web, the following sentence immediately made this thing much less interesting: "WebAppKit runs exclusively in garbage collection mode to minimize the memory management burden." I've never liked garbage collection, if you find memory management a burden, you're doing it wrong. And now that Apple introduced ARC even Apple recommends against using the GC.
- oemera 15y agoMy question would be: Can those web applications can only run on Safari with Mac OS X? If yes: Isn't this contrary to what a Browser wants to do? To Run Web Apps in any Browser. If it cross compiles down to html/js/css it's just fine but the Readme isn't giving much information.