5 ms·

Cappuccino’s FlickrDemo in 45 lines of jQuery

61 points by nickb 18y ago

natrius 18y ago
The Cappuccino version pegs my processor when I resize the images, which makes it jerky. The jQuery version resizes the images smoothly. Might want to look into that.
- zitterbewegung 18y ago
  It seems like the cappuccino version is slower to load compared to the jQuery version
- boucher 18y ago
  the jquery version doesn't live resize images, which the cappuccino version does. that's the difference.
  - Deadsunrise 18y ago
    He fixed that and now it resizes them live much faster than the cappucino version.
    - boucher 18y ago
      It's also resizing 1/3 of the images that the Cappuccino one is.
subwindow 18y ago
The Cappucino version appears to be about 400 lines of Javascript. So the jQuery one is 1/8th the size. Although I doubt the Cappucino version was written with line count in mind.
- boucher 18y ago
  It wasn't. But, it also contains 0 lines of HTML and 0 lines of CSS, while the jQuery demo has about 200 lines of CSS on top of its 50 lines of jQuery.
  - maximilian 18y ago
    I was going to say that if you're going to compare lines of apples to lines of oranges, you should at least include all the lines of apples that you wrote.
  - bootload 18y ago
    "... But, it also contains 0 lines of HTML and 0 lines of CSS, while the jQuery demo has about 200 lines of CSS on top of its 50 lines of jQuery ..." There are a lot of advantages of having this layering (usability, degradable functionality). The biggest problem I see is network latency and rendering appears slower while HTML loads progressively. What are the pro arguments in favour of removing this layer? The biggest (pro) argument I can think of is reliability in construction, cost & development speed. Less to worry about reliably piecing together sites with css/html.
    - tlrobinson 18y ago
      "The biggest problem I see is network latency and rendering appears slower while HTML loads progressively." This isn't so much of a problem for the types of applications Cappuccino is intended for: long running applications, rather than transient web pages. In fact, in some cases 280 Slides launches faster than PowerPoint or Keynote. Uncached I often see load times of about 3 seconds. Cached is about half that.
      - bootload 18y ago
        "... This isn't so much of a problem for the types of applications Cappuccino is intended for: long running applications, rather than transient web pages. ..." Good point I totally missed this.
deleted 18y ago
[deleted]
andreyf 18y ago
You can also write shorter programs in assembler than the compiled version of what someone writes in C. The point of Cappuccino (and C) is to manage complexity. Try writing 280slides in jQuery to see why complexity can be hard to manage.
- nir 18y ago
  For most developers, switching from a Javascript/CSS/HTML based model to a Cocoa/Objective-C one seems to significantly increase complexity...
  - deleted 18y ago
    [deleted]
  - drm237 18y ago
    You forgot the operative word "web"....web developers. For existing apple developers, this is solid gold.
- KirinDave 18y ago
  I'm interested in Cappuccino and I'm very appreciative of Apple's UI kit. I just don't think your assertion is a slam-dunk. HTML is remarkably good at describing layouts, and HTML+js is remarkably good at making very complex UIs that would take hundreds of lines of code to replicate, even in Cocoa.
- trapper 18y ago
  It seems like a pretty simple application - I don't imagine this would be difficult to write in js/jquery, as is evidenced by all the competitors doing exactly that.
- BrandonM 18y ago
  I don't think this comparison is accurate. Assembler is quite rigid (as is C), and the fact that C is more capable of abstraction than assembler is apparent. Adding abstraction capabilities to a language is always a win. That said, once you get to a certain point, the need for further abstraction disappears. Obviously, Lisp-like languages are the epitome of what I'm getting at: as soon as you have powerful macros, you can make the programming for any application trivial by defining a high-level base for it. Domain-specific languages, while typically not as powerful, are also hard to beat, since it doesn't get much easier than, "Put an image with these dimensions <here>." My point is that jQuery is a powerful enough language (having great abstraction capabilities even if it falls short of Lisp) and HTML and CSS are great DSLs. The combination of the 3 are simply good enough to make defining an entirely new approach a game of diminishing returns. Of course writing C is more productive than writing assembler. Is writing Cappuccino easier than using jQuery/HTML/CSS? This submission raises the possibility that it is not.
volida 18y ago
obviously cappuccino re-invented the wheel
- pmorici 18y ago
  But since this was their first wheel it was probably a worth while experience for them.
- unalone 18y ago
  The results will probably work for some people better than for others. If 280 North can make good things with it, then it was worth it.
morbidkk 18y ago
I feel flickr demo is not at all appropriate example for the cappucino. Further I see the trend more and more web development is shifting to model of desktop application development; as most good programmers can keep whole thing in head while designing complex web application. jquery is sweet and fits the bill all the time. Examples for the trend are 1. GWT 2. Apache Wicket 3. Cappuccino
maxklein 18y ago
Cappuccino can win if it does just one thing: Make an IDE with a blank page and a bunch of "tools" on a toolbar. One can drag a tool to the IDE, double click it and type alert('hello world'). I remember when I first did that using VB5. How exciting that moment was when the dialog displayed. Make the start very easy. What the web needs is a gui builder.
- pistoriusp 18y ago
  I'm going to have to disagree with you, I'm sure one of the WYSIWYG companies will try to tackle this (Dreamweaver already has some JS routines for certain things), but the web will never _need_ a GUI builder.
  - maxklein 18y ago
    The C programmers said the same thing...
tlrobinson 18y ago
I'm one of the Cappuccino developers. While this is neat, it's not particularly surprising, and it misses "the big picture", not unlike the sort of "MapReduce implemented in 10 lines of Ruby!" posts we see so often. It actually highlights several of the reasons we set out to do Cappuccino in the first place (some of which might be offensive to web developers): 1. This is minor, but the speed comparison is a little unfair, since the original has 3 times as many photos to scale. Yes, Objective-J method calls have a little bit of overhead, but in profiling a real world application (280 Slides), the message dispatch overhead is not a bottleneck (something like 1%). 2. It's 45 lines of JavaScript... plus several hundred lines of CSS. With Cappuccino you don't have to write CSS, ever. Some may see this as a disadvantage, but we don't. No more fiddling with CSS hacks to get it to look right in all the major browsers, which brings me to my next point. 3. It doesn't work correctly in at least Firefox 2 (OS X) and IE. Yes, this could be fixed, but it's another thing you (theoretically, and usually practically) don't need to worry about when developing in Cappuccino. 4. Cappuccino is designed to scale. The FlickrDemo is a small demo which is just that, a demo. It's definitely on the small side of the types of applications Cappuccino is good for. I'm not bashing jQuery, but I'm honestly curious if anyone can point me to an application written in jQuery approaching the complexity of 280 Slides.
- deleted 18y ago
  [deleted]

61 points by nickb 18y ago

The Cappuccino version pegs my processor when I resize the images, which makes it jerky. The jQuery version resizes the images smoothly. Might want to look into that.

zitterbewegung 18y ago
It seems like the cappuccino version is slower to load compared to the jQuery version
boucher 18y ago
the jquery version doesn't live resize images, which the cappuccino version does. that's the difference.
- Deadsunrise 18y ago
  He fixed that and now it resizes them live much faster than the cappucino version.
  - boucher 18y ago
    It's also resizing 1/3 of the images that the Cappuccino one is.

subwindow 18y ago

The Cappucino version appears to be about 400 lines of Javascript. So the jQuery one is 1/8th the size. Although I doubt the Cappucino version was written with line count in mind.

boucher 18y ago
It wasn't. But, it also contains 0 lines of HTML and 0 lines of CSS, while the jQuery demo has about 200 lines of CSS on top of its 50 lines of jQuery.
- maximilian 18y ago
  I was going to say that if you're going to compare lines of apples to lines of oranges, you should at least include all the lines of apples that you wrote.
- bootload 18y ago
  "... But, it also contains 0 lines of HTML and 0 lines of CSS, while the jQuery demo has about 200 lines of CSS on top of its 50 lines of jQuery ..." There are a lot of advantages of having this layering (usability, degradable functionality). The biggest problem I see is network latency and rendering appears slower while HTML loads progressively. What are the pro arguments in favour of removing this layer? The biggest (pro) argument I can think of is reliability in construction, cost & development speed. Less to worry about reliably piecing together sites with css/html.
  - tlrobinson 18y ago
    "The biggest problem I see is network latency and rendering appears slower while HTML loads progressively." This isn't so much of a problem for the types of applications Cappuccino is intended for: long running applications, rather than transient web pages. In fact, in some cases 280 Slides launches faster than PowerPoint or Keynote. Uncached I often see load times of about 3 seconds. Cached is about half that.
    - bootload 18y ago
      "... This isn't so much of a problem for the types of applications Cappuccino is intended for: long running applications, rather than transient web pages. ..." Good point I totally missed this.

deleted 18y ago

[deleted]

andreyf 18y ago

You can also write shorter programs in assembler than the compiled version of what someone writes in C. The point of Cappuccino (and C) is to manage complexity. Try writing 280slides in jQuery to see why complexity can be hard to manage.

nir 18y ago
For most developers, switching from a Javascript/CSS/HTML based model to a Cocoa/Objective-C one seems to significantly increase complexity...
- deleted 18y ago
  [deleted]
- drm237 18y ago
  You forgot the operative word "web"....web developers. For existing apple developers, this is solid gold.
KirinDave 18y ago
I'm interested in Cappuccino and I'm very appreciative of Apple's UI kit. I just don't think your assertion is a slam-dunk. HTML is remarkably good at describing layouts, and HTML+js is remarkably good at making very complex UIs that would take hundreds of lines of code to replicate, even in Cocoa.
trapper 18y ago
It seems like a pretty simple application - I don't imagine this would be difficult to write in js/jquery, as is evidenced by all the competitors doing exactly that.
BrandonM 18y ago
I don't think this comparison is accurate. Assembler is quite rigid (as is C), and the fact that C is more capable of abstraction than assembler is apparent. Adding abstraction capabilities to a language is always a win. That said, once you get to a certain point, the need for further abstraction disappears. Obviously, Lisp-like languages are the epitome of what I'm getting at: as soon as you have powerful macros, you can make the programming for any application trivial by defining a high-level base for it. Domain-specific languages, while typically not as powerful, are also hard to beat, since it doesn't get much easier than, "Put an image with these dimensions <here>." My point is that jQuery is a powerful enough language (having great abstraction capabilities even if it falls short of Lisp) and HTML and CSS are great DSLs. The combination of the 3 are simply good enough to make defining an entirely new approach a game of diminishing returns. Of course writing C is more productive than writing assembler. Is writing Cappuccino easier than using jQuery/HTML/CSS? This submission raises the possibility that it is not.

volida 18y ago

obviously cappuccino re-invented the wheel

pmorici 18y ago
But since this was their first wheel it was probably a worth while experience for them.
unalone 18y ago
The results will probably work for some people better than for others. If 280 North can make good things with it, then it was worth it.

morbidkk 18y ago

I feel flickr demo is not at all appropriate example for the cappucino. Further I see the trend more and more web development is shifting to model of desktop application development; as most good programmers can keep whole thing in head while designing complex web application. jquery is sweet and fits the bill all the time. Examples for the trend are 1. GWT 2. Apache Wicket 3. Cappuccino

maxklein 18y ago

Cappuccino can win if it does just one thing: Make an IDE with a blank page and a bunch of "tools" on a toolbar. One can drag a tool to the IDE, double click it and type alert('hello world'). I remember when I first did that using VB5. How exciting that moment was when the dialog displayed. Make the start very easy. What the web needs is a gui builder.

pistoriusp 18y ago
I'm going to have to disagree with you, I'm sure one of the WYSIWYG companies will try to tackle this (Dreamweaver already has some JS routines for certain things), but the web will never _need_ a GUI builder.
- maxklein 18y ago
  The C programmers said the same thing...

tlrobinson 18y ago

I'm one of the Cappuccino developers. While this is neat, it's not particularly surprising, and it misses "the big picture", not unlike the sort of "MapReduce implemented in 10 lines of Ruby!" posts we see so often. It actually highlights several of the reasons we set out to do Cappuccino in the first place (some of which might be offensive to web developers): 1. This is minor, but the speed comparison is a little unfair, since the original has 3 times as many photos to scale. Yes, Objective-J method calls have a little bit of overhead, but in profiling a real world application (280 Slides), the message dispatch overhead is not a bottleneck (something like 1%). 2. It's 45 lines of JavaScript... plus several hundred lines of CSS. With Cappuccino you don't have to write CSS, ever. Some may see this as a disadvantage, but we don't. No more fiddling with CSS hacks to get it to look right in all the major browsers, which brings me to my next point. 3. It doesn't work correctly in at least Firefox 2 (OS X) and IE. Yes, this could be fixed, but it's another thing you (theoretically, and usually practically) don't need to worry about when developing in Cappuccino. 4. Cappuccino is designed to scale. The FlickrDemo is a small demo which is just that, a demo. It's definitely on the small side of the types of applications Cappuccino is good for. I'm not bashing jQuery, but I'm honestly curious if anyone can point me to an application written in jQuery approaching the complexity of 280 Slides.

deleted 18y ago
[deleted]