Comment by tmcw | Hacker News Reader

Comment by tmcw | Hacker News Reader

Yes, but this is missing the reasons why people aren't psyched about native code and are psyched about javascript.

There are inspiring stories of people reusing modular bits of javascript that others write. Look at npm, and github. This doesn't happen on anywhere near the same level with cocoa, due to the culture of closed-by-default, the near-zilch focus on stuff like cocoapods, and the fact that most people are making 'products' and don't like to credit the giants they're standing on.

This also uses, but doesn't make or properly explain, what it means by 'better'. Javascript is worse for... the desktop? Notification based apps? This doesn't ring true, and isn't backed up by facts or citations in this article.

TileMill ( http://mapbox.com/tilemill/ ) is nodejs wrapped by incredibly minimal native windows (basically just chrome & an embedded browser) on three OSes. Should we have built three separate UIs, in cocoa, windows apis, and gtk? Would that have been 'better'? No.

Now, I'm not trying to incite a native vs. web flame war here, but I believe that building separate native UI layers would have actually been much better. I hope I can provide some constructive criticism on the native app for the Mac:

The app, as it stands, does not behave like any of the others on my screen. This greatly increases the startup cost for me, since it doesn't follow the idioms I've already learned (and which I'm concurrently employing in these other apps).

For instance, the code editor doesn't behave like any other text editor on my screen (including the Xcode and TextMate source editors open alongside): Ctrl+Arrow doesn't navigate; double-click-and-drag doesn't select by word; my services are not available in the contextual menu; etc.

The keyboard shortcut for "change tab" that works in all the other tabbed windows on my screen does not work in this interface. The same goes for zooming shortcuts, "find" within the source editor, etc.

Then there are more fundamental disconnects: there's a "save" button in the interface, for example. That's an extremely rare thing to see in a Mac app. In fact, as of Lion, the user should never have to explicitly save.

Now, of course, building a native UI layer (in terms of design, not just ABI) would be a great deal of work. You could reasonably argue that it wouldn't be worth that work, but I'd just like to point out that it would indeed provide a much better experience.

Thanks for the notes!

I've filed one issue for a keyboard shortcut for change tab: https://github.com/mapbox/tilemill/issues/1380 and there's already one for find functionality: https://github.com/mapbox/tilemill/issues/968 .

Lion-esque save-constantly behavior would be a bug at this point. Map rendering would need to be instant and isn't.

Tying these changes to 'a native UI' though, doesn't make a lot of sense: none of these changes are impossible, or even more difficult, because the code is in javascript rather than cocoa.

It's true: you could fix these specific bugs with JavaScript (though I don't know if you could ever get Services working!) But you'd get a huge amount of standard behavior if your code editor were based on Cocoa's text system. As it stands, you'll always be playing catch-up as AppKit changes the behavior of Mac OS X's text views from release to release (and as the rest of the apps on the system move with these changes "for free").

Reply on news.ycombinator.com