
For modern development Javascript indeed is a shit language - CmonDev
http://live.julik.nl/2013/05/javascript-is-shit
======
jashkenas
Despite most of the points in this post being debatable — there's one bit that
caught my eye:

    
    
        "Being nice will not help it, and CoffeeScript is not radical enough."
    

As the guy who started CoffeeScript, I agree. It's an intentionally very
conservative approach. But there's more than one good way to skin the
JavaScript cat. I think it would be fun to take another run at the same
problem — attempt to find a minimal, readable, and easier-to-learn language
that fits in the same role as JavaScript — but to do so with a _much_ more
radical design. Whereas previously such a thing would have been unusable in
practice, having good sourcemap support in most browsers these days makes it
viable, perhaps. I've been playing around with it a bit...

~~~
ChrisAntaki
CoffeeScript was obviously inspired by Ruby. While CS is great, I've never
gotten over the usage of "->" or "=>" to signify a function. To me, Ruby's
"def" or "do" reads so much better. Especially with "end", to signify a
barrier, as opposed to whitespace. Have you considered porting Ruby directly
to JavaScript?

By the way, thanks for your work on _ & Backbone!

~~~
jashkenas

        > Have you considered porting Ruby directly to JavaScript?
    

No. It's been attempted before, and it doesn't turn out to be terribly useful
in the end, because of the _vast_ semantic mismatch between the two languages.
See: [https://github.com/jashkenas/coffee-script/wiki/List-of-
lang...](https://github.com/jashkenas/coffee-script/wiki/List-of-languages-
that-compile-to-JS#ruby)

    
    
        > I've never gotten over the usage of "->" or "=>" to signify a function.
    

Give it a try, perhaps. It's _critical_ not to use "def" and "do" when your
functions are first-class values that can be passed as arguments, or assigned
to variables. It's for this reason that Ruby 1.9 has a new lambda syntax that
looks a great deal similar to CoffeeScript's. For example:

    
    
        request(url, def callback(response) do
          ...
        end)
    

... that kinda thing is no good.

The reason it's an arrow is because in any decent function, the input
determines the output, eg. input points to output. And therefore, the
CoffeeScript syntax: (input) -> output

~~~
ChrisAntaki
>> it doesn't turn out to be terribly useful in the end

True, I'd chose CoffeeScript over Opal.

>> Give it a try, perhaps.

Oh, I dig it, especially the fat arrow.

>> It's critical not to use "def" and "do" when your functions are first-class
values that can be passed as arguments, or assigned to variables.

Still, I find "def" to be more `readable` than arrow symbols. I'm not sure how
JavaScript's first class status for functions would deter a keyword containing
letters. Considering JavaScript itself uses _function_ as its.

>> The reason it's an arrow is because in any decent function, the input
determines the output, eg. input points to output. And therefore, the
CoffeeScript syntax: (input) -> output

That definitely makes logical sense. Still, I feel the readability might be
increased by using words, which the mind is more attuned to quickly applying
meaning to.

Edit: Great job, on CoffeeScript, regardless!

------
rdtsc
Sadly I agree, you can just start with this:

    
    
        > [1,10,5,-15,-2,4].sort();
          [-15,-2,1,10,4,5]
    
    

And yes saying "oh but it is because it has weak types" doesn't excuse it, it
is broken and that's that. Naming the brokeness with a label or showing why
historically it is there, doesn't fix it.

On the other hand they do have nice closure support, I do like some of that.
But in large, the language makes me angry every time I have to use it.

Someone mentioned Dart, I am hopeful for that. But who knows how long till
dartvm is embedded in Chrome. For now dart.js and source maps might help.

There is a bit more palatable Coffeescript. But it only puts some band-aids
over JS's brokenness.

Also agree with callback hell. It is funny people extol is at the next big
thing -- whoo, asynchronous calls! You can callback in your callback while you
callback. No, no, no. That is a horrible way to handle large concurrency
problems! (Good for quick one page examples though!). Async and friends help.
But why the heck do I need to stick a callback in the middle of my logic if
all I need to do is make a request to the database or another GET request?

The only sane way I know how to best handle concurrency is using a language
with support of goroutines/isolates/tasks or even threads and queues. Even
deferreds are just sugar on top of callbacks. We all know how Python's Twisted
has taken over the world, right? Oh wait, it hasn't. Calling them Futures or
Tulips or whatever doesn't fix the underlying problem.

> I can understand that some people wanted to escape the MRI infrastructure by
> going Node, because - you know - learning Japanese is hard.

Granted node is fast. (And according to its author scales linearly across CPU
cores, sorry couldn't resist the mandatory jab at that). Ok it doesn't really
scale across cores and it will block everything if you do a for loop in the
middle of your logic. But it is really fast, amazingly so. And that is like
crack. It gets people hooked.

EDIT: JS has weak types not just dynamic, one can have dynamic and strong
types for example, like Python (
[https://en.wikipedia.org/wiki/Weak_typing](https://en.wikipedia.org/wiki/Weak_typing)
). Thanks makslinn.

~~~
masklinn
> And yes saying "oh but it is because it has dynamic types" doesn't excuse it

It has _nothing_ to do with dynamic types[0]. It has to do with

> If compareFunction is not supplied, elements are sorted by converting them
> to strings and comparing strings in lexicographic[0]

period end of the story. You might argue it's a shitty default, but please
argue against reality, not what you (wrongly) believe it is.

[0] this is the MDN translation, the exact specification is steps 14 to 18 of
the SortCompare abstract operation, defined in ECMA-262 5.1 15.4.4.11
"Array.prototype.sort (comparefn)":

    
    
        13. If the argument comparefn is not undefined, then
            a. If IsCallable(comparefn) is false, throw a TypeError exception.
            b. Return the result of calling the [[Call]] internal method of comparefn passing undefined as the this value and with arguments x and y.
        14. Let xString be ToString(x).
        15. Let yString be ToString(y).
        16. If xString < yString, return -1.
        17. If xString > yString, return 1.
        18. Return +0.
    

[0] your edition to "weak types" is just as wrong as the previous version I
quoted was.

~~~
rdtsc
The correct answer is it has to do with weak types.

> `If compareFunction is not supplied, elements are sorted by converting them
> to strings and comparing strings in lexicographic` period end of the story.

As I said explaining the historical context or labeling the brokennes with
something like "weak typing" doesn't excuse. It still stays broken.

> You might argue it's a shitty default, but please argue against reality, not
> what you (wrongly) believe it is.

Surprise, I know it is possible to eventually sort things in JS. I too have
seen sorted tables in JS done entirely in JS. That's not the point. The point
is, it is has fundamentally broken type system.

~~~
masklinn
> The correct answer is it has to do with weak types.

No, it does not. You could define the exact same default function in Java,
Haskell (requiring that the sorted type be a Show instance) or Python (hell,
getting the exact same behavior in Python could hardly be simpler:
`ar.sort(key=str)`. There, I broke it. That is near literally how the
ECMAScript spec _very explicitly_ defines the default comparison function. The
behavior of the sort function is _not_ a consequence of weak typing).

> As I said explaining the historical context or labeling the brokennes with
> something like "weak typing" doesn't excuse.

Which you'd know is not what I'm doing, if you could be arsed to read instead
of trying to substitute your imagination for objective reality.

> The point is, it is has fundamentally broken type system.

That might well be, but the default sort comparison function is not a
demonstration of it. As opposed to the comparison table of 0 and null for
instance:

    
    
        > 0 < null
        false
        > 0 <= null
        true
        > 0 == null
        false
        > 0 >= null
        true
        > 0 > null
        false

~~~
weland
> No, it does not. You could define the exact same default function in Java,
> Haskell (requiring that the sorted type be a Show instance) or Python (hell,
> getting the exact same behavior in Python could hardly be simpler:
> `ar.sort(key=str)`

I don't use JavaScript but to me this looks like a really broken
implementation over weak typing. Of course, this isn't a trait of the typing
system per se as it is a trait of the "interface", if you will, that it offers
to the programmer.

What OP was probably annoyed by was the typical excuse the JS community offers
for this behaviour: "it's weakly-typed so you can treat the arguments as
anything you want". This misses the point of having a weak typing system:
instead of using it to infer the type of the arguments and get a sane default
comparison function, avoiding the verbosity typical of strongly-typed
languages (where you have to specify the comparison function with the correct
type signature), you have to specify the comparison function for anything that
isn't a string. Bummer :-(.

I hope I haven't missed anything here; as I said, I'm not quite fluent in
JavaScript.

~~~
masklinn
> this looks like a really broken implementation over weak typing

No dammit, javascript does not coerce numbers to strings when comparing them,
a "weak typing" implementation would behave exactly as he wants.

> What OP was probably annoyed by was the typical excuse the JS community
> offers for this behaviour: "it's weakly-typed so you can treat the arguments
> as anything you want".

That makes OP fractally wrong instead of merely broadly wrong.

> avoiding the verbosity typical of strongly-typed languages (where you have
> to specify the comparison function with the correct type signature)

Which you don't, not every language is Java and some actually have defaults.
Which work. In fact, even in Java bloody java you don't have to provide a
comparator to sort a list, as long as the list's items implement Comparable
(that is, they can be compared to one another)

~~~
weland
> No dammit, javascript does not coerce numbers to strings when comparing
> them, a "weak typing" implementation would behave exactly as he wants.

Please note that I wrote it's a broken implementation _over_ weak typing, not
_of_ weak typing. The typing system is fine, at least as far as this matter is
concerned, but the standard library is badly applied over it.

~~~
masklinn
> Please note that I wrote it's a broken implementation over weak typing, not
> of weak typing.

But weak typing is a complete red herring, as I noted previously the behaviour
of the default sort function is independent from the typing system, you could
have a default sort function doing more or less the same thing in a very
strict statically typed system.

Haskell's `sort` is defined (more or less) as

    
    
        sort :: Ord a => [a] -> [a]
        sort = sortBy compare
    

it could be (uselessly) defined as

    
    
        sort :: Show a => [a] -> [a]
        sort = sortBy (comparing show)
    

resulting in the same behaviour you see in javascript.

~~~
weland
Yes, of course it is a red herring! OP's rage was against the JS community
taking it as an excuse for shity implementation, that's all I was trying to
clarify...

------
gkoberger
Personally, I disagree. I find JavaScript to be the most "write-able"
language, and switching to Node + frontend JS as my main language (I've done
Python, Ruby, PHP, Java and C++ as jobs) has been the best thing I've done in
a long time. Express and Angular are amazing.

Sure, it has a bunch of quirks. Sure, it's not good for everything (I do
mostly relatively simple CRUD apps). Sure, in the browser, it gets slow when
the DOM is involved. Sure, this is hardly a rebuttal of the points in the
original article.

But, still, I love JavaScript.

I think the problem is that the author is writing JavaScript as though it's
Ruby. A JS developer switching to Ruby would have similar problems.

~~~
drakaal
I see this all the time. JS is slow because of the dom. No. JS is slow because
JS is slow. Yes, I know V8 makes it faster than it used to be. Yes I know it
is neck and neck for computation, but because of the way memory is handled it
is slow for loading large dictionaries.

But I could forgive all of that.

JavaScript is not well designed for work in a team environment, nor is it well
designed for Large Code Bases.

But I could forgive all of that.

All the best languages have a group of scientists that have chosen that
language to be their defacto language. That is why we see Python, LISP,
Fortran (yes still), MatLab, all living on long beyond the "trendy" languages.

JS only picked up steam because Flash died. Not because it was a great
language. If it were a great language people would have started optimizing it
5 years ago. It isn't. So they didn't. The new optimizations are out of
necessity. And because it lets front end pretend to be backend. That may sound
snobby, and it is, but JS for backend is like writing in Visual Basic. These
days you can do anything in it, it will be fast, but that doesn't make it the
right choice.

~~~
w0utert
>> _JS only picked up steam because Flash died. Not because it was a great
language. If it were a great language people would have started optimizing it
5 years ago. It isn 't. So they didn't. The new optimizations are out of
necessity. And because it lets front end pretend to be backend. That may sound
snobby, and it is, but JS for backend is like writing in Visual Basic. These
days you can do anything in it, it will be fast, but that doesn't make it the
right choice._

Very much ^this.

I never cease to be amazed by the defensive attitude and excuses coming from
JavaScript developers. Usually the premise is "I can get shit done in it, so
it must be good", which isn't a particularly strong argument.

If you would make up 20 completely different metrics to rank programming
languages on, and score every popular language using each of them, JavaScript
would be near the bottom of almost all of them, and near the top of none. It's
not terrible in _every_ way imaginable (it would score reasonably well on
'productivity' for example), but it's not great in _any_ of them either, which
frankly makes it a shit language that only exists as a historical accident.

~~~
k__
I wanted to switch to other languages rather often, but most of them are
getting strange quite early in the learning process.

------
pkorzeniewski
I'm so tired of hearing how bad JS is as a language - guess what, it doesn't
metter. The ecosystem and community is absolutely amazing and that's something
you just can't beat - all the well documented, polished and maintaned
libraries, frameworks etc, the amount of books, guides, conferences and so on,
the ability to use JS everywhere, tools, services, cloud based solutions and
much, much more. That's why people create all the amazing stuff and all of
this results in one of the most important things - development speed. Sure, JS
has a lot of quirks you need to be aware of and it's easy to write bad JS, but
with some experience, you can rapidly write a maintainable, easy to read,
flexible and modular code.

~~~
marrs
Yeah, same here. I have no difficulty writing large scale apps in JS because I
play to its strengths and manage its weaknesses. These shit-for-brains
"experts" can't, and somehow it's all the language's fault.

Here's a clue folks: you're the programmer, it's your job to work out how to
programme for your target platform, and if you can't then fuck off and leave
it to the professionals.

~~~
CmonDev
"it's your job to work out how to programme for your target platform" \-
exactly, but there is an active effort to try and put the JS garbage on each
and every target platform!

------
curveship
> a function is not an object, not a datastructure that can carry data

Wait, what? That's the definition of a closure.

Most of this seems to boil down to the author saying "my programming brain was
hardwired by Ruby, and I'm annoyed JavaScript is different." OK, I feel your
frustration. As a reader, though, I'd far rather see a post from someone who
has spent the time to become proficient in both ecosystems and can offer more
considered pro/cons.

On one point, I'll agree: I wish Javascript had an easy way to say
"referencing an undefined property of this object should throw an error."

------
annnnd
I have always wondered why so many people like dynamically types languages...
I mean, if I have a variable I ALWAYS know what kind of data I expect in it.
If I try to use different kinds of data in the same variable then something is
clearly wrong - either with me (for wanting that) or with the way I use the
variable (and I would appreciate some warning about it).

The problem is that you hardly have a choice nowadays. Python, JS and PHP are
dynamic, Java is a great language but crappy concept (don't tell me it isn't
slooo... <wait for GC... ok, done> ...ow). Ironically, the ugliest language I
have ever coded in (ObjectiveC) has the best design decisions (IMHO). ARC
instead of manual memory management or GC, strongly typed but still allows
generic object pointer (id),...

~~~
pdonis
_I have always wondered why so many people like dynamically types languages_

Because you don't have to write a lot of boilerplate to tell the language
things that it should be able to figure out for itself.

 _I mean, if I have a variable I ALWAYS know what kind of data I expect in
it._

But that data might not always be of the same type. For example, in Python, I
might want a variable to hold strings but also None, so that I can
differentiate between, say, "the user explicitly entered an empty string" and
"the user hasn't entered any string at all yet".

Yes, there are ways to do this in statically typed languages (for example,
Haskell's Maybe), but it's still extra code that I have to write.

~~~
annnnd
> Because you don't have to write a lot of boilerplate to tell the language
> things that it should be able to figure out for itself.

This is exactly my point; compiler can't figure out what kind of data I want,
at least not in general. A good example is jQuery $.data() which tries to
guess what kind of data you have in your HTML tag attribute. Guess what
happens if you have a MongoDB ObjectId (as string), for instance
"52259986890d6f24e9000000"? Exactly - it is a floating number. Believe me, it
leads to some interesting debugging sessions... :)

I agree with you however that it is beneficial to have a way to set the var to
None/null/..., indicating "not initialized". Win some, lose some I guess.

~~~
pdonis
_Guess what happens if you have a MongoDB ObjectId (as string)_

But that's a matter of semantics, not static typing. You're going to have to
do type conversion on the string regardless, because "MongoDB Objectid" isn't
a native type for the compiler. But with static typing, you need to tell the
compiler the type of the variable _in addition_ to telling it how to do the
type conversion: for example, in C++, you might have to say...

    
    
        var MongoObjectid id = new MongoObjectid("somestring");
    

..whereas in Python, for example, you could just say...

    
    
        id = MongoObjectid("somestring")

~~~
annnnd
> You're going to have to do type conversion on the string regardless, because
> "MongoDB Objectid" isn't a native type for the compiler

My point was that jQuery .data() tries to guess how to handle strings and
misses in some cases, because the strings are too similar to numbers. The fact
that this particular string was a MongoID is actually not relevant to the
problem, it just illustrates that this is a real-world problem.

------
gexla
It's interesting to see so many people say "JS is great and we used it to
build X" on one side and people who hate JS on the other side.

Obviously Node (and JS) has some things that it is strong in. People use it to
build those things. Good developers won't use a tool in their box which is
inferior to another tool they can use effectively. In between, there is a lot
of room for "good enough" where tools overlap.

I think some developers are able to largely stick with a certain tool because
development goes in waves. I can spend multiple months on a certain profile of
work and then get hit with the same type of project a couple more times. Maybe
by then I become an expert with that thing and I just keep doing those sorts
of projects. You might think I'm crazy because I'm a "Node developer" but you
probably don't know the nature of the work that I do.

Eventually I get hit with a different project and everything falls apart if I
try to keep using the same tools as I had been using. So, I curse myself for
being stupid and wasting time and start over with the tool I should have been
using in the first place.

Some developers might have such a limited set of tools that they can't (or
won't even try) to switch.

"So, I landed a big gig for the government. It's a healthcare site. I'm going
to build it in Wordpress."

Following this thread further, look at some of the selling points of Node.

* It's great because as a front-end developer, you probably already know JS. With Node you can use JS on the back-end also!

* Because the front-end and the back-end are both in JS, I can use one programming language and re-use libraries for each side.

Great, let's encourage people who only know one programming language and a
limited range of tools to just stay in that box.

There are things that X tool does well. There are things that X tool is
horrible at. Perhaps rather than ragging on Node, the author should write an
article explaining that developers should be expanding their tool-set so they
have flexibility in handling different types of problems.

~~~
solomatov
>Obviously Node (and JS) has some things that it is strong in. People use it
to build those things. Good developers won't use a tool in their box which is
inferior to another tool they can use effectively. In between, there is a lot
of room for "good enough" where tools overlap.

People use JavaScript not because it's good but because it's the only option
to develop in a browser. Having the same language on the client and the server
is a very strong point, that's why they use NodeJS.

~~~
sneak
> Having the same language on the client and the server is a very strong point

Only if you're so incredibly strapped for cash that you can't hire real devs
that can pick up another language in a day or two.

Almost every language used commonly on the serverside is vastly preferable to
js.

This whole "well, it's THE SAME" benefit simply isn't. It's a red herring.

I'm convinced the whole ecosystem has sprung up because of hordes of terrible
copy-paste browserside devs that don't actually fully understand what they're
doing in js, who resultantly would be incapable of building anything
serverside in another language at all because their overall comprehension of
programming is marginal at best.

Anyone not stupid or insane just learns ruby or python or scala or go or even
php or .NET.

PS: cue replies from all dozen people on the whole internet who know pointer
math and still like coding webapps in js, who don't realize that I'm not
talking about the 12 of them but the 12,000 who are doing the js/node problems
on codeacademy this instant.

~~~
benaiah
> Anyone not stupid or insane just learns ruby or python or scala or go or
> even php or .NET.

I _started_ with PHP and C#/VB.NET, before learning JS. I know Python, Scheme,
Java, I've played a bit with Clojure and Ruby[0]. After all that, JavaScript
(admittedly, usually through CoffeeScript) is my favorite language. It
provides everything you need to build almost anything you want, wrt tooling.

I understand and agree that it has warts, as does every language. But to call
its use "stupid or insane" is ridiculous.

[0] I have yet to understand the concept of blocks, as they seem to be just a
half-assed implementation of first-class anonymous functions. If someone can
show how they improve on them, that would be much appreciated.

~~~
sneak
....aaaaand scene. Cut!

~~~
benaiah
I have literally no idea what you meant by this.

~~~
sneak
You didn't miss your cue, and delivered your lines perfectly. We're done for
the day, we're not bringing in Eevee[1] and Dziuba[2] to shoot the "every
language has warts hahaha what are you, a noob?" scene until tomorrow.

You did great, thanks again. Don't call us, we'll call you.

[1] [http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-
de...](http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/)

[2]
[http://pages.citebite.com/b2x0j8q1megb](http://pages.citebite.com/b2x0j8q1megb)

------
masklinn
> They are not solvable by making a new ECMA spec.

As it turns out, many of the issues outlined are not only very much solvable
by making a new ECMA spec but either already solved in ES5 or solved in ES6.

> JS has callable attributes

> This is a shitty design decision

I strongly recommend not following the provided link, which is basically
inane, uses the term "slots" in a rather disturbing manner and makes
completely incorrect assertions e.g.

> Self [is] slot-based. This gives one substantial advantage: not having to
> specify that you want to move a block of code as a value explicitly. So you
> can do, for example in JS
    
    
          // boom! we transplanted a method
          someVar.smartMethod = another.otherMethod;
    

to my knowledge, you most definitely can not do that in such a manner in Self.
Slots manipulation in Self can only be done through primitive messages (e.g.
`_AddSlots:`, which takes an object whose slots should be copied into the
receiver).

> Hobjects are unusable for stable keys

> The mixup between objects and hashes is also a very bad idea, because it
> defies the premise that objects can have metadata on them - which alllow you
> to establish a rudimentary type system or at least any kind of
> introspection.

Magnificent baseless assertions. Javascript allows for object metadata through
the prototype, or through properties
(Object.defineProperty/Object.defineProperties) which — amongst others — allow
setting non-enumerable properties. ES6 also introduces the concept of names.
I'm not saying maps-as-objects is great, but I am saying these assertions are
1. wrong and 2. nonsensical.

> Fobjects are unusable for type systems since an object does not carry any
> type information.

> This one is a biggie. Even in the Ruby world, where everything is happily
> quacking like a duck, we often use the Object#class to get information about
> an object.

In ES5, the exact same behavior is provided by Object.getPrototypeOf providing
access to the internal [[Prototype]]. Most implementations also provide direct
access via the __proto__ property, which IIRC ES6 standardizes. And of course
the `instanceof` operator has been there since ES3, but that's only ~13 years
ago.

> Nothing will happen. Since ojects are hashes[...], our constant with the
> wrong key will be undefined, and will happily bleed into the callee. This
> makes stack traces huge.

'Nothing will happen' (and the related "What is the error that you will get if
MyApp.Views.WidgetView is not defined yet? undefined is not a function of
course! [...] And why? Simply because everything is a hash and the language is
incapable of doing any kind of introspection." later) and 'objects are hashes'
have nothing to do with one another. Hashmaps does not actually require
unmapped keys to return nil or undefined. Javascript does because it is shit.
Same for Ruby or Java. Python does not have that issue, accessing an empty key
will raise a KeyError.

> and the language provides zero facilities for constants

All runtimes but MSIE (unless they've added it in IE11) already implement
`const`, and it's standardized in ES6.

> Callback hell

> [...] In a normal situation this would have been fixed simply by adding a
> wait primitive to the language which would schedule the events when the
> result is still being fetched.

You mean, something like ES6's yield?

> Terrible exception handling

No objection there, javascript may well have a worse exception handling than
Go, a language whose users try very hard to make others believe doesn't have
exceptions in the first place. At least runtimes are finally trying to
generate callbacks worth reading.

Not that this help when mixing with async, as your final traceback will lack
90% of the necessary context.

~~~
CmonDev
ES6 has not been finished yet as far as I know.

~~~
masklinn
It is not[0], but when TFA asserts

> They are not solvable by making a new ECMA spec.

I consider using the upcoming ("new") ECMA spec more than fair game to refute
his assertions.

[0] although a number of its features are shimable, precede it by a few years,
are already (possibly partially) implemented in some runtimes or are available
through ES6 -> ES5 compilation via Traceur. See
[http://kangax.github.io/es5-compat-
table/es6/](http://kangax.github.io/es5-compat-table/es6/)

------
me_bx
Aren't all these rants about programming languages as sterile as debating
whether Spanish language sucks because it is not as regular as Italian
language ? I really don't get it, people keep attacking issues of javascript
or php. Fact is: 1) people use the languages of their choice to make programs.
2) Programs work, no matter as shitty the program is reputed to be 3) why look
further ?

My view is: instead of ranting about languages (think about the meaning of
that word), why not instead dissect what we do with them: programs, and find
ways to improve them ?

~~~
Peaker
> why not instead dissect what we do with them: programs, and find ways to
> improve them ?

The way to improve a lot of programs is to write them in a different language.

~~~
me_bx
Another way is to fix/tune the algorithm

~~~
Peaker
That may hit an upper bound, above which you have to rewrite in a different
language. That upper bound may be quite low.

------
Kiro
I'm very glad JavaScript is the language of the web. It has a combination of
things I like that I don't find in many other languages:

* lexical scope

* first-class functions

* prototypal inheritance

~~~
tomlu
Not many languages have prototypal inheritance, but most modern languages have
first class functions these days. And what sane language uses dynamic scoping?

~~~
pmelendez
Do you mean lexical scope? Scheme has it and it is awesome. If you think it is
not a good feature you should grab a SICP and see the magical stuff you can do
with it.

~~~
lmz
He is asking what other sane language does _not_ have lexical scope, as that
was listed as one of JavaScript's advantages.

~~~
pmelendez
Oops you are right... I read it backwards, I can't edit it anymore :(

------
potch
This article reads like this comic:
[http://imgs.xkcd.com/comics/rock_band.png](http://imgs.xkcd.com/comics/rock_band.png)

 _goes back to happily writing JavaScript_

------
headgasket
You are holding it wrong.

No seriously, you might be trying to use a fast glue/prototyping/event
processing and browser deployed language to do something that should be done
in a different environment. If your core logic task is algorithmic, consider C
or Go and call that from your event framework. If it's data integrity/type-
safety related, consider using your sql dialect.

(not a flamebait, but nosql is just a big distraction, please seriously
consider postgres, it rocks, esp with json and plpgsql stored procedures that
can be used to enforce data integrity braces and as independent unit testing
for your data structures)

AngularJS, Express, node, and postgres is the most potent combination I've
used in a long time.

Cheers,and good luck! F

------
prottmann
Yes, JavaScript is terrible. But JavaScript is not the end of programming
languages, it is a step for the next big language.

I think everybody agree that different languages for frontend / backend
development are the not the best solution, so JavaScript is a big step
forward.

But i think soon it is necessary for a complete rebuild for a new language,
with all the things included that we learned and invented from the "old"
languages.

Dart, TypeScript, Coffescript, and the 1.000 other language Modifications /
frameworks try all to fix a little part of the problem. Thats nice but
annoying too.

------
k__
Is Dart an alternative for those problems?

Edit: I mean stuff like "callback hell", does it allow me to programm normally
and still avoid blocking the loop?

~~~
Lazare
If you're doing frontend dev, then you must use Javascript or a language which
compiles to Javascript. I believe Dart currently has a mostly functional tool
to compile Dart code to Javascript.

As for callback hell, Dart has "Futures" which are basically Promises. If you
like Promises, you could use Dart...or one of the many excellent Promise
libraries for Javascript; the syntax is almost identical.

(The linked article savages Promises for no obvious reason. I happen to like
the syntax. In any case, Dart uses the same syntax, so if you buy the articles
criticisms, Dart is no panacea.)

~~~
nbevans
The "syntax" of promises in JS and Dart isn't really a syntax. They are
library features in the form of fluent method chaining. This is merely a
library pattern, it is not a syntax.

A syntax would be something like the async/await support in C#. Or the async
and let!, do! etc along with pipelines in F#.

~~~
Lazare
A valid point; that just seemed like the easiest way of phrasing it to me.

Anyhow, what I was trying to say is that the linked article trashes Promises,
and Dart has Promises, so Dart is at least in that respect not a solution.

~~~
k__
And this aspect is one of the biggest problems I got with JavaScript.

The only big things, which Dart seems to solve, is modularization and the many
tiny JavaScript quirks, for which IDEs or a strong understanding of the
language is needed.

------
qwerta
As someone who maintains old 1000+ KLOC projects I have to agree. Have look at
some large old Perl projects to see how JS code will look&feel in 10 years.

But on other side I see JS bytecode as great alternative to Java and JVM.
Modern languages usually include JS as compilation back-end.

~~~
dpratt
>But on other side I see JS bytecode as great alternative to Java and JVM.

Exactly how is javascript a better byte code than JVM byte code?

~~~
qwerta
Obviously install base is huge.

------
esamek
For modern development of _what_?

Then don't use Javascript.

I'm not sure I can really appreciate another rant about how one language,
framework, pre–compiler, VM, etc is terrible and everyone should stop using
it.

Javascript's popularity has emerged organically. Its not because it has the
best design. Its because it can get the job done and is browser based–and now
server-side too. The browser is the next OS, the ultimate VM, if you will.

If you just stop picking at it and appreciate it for what it is...it is f'ing
awesome.

~~~
nbevans
It's operating a defacto monopoly on a layer of the modern development stack.
This does not make it "f'ing awesome".

People rant about JS not because it's shit, per se. Everybody knows that. They
rant because they long for better languages that are available across all web
browsers.

I would like to see a standardised CLR-style VM that allows language modules
to be loaded as requested by a particular web page. Otherwise we'll just be
replacing JS with what will probably be another old fashioned imperative
language (see: Rust). We don't want that. We want freedom to use whatever
language we want.

------
telephonetemp
The webpage is difficult to view in the Android Browser (though not Opera
Mini) due to the overlay at the bottom.

[http://m.imgur.com/9eOKqJZ](http://m.imgur.com/9eOKqJZ)

On that note, at what resolution, if any, do embedded code snippets from
GitHub and the like stop getting get cut off on the mobile? At 800x480 they
get cut off even in landscape mode.

~~~
pmelendez
The same happened on a windows phone

------
NKCSS
I don't get the "Fobjects are unusable for type systems since an object does
not carry any type information."

You can just do

    
    
       if(myObjectToTest instanceof typeOfObjectIExpect)

------
jamescun
I don't understand how the author thinks simply calling every little annoyance
"shit", without further explanation, is very constructive.

------
codeboost
Here we go again. Let's enumerate the technologies which are shit: HTML is
horrible CSS is an abomination HTTP is wasteful, slow and old C++ is a
horrible language (Linus Trovalds) C is dangerous Java sucks ..

I'll stop there and let you expand the list if you want.

Turns out the whole computing world is built on top of this terrible tech
which many people hate, yet somehow it's moving forward.

~~~
talmand
All I know after years of being in the tech industry, every programming
language ever invented has pissed off enough people that no one should ever
use each language. I'm quite sure that languages not yet invented has already
pissed enough people already that they'll be hated the day they are released.

Personally, I find such people childish in a way.

It's a tool in a toolbox. I've never seen a mechanic rant about the
substandard design of a standard screwdriver because he pulled it first
despite actually needing a phillips screwdriver.

------
z92
"JS has callable attributes, Hobjects are unusable for stable keys...object
does not carry any type information, Null everywhere, since ojects are hashes"

I find most of the problems listed are related with dynamic type system of JS.
These all can be solved most easily by a statically typed language.

Therefore the debate mostly is between static vs dynamic typing.

~~~
nness
I would also argue that expecting an object to carry type information is an
unfair expectation of a non-object-orientated language.

~~~
gnaritas
JavaScript is an objected oriented language.

~~~
Fr0styMatt
Not really, from what I gather it's closer to a functional language that lets
you implement objects with private data by using closures.

~~~
gnaritas
Yes really. It's an OO language based on Self's prototypical OO model rather
than a class based OO model. Prototypical OO is still OO, unless you're
claiming Self isn't OO, but the Smalltalker's who invented Self would very
much disagree. Prototypes are objects, no closures or classes required.

~~~
Fr0styMatt
Ah, I stand corrected, thanks. Makes sense; I think I had something about
private vars in JavaScript and closures running through my head and confused
it with 'JavaScript does OO with closures' :)

~~~
gnaritas
No problem.

People who don't like or get prototypes have certainly reimplemented classes
with closures, but classes are not a requirement to be OO, objects are;
classes are just one way to do it, prototypes are another. Objects don't
require classes, though many a JavaScript programmer thinks so.

------
tluyben2
No matter if I agree with this or not; why the stab at Java there? I'm not
sure what the resemblance, besides the name, is here? Or does OP just dislike
Java (for some completely different reason) and could it just have as well
been Perl or PHP or whatever a lot of people don't like?

~~~
Ygg2
Date API (old, not the new one that is arriving) was taken from Java. And Date
library in Java is frankly... horrible.

------
fridek
Google Closure Compiler + @struct = new property definition outside of
constructor is forbidden.

Or DEBUG_ON && Object.seal(this); at the end of every constructor.

Here, I've fixed "Hobjects" for you.

JavaScript _allows_ you to write shitty code, but whether you do it or not is
just a matter of skills and tools.

------
camus2
\- Unfortunatly you can complain all you want you'll have to write some
javascript if you do front-end development. And today there are quite a lot of
tools (transpilers,linters,etc...) that can help you with that.

Fortunalty you can chose the language you want on the server.

------
chrismorgan
Is it impossible to write an article like this without liberal use of
swearing? Many of the points in the article are quite reasonable, but with the
foul language used in it I cannot bring myself to read it all.

Foul English is far, far worse in my eyes at least than JavaScript.

------
louischatriot
Another rant by a programmer who clearly doesn't understand JS... It does have
its drawbacks (what language doens't?) but if you have some coding discipline
you can code pretty big application without headbanging.

------
goshx
Every time I read an article of someone blaming a language, that is not the
language they love, I feel like I am reading an airplane pilot, driving a bus
and screaming: BUT THIS THING DOESN'T FLY!!!

------
ksec
While I agree JS is a shitty language overall, and worst when writer larger
apps.

Having someone who wrote this on a website that spend 30% of the screen estate
for page footer isn't very convincing.

------
chrischen
I've been meaning to pick up Dart for a new app, but there aren't any great
frameworks for Dart apps yet. It seems Angular is being ported though.

~~~
spankalee
Dart doesn't really need "frameworks" in the way that JavaScript does. The
core libraries are very rich:

    
    
      * dart:async give you Futures (Promises in JS, no need for Q) and Streams
      * dart:core and dart:collections give you real data structures like List, Map, Set, Queue, LinkedList, LinkedHashMap, etc. Much more comprehensive than underscore.js
      * dart:html is much improved over JS's DOM, and have most of jQuery's functionality (see ElementList).
      * New and upcoming standards like Shadow DOM, custom elements and template binding let you declaratively define your HTML template in HTML with data-binding, which is the foundation of frameworks like Ember, Angular, Knockout, etc.
      * Polymer is a JS and Dart library for helping you write custom elements.
    

Also, the package system in Dart, pub, is very similar to npm and encourages
smaller, focused packages rather than sprawling frameworks.

Check it out, it's a very nice language and environment. But I'm on the Dart
team, so I'm obviously biased.

------
ilaksh
Well, this will probably just be ignored or downvoted, but as far as I can
tell, ToffeeScript (a derivative of CoffeeScript which is a derivative of
JavaScript) is the best language to be programming in today.

Of course "best" is subjective, but I believe that the combination of
Node.js's superior module system and the available packages, the clarity of
the language (which actually surpasses Python) combined with the asynchronous
single-threaded event-based model, and ToffeeScript syntax which makes
asynchronous code read like synchronous code, makes this a superior platform.

I do think that Go is a wonderful evolution of C, but the module system or at
least ecosystem is inferior to Node's, and the language syntax and concurrency
approach (although very useful and better than Node's in many circumstances)
is old-fashioned.

Many people don't trust, don't learn, and ultimately cannot objectively
evaluate JavaScript, simply because it is too easy to use. [sarcasm] And
everyone knows that real programmers don't use easy languages. Those are for
beginners.[/sarcasm] That's the real explanation for most of the JS hate. The
other part of it is the people who did try to learn it, found out there were
problems, and then for whatever illogical reason decided that they couldn't
use CoffeeScript or any other similar language to compensate for those
problems.

------
orr94
> In a normal situation this would have been fixed simply by adding a wait
> primitive to the language which would schedule the events when the result is
> still being fetched... 80 percent of the programming is about doing one
> motherfucking thing with another motherfucking thing and you need both of
> them to complete the action.

I love JavaScript, but I totally agree with this.

------
gesman
Agree. JS = gavno. It's faster than Ruby only because Ruby is slow like gavno
as well.

The fact that many are eating gavno and are feeling happy about it does not
make it healthy or tasty. The problem is when there are no other food to
choose (browsers).

That's why I love backend development. I can choose a decent, compiled,
strongly typed language and well-supported framework.

------
timruffles
I thought I'd write up a response to this, pointing out how Javascripters get
around these issues right now, and how they will come ES6:
[http://sidekicksrc.com/post/for-modern-development-
javascrip...](http://sidekicksrc.com/post/for-modern-development-javascript-
is-just-something-you-need-to-learn/)

------
julikt
Hey folks, thanks for all the constructive criticism and death wishes. Will do
my best to respond in detail - but for now I've removed the fixed footer.
Deployment from the train FTW.

------
zimbatm
Looks like learning rage.

When faced with a new thing to learn, point out all the mistakes and flaws
that give you reasons to not learn this shitty thing in the first place.

Or it could be the 3rd stage of grief :)

------
talles
Most of the comments in the article are about the horrible footer. Gosh, is
indeed an awful footer.

Oh by the way I agree with half of what he said (just half) but I still enjoy
javascript.

------
swaagie
To me it seems the author is expressing his own inability to code in the
language, why discuss someone's opinion?

------
seivan
Coffee Script makes it a bit sweeter.

------
jbverschoor
yay ruby!

