5 ms·

Why Objective-J, Cappuccino and SproutCore are completely changing the web app industry

45 points by rob 18y ago

sant0sk1 18y ago
Anybody played with SproutCore yet? First thoughts? Impressions?
- ncubed 18y ago
  tried SproutCore... doesn't work on Opera so it's no use for my needs.
  - jamongkad 18y ago
    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?
jamesbritt 18y ago
"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.
- llimllib 18y ago
  > 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.
  - michaelneale 18y ago
    they can suck. The best example of one that doesn't suck (for me) is the facebook image uploader.
  - orib 18y ago
    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]
    - hello_moto 18y ago
      Declarative UI idea is here: http://code.google.com/p/google-web-toolkit-incubator/wiki/DeclarativeUi http://code.google.com/p/google-web-toolkit-incubator/wiki/D... Whether you like GWT or not (cause it uses Java) is another discussion.
    - llimllib 18y ago
- warwick 18y ago
  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.
  - jamesbritt 18y ago
    "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.
bporterfield 18y ago
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-flash-killer-sproutcore/ 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!
- andreyf 18y ago
  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.
arn 18y ago
I recommend listening to Ajaxian's podcast with SproutCore's creator http://ajaxian.com/archives/audible-ajax-episode-27-sproutcore-with-charles-jolley http://ajaxian.com/archives/audible-ajax-episode-27-sproutco... it's good (though technical) listen.
DenisM 18y ago
Anyone knows how is this different from Google Web Toolkit?
- hello_moto 18y ago
  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).
- mpc 18y ago
  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.
bprater 18y ago
When do leaky abstractions become Niagra Falls?
- Hexstream 18y ago
  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!
SwellJoe 18y ago
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.
- mattrepl 18y ago
  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 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.
  - SwellJoe 18y ago
    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.
edu 18y ago
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 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?
- lg 18y ago
  >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.
- boucher 18y ago
  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?

45 points by rob 18y ago

sant0sk1 18y ago

Anybody played with SproutCore yet? First thoughts? Impressions?

ncubed 18y ago
tried SproutCore... doesn't work on Opera so it's no use for my needs.
- jamongkad 18y ago
  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?

jamesbritt 18y ago

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

llimllib 18y ago
> 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.
- michaelneale 18y ago
  they can suck. The best example of one that doesn't suck (for me) is the facebook image uploader.
- orib 18y ago
  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]
  - hello_moto 18y ago
    Declarative UI idea is here: http://code.google.com/p/google-web-toolkit-incubator/wiki/DeclarativeUi http://code.google.com/p/google-web-toolkit-incubator/wiki/D... Whether you like GWT or not (cause it uses Java) is another discussion.
  - llimllib 18y ago
warwick 18y ago
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.
- jamesbritt 18y ago
  "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.

bporterfield 18y ago

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-flash-killer-sproutcore/ 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!

andreyf 18y ago
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.

arn 18y ago

I recommend listening to Ajaxian's podcast with SproutCore's creator http://ajaxian.com/archives/audible-ajax-episode-27-sproutcore-with-charles-jolley http://ajaxian.com/archives/audible-ajax-episode-27-sproutco... it's good (though technical) listen.

DenisM 18y ago

Anyone knows how is this different from Google Web Toolkit?

hello_moto 18y ago
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).
mpc 18y ago
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.

bprater 18y ago

When do leaky abstractions become Niagra Falls?

Hexstream 18y ago
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!

SwellJoe 18y ago

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.

mattrepl 18y ago
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 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.
- SwellJoe 18y ago
  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.

edu 18y ago

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

lg 18y ago
>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.
boucher 18y ago
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?