4 ms·
I think such a developer (one that has strong knowledge of both JavaScript and Java/Python/Objective-C and still feels compelled to use one of the abstr
by esessoms 18y ago
I think such a developer (one that has strong knowledge
of both JavaScript and Java/Python/Objective-C and still
feels compelled to use one of the abstractions) doesn't
really exist - at least not in any significant numbers.
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.)
- smanek 18y agoI 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.
- esessoms 18y agoOh, 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.
- boucher 18y agoI 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).
- boucher 18y agoIf 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 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] is just objj_msgSend(object, "message"); In that small syntactic change, you're actually conveying a great deal of meaning, and enabling some really powerful features. All with effectively no run-time performance cost, and with no need to compile since the Objective-J preprocessor runs in the browser.