Hacker News new | ask | show | jobs
by boucher 6128 days ago
A lot of good points. About debugging, I would strongly strongly disagree.

The Safari 4 / WebKit debugger is actually getting quite good. Add on top of that the profiler and support for native method names we added to WebKit, and you've got what I consider the best debugging environment in any browser.

Break on exception works well, and even though you are seeing post-processed code, it looks nearly identical to the original.

(The parse error problem is just a generic Safari problem, and Firefox reports much better context for that particular class of error, just something that's useful to know)

About this statement:

      Still has tons of stupid JS problems – implicit globals, type coercion everywhere (with JS primitives), slow as molasses.
There are plenty of globals, but they are intentional. If there are a few strays becoming global, they are bugs we'd be happy to fix. In user code, the global situation is actually slightly better than vanilla JS because we give any top level vars file level scope rather than global scope.

And finally:

      About a 10% performance hit on tight loops if you use Obj-J message sending in them.
That sounds off to me. You can't blindly trust the WebKit or Firebug profilers, because they are not time based, but rather call based, which disproportionately affects short methods.

But even if its true, if a 5-10% performance hit on a critical loop is important, there's nothing stopping you from grabbing the method implementation and calling it directly, completely negating any potential performance hit.

One line of code will grab and store a method implementation, then you can just call it directly in your code:

      var sel = @selector(aSelector:),
          impl = class_getMethodImplementation([object class], sel);

      for (var i=0; i<1000; i++)
            impl(self, sel, arg1, etc);
In general, on the scale of an entire application, the overhead of message sends is much less than 10%.
1 comments
tumult 6128 days ago
Most of my errors are syntax errors, not programming errors, and indeed they are annoying in WebKit/Safari/Chrome. Firefox will sometimes give me the line, sometimes it won't. The named methods and profiling do indeed work well (I wouldn't lump profiling under debugging though.)

There are plenty of globals, but they are intentional. If there are a few strays becoming global, they are bugs we'd be happy to fix. In user code, the global situation is actually slightly better than vanilla JS because we give any top level vars file level scope rather than global scope.

Yeah, I'm talking about my code, not yours :)

But even if its true, if a 5-10% performance hit on a critical loop is important, there's nothing stopping you from grabbing the method implementation and calling it directly, completely negating any potential performance hit.

Right, that's what I do, just like in Obj-C/C.

And I'm definitely not going to argue about the performance of Cappuccino as a whole. I find it to be the best performing browser GUI framework.

edit: I use the profiler in Chromium, if that matters. :]

link
boucher 6128 days ago
Great, glad to clear these things up. I definitely agree about the syntax error thing. We'll try to make it a priority to commit a fix to WebKit.
link