Cappuccino’s FlickrDemo in 45 lines of jQuery | Hacker News Reader

Cappuccino’s FlickrDemo in 45 lines of jQuery

brokendigits.com

61 pointsnickb27 comments

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.

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.

It seems like the cappuccino version is slower to load compared to the jQuery version

the jquery version doesn't live resize images, which the cappuccino version does. that's the difference.

He fixed that and now it resizes them live much faster than the cappucino version.

It's also resizing 1/3 of the images that the Cappuccino one is.

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.

For most developers, switching from a Javascript/CSS/HTML based model to a Cocoa/Objective-C one seems to significantly increase complexity...

You forgot the operative word "web"....web developers. For existing apple developers, this is solid gold.

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.

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.

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.

I don't think I could have said it better than BrandonM.

As a developer I'm wary of learning new platforms until I know that I am going to get returns on my new knowledge(skills). We all have limited time, and there are plenty of techniques or popular platforms I could be learning or improving on that I know will make me employable in more situations.

If HTML and CSS were supported correctly across all platforms, then they would indeed be great DSLs. But until inconsistencies in their interpretation are corrected, they're a pain in the web developer's neck.

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.

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.

The C programmers said the same thing...

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

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.

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.

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.

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

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

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

obviously cappuccino re-invented the wheel

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.

But since this was their first wheel it was probably a worth while experience for them.

Reply on news.ycombinator.com