JavaScript Hacks for Hipsters (slideshare.net)

Makes sense. Javascript is the PBR of programming languages.

I don't know what to make of it.

Some seem like good ideas and some like really bad ones...

I couldn't take it seriously so I laughed instead. I really need some coffee.

"Trade bloated if/else blocks for a quick function call"

Is there any programmer since the 1970s that needs to be told this?

Hows this for hipster: these are all basic programming techniques that have existed for decades and barely need to be pointed out. Or have I missed the joke?

EDIT: this is "fake surprise" isn't it. I'm sorry HN. Everyone has to learn this stuff somewhere. But the title was kindof asking for it.

To any newly minted developers out there, the best way to learn this stuff is just to read other peoples code. Pick the library you enjoy using the most and read every file until you understand what all the constructions and bits of syntax are for. Then compare it to another library, etc etc. Develop a taste for some and a distaste for others. There's no excuse not to learn experimentally in js as it has a repl. Use the source luke!

Most of this is just idiomatic JS, hardly "hacks".

if internet explorer is important in your life, you can forget some of these.

Pff, I used most of those before they were mainstream.

For some reason the entire thing reads to me as a guide to writing Javascript like an experienced Perl developer. Either way, it's really cool to see people advocating an idiomatic style for JS. :)

While introducing new developers to work on the JS part of our codebase (node & client side) - I noticed some puzzled looks here and there.

Not everyone understands why && and || are used outside of if statements. Not everyone knows about joining strings using an array.

This summarises the things you'll have to know to read code in our codebase.

Why `success ? 'method1' : 'method2'` instead of `success ? obj.method1() : obj.method2() `? That seems more concise to me.

Hey, I love neat Javascript tricks... but things like the "TODO" operator are really bad style and will hurt larger teams.

Stick to standards, so ease-of-communication is simpler! The reality is that collaboration is harder than programming!

You certainly lose some code readability with some of these.

This was originally published a year ago in this blog post:

http://berzniz.com/post/68001735765/javascript-hacks-for-hip...

Makes for a nicer read than slideshare imo.

Non-slideshow link: http://berzniz.com/post/68001735765/javascript-hacks-for-hip...

This may impugn my credibility as a professional developer, but I genuinely can't tell if this article is sarcastic or sincere.

Many of these are:

1) Much less legible, and in some cases outright lazy 2) Extremely vulnerable to Javascript's fast-and-loose type checking.

However it's good to be AWARE of them, since you tend to see them a lot in team projects.

var aCoolFunction = undefined;

aCoolFunction && aCoolFunction();

What is the purpose of this?

Some of these are mildly useful, but not sure it deserves front page.

I like using .filter, .forEach and .map native methods on arrays. Also making use of Underscore.js where possible.

One I've never thought of using before is the: isAwesome && alert("yay");

I have used the name || "no name" operator a lot and thought to myself that it looked cool on first impression. But having something like: isAwesome() && alert("yay"); Already makes it harder to read I think. I'm curious to what others think of this one? Maybe its just because it is new to me..

Presentation Hack for Hipsters: Use bigger fonts than this guy.

The problem with #1 is that the minifier (e.g. http://closure-compiler.appspot.com/home) can't optimize as much.

---------

Example using strings:

  var obj = {
    start: function(){
      'use strict';
      console.log('start');
    },
    stop: function(){
      'use strict';
      console.log('stop');
    }
  };
  
  exports.onDummy = function(success){
    'use strict';
    var method = (success ? 'start' : 'stop');
    obj[method]();
  };

results in:

  var a={start:function(){console.log("start")},stop:function(){console.log("stop")}};exports.a=function(b){a[b?"start":"stop"]()};

---------

Same thing, using if..else:

  var obj = {
    start: function(){
      'use strict';
      console.log('start');
    },
    stop: function(){
      'use strict';
      console.log('stop');
    }
  };
  
  exports.onDummy = function(success){
    'use strict';
    if (success){
      obj.start();
    } else {
      obj.stop();
    }
  };

results in the much shorter:

  exports.a=function(a){a?console.log("start"):console.log("stop")};

Someone needs to clarify to me why people are excited about this. Isn't this just horrible for readability?

I've just started reading Clean Code, and there is a lot of emphasis on writhing readable code, because the philosophy is that code is only written once but read many times.

I have read a few places recently about techniques and strategies to get rid of ifs and else's in code. It was all in the spirit of writing more concise and compact code, not about the actual speed when executing the code. So often, I see "concise" at odds with "readability." The '&&' slide is a good example of this. For me, multi-line if/else statements are pretty easy to read. I hate running into complicated, one line, if else statements, it feels to me that it takes twice as long to parse and understand.

I have witnessed many of these on some JS projects I've been working on! While I took time to think on it and figure out what the "author" was aiming at, my colleagues were more like "What does this mean? No way I'm touching that. Let's rewrite that crap!"

IMHO, hipster JavaScript is called CoffeeScript.

    1) do obj[if success then 'start' else 'stop']
    2) ['milk', 'coffee', 'sugar'].join ', '
    3) doStuff = (options = {}) ->
    4) isThisAwesome?()
    5) ### ... ###
    6-8) ...
    9) template = "Hi, my name is #{firstName} and my twitter screen name is @#{screenName}"

[1] http://coffeescript.org/#try:do%20obj%5Bif%20success%20then%...