JavaScript Language Abstractions(ejohn.org)
ejohn.org
JavaScript Language Abstractions
http://ejohn.org/blog/javascript-language-abstractions/
2 comments
I don't get why people so want to abstract around Javascript itself - it's a great language. It supports OOP and functional programming (although, admittedly, the prototype object system does take some getting used to) and it's dynamically typed. You even get a REPL! (e.g., via firebug). I would argue the js is far better than Objective-C and Java, and at least on par with python.
Now, some of the DOM manipulation stuff is just annoying, but that's what jQuery is for :-D
What do you like better about Java's object system than JS's? I prefer JS's because it isn't as constraining - it doesn't force you to use it the way its creators imagined. It's possible to write good JS code, it just takes some self-constraint.
Now, some of the DOM manipulation stuff is just annoying, but that's what jQuery is for :-D
What do you like better about Java's object system than JS's? I prefer JS's because it isn't as constraining - it doesn't force you to use it the way its creators imagined. It's possible to write good JS code, it just takes some self-constraint.
If the DOM is annoying, jQuery is no better. It's DOM++, at best. jQuery is still the DOM, just slightly prettier. If you really believe the DOM is annoying, why not just get rid of it?
People embrace the DOM because its there, but that isn't necessarily a good reason. If jQuery is the C to DOM's assembly (not a particularly apt analogy), why shouldn't we want to branch out to a higher level language? That's one of the reasons we built Cappuccino.
Cappuccino is built on top of the DOM, because its the only thing that makes sense right now in the browser world. But we do our best to make sure developers don't need to worry about the DOM. Of course, as Spolsky would tell us, all abstractions leak and ours is no exception. But, Objective-J is just JavaScript. All the DOM is still there for you to poke at if you must. And the point of Spolsky's article was not that abstractions are bad, just that you should learn what you're abstracting, then use it. Abstractions do save us time, even when they leak.
As far as Objective-J itself is concerned, there were clear motivations for building it. JavaScript lacks dynamic message sending. It lacks classical inheritance. It lacks an import mechanism. We looked at what we felt was missing, and what the best way to fix it was. Turns out, Objective-C was created with exactly these same goals. It was a natural fit for what we needed, right down to implementation level details.
It's important, then, to realize that Objective-J is not about being Objective-C in the browser. It's a better JavaScript. It's a strict superset, so if you just want to use JavaScript, go ahead. If you want to benefit from our hard work and new features, like dynamic code importing, then you can use Objective-J. It even has a REPL: http://tlrobinson.net/misc/console_bookmarklet.html (and a command line version, objj)
Objective-J is also far different in its implementation than Pyjamas or GWT. It's nothing but a preprocessor and a dynamic runtime. It is not a compiler. This means that, in general, the post processed code looks like a slightly uglier version of what you really wrote.
People embrace the DOM because its there, but that isn't necessarily a good reason. If jQuery is the C to DOM's assembly (not a particularly apt analogy), why shouldn't we want to branch out to a higher level language? That's one of the reasons we built Cappuccino.
Cappuccino is built on top of the DOM, because its the only thing that makes sense right now in the browser world. But we do our best to make sure developers don't need to worry about the DOM. Of course, as Spolsky would tell us, all abstractions leak and ours is no exception. But, Objective-J is just JavaScript. All the DOM is still there for you to poke at if you must. And the point of Spolsky's article was not that abstractions are bad, just that you should learn what you're abstracting, then use it. Abstractions do save us time, even when they leak.
As far as Objective-J itself is concerned, there were clear motivations for building it. JavaScript lacks dynamic message sending. It lacks classical inheritance. It lacks an import mechanism. We looked at what we felt was missing, and what the best way to fix it was. Turns out, Objective-C was created with exactly these same goals. It was a natural fit for what we needed, right down to implementation level details.
It's important, then, to realize that Objective-J is not about being Objective-C in the browser. It's a better JavaScript. It's a strict superset, so if you just want to use JavaScript, go ahead. If you want to benefit from our hard work and new features, like dynamic code importing, then you can use Objective-J. It even has a REPL: http://tlrobinson.net/misc/console_bookmarklet.html (and a command line version, objj)
Objective-J is also far different in its implementation than Pyjamas or GWT. It's nothing but a preprocessor and a dynamic runtime. It is not a compiler. This means that, in general, the post processed code looks like a slightly uglier version of what you really wrote.
[object message]
objj_msgSend(object, "message");
Some of that sounds very impressive. Truth be told, I haven't played with Cappuccino much yet - but your post just inspired me to go take a closer look at it. Thanks.
The reason people use jQuery is because the default mechanism for accessing elements is longwinded and ugly. It's the exact same reason people use xml.etree.ElementTree over the W3C-style xml.dom.minidom in Python's standard library. Assuming that people want rid of it completely because they want a better interface is a rather bold assumption, especially when you consider the flexibility using the DOM provides.
I find, in your own words, recognition of several reasons JavaScript fails for building complex systems.
"It's possible to write good JS code" implies that it's not easy or obvious, and "it just takes some self-constraint" implies that in fact you have to be damn good to understand what you're doing.
That's fine, but mere mortals need a programming language too. Fact is that most large projects are not made of up entirely A+ developers (nor should they have to be).
"It's possible to write good JS code" implies that it's not easy or obvious, and "it just takes some self-constraint" implies that in fact you have to be damn good to understand what you're doing.
That's fine, but mere mortals need a programming language too. Fact is that most large projects are not made of up entirely A+ developers (nor should they have to be).
JavaScript is pretty limited. It lacks features like packages, classes and so on. Brendan Eich, the inventer of JavaScript, have stated that the language was frozen prematurely due to political rather than technical reasons.
Luckily core JavaScript is also pretty flexible, which is what allows you to implement your own class system, package system and so on, on top of vanilla JavaScript. And this is basically what language abstractions like GWT, Cappuchino, Pajamas and so on does. They are basically a set op macros on top of JavaScript.
I just think they throw out the baby with the bathwater by implementing a different language on top of JavaScript rather than just extend and improve existing JavaScript in a backwardly compatible manner. This forces the language abstrations to create their own set of libraries, which will never be as good as the native JavaScript libraries. You get caught in a ghetto, and isolate yourself from the broader JS communkty.
My own approach is to embrace and extend JavaScript in a bachwardly compatible manner, such that you can still use the large amount of native JavaScript libraries. Ideally "language abstraction" should be orthogonal to library abstraction. I want a more powerful JavaScript, but I also want to keep using JQuery.
Luckily core JavaScript is also pretty flexible, which is what allows you to implement your own class system, package system and so on, on top of vanilla JavaScript. And this is basically what language abstractions like GWT, Cappuchino, Pajamas and so on does. They are basically a set op macros on top of JavaScript.
I just think they throw out the baby with the bathwater by implementing a different language on top of JavaScript rather than just extend and improve existing JavaScript in a backwardly compatible manner. This forces the language abstrations to create their own set of libraries, which will never be as good as the native JavaScript libraries. You get caught in a ghetto, and isolate yourself from the broader JS communkty.
My own approach is to embrace and extend JavaScript in a bachwardly compatible manner, such that you can still use the large amount of native JavaScript libraries. Ideally "language abstraction" should be orthogonal to library abstraction. I want a more powerful JavaScript, but I also want to keep using JQuery.
I don't get why people so want to abstract around Javascript itself
Macros.
http://common-lisp.net/project/parenscript/
Macros.
http://common-lisp.net/project/parenscript/
Oh, I don't for a second dispute that JavaScript is a much more elegant language than Java, and I would also put it on par with Python. Remember, jQuery is always my first choice.
I only assert that once your (well, my) code base grows beyond a certain size---for me, a few thousand lines, but probably an individual threshold---JS can start to become unwieldy. That "unwieldy-ness" is a problem that Java/GWT does solve. In these cases I prefer Java precisely because it is more constraining.
I only assert that once your (well, my) code base grows beyond a certain size---for me, a few thousand lines, but probably an individual threshold---JS can start to become unwieldy. That "unwieldy-ness" is a problem that Java/GWT does solve. In these cases I prefer Java precisely because it is more constraining.
The problem with abstractions like GWT is that they build a completely different and incompatible abstraction and on top of JavaScript. The benefit of extensions like packages, type checking and so on may be large, but the cost is also large because you have to abandon compatibility with existing code and libraries.
Mascara (http://ecmascript4.com/) is a different approach - it extends Javascript with classes, types, namespaces and so on, but it does it in a backwardly compatible manner, so you can still utilize your old code, use JQuery and so on.
Mascara (http://ecmascript4.com/) is a different approach - it extends Javascript with classes, types, namespaces and so on, but it does it in a backwardly compatible manner, so you can still utilize your old code, use JQuery and so on.
I don't think you understand how Objective-J works (or GWT, or many of these other tools). You can use any existing JavaScript code in combination with Objective-J code. You can use any existing JavaScript code in combination with GWT too, if you do a little work.
Writing an ECMAScript4 to JavaScript translator is really no different than writing an Objective-J to JavaScript one, except Objective-J runs in the browser, not on a python script running on a server. Objective-J runs natively in the browser, an impressive feat.
Writing an ECMAScript4 to JavaScript translator is really no different than writing an Objective-J to JavaScript one, except Objective-J runs in the browser, not on a python script running on a server. Objective-J runs natively in the browser, an impressive feat.
I thought as a member of this mythical group I should speak out. I'm sure there aren't many of us.
First, history: Roughly ten years spent programming in JavaScript (it's hard to believe it was that long) before GWT came out in 2006. Immediately tried GWT, found it too heavyweight, and returned to JavaScript (jQuery, specifically) for another two years, before finally really moving to GWT over the course of the last six months.
Experiences: It really is not possible to write a significant GWT program without good knowledge of JavaScript. I think, on average, every Java class I write has one JSNI (JavaScript Native Interface) method, usually to work around some deficiency in the library but sometimes just to circumvent Java's type system. That's not counting the classes that are pure JSNI that exist to wrap up some JavaScript functionality.
It has also been my experience that it takes roughly 4 lines of GWT code to do the work of 1 line of JavaScript (with a good library such as jQuery). That's from comparing LOC counts on a handful of medium-sized projects I implemented with both technologies.
So, why? The thing that keeps me using GWT even though it is an incomplete abstraction that requires more code is organization. Partly that comes from the fact that OOP is a better fit for GUI programming than the functional paradigm. Mostly it comes from having a nice build system that lets me organize my code in the traditional Java hierarchy. There are lots of ways to try to organize large JavaScript projects---I think I've tried them all---and none have every really felt satisfactory to me.
In the end, most of the time when I'm writing a web page I reach for jQuery first. But when the functionality of a web page crosses over some ill-defined threshold such that I start thinking of it as an application in itself, I change my tools and reach for GWT, all for the benefit of (to me) better organized code.
YMMV.
(Edited for formatting.)