Comments on: Xopus Application Framework: Objective-J Done Different

By: Laurens

Laurens — Wed, 18 Feb 2009 11:07:06 +0000

Disclaimer: We have no plans to release XAF. This blogpost was just meant for inspiration and sharing of knowledge. Feel free to contact us if you want to know more.

> It’s a shame that few Class implementations keep an eye on whats planned for ES3.1+.

We wanted the uncompiled code to be syntactically correct Javascript. This allows us to have any off-the-shelf Javascript engine parse our code and run the compilation. In fact, if we don’t use the serverside compilation step, the code will compile itself in the client (which takes much longer due to HTTP overhead). So we couldn’t defer from what browers understand today.

> who else will be able to read your code?

The flexibility of Javascript can easily lead to unreadable code, we think having a framework and the code guidelines that go with it make our code more readable. Our newest team member can confirm that.

Also keep in mind that it still is Javascript syntax, so you can use what you’ve learned elsewhere. And we can take the code and embed it in another code base (which we do when we backport code to Xopus 3).

> “Keep it simple stupid” comes to mind when I see some of these projects.

We feel we have kept it as simple stupid as possible. We have not written our own parser for instance. But with the metrics of our product we need at least packages, namespaces, dependency checking, (multiple) inheritance, event handling and unit testing. We found no other framework that could give us that. (We currently have 600+ classes in 180+ namespaces, 1300+ handcrafted unit tests, 3K+ generated unit tests, 2.1MB of code which compiles to 2.5MB of Javascript which is obfuscated to about 900KB when shipped.) We have tried to take Plain Old Javascript as far as possible for about 7 years, but it reached its limits. We are now using XAF for almost 2 years and it works very well for us.

> Did they implement soft typing?

Yes, we can have the compiler add runtime type checks at development time which will be omitted in the shipped code.

By: chiaroscuro

chiaroscuro — Wed, 18 Feb 2009 06:03:07 +0000

> Some forms of program veri[fi]cation

Sounds interesting. Did they implement soft typing?

> Inheritance

The feature everybody is missing. :)

By: pplante

pplante — Wed, 18 Feb 2009 05:56:45 +0000

I hate to be the one to say it, but why? “Compiling” javascript from a mess into a larger mess seems like a major step backwards in terms of readability and reusability for future projects.

“Keep it simple stupid” comes to mind when I see some of these projects.

By: PieturP

PieturP — Wed, 18 Feb 2009 00:16:53 +0000

@ whylom: You have! It’s right on the page you’re linking to. :-)

By: whylom

whylom — Tue, 17 Feb 2009 23:07:16 +0000

Assuming you buy into the idea of compiling to JavaScript, this appears to be a very well thought-out approach. I love-love-love the idea of coding annotations to be removed by the compiler. You can use it for conditional compilation, testing, profiling, coverage, and, of course, documentation. And they claim to have hit all these sweet spots – bravo!

I’m not crazy about the way they ask you to express method modifiers:

Class( Static, function() { ... } )

A slight change in formatting renders this syntax well-nigh unreadable, IMHO.

By: TNO

TNO — Tue, 17 Feb 2009 16:53:44 +0000

There are so many ways to add classes to JS that it’s dizzying.
.
It’s a shame that few Class implementations keep an eye on whats planned for ES3.1+.

By: Nosredna

Nosredna — Tue, 17 Feb 2009 16:14:01 +0000

There are so many ways to add classes to JS that it’s dizzying. My chief concern: who else will be able to read your code?

That said, I like the looks of Joose, and Objective-J is creeping up my radar as I learn Objective-C for the iPhone.