

JavaScript Sucks. - spo81rty
http://geekswithblogs.net/mwatson/archive/2012/10/01/javascript-sucks..aspx

======
lucisferre
A completely unsurprising blog post from a .NET guy about how static-typing is
all that's needed to save front-end web development.

Sadly, almost every problem he's listed as a frustration when working with
javascript is almost exclusive to .NET because of how bad the web tooling is.
None of those are problems in Rails or even Node. Why, in this day and age is
.NET still such an isolated and insulated community?

Edit Ok I really can't help myself so here it is point by point:

> I don't like any scripting or dynamic languages. I like code that compiles
> for lots of obvious reasons.

I guess they are not obvious to me. I would really prefer it if you could
actually state your arguments as I'm not generally persuaded by a lot of hand
waving.

> Ever try to use different JavaScript tools with conflicting jQuery versions?
> Yeah, that sucks.

What? No, I can't actually say this has ever been a problem. Nor should it be.

> How about trying to figure out how to make 20 javascript include files load
> quicker as one request? Yeah that sucks too.

This is pretty easily solved in just about every modern development stack
outside of .NET. Perhaps it's just Visual Studio that sucks? To be honest even
in .NET this isn't hard to do, but .NET developers do seem allergic to
anything that involves the command line.

> Performance? Let me just point to the old Facebook mobile app made with JS &
> HTML5. It sucked. Enough said

Is this enough though? It just sounds like an anecdote to me. A single data
point. Linked in's app is great as another example. Even so, no should expect
that HTML5/JS was for _everything_ or the ultimate in front-end performance.
Typescript will do absolutely nothing to improve this. It isn't simply a
language problem it is the curse of code hosted in a browser intended to be
completely cross-platform compatible.

> How about unit testing JavaScript? I've never tried it...

Then I can't really see why you would be an expert on how javascript sucks in
this regard (or any really). Have you tried unit testing the front-end of a
WPF or Silverlight app? I can tell you from direct experience it truly sucks.

This is entirely a tooling and experience based problem. I've done web
development in .NET too, for years. It sucked, so I stopped doing it that way
and moved to Rails finally. Despite this, I still didn't have the same level
of issues that the author experienced. It is possible to do front-end web
development in .NET with a minimum of pain it just isn't the norm, and
arguably it still isn't very convenient. Especially with a community that
largely waits around for Microsoft to anoint and every technology and bless it
with Visual Studio integration before using it.

I hate javascript too. I just think I have better reasons and personally find
Coffeescript more than sufficient to ease my pain.

~~~
michielvoo
Just for the record, in ASP.NET you can use many tools to combine (and minify)
scripts and stylesheets [1][2]. Generally, these do not require the use of a
command line.

To be fair, the majority of .NET developers depend on the tooling provided by
Microsoft, which consists mainly of Visual Studio. The tools from Microsoft go
a long way to isolate developers from using the command line, although the
recent addition of NuGet to the toolset has also introduced the Package
Manager Console [3] inside of Visual Studio.

[1] <http://www.nuget.org/packages/Microsoft.Web.Optimization>

[2] <http://www.nuget.org/packages/Cassette.Web>

[3] [http://docs.nuget.org/docs/start-here/using-the-package-
mana...](http://docs.nuget.org/docs/start-here/using-the-package-manager-
console)

~~~
lucisferre
Yup I know. That's what made this blog post somewhat frustrating. The author
clearly has no depth with javascript or front-end web development.

However perhaps I was a bit harsh. While these are not particular valid or
well reasoned points about javascript, they are still a common first
impression javascript leaves on many developers. Perhaps it still does speak
to deeper problems with javascript as a language.

------
actsasbuffoon
This article has no substance. He complains about how Javascript is "messy to
code with", but that's subjective and he provides no context. What does he
mean by messy? What features would make it less messy?

He also complains that it lacks modern features. JS has support for anonymous
functions, closures, higher order functions, some very advanced meta
programming, and loads of other modern features. In fact, it supports a lot of
the stuff that makes Ruby feel very modern to me. I'd like some specifics.
What features is it missing?

He also implies that test driven development with Javascript is a hassle, then
admits that he's never actually tried it before. It was so absurd that I
wondered if he was making some kind of very dry joke.

Don't get me wrong, I don't love Javascript and I agree with his closing
statement. I would love to see browsers begin to switch over to bytecode
interpreters, thus allowing developers to write in any language. Unfortunately
we'll probably colonize Mars before JS is displaced from browsers.

Take a look at this list of languages that compile to JS:
[https://github.com/jashkenas/coffee-script/wiki/List-of-
lang...](https://github.com/jashkenas/coffee-script/wiki/List-of-languages-
that-compile-to-JS)

There are tons. I haven't counted, but it looks like there are in excess of a
hundred languages there. That suggests that a lot of people really feel the
need to replace Javascript. I can't say that I blame them.

Variables are global by default. Think about that for a minute. What deranged
fiend decided that variables should be global unless prefixed with a keyword?
This is one of the weirdest and most unforgivable things I have witnessed in
any language, and I'm embarrassed to admit that I briefly programmed COBOL
professionally (I was young and I needed the money).

The fact that == has implicit type coercion is a huge pain. I know ===
resolves that, but it's a hassle to try to remember that when I'm programming
in 2 or 3 languages at once. I can only think of one other major language that
does automatic coercion on equality checks, which is PHP. Say what you will
about the pros and cons of PHP, but I think most people would agree that you
shouldn't look to it for advice on language design.

While the prototype based inheritance system offers some nifty meta
programming opportunities, it makes it really hard to debug. Things don't have
classes, they just have prototypes. Virtually everything in JS comes out as
[object Object]. That's a really handy message when I'm trying to debug a
thorny issue!

While I appreciate the elegance of making object constructors from regular
functions, that makes it possible to run a constructor without putting "new"
in front of it. That runs the code from the constructor, but "this" refers to
window instead of your new instance. In "Javascript: The Good Parts", Douglas
Crockford recommends writing some boilerplate at the top of every constructor
to catch this and recall the constructor with new in front of it. That's a
clever hack, but I not a fan writing boilerplate at the top of every
constructor.

Don't even get me started on how callbacks mess with the value of "this".
There are some nifty meta programming tricks I can accomplish with that, but
99.9% of the time I want "this" to refer to the object I'm in!

Speaking of which, "apply" is pretty nifty (I love T combinators), but I hate
that I can't use it on constructors. The hoops I have to jump through to
convert an array into arguments for a variadic constructor in JS are absurd.

There, rant over.

This is what I consider substance. Please list specific grievances and make
suggestions when possible. Vague statements about messiness and modernity tell
me nothing. In fact, they sound like FUD which is just going to agitate me.

------
ef4
I was hoping to read about some of the real reasons Javascript sucks, like the
contortions I have to go through to get exception-safe asynchronous flow
control.

But this article is just trolling.

~~~
halbermensch
_...like the contortions I have to go through to get exception-safe
asynchronous flow control._

OK, I'm game. Care to elaborate?

~~~
ef4
It's a real pain to guarantee that you will always get an answer back about
whether some asynchronous operation succeeded or failed. Every callback needs
to manually trap its own exceptions, manually listen for exception reports
from the subsequent callbacks that it dispatches, and report it all back to
the original caller.

There are libraries that make this better (example:
<https://github.com/kriskowal/q>). But since they're not built into the
language itself, you end up with more verbose code that's harder to debug when
it breaks, and you can't easily interoperate with other code that uses a
different flow control library.

There are lots of ways to design a language so that it doesn't suffer this
problem. If you simply built an API like Q's into the spec for Javascript so
that it had nice syntax and everyone could interoperate using it, that would
be a minimum viable solution that retains all Javascript's existing
performance characteristics. Alternatively, you can have real coroutines which
I think would be even better, though that does change the memory-usage
patterns more significantly.

------
cleverjake
>>JavaScript Sucks. ... Microsoft's announcement of TypeScript got me thinking
today. Is this a step in the right direction?

probably not, but since when does a hacker let that stop him?

>> But is it really just duct tape and super glue for a programming model that
needs to be replaced?

In my opinion, no. But I can understand why some people do not like the
looseness provided in javascript.

>> Now people are even trying to use it on the server side via node.js.

Historical note - Netscape released server side javascript in Netscape
Enterprise Server back in December of 1994. There has been many server-side
implementations since then, before and after node. Node is just the first that
has a strong culture.

>>Ever try to use different JavaScript tools with conflicting jQuery versions?
Yeah, that sucks.

Why would you do that? Sure there are certain situations where you may have
conflicting versions due to widgets or something, but I don't see why it would
ever be required to have two versions, let alone having to architect around
that need. On top of that - this is a complaint against a library, not a
framework.

>>Performance? Let me just point to the old Facebook mobile app made with JS &
HTML5. It sucked. Enough said.

How about iTunes? Or the LinkedIn App? You don't notice apps made with html/js
unless they suck - because when it is well done it feels natural and native.

>>How about unit testing JavaScript? I've never tried it, but it sure sounds
like fun.

It is. Seriously. Assuming you like the confidence of coding against tests.

>>My biggest problem with JavaScript is code security. If I make some awesome
product, there is no way to protect my code. How can we expect game makers to
write apps in 100% JavaScript and HTML5 if they can't protect their
intellectual property?

Not sure what you mean by this. If this were true we would have a million
gmail clones.

>>There are compiling tools like Closure, unit test frameworks, minify, coffee
script, TypeScript and a bunch of other tools. But to me, they all try to make
up for the weaknesses and problems with JavaScript.

Closure and similar minifing tools are not to make up for issues in the
language, but to address the fundamental fact that browser code goes over the
wire, and as a result, should be made to be as compact as possible. You do the
same thing with swf's in flash, or java applets. You want to send down the
smallest possible version to make it as fast as possible.

I have no idea how unit test frameworks make up for weaknesses/problems. They
test your code, and nothing more. They exist in every mainstream language, and
honestly has only recently started to catch on in the javascript community. I
would really like to hear your issue with them in more detail.

Coffee script is the only thing in this list really is trying to make up for
weaknesses in the language - but a lot of that has less to do with the
language having problems as it does with its uniqueness. There are a lot of
'features' in javascript that are not obvious, and backwards compared to other
languages (a lack of block scoping comes to mind), that coffee script tries to
smooth over.

>> JavaScript is a mess and we spend a lot of time trying to work around all
of it's problems.

It is also, by far, the most installed programming language in the world, as
well as one of the easiest to get started learning. While it may not be ideal,
I do believe it is a beautiful language with a ton of underrated features.

At the end of this, I really don't understand the argument. You aren't really
saying much at all. If you could go into more detail, I would really like to
hear hat features specifically you feel are misguided or wrong in javascript.

------
drgath
Some of the complaints in this post are valid, but most have nothing to do
with the language itself. It's just a lack of understanding tools and
technologies the JavaScript ecosystem offers. I'm a contributor to YUI, so I
of course have a bias, but you could replace the examples below with things
that are available for other libraries.

> Ever try to use different JavaScript tools with conflicting jQuery versions?
> Yeah, that sucks.

That's what is great about YUI, where you have most tools you need to build
whatever you like (50+ components), and they're all tested and guaranteed to
work together every release. <http://yuilibrary.com/yui/docs/guides/>

> How about trying to figure out how to make 20 javascript include files load
> quicker as one request? Yeah that sucks too.

No it doesn't. YUI's modular system is completely centered around the concept
of CDN combo-loading. It's dead-simple.

> Performance? Let me just point to the old Facebook mobile app made with JS &
> HTML5. It sucked. Enough said.

"HTML5" isn't a magic bullet that automatically makes everything awesome. You
still have to design apps correctly. The author didn't elaborate on any
specifics of why it "sucked", so I don't have much to go on to counter. JS
would seem to perform quite well for anything FB needs to do in a Web app
(display text, pictures, links), so any issues were likely just bad design.

> How about unit testing JavaScript? I've never tried it, but it sure sounds
> like fun.

It's actually pretty simple (and dare I say fun?). I've written hundreds of
test cases. There are plenty of JS testing frameworks out there, including
Y.Test (written by Nicholas Zakas, <http://yuilibrary.com/yui/docs/test/>)
which can be used for YUI and non-YUI applications.

YUI itself has 6,300+ unit tests covering everything from core modules to
website examples, and every single one of them pass 24/7 (or is fixed
immediately).

> My biggest problem with JavaScript is code security. If I make some awesome
> product, there is no way to protect my code. How can we expect game makers
> to write apps in 100% JavaScript and HTML5 if they can't protect their
> intellectual property?

Is this arguing security, or IP protection? There's a reason why every
proprietary plugin/runtime for the Web ultimately falls to the open
competitor. A 50-line JS widget can easily be "stolen", but how much was it
worth to begin with? View-source (IMO) is one of the best features of the Web,
because it enables the Web to progress and evolve at a pace otherwise
impossible. "Awesome products" have been made by Google, Facebook, Yahoo,
Twitter, countless startups, and I don't think source-code visibility has
harmed them in any significant way.

In conclusion, if I read this post 10 years ago, the author would have a solid
case. But tens of thousands of developers have helped create an incredibly
supportive ecosystem that provide just about every tool you need, just open
your mind a little bit. JavaScript absolutely does not suck.

------
voidr
> Ever try to use different JavaScript tools with conflicting jQuery versions?
> Yeah, that sucks.

So library conflicts are unique to JavaScript? also I never had compatibility
issues with jQuery because it does a good job at staying backward compatible.

> How about trying to figure out how to make 20 javascript include files load
> quicker as one request? Yeah that sucks too.

I can do it with one shell script, if you have a problem figuring that out,
the issue is not with JavaScript...

> Performance? Let me just point to the old Facebook mobile app made with JS &
> HTML5. It sucked. Enough said.

So Facebook's mobile app is representative of ever web app ever created? This
statement is ridiculous in so many ways.

> How about unit testing JavaScript? I've never tried it, but it sure sounds
> like fun.

If you can't explain why it's a bad experience, you shouldn't bother stating
it, otherwise it's just BS.

> My biggest problem with JavaScript is code security. If I make some awesome
> product, there is no way to protect my code. How can we expect game makers
> to write apps in 100% JavaScript and HTML5 if they can't protect their
> intellectual property?

There are 99999 minifiers and obfuscators out there and don't act like you
never heard of disassemblers.

> There are compiling tools like Closure, unit test frameworks, minify, coffee
> script, TypeScript and a bunch of other tools. But to me, they all try to
> make up for the weaknesses and problems with JavaScript. JavaScript is a
> mess and we spend a lot of time trying to work around all of it's problems.

It's like saying that Visual Studio and all tools used with .NET make up for
the weaknesses of C#.

> It is possible to program in Silverlight, Java or Flash and run that in the
> browser instead of JavaScript, but they all have their own problems and lack
> universal mobile support. I believe Microsoft's new TypeScript is a step
> forward for JavaScript, but I think we need to start planning to go a whole
> different direction. We need a new universal client side programming model,
> because JavaScript sucks.

The title should be changed: One .NET guy doesn't like programming in
JavaScript.

------
halbermensch
Yeah, man. We know, we know, we _know_. What's your replacement?

~~~
snogglethorpe
> _What's your replacement?_

He's all too likely to actually _answer_ that question with his own bizarro
language.

Everybody and his dog seems to have a javascript replacement these days, many
of which seem to just sort of rearrange the suck a bit to suit the author's
tastes.

I don't personally think javascript is particularly bad, indeed it seems a
mostly pretty decent language for its niche, with a few annoying quirks—but
_every language_ has annoying quirks.

~~~
orangecat
_but every language has annoying quirks._

IMO Javascript's quirks are unusually bad because failing to avoid them
frequently results in code that appears to work just fine (and will probably
pass all its tests), only to blow up at some random point in the future.
Missing var, == instead of ===, for-in without hasOwnProperty...

------
pacomerh
"Ever try to use different JavaScript tools with conflicting jQuery versions?
Yeah, that sucks."

Not really. You might be relying too much on 3rd party libraries. You gotta
get you're hands dirty a little more, but this might be due to your
disinterest in non-compiling languages.

It's now three people I read that work for the enterprise and don't like JS.
Interesting.

------
speg
I think JavaScript is a tool, right for some jobs. If you want to secure your
game code, write a native binary for the platform of your choosing. You'll get
better performance too. If you want to write a website that is accessible on
all browsers and all platforms then JavaScript serves its purpose very well.

------
isaacpei
the replacement is clear: lua <http://blog.luapineapple.com/?p=152>

one of the most interesting and impressive lans out there:
<http://luajit.org/>

things exist such as: luakit <http://mason-larobina.github.com/luakit/>

------
keymone
your 404 message sucks too..

