The good, the bad, and the ugly: large scale JavaScript apps

It’s pretty sad that no matter how hard JavaScript tries to be more “serious” it is still perceived as that “scripting” language. Compared to Java or C++ or something else that is “more serious” JavaScript won’t have a chance. But why? really it came a long way from where it started.

The saddest part of the story is that it’s called “JavaScript”. The “Java” part was probably just a marketing tactic by Netscape. The “script” part gave it that perception of being “not serious”. So what changed for JavaScript over the last 10 or so years? He-ll-o AJAX.

AJAX is JavaScript’s sexier cousin from some exotic island. Believe it or not, AJAX came to JavaScript first from Microsoft in IE 5. It wasn’t even called AJAX then, it was just XMLHTTP – of course you can’t depend on Microsoft to come up with a better name. AJAX officially got its name in 2005  thanks to Jesse James Garret. AJAX changed everything for JavaScript. More people started talking about it. Customer’s wanted more of it. Everybody was all over AJAX — except those technology guys that thought JavaScript was not “serious” enough.

Even though AJAX and JavaScript have been seen together across the inter webs since the early 2000s it wasn’t really that common until I would say GMail (2004) and Google Maps (2005) came out. Then of course we had Twitter, Facebook and many popular applications build their experience around AJAX. Then we had executives asking for “Web 2.0″, “Ajaxy”, “Googley” applications across giant enterprises that are mainly Microsoft or Java shops that didn’t care about that “hack” JavaScript. (I would argue JavaScript is more appreciated in the Python / PHP / RoR world but that’s just me)

Anyway so what happens next? Well, it is called “JavaScript”, and we have been coding JavaScript for 10 or so years, how bad it can be? This is what a lot of people missed. Today you are building large JavaScript applications unlike what you were doing 10 years ago. 10 years ago you code some JavaScript to perform some client-side validation. Building large applications requires architecture and engineering, not just coding. Yes, and you’re better off with a framework too. However a framework will not save you by itself.

So now we have dozens of JavaScript frameworks and libraries and tools to use, just like the other “more serious” languages we also have MVC, messaging, pub sub, and even build and dependency management systems. JavaScript even has optimization and profiling tools! An automated test harness too! Wow so much has changed since you started using alert().

Where do we go from here? Step number one would be to forget all the bad habits you have picked up since 1995 and start learning some new and better practices. I’ll start you off with  “5 tips to writing better JavaScript” I presented at DevTO last week:

  1. Use namespaces and break code into modules. Modules, modules, modules. Not functions, functions, functions.
  2. Use Event driven programming. Web apps will always be event driven. You’re either responding to a user event or a system event. Architect and program your components as such.
  3. Use a publish/subscribe plugin or something within your framework if it supports it already. Ties nicely into the event driven architecture.
  4. Use a templating engine. Don’t mix HTML markup within JavaScript code or vice versa.
  5. Last but definitely my favourite. Everything is a module. Use decorators to change behaviour dynamically. You can mix and match different JS objects and functions dynamically on demand. This can be very powerful. It’s like your on demand movie subscription…but much better. Imagine you can mix Dexter with True Blood and in the Mad Men days? Wow.


Don’t blame JavaScript for your crappy application. Blame yourself for not taking the time to understand it better. Here’s a good book to start understanding it better: JavaScript: The Good Parts by Douglas Crockford

 

 

Also come out to #DevTO which will always be the last Monday of every month to share some more good parts about JavaScript with myself and others :)

 

This entry was posted in #devTO, dojo, how to, thinking out loud, web apps. Bookmark the permalink.

7 Responses to The good, the bad, and the ugly: large scale JavaScript apps

  1. Azizi Yazit says:

    The “5 tips to writing better JavaScript” is awesome and
    totally valuable for anyone who want to start to code
    javascript.

  2. Emil says:

    Very well-written. It has been a somewhat strange travel
    JavaScript have had from the mid 1990′s and to now but with all the
    frameworks and JS applications popping up everywhere I think we
    just begun to scratch the surface of JS’ potential. Especial with
    some of the more “experimental” applications such as node.js it is
    going to be an exciting time. Thanks again for a very nice post :-)

    • Nael El Shawwa says:

      Node.JS is definitely exciting. Not sure if I would just use it by itself yet, might consider it for some component where it makes sense to me, but not yet as the whole stack my app sits on.

  3. Yannick says:

    So … let imagine that javascript has all the tooling
    suite needed to write efficient, bullet proof human readable code.
    Why should i write my next big app with javascript since its still
    a magnitude slower than Java (don’t speaking about C++ …) ?
    (http://www.olympum.com/java/quick-benchmark-java-nodejs/). All
    that stuff are just a hype … It is not because it can be done
    that it necesserely mean that’s a good idea.

    • Nael El Shawwa says:

      I was talking specifically about node.js but JavaScript in general. If you’re building web apps then you must be writing JavaScript for the front end piece at least. That needs to be architected properly just like you would your Java back-end. As apps get richer you will see more MVC style JS front ends.

      As for node.js I’ll leave that to another post : )

  4. Jan says:

    Nice post.this is exactly what drove me to the Google
    Closure Tools.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>