New Product From 280North: Atlas

by jasonlbaptiste • 17 years ago

192 73 17 years ago

hbien• 17 years ago

That's pretty amazing. It's like Interface Builder but for Cappuccino ... and as a web app.

I can't believe how awesome these guys are, I hope Apple acquires them and starts using their technology for MobileMe + iWork.

numair• 17 years ago

If you knew anything about what happened to WebObjects, you would be hoping that such a scenario never occurred.

mpc• 17 years ago

A summary of that would be great....

I know that Apple pushed WebObjects to the back burner when they acquired NeXT in the mid 90s but I'm not sure why it would be bad for them to buy 280 North today.

tlrobinson3• 17 years ago

We don't plan on creating a Java version of Cappuccino and killing off the Objective-J API any time soon ;)

dizm• 17 years ago

I believe some if not all of the guys working at 280 North are ex-Apple engineers.

ktom• 17 years ago

absolutely stunning!

swivelmaster2• 17 years ago

Mind blown.

fuelfive• 17 years ago

This is incredible, excellent work guys

joubert3• 17 years ago

Übercool. Can't wait to no longer have to build views in code.

Seems like there is a good text editor being used in Atlas, hopefully this will make its way into Cappuccino soon!!

mikeryan2• 17 years ago

I love what these guys are doing - I'm just not sold on the whole Objective-J thing.

kqr22• 17 years ago

Does anyone know of any large projects using Objective-J / Cappuccino besides 280North?

richcollins3• 17 years ago

Were currently using it:

http://stylous.com/

sant0sk1• 17 years ago

Somebody should write an equivalent which will create Rails views.

ph0rque• 17 years ago

I've been thinking about it... too many ideas as it is already, though.

gstar6• 17 years ago

Fantastic. RAD tools for the web haven't ever been done properly.

This could be huge.

The funny thing is, it actually looks quicker and easier than IB - probably because Objective-J is interpreted and runs in the browser, and it has the controllers in Atlas.

cpr3• 17 years ago

It's fascinating to watch the re-invention of the browser as a NeWS server (client in normal terminology) from nearly 20 years ago.

Postscript imaging model == HTML5 Canvas, Postscript == Javascript.

Hmm...

wmf• 17 years ago

But was NeWS a good idea? It seemed excessively complex to me, just like AJAX.

cpr3• 17 years ago

I didn't mean to imply it was a good idea, just that this model, like X Windows, has already been tried before (and found wanting?).

scotth• 17 years ago

What do you find to be complex about AJAX?

mcav• 17 years ago

Fascinating... though I now feel like an old assembly programmer saying things like "In my day, we wrote Javascript by hand, and it only consumed suchandsuch memory and was blazing fast... now you with your newfangled GUI builders..."

jacquesm2• 17 years ago

Borland cbuilder meets the web, very impressive.

releasedatez2• 17 years ago

can't seem to get on right now.

poub2• 17 years ago

You can watch the video there: http://www.viddler.com/explore/boucher/videos/1/

releasedatez2• 17 years ago

Thank you very much

cjoh• 17 years ago

This really is amazing. But it makes me nervous. I'm open to the idea, but just as I prefer using a text editor to write my HTML code rather than Dreamweaver, I'm concerned that this can take me too far away from my web app code.

Like any other tool, in order to use it effectively you have to master the tool just like you'd master a language. Hopefully what's under the hood here and the code it generates makes it easy to do that.

joubert3• 17 years ago

In order to build views with Cappuccino today, I'm doing it by hand (i.e. subclassing for example a CPView and constructing child visuals) - this means instancing elements such as CPTextField, CPButton, etc. and adding it to a view.

But being able to do it visually ala Interface Builder with similar semantics around delegates, subclassing, IBAction and Outlet concepts will rock - speeding up development time tremendously.

cschneid2• 17 years ago

Cappuccino doesn't use html as it's main language. HTML / CSS / Javascript are Cappuccino's assembly language. You write everything in their Obj-J language (which is a cross between Javascript & Obj-C. And apparently actually all legal javascript).

andreyf3• 17 years ago

Very nice, although the demo seems a bit overly-staged. My prediction: the quality of their debugger will make or break this company.

s3graham• 17 years ago

Very snazzy!

I don't know how y'all plan to make money, but don't get too caught up in dev tools! They're fun, and might be good marketing, but be sure they're actually saving time against making the thing that people with money actually want.

fauigerzigerk4• 17 years ago

These guys are awesome and I feel kind of bad to say this, but it's the perferction of a failed idea. I've been trying these kinds of GUI builders for almost 20 years, starting with VB and PowerBuilder, and I always ended up not actually using them.

The usual criticism is that they generate awful code, but that's not necessarily the case. The problem is really that these tools ask you to keep clicking on lots of little sliders and lines and bars and shapes and then click over there in that text box to enter a name and then select this or that from a list or menu, wait until that three pixel graphic changes its shape into a handle so you can drag that line over here, etc, and there's no way to automate this.

It's a matter of taste whether you like to do it that way when you create _one_ form, but once you create an application or two or three you have to abstract from the repeating patterns and you can't do that with the GUI builder.

GUI builders make you stay on the same level of abstraction forever because they don't have the equivalent of meta programming or even just plain procedural programming.

The reason why code built with GUI builders is so awful is not so much that they necessarily generate bad code. It's that developers who can put up with repeating the same clicks and drags on the same level of abstraction for years and years are in the wrong profession and create bad code regardless of the tools.

Programming is all about abstracting and automating stuff. The pinnacle of GUI builder based abstraction is what Microsoft calls "user controls". All they abstract is a bunch of widgets statically glued together on a panel. Great, but that's like 5% of what you want to do.

I'm afraid GUI builders are hopeless for any serious programming.

allertonm• 17 years ago

I agree with a lot of what you say here, and have had much the same experience, but there is one powerful counter-example in Apple's "Interface Builder". I get the impression that most Cocoa developers use it for at least some part of their code.

gstar6• 17 years ago

You've got some good points, but Interface Builder (and I imagine Atlas) departs fundamentally from VB and PowerBuilder in that the code doesn't live directly behind the GUI elements. Instead, it's connected by a series of inlets and outlets that are designed to allow for reusability and model-view-controller disconnect.

You can also define UI things in code in Cappuccino (as well as Obj-C).

IB is optional with Obj-C, and I imagine Atlas will be optional with Cappuccino.

ashleytowers2• 17 years ago

To be precise Interface Builder doesn't actually generate ANY code at all. You are manipulating in-memory objects and setting their properties. When you save your UI it's effectively just a serialized form of the objects you were playing with.

fauigerzigerk4• 17 years ago

IB is a standard run-of-the-mill GUI builder. I found nothing in it that current versions of Microsoft tools don't do, quite the contrary. But the important thing is that separating code from the UI a bit better than VB did in 1992 is not what I mean by abstraction.

There are a few fundamental requirements for a language to allow for powerful abstractions. I think self-referentiality and closure (in the maths sense not in the CS sense: http://en.wikipedia.org/wiki/Closure_(mathematics) ) are among those requirements.

GUI tools are ages behind what today's programming languages can do in terms of abstraction. So I don't see why it should be a good idea to limit the expressiveness of my toolset by inserting static blobs or nibs of visual somethings everywhere.

To make it perfectly clear: I want to be able to insert a function in place of any static structure, anywhere! I don't want barriers that make this process more difficult. And that's what GUI builders do.

You say I can define UI things in code as well. Great, I'll gladly take that offer, thank you very much ;-)

10ren5• 17 years ago

Stimulating points, but it's far from "failed" in commercial terms; and the best GUI designers often aren't coders, but designers. Different tasks, different values.

Challenge: how could one make a visual version of abstraction? Would you say that there is no abstraction in templates?

fauigerzigerk4• 17 years ago

You're right about the designer/coder separation. I didn't think of that because I have never worked in an environment where designers created functional UIs.

Yes there is abstraction in templates. Templates typically let you indicate (visually or otherwise) what the static parts look like and where the dynamic parts go. That's it. We have done that forever. There's no progress. Templates don't describe interaction and that's what UIs are there for and it's the growing part of UI design.

Tool vendors have tried for many years to describe the interaction parts visually as well. But interaction is not inherently visual. A condition is not visual. A data transformation is not visual. Even the difference between two visual states is not visual itself.

It's a logical abstraction that manipulates visual objects. Mixing logic that manipulates visuals with the visuals themselves is not useful, and in terms of established software design principles it violates the separation of concerns.

Painting logic with a GUI builder is like entering a sine function by drawing squiggly lines on the screen.

Maybe we could create a better visual version of abstraction, but I don't feel it's the most promising direction to take in order to make abstraction more powerful.

wallflower2• 17 years ago

Adobe is working on a promising product called Catalyst that aims to allow designers working on Illustrator/Photoshop templates to convert them into Adobe Flex UI screens (mxml). It is promising because from what I've seen so far the mxml isn't very developer friendly.

The aim, of course, is for the designer to generate the exact look and feel for the wireframes and render them (using Catalyst) to MXML for the Adobe Flash/Flex developer to code in the behavior/functionality. Catalyst will require Flex Builder 4 (which will not be out until 2nd half of 2009).

http://labs.adobe.com/technologies/flashcatalyst/

FXG (the interchange format spec):

http://opensource.adobe.com/wiki/display/flexsdk/FXG+1.0+Spe...

As an aside, I work on a large project (at least 10 UI developers) that uses Flex. We don't even use the GUI builder.

sammcd• 17 years ago

I think you need to take a closer look at the Mac third party application Community. We have been using a GUI builder called interface builder since NextStep existed, and it is far from failed for us. When it is done right it works well.

I'm not sure how Atlas works, but on the mac code is not Generated in the way you are thinking. You should really check it out.

tlrobinson3• 17 years ago

To nip this one in the bud: Atlas doesn't generate code. It serializes the objects that represent the "views" and other objects. This has a number of advantages over the code generation method.

Also, I think Atlas allows for the sort of abstractions you're looking for. It comes with a bunch of built in widgets which are great, certainly for prototypes and simple UIs, but even fairly advanced ones too. But if they're not good enough, or you have some custom widget/layout you can easily add it to Atlas as a plugin and treat it as if it were a built in component.

But I'm certainly interested in hearing more about the problems people have with these sort of tools.

cpr3• 17 years ago

I think you're not aware of the Cocoa development culture that spawned Atlas/Cappucino.

People in this culture don't tend to build the kind of endless, mindless forms you're talking about. They build real apps.

And they don't generate code--they generate linked objects (freeze-dried in .nib/.xib and now .cib? files) that are unfrozen at runtime.

If you had to generate a whole bunch of mindless forms, you're right--metaprogramming solutions would be a big win.

jli• 17 years ago

I think this has some potential to allow more developers to publish a web app with at least a decent looking ui. There are a lot of good backend developers who happen to be bad at ui, this might allow more potential customers to view the product instead of being horrified as soon as they saw the ui.

pclark• 17 years ago

wish sites would put a textual description below videos.

10ren5• 17 years ago

A visual IDE in a browser. Very cool.

Is it fast/responsive enough to not be annoying? No demo yet.

And I wish they had a one-line pitch.

rman666• 17 years ago

Tried to get to it last nite and this morning. No luck. Is it the "slashdot" effect, or is something else going on?

tlrobinson3• 17 years ago

Sorry about that. We're still in a hotel in Miami with shitty Internet. Will be back in California tonight and everything should be smooth sailing after that.

epall• 17 years ago

So, when do we get to play with it??

poub2• 17 years ago

I’m using a lot Interface Builder to generate my Capuccino views using their tool nib2cib.

Atlas is going to save me a lot of time.

Sure you can still edit the plist by hand or programatically but I don’t find it more efficient neither easier.

New Product From 280North: Atlas

Related Stories