Share Your To-Do List

@Kassem, a couple of advices about JavaScript.

Drop the libs: JavaScript != jQuery
JS is fundamentally messed up, not because it's a bad language, but because it's a powerful language that made a lot of poor choices. The original version version was a prototype written in 10 days which, due to political reasons amongst Netscape managers, ended up in production. And since we cannot break the web, we're going to spend all our lives maintaining (and perpetrating) the mistakes it introduced.

Because of these poor choices, JS will break in so many edge cases and will regularly drive programmers crazy. You won't get the elegance you're familiar with in C#. And this brings us to my point: Hiding behind libraries won't shelter you from JS monstrosity. Until you are familiar with the quirks of the language, you won't be able to write anything larger than a few hunder lines without going completely crazy.

Do you think someone can write .NET apps without a solid grisp on C# (or any language they want to use)? Wait until you're fluent in JS, and only then adopt these libraries.

Learn JavaScript, the good way: JavaScript != Java
Arguably, one of the several mistakes done by JavaScript was to adopt a C-like syntax, with curly braces, semi-colons and all the goodness packed in C, C++, Java, C#, D, etc. It's a mistake, not because of my personnal preferences, but because it leads developers coming from the imperative, class-based OOP languages to think they can pick up JavaScript without having to actually learn it.

Note: To understand why JavaScript adopted this syntax, or its confusing name, you have to understand the political climate in the tech world of the mid-nineties, namely the weird partnership between Netscape (now Mozilla) and Sun (now Oracle) against their common ennemy, the Microsoft behemoth.

JavaScript is nothing like Java, C# or any of the commonly widepsread languages. If I had to describe what languages its closest to, I'd pick these two (and you'll notice that none of them has adopted a C-like syntax, at all):

• Self: Self is a language heavily influenced by Smalltalk (one of the oldest OO languages, and arguably one of the most elegant languages to ever exist) and has developed a new way of implementing OO: Prototypal inheritance. While work on Self hasn't been activefor over 15 years now, JS is probably the only popular modern language to use this OO pattern. The biggest change is that there are no classes in JS. Each object inherits from a parent object and properties lookup is done in a a chained way.
• Scheme: Scheme is a dialect of Lisp, and while not a pure one, is widely cited as a functional language. Just like Scheme, JS uses functions to do everything, and most importantly to define variable scopes.

Self is discontinued (its ideas live on inside the HotSpot Java machine) so don't bother learning it. And Scheme is a highly academic language so you probably won't enjoy playing with it. However I strongly suggest that you become familiar with both FP and prototypal inheritance in order to understand JS.


TL; DR: If you want to learn JS, learn the language before the libraries and start by learning FP.

PS: I cannot recommend Douglas Crockford's book enough. It's literally the best resource you can find on the language.

PS2: I found this nice blogpost to list examples of the stupid things JS does. Note mistake nbr 10.

ramiraz wroteThe article is not about stupid things JS does, it's about mistakes JS developers make.

You're mislead by the title. It could've as easily be renamed "Stupid things JavaScript forces you to work around" and it still would've been valid. Don't use the literary style of the author as an excuse for the mistakes of JS.

JavaScript is a very powerful and flexible language, I never understood the hate it gets (Don't hate JavaScript, hate the DOM). I think you made claims that weren't supported and reflected personal preferences.

If you look carefully at what I've written, you'll see that I called JS "powerful" by the second sentence of my post. But since you called me on making "claims that weren't supported and reflected personal preferences", I'm going to seize the opportunity to show you some examples of what makes JS broken. Maybe you'll understand "the hate it gets".

Why JS sucks

The list is non-exhaustive and reflects mainly the corner cases I've encountered in the month or so I've been practicing the language.

• Stupid coercion everywhere: Every time JS encounters a type error it tries to outsmart the programmer by trying to convert the objects into arbitrary types in order to make the statement valid. This may seem like a convenient feature, God forbids we manually convert our numbers into strings before printing them, but the truth is, it's a really sneaky evil. Errors can go unnoticed until several statements afterwards, and the programmer is given no clue as to what actually went wrong. Without running the code, can you tell me what the following will output?

  [] + [] // empty array + empty array
  ({} + [])[3] // 4th element of empty array + empty object literal
  "hello" - "world" // string - string
  

  And here are the answers, which of course make a lot of sense:

  > [] + []
  ''
  > ({} + [])[3]
  'j'
  > {} + []
  '[object Object]'
  > "hello" - "world"
  NaN
  

  Coercing arrays into string?! Who decided that's a good idea? Or empty objects into the string '[object Object]'!! Seriously!
  The most bizarre part is that this behavior differs according to the JS interpreters (I used node.js), when it should normally raise an error, that's the only sane thing to do.
  
  PS you do realize we're talking about a coercion system so broken that the initial equality operator ('==') evaluates almost everything to true!
• Inappropriate syntax: JS shouldn't have adopted this C-like syntax, especially when it uses curly braces both for block delimiting and objects literals. Couple this with Automatic Semicolon Insertion (an "insanely stupid idea") and mayhem ensues, These 2 bits of code behave very differently:
  

  def foo() {
      return {
          something: 5,
          somethingelse: 6
      }
  }

  And

  def bar() {
      return // a semicolon is automatically inserted here.
      {
          something: 5,
          somethingelse: 6
      }
  }

  The function 'bar' will not return the object, but 'undefined'. No error will be raised whatsoever, JS will continue its execution and several lines below ... BAM! Everything goes wrong. (you can read more about it here)
  
  Speaking of crappy syntax, I am okay with the concept of wrapping a block with self -invoking anonymous function, but would it be too much to ask for a special syntax for it? This is seen all the time in the language, can't we just give it a fancy name, a keyword and be done with it? Or do people actually enjoy this?

  (function() {  ...; })());

• Weird type wrappers: Take a look at the following code:
  

  var x = new Boolean(false);
  if (x) {
    alert('hi');  // Shows 'hi'.
  }

  If you're thinking "x is an object of type Boolean and of value true" you're wrong. It's an object that contains one method called valueOf which returns "true" when called. When you only evaluate x, it returns true.
  
  Did you know that typeof(new String("hello")) is the same as typeof(new Number(10))? If you compare them (with a triple equal sign of course) you'll get the value true.
• No overloading: You cannot overload function and operators, nor can you extend native types. I don't know if that's a mistake or not, but coming from a Python environment I find this feature pretty neat. I'm still looking for JS's alternative to calling the same function on different arguments, but unless I find something cool, I'll still consider this to be a flaw in the language.

The list could go on. There're many things that are wrong with JS, and if someone cannot see it, he either never did anything real in JavaScript or has never played with a truly powerful language (I suggest giving something like Python, Lua or Common Lisp a try).

The libraries Kassem mentioned are JS libraries/frameworks not jQuery.

And it doesn't matter. I still recommend becoming very comfortable with JavaScript before using them. Note that I am the first one to argue that you should be using framework in your programs, especially when developing websites. What I think is wrong is to imagine that you can learn a JS framework without knowing JS good enough.
I don't know how Django works, but I know Python (relatively) well. If something goes bad, I have the ability to open the source and start reading. Then I'm not afraid of using it.

To better understand the quirky parts of JavaScript, I highly recommend JavaScript Garden.

@ramiraz: you make good points, but I'm still not entirely convinced.

Don't add objects

ramiraz wroteyou should not add objects to each other.

This is an annoying limitation, but I could learn to live with it. My problem with coercion is when it happens unwillingly. Sure it's obvious in the examples I gave, but what about adding the results of two functions?

In theory function A and function B both return numbers, so A() + B() should return a number as well. For whatever reason, function A returned an object, would it be too much to ask to throw an exception?

The other solution (which is what I'm doing in JS to circumvent this) is to manually check for the type with typeOf. I shouldn't have to do this, or else at least give me (optional) static typing.

Don't use new

ramiraz wroteYou don't need the new operator unless you want to attach properties to your value, which rarely if ever happens (why would you want to add a property to a number? or a string? or a boolean?)

You seem to assume that all JS code you encounter will be code you are writing. What if you're working on somebody else's code? new is one example of several constructs in JS that are too ambiguous. This ambiguity is coupled with an extremely permissive interpreter that will do anything to avoid throwing an error (including modifying your data!).

This introduces a high risk of subtle errors that become hard to catch. A language (especially one claiming to be "dynamic") should be easy to read and ideally unambiguous.

Don't use it alone

ramiraz wroteThe recent boom in frameworks and libraries has shown how powerful it can be.

I think it's misguided to cite popularity as an argument for quality (isn't PHP one of the most popular languages still?). But even so, I think (and this may be a personal bias) that JS success is largely due to the tools it developed, mainly JSLint and the rest of Crockford's suite.

That's a bold claim, especially since, arguably, every popular language comes with its own tools and ecosystem. I still believe that, even in comparison, JS owes a lot to the tools it packs to overcome its annoying quirks.

Conclusion

ramiraz wroteYou can probably find a million things about JavaScript that you don't like, which is ok, everybody has preferences. But to go as far as saying it sucks it just plain wrong. [...] would you blame clay if the potter made defective pottery? It's just a tool and it can be as good as the developer using it.

I don't think that JS sucks completely, just parts of it. And we may all agree that we need to use a subset of the language ("the Good Parts"), but that's only going to limit the Bad parts, not eliminate them.

I cannot blame clay for defective pottery, but as a potter I can argue that ceramic is better than clay. And just to make it clear: I really don't think JS sucks as a whole. But would I have been happier with something like Lua inside the browser? Oh definitely yes, a billion times yes.

Different notes

(Completely different) Note: You are being overly aggressive, you are moderator damn it you should set an example for others.

My aggressiveness is geared towards the language, I don't mean it to be personal. I apologize if it came out this way, I surely did not intend it to be.