youre-doing-it-wrong.md

#You're Doing it Wrong

On G+ a couple days ago I read a post by João Saleiro which basically slams JavaScript and HTML5 and claims Flex is far superior, and you know what? It very well could be because I've never used Flex. I constantly hear and experience bad things about Flash, but I don't know what it's like to develop on the platform. However, I do know my language, JavaScript which he makes incredibly outrageous and false claims about it for whatever reason.

When I pointed a portion of these out and explain the falsehood of them he asks me why I'm making this a "religious war". Well, I'll tell you why. JavaScript has been a plaything of a language for over a decade. It's taken us JavaScript engineers a very long time to be taken seriously. To this day it's still rare to have a job title like mine which is "JavaScript Engineer". It's usually "front-end engineer" or something like that. JavaScript even as important as it is in modern day web apps, is still usually a second language. Front-end usually implies good slicing, HTML, and CSS knowledge, and, oh yeah, you know jQuery too right?

The JavaScript community has worked it's ass off for too many years trying to get respect to deserve an utterly shitty take on JavaScript with false claims to either make it look bad or because he didn't actually spend the time learning the language for the language that it is. Shame, because I was actually interested in hearing about differences and real pros and cons.

But, I'd like to dispel some terrible inaccuracies about JavaScript mentioned in this article:

We work on the enterprise and enterprise means stability.

HTML is not unstable. HTML is far more stable than Flash and even has more support than Flash. HTML is supported on more devices than Flash is for a reason. It's more stable, less RAM hungry, and overall safer. Apple didn't want to support Flash for a reason.

...in HTML5 there's nothing new or better than what you already have.

Err, nothing new? Let's see:

• Forms have been vastly expanded
• Audio API
• Video API
• File API
• WebSockets
• Canvas
• Offline support

...and the list goes on. Is it better than what you Flash people have? I don't actually know because he never mentioned any of these.

There.are.no.real.classes.in.javascript. Of course, you can try to mimic them - I've read half of a book teaching how to do that.

Why? Why would you read half a book trying to mimic them and not spend that time learning the the language which is a fucking prototypal language, not classical. It's like saying, "Gosh darn it, my hammer doesn't cut things like I want, so I'll learn to solder so I can solder a saw blade to the end of my hammer, because I'm so used to hammers it'll just be easier."

Or, one of my favorite quotes I love sharing with people who try to force JS to use classes:

I now see my early attempts to support the classical model in JavaScript as a mistake.

• Douglas Crockford source

I could have sworn the article said JS wasn't OOP, maybe it was edited, maybe I read it wrong, but just to be clear, JS is an OOP language.

Hard coupling everywhere.

Hard and loose coupling is a programming design pattern. It has almost nothing to do with the language. If you want to loosely couple components read about the mediator pattern and understand the concepts of pub/sub.

Ugliness. I'm used to a HUGE-ULTRA-CLEAN separation between classes, libraries, modules, components and applications

Again, doing it wrong. You want modules separated? Well, separate them. Put them in a different script tag, or use something like require.js. You want HTML separated? Fine, put them in a .template file and call them in with a function like "getTemplate()". You can separate it as much as you want. Again, like the coupling thing, this is a architecture issue, not a language issue.

It's not built for team work.

Basically he talks about how someone committing bad code or not knowing where files are. I haven't dealt with ActionScript but I can't imagine if I committed broken code it wouldn't break the app. That doesn't even make sense. Also, not knowing where files or chunks of code are is, (for the love of god, again?) an architecture problem. Figure out a standard for your MVC directory setup, naming conventions, module locations, etc. Then, voila, problem solved. Committing broken code that breaks the app? Yeah, not sure how to help with that. I'm pretty astonished you can commit broken code into ActionScript yet... it doesn't break. I'm having a feeling thats bullshit.

In JS, "this" can mean pretty much anything

this can indeed be hard to understand and even seasoned JS engineers will trip up on it from time to time. This is one thing about JS that does suck. However, it doesn't mean pretty much anything and there's plenty of articles that will explain it.

Code practices. These are completely different from everything you know. ... By some weird reason, people like to write as much code as possible in a single line, making it not only very hard to read, but also very hard to maintain. I've got used to seeing the $('#huge').line({of: code, that: function() { looks() }).like('a').train();

No. Who does that? No one I've ever worked with. That code should be written:

$('#huge').line({
  of: code, 
  that: function(){
    looks();
  })
  .like('a').train();

That syntax I gave an example of is usually only used when traversing DOM elements like:

var huge = $('#huge');

huge.css({
  color:'#f00',
  background:'#000'
})
  .children('button').attr('disabled','disabled');

That shouldn't be used for actual application methods tho and the above example is about as legible as you can get. Huge's css for color and background, find the child buttons and add the disabled attribute. Easy and clear.

...we had to change the designs of the product we're building a couple of times on the middle of the project to turn them into something possible/easier to achieve in HTML.

I'd like to know what these were. I've personally never come across a design that was "unsliceable". I've seen full fledged cartoons done in HTML and CSS, so I'd have to see if this is purely a lack of DOM and CSS understanding or a true limitation. If, for whatever reason, it was a limitation luckily we have SVG and canvas which you can do anything you want. No DOM.

My response is already ridiculously long, but I wanted to at least respond to a few completely bogus claims. If you're an engineer wanting to try JavaScript, forget everything you know about your classical-compiled-written-in-an-IDE language and learn JavaScript for the language it is which is a prototypal language you don't need an IDE for because you can refresh your browser instantly after saving and if you don't like DOM, don't use it if you don't need it. Use canvas or SVG.

Note: He's gone back and edited portions of it since it's original posting, but I assure anything I quote was in there copy/pasted.

I totally agre with what you say here

Preach it

Not again. A guy talking about what hears from others which is false. If you don't know about one of them that you are comparing just Shut the f.. up.