I was a full time java developer, now I'm also working with JavaScript and Android. A couple of years back when I started learning JavaScript, the first library I tried was jQuery. But it made my life harder, and after sometime I started writing fairly large a JavaScript app. It wasn't coming together for me using jQuery. I had huge a code base without much of a structure. Method blocks updating HTML blocks using selectors.

Then I tried MooTools and obviously as a Java developer it appealed to me a lot. And I was able to write managable web apps having huge code base.

As per my understanding MooTools is not considered a preferred way to write JavaScript because it mimics conventional OO over default prototype-based OO language. So now to really understand Javascript and desire of walking with the world, I decided to try other approaches, so again I turned back to jQuery, and realise that only jQueryis not enough.

So started looking at current trending frameworks like backbone, spine, ember.js, sprouteCore. Strangely I found that these frameworks mimic conventional OO like MooTools only by having constructors and creating a object of class and reusing this class object to create instance objects. So

  • Am I missing something?
  • Is MooTools really wrong?
  • MooTools project is very alive and releases new versions/features, but I don't see many people talking about it on internet, also there are no comparisons vs backbone/spine etc.
  • 4
    Have you tried to do anything in JavaScript without the help of a framwork? It might help, in a back-to-basics sort of way to learn the fundamentals. – FrustratedWithFormsDesigner Feb 22 '12 at 18:59
  • 6
    Frameworks inhibit your ability to learn and impose stupefying overhead. Avoid them at all costs unless you're in a giant bind. MooTools in particular is some form of sanity amongst mass stupidity, but it still is unnecessary for most JavaScript-related problems. – null Feb 22 '12 at 19:02
  • 7
    @MattMcDonald, are you really advising OP to avoid using all JavaScript frameworks? Really? That's a whole lot of wheels to reinvent. He obviously needs to learn the language, but over the long term, his productivity will fall off the table. – Adam Crossland Feb 22 '12 at 19:07
  • 2
    @MattMcDonald have you ever had a construct a product under time/budget/resource constraints? – MattDavey Feb 22 '12 at 19:23
  • 2
    @MattDavey have you ever had a product evolve past the constraints of generic framework X and then regret using said framework because it gets in the way. – Raynos Feb 22 '12 at 19:44

You aren't missing anything.

The pseudo-classical method of Object Oriented JavaScript has been an accepted technique for a very long time. There's certainly no reason you can't use it.

There are a couple reasons some people eschew it, though (myself included):

  • It's a misdirection - the pseudo-classical pattern, by necessity, uses prototypal inheritance, but this is not obvious. People who like to know what's going on at a low level (read: me) don't like non-obvious abstractions.
  • Purism - honestly not that great of a reason, but knowing how JavaScript works is good.

There are also several reasons that people eschew frameworks in general:

  • Overhead
  • Misdirection (non-obvious abstractions)
  • Poor APIs (which obviously depends on the framework)
  • Lack of modularity (they need one part of the framework, but don't want to load the whole thing)

The tendency, for people who want to avoid frameworks is to use micro-libraries, so they don't have to reinvent the wheel. Cross-browser XHR can be written in less than 20 lines (maybe far less than that). DOM interaction is similarly easy. Animations are less so, but there are still small libraries that can do animations. This is a modular approach that follows the concept of YAGNI, and keeps load times low.

jQuery in particular has a lot of issues. Some of which are solved by MooTools (which I'm just beginning to explore myself). Personally, I'm unfamiliar with many JS frameworks, but am exploring them simply for the sake of exploring them.

I find that since I know JavaScript fairly well, and how to properly construct object-oriented code in the language, I don't need a lot of what frameworks have to offer. I have no problem using the native DOM API. I have no problem using native prototypal inheritance patterns. And I have no problem using CSS for presentational bits (transitions in particular).

So, as I've become more well-versed in the ways of JavaScript, frameworks have become less of a nicety, and more of a burden. I keep my eye toward straightforward, modular code that is in line with YAGNI and DRY, and I think my applications are better for it.

| improve this answer | |
  • Twenty lines for cross-platform XHR? You know it's one line in jQuery, right? – user16764 Feb 22 '12 at 22:10
  • sigh... it's a 20 line library, which you can then use in a couple lines. – Ryan Kinal Feb 22 '12 at 22:12
  • @user16764 WRONG It's 7 lines with jQuery and 6 lines with XHR. – Raynos Feb 22 '12 at 22:24
  • @Raynos Your jQuery example could be better written as a one-line call to $.post (not including the definition of the callback that you pass in, which can be of arbitrary length). So it is indeed one line in jQuery. Also, I find it very unlikely that your XHR example is the cross-platform code that Ryan is referring to. – user16764 Feb 22 '12 at 23:02
  • Really? That's exactly what I was referring to. There is a minimal script behind it that normalizes XMLHttpRequest. So, if you need XHR (and only XHR), then you can use that instead of including the entirety of jQuery for one feature. – Ryan Kinal Feb 23 '12 at 13:11

If you are missing anything, I think that it is only that the large number of JS frameworks/libraries give you the option to choose the one that works best for you. I'm not personally a fan of techniques that try to force the round peg of JavaScript into the square hole of classic OOP, but my personal preference is well-served by the incredible set of alternatives to mooTools that are more prototypal.

Let's take a look at Google Web Toolkit: it allows you to write your code in Java and it translates that code into JavaScript to run in the browser. It's very unlikely that the resulting JavaScript has some quality of pureness or JavaScript correctness. It probably won't look good going through JSLint, but why would you care if your application runs the way that you want it to.

Similarly, the CoffeeScript language compiles to JavaScript and gives a completely different programming experience. Some people swear by it and couldn't go without it. Other people develop grand web apps and have not spent five minutes looking at it.

So if mooTools or some other framework presents a classic-OOP face to JavaScript, why would you care as long as you are productive and your application works?

Scott Hansleman called JavaScript the Assembly Language of the Web. After doing so, of course, he was immediately agreed with and reviled by large numbers of equally committed proponents and opponents, but there is a hard kernel of truth in it that any open-minded engineer is going to see. It is (in my opinion) to JavaScript's credit that it is flexible enough to be both a primary language and target for compilers.

As long as the approach works for you and whoever you are developing with and it makes your application work, go with it. Everything else is just some preacher shouting their special beliefs.

| improve this answer | |
  • 2
    Raw Javascript has something else in common with assembly language. Just as assembly written for one ISA is not portable to any others, Javascript written for one brower's DOM is often not portable to any others. C and jQuery have the advantage of abstracting those platform incompatibilties out. – user16764 Feb 22 '12 at 21:11
  • That is a very excellent point, @user16764. A good library like jQuery allows us to write JavaScript without worrying about browser quirks. – Adam Crossland Feb 22 '12 at 21:12
  • 3
    In the modern browser landscape, it is trivial to write cross-browser DOM code. Seriously. – Ryan Kinal Feb 22 '12 at 21:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.