Hacker News new | ask | show | jobs
by asto 5085 days ago
The reason javascript won't get nearly as much ridicule as PHP is because there's no other choice with javascript. Most arguments against PHP are in the form - I'm using <super awesome language> because PHP has .... faults.

Also, the fact that very few people code pure javascript, instead choosing frameworks like jquery, goes to show how much people like it!

3 comments

I second this. Javascript is a dumpster-fire of a language, as is PHP. If I could use anything other than javascript for scripting in the browser, I would, but I can't. So I use it. I can use things other than php on the server, so I do.

However, I'd say the use of libraries and frameworks help javascript programmers, for sure, but that doesn't make the language any less of a mess (and in some cases, like jQuery setting "this" to whatever the hell it wants, makes it more of a mess). I can't speak for php, because I've used it far less, but I suspect the same holds true there, too.

I'm unclear what in particular is such a mess about Javascript?
Javascript's maze of type coercion rules produce results which manage to be frequently wrong but in ever more bewildering ways only slightly less crackheaded than PHP. It's also saddled with Java's inexcusable "everything is an object, except for all the crap that isn't" philosophy. http://wtfjs.com/ is a growing list, but a few of my favorites:

  [] != []
  [] == ![]
  {} + [] is 0
  [] + {} is "[object Object]"
  {} + {} is NaN
To be exact, {} + {} is NaN only when used as a statement. In fact it is equivalent to {}; +{} which results in the last statement being evaluated as NaN. When you put parentheses around it (e.g. ({}+{})) it evaluates to "[object Object][object Object]", which should be obvious from [] + {} if it were indeed obvious.
Yeah, the people talking about this are talking about it due to a five-minute lightning talk, and honestly it really bothers me that he is making people think that adding two objects together has that behavior when in fact it has nothing to do with objects at all: it has much more to do with automatic semi-colon insertion than with scary type conversion.
Clearly my comment has annoyed someone. I'm actually quite serious though; rather than voting me down, perhaps an answer (or even just a link!) would be more useful to the discussion at hand.
I have not read the book, but I'm told that (despite being only 176 pages) half of that book actually talks about language flaws and bad parts and only half of the book is actually about the good parts. Again, have not read it, just what I was told.
There is are a couple appendices at the end that discuss the truly terrible and the simply bad-but-work-aroundable parts. Most of it is discusses the subset of the language that is powerful and expressive. He starts the book off by saying "Javascript is a steaming pile of good intentions" which pretty much sets the tone for the rest of the book.

You should read it. It IS very short and can be read in one sitting. Then you wouldn't be left to trust the word of others.

> Also, the fact that very few people code pure javascript, instead choosing frameworks like jquery, goes to show how much people like it!

I'd say most languages are coded in frameworks and not just the "pure" language.

Sorry, your point about jQuery is off the mark. jQuery is a library (not a framework), and if you are not using libraries you are most likely doing it wrong, in any language!

jQuery does nothing to alter the language, so people using it are still coding pure JavaScript. jQuery itself is implemented in pure JavaScript.

----

There does exist variants of JavaScript, such as Paper.js, Protovis and maybe even CoffeScript, but these are not what the majority of JavaScript users use.

I'm not so sure whether jQuery can be considered a framework or not. If you're using jQuery properly ($(document.ready).ready() and so forth) jQuery behaves very much like a framework, with inversion of control and other patterns.

JavaScript in the browser has access to the standard JavaScript and DOM libraries. I really don't think that not using any third-party libraries in any language means "you're doing it wrong". Pure JavaScript/DOM can go a very long way (especially in these days of more standard-compliant browsers), just like pure Objective-C & Cocoa or pure C# & .NET.

Finally, while obviously jQuery does not alter the language, it really changed how people approach problems in JavaScript. Code that uses jQuery looks nothing like code that doesn't use it.

jQuery is big and important and has lots of features that you can use or decide not to use. However, if you decide to implement simple animations yourself in a situation where jQuery would have been a fit, you are likely wasting time and effort.

Using jQuery for this does not mean that you like or dislike the language. That was the point I was trying to refute.

Animations is of course also not the only problem you can solve by using jQuery as a library every now and then.

----

For what it's worth, I don't think jQuery qualifies as a framework in the definition on Wikipedia ( http://en.wikipedia.org/wiki/Software_framework ), but this is besides the point.

The difference between library and framework is quite subtle sometimes and in this case many use it interchangeably. You are correct though, jQuery themselves call it a library.

I don't agree to "does nothing to alter the language" though. It changes the way you manipulate DOM across your codebase. When one says 'library', I assume it's something you make calls to to achieve certain functionality. Like an image library or oauth library.

Also, that jquery is implemented in javascript is not relevant in my opinion. Rails is implemented in ruby. Does that make it not-a-framework?

OK, then we have different understandings of what makes a language.

You said: "the fact that very few people code pure javascript (...) goes to show how much people like it!"

I argue that using jQuery does not change the "pure JavaScript"-ness of any code, just like using Rails does not change the "pure Ruby"-ness of any code, just like using libpng does not change the "pure C"-ness of any code. In every case, it's all in one language anyway -- therefore it is pure in that language.

This comment is not intended to be an argument either way. I am just trying to clarify exactly which point of view I have been trying to argue :)