Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Why Objective-J, Cappuccino and SproutCore are completely changing the web app industry (carsonified.com)
45 points by rob on June 25, 2008 | hide | past | favorite | 34 comments


Because Apple's dev tools have always had such a huge impact on the software development industry, and web-based variants of those tools will obviously completely change the industry?

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.


Apple is not that important. Seriously.

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.


True, but as SwellJoe said, they are not that important, particularly in the space in which this topic resides. Their contributions regarding UI and design have definitely been impressive, but we're talking about dev tools here. The mass adoption of iPods and MacBooks hasn't yet resulted in an equivalent increase in Objective-C, and I would think that it would do so even less with web technologies.


How many Objective-C books were on the shelf at barnes and noble before apple used it? Now there is always one or two and I expect that to grow with iphone uptake.


Two whole books? Why, that's as much as .1 times the number of Java, Python, Perl, Ruby, JavaScript, or even Lisp books on the shelf at your average bookstore! Get ready world, here comes the Apple development juggernaut!

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).


Cocoa was designed from the ground up to build GUI applications. Java certainly can't claim that. Cocoa was designed 20 years ago at NeXT, and in all that time, it has barely changed. Interface Builder is an incredibly powerful tool.

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.


To quote myself, "unless your problem set happens to closely happens to overlap very closely to what it was designed for". If the GUI is the majority of your problem, then perhaps it's a great tool (I'd be hesitant to say it's the best tool, as I found it to be less pleasant to work with than, say, Python with one of its many GUI toolkits).

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.)


WebObjects was way too far ahead of its time. You're absolutely right that so far Apple has contributed very little to the web app space. We'll have to see what happens in the future.


Your comment is spot on, except the first paragraph. Apple's dev tools may not be used by the majority of developers, but they have influenced the industry.

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.


I guess my comment seemed, somehow, to be praising Java. Java is a setting sun, and becomes increasingly irrelevant in web apps by the day. The JVM, on the other hand, might turn out to be very relevant, due to the increasing number and quality of dynamic languages that run on the JVM. And the JVM is not something that can be claimed to have lineage from Objective C (since ObjC has no VM).

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.


You said: "[b]ecause Apple's dev tools have always had such a huge impact on the software development industry".

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.


"Objective-J and SproutCore change all that. They allow you to create true desktop-like apps right inside the browser. "

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.


> 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.


The problem is that even though Java GUIs tend to suck, web app guis suck more. I'm probably going to get a fair bit of hate from this, but seriously, web apps are a pain.

    - 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)
While web-app style development is going to get better, I somehow hope we could get to the "write your UI in a GUI description language, develop your logic separately, talking to a network server" stage without being stuck with compatibility baggage resulting from needing to be compatible with the browser.

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]


So! I agree with you about your limitations, and agree that they suck. Where we disagree is on the valuation of those limitations.

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.


Declarative UI idea is here: http://code.google.com/p/google-web-toolkit-incubator/wiki/D...

Whether you like GWT or not (cause it uses Java) is another discussion.


they can suck. The best example of one that doesn't suck (for me) is the facebook image uploader.


I was thinking a lot like this, but recently I've changed my opinion. Just to contradict your 'only web devs like it', I'll mention that most of my work is done in Obj-C and Cocoa.

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.


"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."

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.


I consistently see posts like this touting 'new web-app frameworks' and such, and always find a few important concepts about web apps mysteriously unmentioned:

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!


I think you misunderstood the article. Video is not king - it's important, but it has it's place. HN wouldn't be better if all comments were videos.

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.


I do know little about the development process, but that wasn't the point of my comment. I think it's perfectly acceptable to discuss things that justify general points without having in-depth knowledge about the specifics. Nor was my point that video is necessary for every web app. These are points that, when taken as a whole, explain why I think the new frameworks are not a revolution in web app development.

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.


Well, the first thing is that until Objective-J and Cappuccino are released they won't change the industry in any way, and then we will see.

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?


I don't really think web apps have to look like desktop apps. But I think any such discussion also required a bit of consideration of what counts as a web application, and what is just a web site.

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?


>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.


I recommend listening to Ajaxian's podcast with SproutCore's creator

http://ajaxian.com/archives/audible-ajax-episode-27-sproutco...

it's good (though technical) listen.


When do leaky abstractions become Niagra Falls?


Indeed, I completely abandonned the idea of abstracting HTML/CSS/Javascript away completely by building a higher-level language on top. The problem with trying to do that is that you have an unsolvable Ease-of-Use VS Completeness problem. If you want your code to be easier to write you'll have to shun some features (ex: html attributes) and that will come to bite you in the ass later. But if you support everything HTML does then you end up with... HTML!


Anybody played with SproutCore yet? First thoughts? Impressions?


tried SproutCore... doesn't work on Opera so it's no use for my needs.


Took a peek at SproutCore and is it just me but it's slow as molasses. Using FF2 on Ubuntu...another thing I want to raise is it's over reliance on Ruby to install the damn thing. Why can't it be like jQuery and other js libs that you just drop into your web directory and call em from the page. How is this different from jQueryUI?


Anyone knows how is this different from Google Web Toolkit?


It's quite different. In GWT, you write your front end in the Java programming language and GWT compiles your source into highly optimized JavaScript. GWT's goal is to abstract away JS/DHTML development.

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.


GWT compiles to optimized+slimmest JS.

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).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: