7 ms·

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

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.

cdelsolar 12y ago
Read the Good Parts of Javascript and get a JS linter. Javascript is a fine language if you do this.
- Shizka 12y ago
  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-Crockford/dp/0596517742 http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor... And how/why did the book improve your opinion about the language?
  - callum85 12y ago
    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 12y ago
      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 12y ago
        Where is the action at a distance when I use new?
        Havvy 12y ago
        The `new` is used at the call site while invisible at the function declaration.
- aikah 12y ago
  > 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 12y ago
    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 12y ago
      Agreed. And things could have been enormously worse (hint: VBScript).
  - mateuszf 12y ago
    Every language has good and bad parts.
    - jules 12y ago
      This can be used to justify any atrocity.
  - aflinik 12y ago
    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.
- pedrocr 12y ago
  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.
lhnz 12y ago
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 12y ago
  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.
spion 12y ago
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?
- warfangle 12y ago
  We've got parallelism in the browser (sorta) with webworkers.
  - yazaddaruvala 12y ago
    I'm actually glad there isn't parallelism (well threads/actors/tasks). I'd go so far as to consider it a feature.
    - Xixi 12y ago
      May I ask why? Not having parallelism seems like a net negative to me...
      - yazaddaruvala 12y ago
        [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;
hrktb 12y ago
> 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 12y ago
  It's already getting more enjoyable to me. Things like .forEach and => mean I can write really nice code.
lobster_johnson 12y ago
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 12y ago
> 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.
ori_b 12y ago
> 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.
ori_b 12y ago
> 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.
ori_b 12y ago
> 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.
mmanfrin 12y ago
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.
denizozger 12y ago
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 12y ago
  > 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.
aaronem 12y ago
Industry vs. academia in two comments. Well done, the pair of you. Now stop it.
par 12y ago
Yes OP is serious, I don't think it's that hard to tell.
D_Guidi 12y ago
>JS the language of the future? Why? because it's pervasive. market matters, not developers.
swah 12y ago
From http://steve-yegge.blogspot.com/2007/02/next-big-language.html 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 12y ago
  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.
conradk 12y ago
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 12y ago
  > 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)

cdelsolar 12y ago

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

Shizka 12y ago
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-Crockford/dp/0596517742 http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockfor... And how/why did the book improve your opinion about the language?
- callum85 12y ago
  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 12y ago
    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 12y ago
      Where is the action at a distance when I use new?
      - Havvy 12y ago
        The `new` is used at the call site while invisible at the function declaration.
aikah 12y ago
> 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 12y ago
  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 12y ago
    Agreed. And things could have been enormously worse (hint: VBScript).
- mateuszf 12y ago
  Every language has good and bad parts.
  - jules 12y ago
    This can be used to justify any atrocity.
- aflinik 12y ago
  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.
pedrocr 12y ago
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.

lhnz 12y ago

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 12y ago
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.

spion 12y ago

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?

warfangle 12y ago
We've got parallelism in the browser (sorta) with webworkers.
- yazaddaruvala 12y ago
  I'm actually glad there isn't parallelism (well threads/actors/tasks). I'd go so far as to consider it a feature.
  - Xixi 12y ago
    May I ask why? Not having parallelism seems like a net negative to me...
    - yazaddaruvala 12y ago
      [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;

hrktb 12y ago

> 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 12y ago
It's already getting more enjoyable to me. Things like .forEach and => mean I can write really nice code.

lobster_johnson 12y ago

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 12y ago

> 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.

ori_b 12y ago

mmanfrin 12y ago

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.

denizozger 12y ago

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 12y ago
> 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.

aaronem 12y ago

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

par 12y ago

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

D_Guidi 12y ago

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

swah 12y ago

From http://steve-yegge.blogspot.com/2007/02/next-big-language.html 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 12y ago
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.

conradk 12y ago

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 12y ago
> 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)