Why Objective-J, Cappuccino and SproutCore are completely changing the web app industry
carsonified.com
carsonified.com
Apple is not that important. Seriously. They make very pretty products. But they aren't shaping the developer landscape, outside of a few segments of the industry. I went to YAPC::NA a week ago...350-ish people, 10-15% Mac users. I went to a Sun-sponsored, Open Source focused event a few months back...~1200 people, 15% Mac users, tops. Even at Startup School (where folks like to talk a lot about "wow, look at all the Macs!"), 800-1000 people, 30-40% Mac users.
It's really easy to look around at all of your friends and say, "Wow, everybody is using this, and thinks it's awesome! It's really going to take over the world!" But, your friends are not a representative sample of the development world.
So, Objective-J is a cool idea, and if it helps 280North (who are smart, nice, cool guys doing great work) get their product out the door faster, I'm excited about it. But, I've also looked at Objective-C and Apple's development environment, and came away far less than impressed. While it may be superior to working in C++ (or plain ol' C), it's probably not even better than Java for getting things done (and that's not all that good), unless your problem set happens to overlap very closely to what it was designed for.
There are already several revolutionary JavaScript libraries and toolkits out there (jQuery, YUI, ExtJS, Dojo, Mochi, etc.), and they're all making an impact...but let's keep the hyperbole under control.
One such example is Obj-C and NeXTStep's influence on Java (http://cs.gmu.edu/~sean/stuff/java-objc.html). Of course it was really NeXT's influence, but it was still Steve Jobs and company behind the scenes.
Anyway, I just think the hyperbole is way out of place. Apple is not going to dramatically alter the web app development landscape. Some people (mostly people who've built Apple desktop apps) will find Objective-J a more comfortable way to build web apps, and that's wonderful. But it's not a world-shaking thing.
I simply provided a single example that refuted your conjecture that Apple had no influence in the development world. It's irrelevant what either one of us thinks of Java or its future; Java was a significant, mainstream development tool and it was impacted by Apple development technologies.
Cocoa has also enabled very small teams at Apple (and outside of Apple) to build really world class consumer products in incredibly short time frames, something you don't see in the Java world. GUI's are definitely Java's weakest point.
If you like it, and enjoy it, that's wonderful. I merely think the hyperbole in the OP title was pointless. Apple is not reshaping the web app developer landscape. (WebObjects didn't exactly set the world on fire, for example.)
Even with a mere 10% market share, Apple is so incredibly important. Since 2000, they have continually set the standard in industrial design across the electronics industry (and even beyond it). Beyond that, they've also completely changed the music industry. They went from zero music presence to 80% market share in music players, and the number one music store (not just online music store). The iPhone is already redefining the cell phone industry.
Sure, they may be small, and maybe they'll never get bigger, but you can't for a second claim they aren't important.
My comment was merely to point out the silliness of hyperbole. I'm not picking on Apple, or its fanboys. You like Apple products, and development tools that emulate Apple products, and that's wonderful for you. But, it doesn't alter the fact that Apple has historically had little to no impact on the web development world (web design, they've had a huge impact on...actual code, not so much).
1) Video.
Video on the web is king. Streaming video. Live video. Video comments. Video video video. None of these javascript-based solutions have an inherent solution for incorporating video into your web app, and therefore will always need to be augmented with a video technology for web-apps that require video.
2) Cross-browser compatibility
We're getting closer with javascript compatibility, but not there yet. Yes, many of these frameworks claim to hide the issue, but what about developers that want to develop components for the framework? A virtual machine that is consistent across all browsers (well, supported browsers) makes development much cleaner.
3) Flash IS Open-source.
Flash may not be truly 'open-source', but rarely is there a mention that Adobe has released the specifications for the specifications for both the .swf file format and the actionscript virtual machine, and are accepting feedback on both.
4) Rapid Development Environments
I admit to knowing little about how people are developing these apps in these languages, but doubt that the IDE's contain the feature-rich capabilities required for complex RIAs - things like code hinting across libraries, a walk-through debugger, visual drag & drop component interface, etc etc.
---
I am in no way suggesting that these new technologies are not exciting or an improvement - I just think the hype around them (http://www.roughlydrafted.com/2008/06/14/cocoa-for-windows-f...) is somewhat unsubstantiated. They still have a long way to go. But it's great to see some new competition creeping in on the big guys - good for the consumer!
In general, you seem to have missed the point of this article - it isn't comparing RIA's and JS, it's comparing 'old' JS frameworks and new ones, and the new ones are making big progress to being desktop apps.
I admit to knowing little about how people are developing these apps...
I don't mean this personally, but then why are you talking about this? Can we all agree to talk about things that we know about? I think that heuristic will benefit this community most.
Web apps are dominated by Flash, and to a lesser extent, Silverlight, for a reason. The hype around these new frameworks just isn't justified. If the title was more to the effect of 'new frameworks are a good step forward in the javascript-based web-app approach' then I'd happily concede. The title says completely changing the web app industry!! The point of the article seems, to me, to be about how these new frameworks allow for simple web-app (aka RIA, more or less) development with more support from big players. My point is that this isn't as much of a game-changer as some people seem to think.
Why would I not prefer a true desktop app right on my desktop?
Using Java and JNLP I can get an app the can be auto-updated (as a Web app would be) but takes advantage of an arguably more robust and speedier language (Java, perhaps by way of JRuby or Scala or Jython) with true desktop features.
It seems that the "Build Apps in a Browser with JavaScript" pitch is mainly a win for Web developers who only know JavaScript. It isn't clear what the benefits are to the end user.
A UI that doesn't suck eggs comes to mind.
I use strong language to get a point across; Java UIs today feel to me like Motif UIs did in 2000.
- they have the browser's baggage. Address bar, back/forward buttons, etc
- They don't use native widgets... except for some places (form widgets)
- They're slow
- They can't integrate with other desktop apps (drag and drop, saving to local disk, heck, even loading from local disk sucks)
To be clear on what I mean -- Yes, currently developing and deploying desktop apps isn't fun. Who wants to write reams upon reams of code to pack widgets into containers, or whatever layout-method-du-jour your toolkit is using, when you can simply type some XML to describe your UI? Who wants to use a slow installer after a slow download to get an app installed? Web apps win here.
However, web apps -- by design -- are unable to integrate properly into a desktop. They're trapped in a browser, cut off from interaction with the rest of your UI, and if they weren't, it would be an insanely bad design decision.
On the flip side, with things like Glade, designing a desktop GUI is starting to hurt far far less. I think that pushing desktop app development frameworks towards being far more network aware, easily deployable, and faster to develop will lead to far, far better results than trying to make web apps not suck, while dragging the web browser legacy junk onto desktoplike web apps.
[edit - expand on ideas]
The benefits of web apps in consistency of interface elements, interoperability (hyperlinks!), customizability (greasemonkey!), toolset (FF, IE, Opera, Safari, Lynx, Emacs, mostly use whichever floats your boat), and portability (use the same app at work as you use at home) far outweigh the drawbacks.
Which is not to say that we should not attack those drawbacks, we should, but we should do it in a way that we maintain the benefits we've gotten from web applications.
Whether you like GWT or not (cause it uses Java) is another discussion.
Web apps have some inherent advantages. Being 'installed' by clicking on a link, which lowers the barrier to a user trying your app. Having data available everywhere. Autoupdating that doesn't involve a download and relaunch.
Traditionally I've been opposed to putting full apps on the web. I didn't think I could deliver as good of an interface with it, but seeing SC and 280North changed my mind.
I should mention that though I'm looking at porting one of my desktop products, I'm intending to maintain the desktop app and the port in parallel and give customers a choice if they want to download the desktop app.
Java Web Start gives you the first, and common networking libs give you the second.
For the third, something ina desktop app would need downloading and a restart, though, on the other hand, using a Web app means downloading something on almost every use; a desktop app is always there, so off-line use is likely more robust.
One thing I don't understand is why web apps have to look like desktop apps? Browser/net and desktop are completely different environments, each with their own characteristics. And trying to do a desktop-like web app brings two problems:
1. It fails in the uncanny valley: http://en.wikipedia.org/wiki/Uncanny_Valley.
2. They use a lot more JS than it's needed, and while this is not a problem on computers it is in mobile devices. Do you really want a web app suck all the battery of your iPhone, even when it's not necessary?
Do you really want a GUI sucking all the battery out of your iphone even when it's not necessary? Yes.
Objective-J and Cappuccino (and SproutCore) are really designed to build applications. Long running applications that exist in the context of the browser. By my definition, this is far from the realm of web pages, so why should they have to look like a web page?
Google's Presentation app is an apt tool for comparison. It was designed to look very much like the rest of Google's web pages. In my opinion, its not a very good design. Admittedly I'm biased, but the UI in 280 Slides is just light years ahead of Google Docs.
As far as using "more JS than needed", what makes it unnecessary? If it were really the case that you could build UIs like 280 Slides without using a pretty advanced JS framework, than why haven't people been doing it?
http://ajaxian.com/archives/audible-ajax-episode-27-sproutco...
it's good (though technical) listen.
It appears that obj-j's goal is to make JavaScript more like Objective-C and cappuccino's goal is to make it is easier to develop web UIs that look and work like OSX.
Obj-J doesn't. In fact, it does runtime translation. Speed-wise you can test 280 North Slide app yourself.
SproutCore is a JS framework that has the looks-n-feel of developing Rails (haven't tried it out, only saw the demo/tutorial).