Hacker News new | comments | show | ask | jobs | submit login

All of these compile-to-JS efforts are great, and as much as I love things like CoffeeScript I have to say I definitely worry about language fragmentation.

JavaScript is full of flaws, but its monopoly in the browser space has brought about one intriguing and welcome side-effect: a VERY efficient market for both employers and employees.

It's easy to overlook how important this common denominator has been for everyone involved. Employees have a tremendous amount of mobility within the industry: don't like your current JavaScript job? No problem - just about every dot-com needs a JavaScripter. Similarly, companies can today tap into a tremendous pool of JavaScript developers.

In today's fast-paced development environment, the ability to hit the ground running is key, and I worry that fragmentation will introduce unnecessary friction in the industry.

I think you were referring to the JavaScript syntax when you said JavaScript is full of flaws, because IMHO the language itself - except the syntax component - is actually very good. Someone on Quora said[1] it very well:

JavaScript is a wonderful language, deep down: It's Lisp-y, yet imperative. Its lack of support for threads has turned out to be a strength on the server side. And recent implementations have made it very fast.

People favoring node.js and compile-to-JS languages like Iced CoffeeScript to other server-side languages supports the fact that JavaScript itself is actually quite decent. At the end of the day, a language too broken could not easily be fixed with any thin compile-to-* effort, and most of the compile-to-JS efforts (with the notable exception of emscripten, whose goal is not to fix JavaScript) are quite quite thin.

[1] http://www.quora.com/CoffeeScript/What-are-disadvantages-of-...

The language itself is broken, especially when it comes to equality, type coercion, `arguments`, and Date processing.

Equality (and that portion of type coercion) is pretty much solved by using === and the rest of type coercion is solved by only using + when both sides are numbers or strings. I don't see how that gets as much ire as it does

> I don't see how that gets as much ire as it does

Because it's the straw-man.

I think you mean, when only looking at those things. Outside of hoisting, you just listed all of the issues. Even hoisting is only an issue when you start polluting the global namespace.

Depending on who you are you can also complain about scoping rules, the object model, semicolon insertion and more general syntactic complaints, speed, access to native APIs and so on. One language is never going to be all things to all people.

The good parts are good. The bad parts are pretty horrible.

The intrinsic beauty of JavaScript doesn't matter in this context. Either you use JavaScript or you use something else, and if you use something else then that'll lead to language fragmentation, which is arturadib's concern.

>Its lack of support for threads has turned out to be a strength on the server side.

ummmm, can someone elaborate? I don't understand that statement.

I think it means the language forces designs and eventually an ecosystem that's optimized around having cooperative multitasking as the only option. That makes dealing with concurrency an easier task since every library you depend on also takes concurrency seriously. And since cooperative multitasking is much much more efficient than preemptive alternatives, you end up with applications with great efficient concurrency support by default.

E.g. node.js + socket.io. The event-driven concurrency model makes it easier to write servers without worrying about race conditions and thread locks while also having less overhead from a heavy thread implementation. For some applications this has been quite good. The downside is that it can be a bit tricky to scale node.js larger but it's not too hard to run multiple processes or do other load balancing. It's not good for all applications, but very good for some.

> The event-driven concurrency model makes it easier to write servers without worrying about race conditions and thread locks

Well, no, you're just writing the locks yourself in an ad-hoc way. Every time you have a callback calling another callback, you have a lock and all the race condition/deadlock issues associated with that. Of course, writing an application that doesn't have complicated synchronization requirements (streaming fileserver) can often require less boilerplate in an evented system. However, you run into a catch-22 here: by definition it's an application with fewer synchronization requirements, so you'd have to use fewer complicated locks in a 'heavy thread' implementation as well :).

Ultimately it's an engineering tradeoff problem, and you have to weigh lightweight node-style cooperative multitasking with the ability of a traditional thread system to better handle highly complicated scenarios.

Or you can be Russ Cox and argue that this is a false dichotomy[1] and that we should all be using CSP. I'm in that camp.

Andrew Birrell: threads.

John Ousterhout: events.

John DeTreville: no.

Rob Pike: yes.

[1] http://swtch.com/~rsc/talks/threads07/

> makes it easier to write servers without worrying about race conditions

So how do you handle concurrency without race conditions without using isolated processes or pure message passing? Ok so you don't have thread locks, big deal, but you still have shared data structured that could be updated in a non-deterministic order depending on which file descriptor gets fired first by epoll (or whatever select thingy is being used lately).

> In today's fast-paced development environment, the ability to hit the ground running is key

actually, i think one of the major flaws in the current programming job market is overrating the ability to hit the ground running. that leads to a dangerous level of short-term optimisation, where, say, you'd choose an employee who has experience with your current stack over someone with a better track record but requiring a month or so to learn their way around the specific languages and ecosystems involved.

JavaScript is forever stuck in design-by-committee hell, which dooms it long-term. Developers who do nothing but pure JavaScript and don't at least play around with the other options (Dart, TypeScript, Haxe, CoffeeScript, et al) are just going to be hurting themselves long-term.

It is always a bad idea to tie yourself too strongly to any single language.

Conversely it's a bad idea to spread yourself thin in multiple languages but master of none.

Having said that, I'm pretty much tied to Java since 2000 and haven't seen anything wrong... yet. In fact, I'm determined to get better in Java everyday (memory model, JVM, concurrency, better design, etc).

Side note: I'm also learning pure "modern" JS just because there's no choice on the client-side.

Actually, it's quite easy to write for the client in most languages targetting javascript. Certainly it's the case for CoffeeScript, and TypeScript looks even better in that regard since it's a strict superset.

> Side note: I'm also learning pure "modern" JS just because there's no choice on the client-side.

Knowing Javascript, GWT is a win.

I've done GWT for about 2.5 years from version 1.x to 2.x. I'm not sure I prefer one or the other.

GWT development is a bit painful to setup and to work day-to-day.

It's nice to have the similar Java structure and to be able to write unit-tests to test the app via MVP patterns but I'm still not sure it's a big win for me going forward. Especially when the founding members have left the team.

I don't know, ECMAScript 6 looks a lot like Coffeescript, and ECMAScript 6 modules look a lot like Node modules.

ECMAScript 4 looked a lot like ActionScript 3 up until the whole thing was suddenly killed. I don't care too much what a language is supposed to look like years from now if everything goes right. This goes double for languages with a tortured history of failure when it comes to big changes.

>I don't know, ECMAScript 6 looks a lot like Coffeescript, and ECMAScript 6 modules look a lot like Node modules.

The fact that after all this time and efforts, ES6 won't be released for another year plus, speaks volumes about the "design by committee" thing.

Nope, spec finalization follows shipping.

First, Firefox and Chrome (under a flag, to be removed) already ship great pieces of ES6. JSC (Safari) and IE prototypes coming too. This is necessary to test interop and design soundness.

Second, we don't do "Design by Committee", we use the "Champions" model where 1 or 2 people design a proposal and a larger number beat it into consensus shape without "redesign".

Nothing's perfect, least of all with multi-browser standards, but if you have an alternative for evolving the actual JS language implemented by browsers, lay it on us.

Compilers on top are great, and many. Good to see MS do one that tries to build on ES6.

Wow. Didn't expect a reply from "THE Eich" itself. Honoured.

>Nope, spec finalization follows shipping.

Still, shipping ES6 is also scaled back at this time, and it requires special flags and hoops to be enabled.

This means actual mainstream use (the way we know use HTML5, IE7 be damned) will be possible 2-3 years in the future at the minimum, which would be like 6-7 years from the beginning of the whole process.

This is W3C-level waiting times, especially considering that ES now is essentially the same it was in 1999, with minimal changes to the language or the standard libs.

>Nothing's perfect, least of all with multi-browser standards, but if you have an alternative for evolving the actual JS language implemented by browsers, lay it on us.

I would wish for a "one guy sets them all straight, it's his way or the highway" benevolent dictator model, but I understand that while it works for Ruby or Scala or whatever, it doesn't work in JS case where you _have_ to have 4 different implementation by 4 browser vendors to have it adopted.

I think what those vendors need is something to force their hand, but don't know what that could be.

Device turnover on mobile is 2-3 years. Things are picking up with more balanced competition and the rise of mobile to dwarf desktop.

You can't get an interoperable spec of a new edition of a language the size of JS in less than three years, for any such language. Not for Dart (which is still changing and by Google's own plans nowhere near ready to standardize) or TypeScript (also new, and tracking ES6). Java, C#, Python, Ruby, etc. were built to today's state over years or decades.

Bite-sized specs are much better. Small libraries on github and universal edge-caching, even better. Could we have bite-sized specs for JS?

As I speculated at Strange Loop last week, with a few final gaps in the language filled (Object.observe, slated for ES7, weak refs and event loops, and definitely macros! see http://sweetjs.org/) by a future JS standard, we will be "all but done".

Working away at this goal,

90% marketshare was effective for IE6 forcing other vendors' hands. Not that that's a good model to go back to. :)

(Was that a "Lensman" ref in your first line? ;-)

This same fear of fragmentation is what kept Java from progressing for so many years and look what happened there. Things 'fragmented' by people just switching to other languages. I say roll the dice and see what happens.

Javascript is dreadfull , and its flaws are counter productive and intolerable. It has good things like closures and first class functions , and that's it. Most of js developpers hate javascript , but are forced to work with it. So they dont care what they use as client language provided it gets the job done. few people cares about Javascript. most of the devs hate it. But the browser as dev plateform is a fact.

From my experience, "most" of those JavaScript developers who "hate JavaScript" are in fact front-end developers who hate writing JavaScript for websites, since they struggle daily with issues such as cross-browser compatibility and inconsistent DOM implementations, which have nothing to do with JavaScript at all, and can't be fixed by a different syntax.

It's also compounded because the majority of front-end developers write their code procedurally for each application component, which creates a terrible nest of repetitive and error-prone code.

They feel the pain, don't know how to solve it, so switch to a different syntax, blaming that as the root cause of the problem.

But feeling enough pain to viscerally HATE a language, as many front-end developers do, is not something that can simply come from the syntax of the language and the fact that the equality operator does type conversion and whatever small list of gripes users have. Most other languages (including CoffeeScript!) have a similarly-sized set of flaws and aren't nearly as derided.

Correlation not causation.

As someone who has built large scale JavaScript applications, and has a lot of experience in other languages I really don't like JavaScript. My experience is that a lot of people know JavaScript, but very few people actually like it... Those people generally make writing JavaScript their day job.

Overall, cross browser js isn't really that difficult anymore and I rarely see people complaining about that. Of course, I've been part of the AltJS community for a while, and the people I follow closely are not front end developers.

Agreed, it's a terrible language. Among other things, it makes it way too easy to write code which many people will read as being correct, but will actually be subtly incorrect.

A few of the weakest parts:

- for (var x in y) when used for array iteration or even dict iteration; hasOwnProperty? Really?

- x[obj] = y; seriously, did i really want '[Object object]' as my key?

- the choice of function level scope over block level scope

I'm not sure function level scope over block level is a bad thing. It makes it more Lisp-y. And if you want block level scope, it's about as easy as (in CoffeeScript):

    do ->
        ... local variables right here ...

> I'm not sure function level scope over block level is a bad thing. It makes it more Lisp-y.

Lisp has block scope.

Well, it can have both...


Can you write Lisp like this?

Function for(){ f(x); var x = 2; }

Compiles and runs with f(undefined)

It might be nice to make a canonical list of things which suck about JavaScript.


> Most of js developpers hate javascript

I don't know of any JS developers that hate JS. I know a lot that hate some browser implementations of JS though.

I've done quite a lot of JavaScript development, enough that I guess I'm a "JavaScript developer" (though thankfully that isn't my current day to day job) and I hate it. So now you know of at least one.

I agree with everything camus said. Yes JavaScript has some cool stuff in it, but taken as a whole it is a pretty shitty language. This has less to do with the creation of JavaScript than it does the practical reality that JavaScript cannot really be changed in fundamental ways without immense amounts of politics. Pretty much the entire time JavaScript has existed it was due to be fixed in a couple of years, but then political fiasco after political fiasco (eg. EcmaScript 4) delays this.

JavaScript as you can use it today sucks pretty much as much as it always has, and is only tolerable now because there are some good libraries that hide the shittiness of the language from you. Wouldn't it be better to have a web language without such a shitty core, that didn't require 100k libraries to hide you from the terrible bits?

> good libraries that hide the shittiness of the language from you.

Ah, the "only the libraries make the language tolerable" argument.

My experience has pretty much been that most of the devs who thinks the libraries are hiding problems with the language are confused on one or both of the following points:

1) the distinction between the DOM and JavaScript (for those who don't know: jQuery and the like address problems with the former)

2) the idea that a language is terrible if it doesn't have a specific class-based OO model

Hard to say in your case, though, given that you didn't mention any specific problems or solutions presented by specific libraries.

I end up using underscore.js in every project I work on because JS doesn't have good functional programming built in, at least not that you can count on in all implementations.

I use date.js or moment.js whenever I have to deal with times/dates in JS because the built in date support is pretty bad.

That being said, I think libraries like this take Javascript from being "tolerable" to "lovable"

What are the problems with Javascript you speak of? The libraries hiding you from terrible bits, at least the ones I use, have to do with the DOM and not with Javascript.

The problems should be blatantly obvious to developers who have used languages other than JavaScript and PHP (which both have many of the same flaws).

Once you've studied and used languages like C, C++, Python, Java, C#, Haskell, Scheme, Erlang and Standard ML, you'll see what we mean when we say that JavaScript is a very flawed language. Pick any of its features, and compare that feature to the equivalent feature in the other languages. JavaScript's approach will generally be the worst of all of them.

Variable scoping, unavoidable global namespace pollution, === vs == insanity, etc.

Last week I learned about another crazy "feature": Function hoisting


But how do libraries help you from that?

Kitchen sink libraries like jquery + jquery ui save you from having to write much JavaScript at all beyond basic glue code. The less JavaScript I write, the happier I am. This is in stark contrast to other languages I work in where I actually like to roll my own frameworks.

I'll second that. I use it yet avoid it when possible. It's downright clunky compared to many scripting languages. Not completely broken, but broken enough.

That is a sweeping condemnation of JavaScript that I've honestly never heard support for. JavaScript has quirks that people don't like, but it can be rather enjoyable to work with.

It sounds like a condemnation coming from 1998, when doing anything in the browser was painful and that was the only place JavaScript existed. I hated JavaScript in those days, too, but today is a very different world.

Please don't speak for javascript developers without some substantiation of your opinions.

I've only started playing with it recently, but I've been doing some heavy stuff and wonder whether the criticism stems from deficiencies in the language (for which there are workarounds within the language) or a fundamental lack of understanding of the javascript model.

JavaScript is my main language since about 5 years, and I love it. I know a lot JavaScript developers and honestly I don't know any that "hate" the language, about 80% are very passionate about it, for rest is just tool to achieve the goals.

JavaScript has minor flaws but in general when understood it's outstanding. However it's not the style that you've been taught in school (OOP) and that's the problem for many newcomers.

It looks that you're just frustrated with something and want whole world to be as well, it won't work. Try CoffeeScript, it's much more approachable when coming from OOP world, then when you get how JavaScript works and understand it makes sense, you'll be ready to program in it directly.

Nah, you're generalizing. I know many JS developers and they all love Javascript in one way or another.

Of these developers, how many of them have any real experience with languages like C++, Java, C#, Scheme, Haskell and Erlang?

It's easy to find JavaScript developers who love JavaScript solely because it's the only language they know. But once you start dealing with JavaScript developers who have a wider understanding of what various programming languages offer, the problems with JavaScript become much more obvious, and the hatred for JavaScript becomes immense.

I think Anders Hejlsberg knows a few other languages.

Yes, indeed. That's why we're finally seeing some sensibility being brought to JavaScript. He's bringing in basic features and functionality that should have been included 17 years ago, back when JavaScript was first developed.

Is that not generalizing as well? I'm one that doesn't. But then, you probably don't know me.

Critical difference is that pacomerh is speaking about the JS developers s/he knows while Camus had no such qualification.

Yeah, "I know many" refers to a group of people I know, so I'm not generalizing. It's like that silly quote from the Anchorman '60 percent of the time, it works every time'.

With a name like Camus, how can you not be a fan of javascript?

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact