JavaScript Sucks.
geekswithblogs.net
geekswithblogs.net
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.
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...
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.
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...
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.
But this article is just trolling.
OK, I'm game. Care to elaborate?
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.
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.
> 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.
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.
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.
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...
Whatever it is, it would have to be sandboxed in the browser so it doesn't cause security issues. Silverlight used as a class library only meets all the criteria to be the solution. But I think something entirely new may have to be created.
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.
one of the most interesting and impressive lans out there: http://luajit.org/
things exist such as: luakit http://mason-larobina.github.com/luakit/