8 ms·

So I'm an above average JS developer. I feel save saying this and claiming this. I would never use most of the exotic new stuff and I would probably never use

by neals 11y ago

So I'm an above average JS developer. I feel save saying this and claiming this. I would never use most of the exotic new stuff and I would probably never use any of the red stuff. I'm not saying it shouldn't be in there. I love that JS can be a fit for everybody. I just wonder how much we're gonna be adding and when it's enough...

nkohari 11y ago
Languages constantly evolve. Java was created 20 years ago and it's still receiving regular updates.
- shriek 11y ago
  While I agree with you I also don't believe in adding things just for the sake of adding features. Remember, once you put a feature in a language it's going to remain in it forever and slowly the language can get bloated with lot of history in it's baggage (not that js already doesn't have this).
- mkohlmyr 11y ago
  Obviously this is true, but I kind of agree with him. So far I don't use the overwhelming majority of new features and it does sort of seem like JavaScript is in some kind of race with itself to implement every paradigm and idea that anyone latches on to. There is beauty in simplicity and commonality in code. I don't think there would be anything wrong with taking a more conservative approach to adding new language constructs. JavaScript needed a class syntax. It needed block-scoped variables. It needed better parameter syntax and object loops. Generators are great. I'm not sure how much else of what is being added is strictly necessary as opposed to a technological debt for the future that must be supported for compatibility.
  - likeclockwork 11y ago
    > JavaScript needed a class syntax. Did it? Or is that just a paradigm you've latched on to?
    - mkohlmyr 11y ago
      You got me.. Although the multitude of awful shims people invented would tend to support my assessment that a singular way of doing things was needed. Oh, and all the blog posts explaining "this" and prototype inheritance.. I take it back, you didn't get me. JavaScript needed a coherent common syntax for doing what everyone was trying to do anyway.
  - ufmace 11y ago
    As far as using the new features, how many people actually can/are? I can agree that they're needed, and I'm glad that they're coming, but support in browsers is variable at best, meaning you can't really use it in the front-end for anything in production without a transpiler, which IMHO mostly defeats the purpose. When you try to actually debug something, you have to deal with the mental translation of going back and forth between the translated/compiled stuff that's actually running and the source code. Could be different for stuff running in Node on the server, but then according to this, Node native support for ES6 features varies between bare-bones and not very tested to nonexistent. So we're back to transpilers again, not quite as much of a pain on the server, but still not great.
  - tracker1 11y ago
    Did it really need class syntax? I mean, there are a lot of us following functional patterns as much as possible, and I feel that I rarely need class syntax... I mean it's kind of nice for a react component, but even then, not something that couldn't easily be represented with static objects. I rarely use classes, or for that matter constructor functions... a lot of the code is far easier to follow and reason that way. As to block-scoped variables, understanding that variables were scoped to the function they are declared in wasn't a huge hinderance, and is part of the reason why the new stuff runs slower... creating that scope has overhead. I'll add that destructured assignment and string templates are huge... taking generators the next step to async functions with await is very nice as well, not that co didn't work. Fat-arrow syntax cuts quite a bit of typing out with a default return. Each piece is valuable to some, and collectively not everything is valuable to some... Just because you don't see the value, doesn't mean that nobody does. I, for example, will probably not use the WeakMap/Map/Symbol in practice... But I see how someone can find those valuable additions.
Keepo 11y ago
Can you elaborate more on what features you would never use and why please? > I feel save saying this and claiming this Is `this` some kind of pun? When I was learning JS I never felt safe around this:)
BinaryIdiot 11y ago
While I hold your same opinion I think you're being down voted for not elaborating on the way as it appears you're only ranting and not adding anything to the conversation. For me most of my work in node needs to work over multiple versions and most of my browser work also needs to work over multiple browsers. Transpiling with Babel means I can't debug the code I actually wrote (even mappings won't work in all browsers or older ones) and I don't need extra, unnecessary complexity added to my build and development. I like many of ES6's features but I value simplicity over almost everything so I can only hope to use it at some point in the future.
seanclayton 11y ago
Keep on using the old stuff then — crisis averted.
spriggan3 11y ago
It doesn't matter if you don't use them, libraries that you might depend on will use them, and you have to know the new syntax in order to read javascript code from now on.
ry_ry 11y ago
Out of curiosity, what is your definition of an average js dev? Are we talking 'does not use many jQuery plugins these days' or 'regular contributor to ${framework}' here?
terda12 11y ago
Some things I like about ES6 1. Arrow functions are really handy: ["the", "red", "fox"].map(word => console.log(word)) is much cleaner than ["the", "red", "fox"].map(function(word) { console.log(word) }) 2. Imports, while more ambiguous than `require`, look quite nice: import React, { Component } from 'react'; import Block from './Block'; vs var React = require('react'); var Block = require('./Block'); 3. Exports are cleaner and streamlined export default myFunction() vs module.exports = myFunction() So while ES6 is more ambiguous than ES5 and has a higher learning curve, I think it's much cleaner and looks more like a proper programming language. ES5 feels like a homegrown hacky language in comparison.
- mbrock 11y ago
  The code I write in ES2015 makes very heavy use of arrow functions, destructuring parameters, the ellipsis syntax for extending arrays and objects, and the syntax for evaluated object literal keys. Random example: DRAFT_LOADED: ({ state: { drafts }, payload: { draft } }) => ({ drafts: { ...drafts, [draft.id]: draft } }) In classic JavaScript, I'd have to write something like: RESULTS_LOADED: function(state, payload) { return { drafts: Object.assign( {}, state.drafts, keyValue(payload.draft.id, payload.draft) ) } } The new syntax rules combine to significantly improve the clarity of this kind of transformation function.
  - z3t4 11y ago
    hmm. Looks like some sort of exploit. Tried to run it in node and got some weird error I haven't seen before. Did you just pwn me?
    - mbrock 11y ago
      haha, no... I haven't tried it in pure Node, I'm using Babel for transpiling.
- minitech 11y ago
  I don’t find the arrow function version of (1) cleaner than the anonymous function version. Is it cleaner because you can fit it on one line? I don’t find the import version of (2) cleaner than the require() version. Having a boring old function that’s consistent with the rest of the language actually seems better than dedicated syntax, especially when that dedicated syntax is unnecessarily verbose. Copying Python’s might have been okay: // I have to repeat “fs” =( var fs = require('fs'); // Wait, I still have to repeat “fs” *and* it’s longer // *and* it looks more confusing? There’s no precedent // for this use of * in JavaScript. import * as fs from 'fs'; // Nice. import fs; I don’t find the `export default` version of (3) cleaner or more streamlined than the one that assigns to `module.exports`. It just seems like another waste of dedicated syntax.
drinchev 11y ago
I will be pretty happy if I see non-ES6 code if it is properly structured and documented well. Nevertheless if I see people has just replaced `class` with `jQuery.extend` or with some other helper tool it would be a downside. Also we are talking about lodash vs native implementation. That's one of the reasons I stopped working with coffeescript.

by neals 11y ago

nkohari 11y ago

Languages constantly evolve. Java was created 20 years ago and it's still receiving regular updates.

shriek 11y ago
While I agree with you I also don't believe in adding things just for the sake of adding features. Remember, once you put a feature in a language it's going to remain in it forever and slowly the language can get bloated with lot of history in it's baggage (not that js already doesn't have this).
mkohlmyr 11y ago
Obviously this is true, but I kind of agree with him. So far I don't use the overwhelming majority of new features and it does sort of seem like JavaScript is in some kind of race with itself to implement every paradigm and idea that anyone latches on to. There is beauty in simplicity and commonality in code. I don't think there would be anything wrong with taking a more conservative approach to adding new language constructs. JavaScript needed a class syntax. It needed block-scoped variables. It needed better parameter syntax and object loops. Generators are great. I'm not sure how much else of what is being added is strictly necessary as opposed to a technological debt for the future that must be supported for compatibility.
- likeclockwork 11y ago
  > JavaScript needed a class syntax. Did it? Or is that just a paradigm you've latched on to?
  - mkohlmyr 11y ago
    You got me.. Although the multitude of awful shims people invented would tend to support my assessment that a singular way of doing things was needed. Oh, and all the blog posts explaining "this" and prototype inheritance.. I take it back, you didn't get me. JavaScript needed a coherent common syntax for doing what everyone was trying to do anyway.
- ufmace 11y ago
  As far as using the new features, how many people actually can/are? I can agree that they're needed, and I'm glad that they're coming, but support in browsers is variable at best, meaning you can't really use it in the front-end for anything in production without a transpiler, which IMHO mostly defeats the purpose. When you try to actually debug something, you have to deal with the mental translation of going back and forth between the translated/compiled stuff that's actually running and the source code. Could be different for stuff running in Node on the server, but then according to this, Node native support for ES6 features varies between bare-bones and not very tested to nonexistent. So we're back to transpilers again, not quite as much of a pain on the server, but still not great.
- tracker1 11y ago
  Did it really need class syntax? I mean, there are a lot of us following functional patterns as much as possible, and I feel that I rarely need class syntax... I mean it's kind of nice for a react component, but even then, not something that couldn't easily be represented with static objects. I rarely use classes, or for that matter constructor functions... a lot of the code is far easier to follow and reason that way. As to block-scoped variables, understanding that variables were scoped to the function they are declared in wasn't a huge hinderance, and is part of the reason why the new stuff runs slower... creating that scope has overhead. I'll add that destructured assignment and string templates are huge... taking generators the next step to async functions with await is very nice as well, not that co didn't work. Fat-arrow syntax cuts quite a bit of typing out with a default return. Each piece is valuable to some, and collectively not everything is valuable to some... Just because you don't see the value, doesn't mean that nobody does. I, for example, will probably not use the WeakMap/Map/Symbol in practice... But I see how someone can find those valuable additions.

Keepo 11y ago

Can you elaborate more on what features you would never use and why please? > I feel save saying this and claiming this Is `this` some kind of pun? When I was learning JS I never felt safe around this:)

BinaryIdiot 11y ago

While I hold your same opinion I think you're being down voted for not elaborating on the way as it appears you're only ranting and not adding anything to the conversation. For me most of my work in node needs to work over multiple versions and most of my browser work also needs to work over multiple browsers. Transpiling with Babel means I can't debug the code I actually wrote (even mappings won't work in all browsers or older ones) and I don't need extra, unnecessary complexity added to my build and development. I like many of ES6's features but I value simplicity over almost everything so I can only hope to use it at some point in the future.

seanclayton 11y ago

Keep on using the old stuff then — crisis averted.

spriggan3 11y ago

It doesn't matter if you don't use them, libraries that you might depend on will use them, and you have to know the new syntax in order to read javascript code from now on.

ry_ry 11y ago

Out of curiosity, what is your definition of an average js dev? Are we talking 'does not use many jQuery plugins these days' or 'regular contributor to ${framework}' here?

terda12 11y ago

Some things I like about ES6 1. Arrow functions are really handy: ["the", "red", "fox"].map(word => console.log(word)) is much cleaner than ["the", "red", "fox"].map(function(word) { console.log(word) }) 2. Imports, while more ambiguous than `require`, look quite nice: import React, { Component } from 'react'; import Block from './Block'; vs var React = require('react'); var Block = require('./Block'); 3. Exports are cleaner and streamlined export default myFunction() vs module.exports = myFunction() So while ES6 is more ambiguous than ES5 and has a higher learning curve, I think it's much cleaner and looks more like a proper programming language. ES5 feels like a homegrown hacky language in comparison.

mbrock 11y ago
The code I write in ES2015 makes very heavy use of arrow functions, destructuring parameters, the ellipsis syntax for extending arrays and objects, and the syntax for evaluated object literal keys. Random example: DRAFT_LOADED: ({ state: { drafts }, payload: { draft } }) => ({ drafts: { ...drafts, [draft.id]: draft } }) In classic JavaScript, I'd have to write something like: RESULTS_LOADED: function(state, payload) { return { drafts: Object.assign( {}, state.drafts, keyValue(payload.draft.id, payload.draft) ) } } The new syntax rules combine to significantly improve the clarity of this kind of transformation function.
- z3t4 11y ago
  hmm. Looks like some sort of exploit. Tried to run it in node and got some weird error I haven't seen before. Did you just pwn me?
  - mbrock 11y ago
    haha, no... I haven't tried it in pure Node, I'm using Babel for transpiling.
minitech 11y ago
I don’t find the arrow function version of (1) cleaner than the anonymous function version. Is it cleaner because you can fit it on one line? I don’t find the import version of (2) cleaner than the require() version. Having a boring old function that’s consistent with the rest of the language actually seems better than dedicated syntax, especially when that dedicated syntax is unnecessarily verbose. Copying Python’s might have been okay: // I have to repeat “fs” =( var fs = require('fs'); // Wait, I still have to repeat “fs” *and* it’s longer // *and* it looks more confusing? There’s no precedent // for this use of * in JavaScript. import * as fs from 'fs'; // Nice. import fs; I don’t find the `export default` version of (3) cleaner or more streamlined than the one that assigns to `module.exports`. It just seems like another waste of dedicated syntax.

drinchev 11y ago

I will be pretty happy if I see non-ES6 code if it is properly structured and documented well. Nevertheless if I see people has just replaced `class` with `jQuery.extend` or with some other helper tool it would be a downside. Also we are talking about lodash vs native implementation. That's one of the reasons I stopped working with coffeescript.