[kulkarnic]

Is this a serious post, or are you being sarcastic? I honestly can't tell. JS the language of the future? Why? It has probably the worst gotchas of any language I've coded in, it's verbose, and weird scoping. Nor is it especially nice to optimize for/with.

I can certainly see being stuck with Javascript (just like we're stuck with the x86 instruction set even if simpler alternatives exist), but I'm not sure it's something I rejoice about. Javascript is like anti-Batman: a language we all deserve, but not one we need.

[spion]

ES6 adds lambdas, destructing assignment, default/rest/ spread arguments and template strings - all of those reduce verbosity. And there is `let` which has a "normal" scope, although I'm not really sure it needs that. Additionally, generators let you use normal control flow constructs for IO, if you prefer that to FP.

While its no Haskell, it certainly isn't much more verbose than other dynamic languages anymore. And a typesystem like TypeScript or Flow pretty much eliminates the rest of the gotchas.

Off the top of my head, there are two embarrassing holes: bigger integers and parallelism. Can't think of anything else at the moment (macros maybe, but they're a double-edged sword wrt tooling). Wonder if anything else is missing?

[_pmf_]

> ES6 adds lambdas, destructing assignment, default/rest/ spread arguments and template strings - all of those reduce verbosity.

Yes. But the existing warts do not go away (and neither will they ever, due to the need for backwards compatibility).

[Havvy]

There's Sweet.js if you want macros.

[warfangle]

We've got parallelism in the browser (sorta) with webworkers.

[yazaddaruvala]

I'm actually glad there isn't parallelism (well threads/actors/tasks).

I'd go so far as to consider it a feature.

[Xixi]

May I ask why? Not having parallelism seems like a net negative to me...

[yazaddaruvala]

[Edit] Before starting, I just want to state: I know JavaScript has parallelism/concurrency in its supporting "system calls" (ie what would, in other languages, be blocking calls, in both the browser or Node). In fact I like this parallelism model, but I was specifically talking about parallelism built into the language (Threads, Actors, Tasks).

This is a long and complicated answer. I doubt I'll do it justice in a few paragraphs, but I'll try.

In one word: simplicity. Primarily, not having parallelism is far simpler than having it. Yes, some models of parallelism are simpler than others but at the end of the day I think we can all agree none of these models are as simple as not having parallelism. As per "net negative": yes, ofcourse, not having parallelism is a "negative". However, "net negative" is interestingly more linked to the applied domain rather than the actual concept. Simply put, the domains that JavaScript is used in don't heavily rely on parallelism (or rather, require the optimization of parallelism).

Thinking about this now, its sort of similar in nature to why people like garbage collection. There is an inherent negative to using a garbage collector, however, (I think we can both agree) in certain (most) domains it turns out to be a net positive. Why? For the same reason, simplicity.

I mean, I could go on, but I'm trying to be as concise as possible. Hopefully, that was a useful. I'm happy to elaborate if you have more specific questions about this.

* s/simplicity/developer efficiency + implicit safety guarantees/g -- Since "simplicity" is quite vague;

[Xixi]

This is an interesting point of view. I personally find the erlang approach -no shared memory- to be the least error prone, and as a consequence the most efficient for developers.

With Erlang you can't share memory [0], but in exchange you get sequential code (no callbacks or yields), true parallelism, and even distribution over a cluster. With node.js all the asynchronous calls live in the same memory space, but code is written with nested callbacks (or yields), and of course you get no parallelism.

[0] There are shared dictionaries for when it is really absolutely necessary.

[xixixao]

Agreed. Rarely argued I think this is a very valid view. Additionally, some languages which have true parallelism are converging to the same model (say non-blocking IO ala Node), built on top of their crude parallelism primitives.

[scotth]

Honest question: How different is a web worker from an actor?

[inglor]

Surprise answer: It's not.

When people sat down and decided how workers are to act in browsers - Actors are what they had in mind.

This is why Web Workers don't have access to the window scope, use explicit message passing etc.

[yazaddaruvala]

So to reply to both of you:

Correct me please, but from what I understand web workers are not a part of the JavaScript language. The same way AJAX isn't a part of the JavaScript language. I would consider those (AJAX/WebWorkers) more like "system calls" to the browser. And like any system call, it has privileges the application doesn't.

[alexjeffrey]

a cryptographically secure pseudorandom number generator would be nice, too.

[ricardobeat]

Server-side js has that already. On the clientside it would be useless.

[ajuc]

What about p2p?

[nextw33k]

There is a problem with JavaScript in that there is no security mechanism currently in place to ensure the JS file you are running is what you expect to be running.

Imagine your on your favourite social network that used a JS based encryption in a p2p chat to your friend. On that same page advertisers are pushing content to you. That content could be a malicious JS file which can eavesdrop on your conversation, all the while you think its encrypted.

[realusername]

Isn't crypto.getRandomValues created just for this purpose ?

[hrktb]

> JS the language of the future? [...]I can certainly see being stuck with Javascript

I think we all agree. JS has very ugly things, but it isn't going anywhere for the forseeeable future.

If we're going to use for at least a few more years, I'd applaud anyone making better tools and rejoice when I see better frameworks and easier to use libraries.

Now by the time alternatives to javascript become viable, we might have made javascript something way better than what we already have now. It could survive a long long time and with people actively making it evolve, and it could be very enjoyable. Who knows.

[TazeTSchnitzel]

It's already getting more enjoyable to me. Things like .forEach and => mean I can write really nice code.

[lobster_johnson]

JavaScript is changing rapidly. ES6 and TypeScript are fixing the warts and adding much-needed features. And you can use those features today, thanks to projects like Traceur, 6to5, TypeScript and Flow.

If you factor in all these improvements, and the fact that it runs brilliantly on the server, it's a vastly different situation than just a few years ago.

[ori_b]

> JS the language of the future? Why? It has probably the worst gotchas of any language I've coded in, it's verbose, and weird scoping. Nor is it especially nice to optimize for/with.

You're looking at it from a technical perspective, and from a technical perspective JS is an awful language.

It may be a turd. But it's the only sandboxed-by-default, zero-install, reasonably-fast, free, preinstalled-on-every-machine turd that we have.

[lhnz]

You are right that there are some problems in the language. However, I would rethink your argument based on the rapid development of the language over the last 5 years.

For example, yes callbacks were very messy but very soon we will have generators. And, yes, the scoping was nasty but soon we will have the 'let' keyword. I cannot remember where I read it, but I do also remember seeing a talk about some proposals to extend "use strict" to allow people to fix some of the type-casting behaviours made infamous by wat, too.

My point isn't that everything is fixed and we can stop complaining about the bad parts. My point is that it is very impressive how those in charge are handling the evolution of the language.

I think it's worth taking a bet on a language which improves so much every year.

[themartorana]

There's momentum, and that's the why. Imagine trying to get Apple, MS, Google, Mozilla, et al to agree on a JavaScript replacement that was rolled out at the same time.

Then deal with the 5-10 years or so legacy browsers hang around with significant market share.

JS was anointed long ago, and if we knew then what we knew now, maybe it wouldn't have been so? I remember DHTML and how silly it was and how it was just a toy and BOOM! Ajax.

So here we are. Every browser supports it, none could agree to change, so we deal with what we got. Better tools are better than nothing.

[aaronem]

Industry vs. academia in two comments. Well done, the pair of you. Now stop it.

[conradk]

A lot of what you say is purely subjective.

I would consider C++ to be way more verbose than Javascript. Especially with ES6 coming (and things like Flow / Typescript allowing you to use ES6 today).

Weird scoping? What are you talking about here? It's not the same as other languages. That does not make it weird. When you understand how it works, it's not a problem. Use it to your advantage.

Not nice to optimize for? Javascript is fast enough for most tasks, provided you use best practices. You can even build AAA games with it nowadays, through ASM.js. I'd like to learn more about what you mean exactly when you say it's not nice to optimize for, if you have the time.

I get that Javascript has its quirks. But so do most languages. What's awesome is that JS is easy to get started with, but can be used to build complex apps (especially with things like Flow / TS). And it works everywhere. And it has an amazing ecosystem of client side and side libraries.

[lmm]

> I would consider C++ to be way more verbose than Javascript.

Rather damning with faint praise there.

> Weird scoping? What are you talking about here? It's not the same as other languages. That does not make it weird.

Yes it does. In the '80s this was an open research area, but a consensus was reached in favour of lexical scoping for a reason.

> I get that Javascript has its quirks. But so do most languages.

False equivalence. Python (to pick an example I'm familiar with) has some quirks, sure, but it's a million times nicer to program in than Javascript, and it has all the other advantages you list (it's easy to get started with, suitable for complex apps, cross-platform and so on). I'm sure the same could be said for Ruby or OCaml or hundreds of other languages. If it were as easy to run these in the browser, I don't think we'd see anyone choosing Javascript - it really is a worse language than so many alternatives.

(I mean, by the standards of a single-application scripting language that was written in three days, Javascript is very good - we wouldn't expect such a language to be the equal of a carefully designed general-purpose programming language)

[swah]

From http://steve-yegge.blogspot.com/2007/02/next-big-language.ht...

- Rule #1: C-like syntax

- Rule #2: Dynamic typing with optional static types

- Rule #3: Performance

- Rule #4: Tools

- Rule #5: Kitchen Sink

- Rule #6: Multi-Platform

This tool provides #2 for Javascript, the NBL.

[CmonDev]

He got Rule #2 slightly wrong, should be: "Strong static typing with optional dynamic typing".

Makes much more sense, but I am going to forgive him.

[denizozger]

The bad parts are there, but as of today it's a very powerful language that runs on every browser (hence every computer in practice?) with massive community support.

[tripzilch]

> hence every computer in practice?

Oooh, there's many more computers around you than you think ;-) Nearly every modern piece of electronics. Many don't run browsers. For instance your washing machine has an OS, but it probably doesn't run Javascript. Same goes for your car, washing machine, dishwasher, microwave, central heating system, stereo/hifi, etc. And of course the more obvious "non-PC computers" like routers, printers, scanners, TV (might actually run JS if it's "smart" and has a browser), computer monitor and who knows what else. Coffee machine. The "fancier" it is (for a rather low barrier of "fancy"), the more likely it is to have a chip in it that runs some firmware/OS something, equal in power of what people ran as desktop personal computers a few decades ago.

[D_Guidi]

>JS the language of the future? Why? because it's pervasive. market matters, not developers.

[cdelsolar]

Read the Good Parts of Javascript and get a JS linter. Javascript is a fine language if you do this.

[aikah]

> Javascript is a fine language if you do this.

No,it's not fine, it's a horrible language,with a few good features that saves it from being a catastrophy.hence "Good Parts".

Or we wouldnt be here talking about Flow,Typescript or others if the language was "fine". JS was clearly not designed for what we are making out of it today.

But since there is no way around Javascript in webdev,good or bad,it doesnt even matter.It exists.TC39 isnt going to fix types,so types are fixed in userland.hence "Flow".

[hnriot]

nonsense. Just because people and companies have contributed new features and capabilities to the language doesn't make your point. It's not a horrible language, any more than any language. Of course it has things that aren't ideal, but it's highly expressive and if you know what you're doing it can be elegant.

[gmac]

Agreed. And things could have been enormously worse (hint: VBScript).

[aflinik]

You're criticizing the raw JS language, but that's not what most people in the industry are using. Fine, the original language design was horrible, but if you consider the typical stack used for web development (which could be any combination of transpilers like CoffeeScript/TypeScript, Flow, Promises, module systems, etc) it's not that bad.

Also we already have Strict mode; I imagine in the future it will get more and more uncompromising, so the JS subset we'll be actually using will be just fine.

[mateuszf]

Every language has good and bad parts.

[jules]

This can be used to justify any atrocity.

[Shizka]

I've had the exact same concerns as the person you replied to. I just want to make sure since the title differs from the one you stated. Is this the book you were talking about: http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor... And how/why did the book improve your opinion about the language?

[callum85]

It's an opinionated book that sets out a subset of JavaScript that you should use, avoiding all the 'bad parts'. This subset is what tools like JSLint and JSHint were designed to promote - they flag you up if you use a bad part. It's a seminal work. These days I find some of its rules a little dogmatic (for instance I like the 'new' keyword now), but I'm glad I went through a phase of sticking to it relgiously for a while. It taught me to stop bitching about the weird parts, just avoid them instead. And when you do this, you end up loving the language and making cool shit with it. Which is a good situation to be in, because it's the most widely distributed runtime in the world.

[Havvy]

But `new` is a bad part. Just an optimized bad part... You could replace every usage of it with `var instance = Object.create(Ctor.prototype);` (and change every `this` to `instance` in your code), and actually explicitly return `instance` -- and then never use `new` again. Your code will become more readable to boot, as there is less action at a distance.

[callum85]

Where is the action at a distance when I use new?

[Havvy]

The `new` is used at the call site while invisible at the function declaration.

[pedrocr]

This is the standard advice in these threads. I've found the book quite short of that goal. It has a few patterns to make the stranger parts a bit more bearable but real world JS still fails in all sorts of non-obvious ways unless you're very familiar with it. I hope the newer versions JS versions have gotten better

It used to be that building a competent web app was something you could do in a number of different languages, these days you really need to know JS or one of it's skins and it's made developing for the web much less friendly to people that don't do it every day.

[par]

Yes OP is serious, I don't think it's that hard to tell.

[mmanfrin]

   JS the language of the future? Why? It has probably the worst gotchas of any language I've coded in

You have conflated quality and popularity.