7 ms·

I think it's a common misconception that JavaScript isn't an elegant language. The real issue is that it's the only language with a monopoly. So people who want

by watson 10y ago

I think it's a common misconception that JavaScript isn't an elegant language. The real issue is that it's the only language with a monopoly. So people who want to work on the web have to use it. This results in people being forced to use it against their will. So obviously a lot of people don't like it - probably because it doesn't have that feature they really like from their primary language - whatever that is. If we invented a replacement language, the issue would not go away, but simply shift. I think instead the real issue is that we're too bad at educating people in how to properly use the language. Sure there's corners of the language that are bad, but as a seasoned JavaScript developer you simply know to ignore those corners. So they don't bother you. You instead focus on the cool things about the language. Any programming language have good and bad things. And we as developers learn to focus and leverage the good parts to our advantage. The ideal of a perfect language is a pipe dream unfortunately - instead my advice is to really learn the language and embrace it instead of fighting it.

GavinMcG 10y ago
I don't think it's about missing features. JavaScript has a lot of footguns. You admit that, but dismiss the complaints. Sure, with experience you know what to ignore, but a well-designed language has fewer of those areas in the first place.
- kelvin0 10y ago
  I've used JS enough to find that it's more like a nuclear powered .50 cal Gatling gun.
golergka 10y ago
> seasoned JavaScript developer you simply know to ignore those corners I'm sorry, but how does a seasoned Javascript developer ignores the absence of compile-time type checks? Aside from switching to a language that compiles to Javascript.
- jcao219 10y ago
  I've always thought that Javascript makes up for its lack of compile-time guarantees with compensating tooling. For example, it's common to use Flow with Javascript to enable static type checking before actually running it. The language itself doesn't guarantee type safety, but when used with peripheral tooling, the developer isn't missing too much.
- bruce_one 10y ago
  There are many popular dynamically typed languages. Why is it suddenly a foregone conclusion that seasoned Javascript developers all want compiled statically typed languages?
  - golergka 10y ago
    I know that it's a very old argument that I'm not going to win. But I would like to provoke you to it because I'm really trying to change my mindset, coming from a static language to Javascript - and I still just don't see, where are the wins. Please argue with me, because I _want_ to be convinced. I'm trying. It may be because of the habits I developed, writing compiled code. I always would first concentrate on my concepts, things that I want the code to do, data and flow structure - while keeping all errors (even syntax) silent. And only when I got everything I wanted implemented and consistent, I would turn to a compiler to quickly fix all mismatches in API, all wrong method names and other trivial blunders. Now I stumble, feeling that I'm a blind man going through a minefield. Every line I write, I have to think about the things that I want to express and the mechanics of language and API simultaneously - because nothing's got my back. (Yes, I know that I should write unit tests, but not all of us have the luxury of working on perfect projects, starting perfect projects from scratch, or having the resources of putting good practices into legacy code). Every time I discover that I mistyped the name of the function or variable, forgot to use "this" when referring to an object property (C# habit), forgot that external API function returns a custom type and not a string - I do it too late. Instead of quickly fixing the thing that I've only typed right now, I have to go back, and spend time reading and understanding relevant code again. All I'm trying to understand is, where are the trade-offs? Where are all the awesome dynamic things that make all that worth it?
pjmlp 10y ago
We hate JavaScript, because writing the code below is a perfect valid way of calling alert(1). [][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+ [])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()
- jaredsohn 10y ago
  That's a feature if most of the keys on your keyboard are broken. :) Seriously, it is not a good reason. Just don't write code like this nor allow other people in your team to write code like this. Fortunately, this kind of code is unlikely to be written by mistake so it is easily avoidable.
  - pjmlp 10y ago
    That was just one example, there are lots of other WATs. As for team, in enterprise consulting, the concept of team is very shallow.
    - scriptproof 10y ago
      I initially believed it was a sarcasm!
- smonff 10y ago
fvargas 10y ago
I think ES6+ has done wonders for JavaScript and has made it a highly expressive language. It's true there are quirks and poorly designed aspects which can be confusing at first glance. But like with any language, once you understand how it works, you learn to work with it. Moreover, as the language continues to improve, many of those quirks become irrelevant. It's important to understand that, by virtue of having been bestowed with a monopoly over the web, JavaScript holds a great deal of leverage as a language. If you want to develop for the web, you pretty much have to adopt JavaScript into your stack. It's no surprise, then, that Node became so popular. Being able to use that language you're forced to use for the client on the server and to run the same code has major benefits. The Node and npm developers got many things right to be sure. But Node and its ecosystem, by virtue of offering JavaScript, benefitted immensely from developers' desire to unify a previously disjoint part of their stack. I find myself asking instead, how far will JavaScript's reach continue to stretch? Electron and React Native have become extremely popular. It's not just speculation, there is undeniable momentum.
- erikpukinskis 10y ago
  I think ES6 is the worst thing that ever happened to JavaScript because it killed it's best feature: being a small language that runs everywhere. Now when I want to use a JS library, I have to think: what is this author's philosophy about language extension? Are they going to start using some new feature that some other library I depend on is incompatible with? You used to be able to run JavaScript anywhere on any device. Think about how powerful that is. We sacrificed that for supposed gains in "ergonomics". People hate callbacks. People hate "this". But if you ask people who really learned how to use those things, they're not problems at all. They're only problems if you're coming from Ruby. It's like someone took an Apple and said "this is gross, it's not juicy and tangy like an orange!" And then they soaked it in vinegar and wrapped in orange skins. Now it scores well on orange-ness but is that a virtue?
  - ng12 10y ago
    Who's writing native ES6 code? Support for IE8 is just now starting to slip in the community (due too old, mundane things like Object.defineProperty). Almost every package on NPM targets ES3. Also, IE never ran everywhere. Targeting IE8 is hard, targeting IE6 was a nightmare.
ergo14 10y ago
> I think it's a common misconception that JavaScript isn't an elegant language. 1 + 'a' = "1a", I've seen more ellegant solutions, I'd love JS to be strongly typed at least (without typescript).
blueprint 10y ago
I'm not nearly so concerned with elegance as I am with being able to manage memory simply. the GC and "needed" detection lend themselves, how shall I say, to complexity.
- z3t4 10y ago
  GC is often better at the job then humans. you can manage memory in JS yourself though by not crating new objects and using pre alloc buffers instead.
jondubois 10y ago
I agree, JS is quite an elegant language, especially since ES6. I'm kind of disappointed with the introduction of the 'class' keyword though (and the way it was implemented). The old prototype function declaration approach is really good once you understand it.
- spraak 10y ago
  I do like how the prototype way makes it more clear that it's just a function. What about you?
  - coldtea 10y ago
    I find that an implementation detail that most people don't care about in their use of prototypes.
    - spraak 10y ago
      I don't follow
      - woah 10y ago
        Prototypes in js are almost always used in a way that approximates classical classes, but with confusing syntax. The 'class' keyword just makes things more readable.
ben_jones 10y ago
I think we know how to teach it but we can't agree on how to use it. How many shops are more then happy to cut corners, pull in gigantic misunderstood 3rd party libs, green light advertisers code, allow unsupervised and under-trained juniors to contribute if it "looks right", etc. etc. Bottom line is the business and administrative aspects of language usage are loosely defined with javascript and it makes our lives as engineers slightly less pleasant (or potentially extremely unpleasant depending on what you have to work on). And the world keeps spinning.
devwastaken 10y ago
>I think instead the real issue is that we're too bad at educating people in how to properly use the language. I don't think this is true at all. I think over time it becomes very easy to apologize for the environment we're forced to use, because there is no comparison, we only have JS for the web. In any decent project, you're going to have hundreds of 3rd party dependencies installed from tons of sources, some of which could freely introduce exploits into popular programs at any time. If any of these break, you're going on a long hunt to track it down, ultimately to be met with authors that aren't responsive or some bug caused by god knows what incompatability. We're stuck between the ever flowing battle of new language constructs and languages ontop of JS that try to make it 'easier'. JS lacks very important things that devs have found to be necessary, like typings, and even trying to add typings is a huge battle in itself, that again, is ever changing. Just try and google for where you should put your .d.ts files, and you'l get 4 different answers, all from different stages of versions and recommendations. You can't teach JS. You can only say that things never stay the same, so build things fast and break them quicker. What you consider 'properly' today, is tomorrows bad practice.
- woah 10y ago
  You can put //@flow at the top of your files and install a plugin for your editor and have typing in about 30 seconds.
  - devwastaken 10y ago
    See, thats the thing though. There's so many ways to do something, with multiple competing standards on how to do it, along with plenty of quirks and ways of working with it you only understand by experience. This is good, when you already know exactly what you need and what that provides, but its impossible to keep up unless you're spending a lot of time testing and researching, and even still, at the end of the day you've gotta make the application. One of those 'it takes a village' to make a good JS app.
    - gabrielcsapo 10y ago
      a village?! Come on healthcare.gov ...
Chris2048 10y ago
Having a monopoly could potentially be a great thing, no more tech-change anxiety, consolidation of effort etc But there is so little structure, and so many roll-your-own efforts, the JS world is heavily fragmented... > we're too bad at educating people in how to properly use the language Does such a thing exist? How does a seasoned JS dev avoid DOM manipulation/interference nightmares, lack of typing, event hierarchy complexity? How do you really make a modular site without heavily committing to one framework? > ideal of a perfect language is a pipe dream Nothing's perfect, but still keep fighting for better.

by watson 10y ago

GavinMcG 10y ago

I don't think it's about missing features. JavaScript has a lot of footguns. You admit that, but dismiss the complaints. Sure, with experience you know what to ignore, but a well-designed language has fewer of those areas in the first place.

kelvin0 10y ago
I've used JS enough to find that it's more like a nuclear powered .50 cal Gatling gun.

golergka 10y ago

> seasoned JavaScript developer you simply know to ignore those corners I'm sorry, but how does a seasoned Javascript developer ignores the absence of compile-time type checks? Aside from switching to a language that compiles to Javascript.

jcao219 10y ago
I've always thought that Javascript makes up for its lack of compile-time guarantees with compensating tooling. For example, it's common to use Flow with Javascript to enable static type checking before actually running it. The language itself doesn't guarantee type safety, but when used with peripheral tooling, the developer isn't missing too much.
bruce_one 10y ago
There are many popular dynamically typed languages. Why is it suddenly a foregone conclusion that seasoned Javascript developers all want compiled statically typed languages?
- golergka 10y ago
  I know that it's a very old argument that I'm not going to win. But I would like to provoke you to it because I'm really trying to change my mindset, coming from a static language to Javascript - and I still just don't see, where are the wins. Please argue with me, because I _want_ to be convinced. I'm trying. It may be because of the habits I developed, writing compiled code. I always would first concentrate on my concepts, things that I want the code to do, data and flow structure - while keeping all errors (even syntax) silent. And only when I got everything I wanted implemented and consistent, I would turn to a compiler to quickly fix all mismatches in API, all wrong method names and other trivial blunders. Now I stumble, feeling that I'm a blind man going through a minefield. Every line I write, I have to think about the things that I want to express and the mechanics of language and API simultaneously - because nothing's got my back. (Yes, I know that I should write unit tests, but not all of us have the luxury of working on perfect projects, starting perfect projects from scratch, or having the resources of putting good practices into legacy code). Every time I discover that I mistyped the name of the function or variable, forgot to use "this" when referring to an object property (C# habit), forgot that external API function returns a custom type and not a string - I do it too late. Instead of quickly fixing the thing that I've only typed right now, I have to go back, and spend time reading and understanding relevant code again. All I'm trying to understand is, where are the trade-offs? Where are all the awesome dynamic things that make all that worth it?

pjmlp 10y ago

We hate JavaScript, because writing the code below is a perfect valid way of calling alert(1). [][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]][([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][[]]+[])[+!+[]]+(![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[+!+[]]+([][[]]+[])[+[]]+([][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]]((![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]+(![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]]+[+!+[]]+(!![]+[][(![]+[])[+[]]+([![]]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+ [])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[!+[]+!+[]+[+[]]])()

jaredsohn 10y ago
That's a feature if most of the keys on your keyboard are broken. :) Seriously, it is not a good reason. Just don't write code like this nor allow other people in your team to write code like this. Fortunately, this kind of code is unlikely to be written by mistake so it is easily avoidable.
- pjmlp 10y ago
  That was just one example, there are lots of other WATs. As for team, in enterprise consulting, the concept of team is very shallow.
  - scriptproof 10y ago
    I initially believed it was a sarcasm!
smonff 10y ago

fvargas 10y ago

I think ES6+ has done wonders for JavaScript and has made it a highly expressive language. It's true there are quirks and poorly designed aspects which can be confusing at first glance. But like with any language, once you understand how it works, you learn to work with it. Moreover, as the language continues to improve, many of those quirks become irrelevant. It's important to understand that, by virtue of having been bestowed with a monopoly over the web, JavaScript holds a great deal of leverage as a language. If you want to develop for the web, you pretty much have to adopt JavaScript into your stack. It's no surprise, then, that Node became so popular. Being able to use that language you're forced to use for the client on the server and to run the same code has major benefits. The Node and npm developers got many things right to be sure. But Node and its ecosystem, by virtue of offering JavaScript, benefitted immensely from developers' desire to unify a previously disjoint part of their stack. I find myself asking instead, how far will JavaScript's reach continue to stretch? Electron and React Native have become extremely popular. It's not just speculation, there is undeniable momentum.

erikpukinskis 10y ago
I think ES6 is the worst thing that ever happened to JavaScript because it killed it's best feature: being a small language that runs everywhere. Now when I want to use a JS library, I have to think: what is this author's philosophy about language extension? Are they going to start using some new feature that some other library I depend on is incompatible with? You used to be able to run JavaScript anywhere on any device. Think about how powerful that is. We sacrificed that for supposed gains in "ergonomics". People hate callbacks. People hate "this". But if you ask people who really learned how to use those things, they're not problems at all. They're only problems if you're coming from Ruby. It's like someone took an Apple and said "this is gross, it's not juicy and tangy like an orange!" And then they soaked it in vinegar and wrapped in orange skins. Now it scores well on orange-ness but is that a virtue?
- ng12 10y ago
  Who's writing native ES6 code? Support for IE8 is just now starting to slip in the community (due too old, mundane things like Object.defineProperty). Almost every package on NPM targets ES3. Also, IE never ran everywhere. Targeting IE8 is hard, targeting IE6 was a nightmare.

ergo14 10y ago

> I think it's a common misconception that JavaScript isn't an elegant language. 1 + 'a' = "1a", I've seen more ellegant solutions, I'd love JS to be strongly typed at least (without typescript).

blueprint 10y ago

I'm not nearly so concerned with elegance as I am with being able to manage memory simply. the GC and "needed" detection lend themselves, how shall I say, to complexity.

z3t4 10y ago
GC is often better at the job then humans. you can manage memory in JS yourself though by not crating new objects and using pre alloc buffers instead.

jondubois 10y ago

I agree, JS is quite an elegant language, especially since ES6. I'm kind of disappointed with the introduction of the 'class' keyword though (and the way it was implemented). The old prototype function declaration approach is really good once you understand it.

spraak 10y ago
I do like how the prototype way makes it more clear that it's just a function. What about you?
- coldtea 10y ago
  I find that an implementation detail that most people don't care about in their use of prototypes.
  - spraak 10y ago
    I don't follow
    - woah 10y ago
      Prototypes in js are almost always used in a way that approximates classical classes, but with confusing syntax. The 'class' keyword just makes things more readable.

ben_jones 10y ago

I think we know how to teach it but we can't agree on how to use it. How many shops are more then happy to cut corners, pull in gigantic misunderstood 3rd party libs, green light advertisers code, allow unsupervised and under-trained juniors to contribute if it "looks right", etc. etc. Bottom line is the business and administrative aspects of language usage are loosely defined with javascript and it makes our lives as engineers slightly less pleasant (or potentially extremely unpleasant depending on what you have to work on). And the world keeps spinning.

devwastaken 10y ago

>I think instead the real issue is that we're too bad at educating people in how to properly use the language. I don't think this is true at all. I think over time it becomes very easy to apologize for the environment we're forced to use, because there is no comparison, we only have JS for the web. In any decent project, you're going to have hundreds of 3rd party dependencies installed from tons of sources, some of which could freely introduce exploits into popular programs at any time. If any of these break, you're going on a long hunt to track it down, ultimately to be met with authors that aren't responsive or some bug caused by god knows what incompatability. We're stuck between the ever flowing battle of new language constructs and languages ontop of JS that try to make it 'easier'. JS lacks very important things that devs have found to be necessary, like typings, and even trying to add typings is a huge battle in itself, that again, is ever changing. Just try and google for where you should put your .d.ts files, and you'l get 4 different answers, all from different stages of versions and recommendations. You can't teach JS. You can only say that things never stay the same, so build things fast and break them quicker. What you consider 'properly' today, is tomorrows bad practice.

woah 10y ago
You can put //@flow at the top of your files and install a plugin for your editor and have typing in about 30 seconds.
- devwastaken 10y ago
  See, thats the thing though. There's so many ways to do something, with multiple competing standards on how to do it, along with plenty of quirks and ways of working with it you only understand by experience. This is good, when you already know exactly what you need and what that provides, but its impossible to keep up unless you're spending a lot of time testing and researching, and even still, at the end of the day you've gotta make the application. One of those 'it takes a village' to make a good JS app.
  - gabrielcsapo 10y ago
    a village?! Come on healthcare.gov ...

Chris2048 10y ago

Having a monopoly could potentially be a great thing, no more tech-change anxiety, consolidation of effort etc But there is so little structure, and so many roll-your-own efforts, the JS world is heavily fragmented... > we're too bad at educating people in how to properly use the language Does such a thing exist? How does a seasoned JS dev avoid DOM manipulation/interference nightmares, lack of typing, event hierarchy complexity? How do you really make a modular site without heavily committing to one framework? > ideal of a perfect language is a pipe dream Nothing's perfect, but still keep fighting for better.