Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Tangentially related: I've started using the Google Closure Compiler, and I see JS in a whole new (and mildly depressing) light now.

When I first learned to use jQuery, I went hog-wild, running circles around fellow devs who didn't use it. I got so into JS, that I started writing more logic in the client, because I could, and because JS, with it's loose typing and object notation was just a fast place to write code.

Now, two years later, I've embarked on a large project, an HMI in an industrial sector, and I of course made heavy use of jQuery. After 4000 LOC, the program needed some serious re-factoring in order to handle the next level of complexity.

To handle the complex demands of the application, I decided to use the Closure Compiler, which is great! The only problem is, that now, I'm writing typed code, in a non-typed language, and there's not much to really like about the language, besides the fact it's on all web browsers and has a ton of third-party support.

I guess my point is: I think tools like Closure Compiler and others which produce "compiled Javascript" are the future, if anything is. Maybe we'll see Python, or Java get JS like support in the browser, but if I could talk to the me from two years ago, I'd tell him: "Start using the Closure Compiler, and use less jQuery."



Hi, I'm you from two years ago (loving jQuery, moving more code from server to browser, never used Closure Compiler). I'd like to take your advice, but I'm confused about something.

It sounds like you said (1) you had a great experience with jQuery, (2) writing Javascript is a much worse experience with Closure Compiler, (3) therefore use the Closure Compiler and not jQuery.

Could you please explain why you like the Closure Compiler, so I can understand the jump to (3)?

(1) "running circles around fellow devs", "JS, with it's loose typing and object notation was just a fast place to write code" (2) "now, I'm writing typed code, in a non-typed language, and there's not much to really like about the language" (3) "Start using the Closure Compiler, and use less jQuery"


It depends on the size of your project. Mine is large. Javascript becomes unwieldy after a few thousand lines. Closure Compiler really helps, but in you have to use comments to tell the compiler what types your functions take and return. This becomes a drag, making JS, to me, less fun.

If you're going to make a big project, I recommend CC from the start.


You may want to look at ShrinkSafe and the Dojo build system. While it does not create quite the compactness of the Closure compiler it does get you close without enforcing constraint on the way you write JS.

As well, if you are doing large apps with jQuery then you should take a look at Backbone. It helps organize the JS application architecture. In saying that though there really are better toolkits for large JS apps that are designed to provide the frameworks of application architecture in your app.

Dojo is the one that I use and recommend, once over the learning curve you will find that it is designed to handle large JS application is an intuitive manner and not just by making it look like Java in the browser. It exploits the best parts of Javascript while bringing in language constructs from several schools of thought to provide a very robust toolkit.

I have used most all of them and it is my choice when the webapp surpasses a certain point in complexity. I always tell people that I can save them a lot of time when it comes to JS toolkit selection and then I tell them if it's small use jQuery and if it's large use Dojo. It is meant to be slightly humorous but there is a grain of truth to it.

There is nothing faster to learn and more intuitive that jQuery but it comes at the cost of reduction in it's robustness. There are tools to address this but to me they always feel like bolt on's.

Dojo on the other hand trades up front intuitiveness for robustness. A trade off that toolkits like Closure make is to make JS more like Java to bring back some of that intuitiveness but at the cost of some of that robustness. Dojo is unapologetic a JS toolkit and uses JS concepts as first class citizens. It then borrows best of class language constructs from other areas of language progression.

Anyway, my long winded point is, if you are having issue with growth of your jQuery application you may want to give Dojo a try. Rebecca did and was pleasantly surprised:

http://blog.rebeccamurphey.com/2009/11/12/dojo-confessions-o...


Thanks, that makes a lot more sense. My projects so far have included well under 1000 LOC of my code per page. If and when this changes, I will watch out for this issue and consider Closure Compiler as a possible solution.

I also wonder if (runtime-checked) pre/post-conditions could bring much of the benefits you speak of, with the option to use them sparingly and avoid the "drag" part. In other words, make the type annotations optional and only put them where it looks like the extra safety is important enough to be worth it.

In any case, I'll cross that bridge when I get to it. Thanks for the heads up.


I think there'll always be a place for scripted (non-compiled) languages, particularly in the web context, no matter how complicated Web apps become. And there are lots of strategies for complexity management; compilation is just one possibility.

It's never the case that the shiny new technology blows away the busted old technology; more like the new stuff becomes another blade in your swiss army knife.

What's the learning curve for Closure like and how did you come up to speed on it? It is like an API or more like a tool like gcc?




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: