If you haven’t seen it yet, you really should watch the demo of 280Atlas. It’s basically Interface Builder written for the browser. Just watch their demo and tell me that that doesn’t look like a great way to build webapps (and I do mean apps and not sites).

A lot of work goes into designing good software. 280North are taking the great design work put in on Apple’s developer tools and making it available to people building browser-based apps. They’ve saved themselves the work of inventing every little piece of the model, instead focusing on the work of making it work well in JavaScript.

6 Comments

These apps look really nice, feel nice, and seem like a good idea (Cocoa has evolved from many great minds who were solving the Interface problem and Objective-J is based on Cocoa). However, I’m still on the fence about the whole leaky abstraction thing here. What happens when there is a JavaScript error? Seems like you’re pretty much helpless — just report the bug and wait. But I don’t know, I haven’t used it myself.

Their point was that everything is an abstraction so why not use an abstraction? I disagree. jQuery is less of an abstraction than GWT, Pyjamas, or Objective-J. If there is a jQuery error you can more or less get a decent traceback (using Firebug) to pinpoint what is happening. Good luck getting a useful traceback with Objective-J or the other compiled languages. That said, Objective-J is a powerful, elegant language and a successful and ambitious product.

Oh, I should point out that Objective-J claims it is not compiled to JavaScript like GWT would be. But its syntax is not valid JavaScript. It says it is “interpreted in the client” not pre-compiled but that seems to yield the same problems of abstraction that the compiled languages yield if you ask me.

Objective-J is a strict superset of JavaScript. What this means is that any valid existing JavaScript code is valid Objective-J code as well. Objective-J isn’t compiled, it’s pre-interpreted dynamically in the browser. This means that web developers can continue to use the change/refresh development cycle they are used to, rather than adding a compilation step.

I’m not sure, though, what you mean when you say you’re worried about language abstractions. Every language is an abstraction on some technology beneath it, it’s the abstraction that makes the language powerful. By eliminating repetitive code, or making previously difficult problems trivial, you are able to do things faster and better. There’s nothing wrong with a good abstraction.

and I don’t understand how that is a strict subset of JavaScript since there are missing parenthesis.

As for the abstraction part, I do worry about abstraction, but as your article pointed out, we all use them and I’m no different. I just worry when things get too abstract because as a developer that puts you further away from the problem when code starts to fail.

Let’s say an error in a user’s code triggers an error somewhere in the low level of Objective-J internals. If you’re saying that the traceback in this scenario would be comparable to that of triggering an error in jQuery internals then I stand corrected. I was under the impression that you would get a more direct traceback from an abstraction layer like jQuery.