3 ms·

> I never write JS > ECMAScript 5. Why? That's a bold statement. Why EcmaScript 5 and not JavaScript 1.4 for that matter? Programming languages change and evo

> I never write JS > ECMAScript 5. Why? That's a bold statement. Why EcmaScript 5 and not JavaScript 1.4 for that matter? Programming languages change and evolve. EcmaScript 6 introduces a lot of features, including some that greatly improve the readability, maintainability, and cleanliness of the code. Sure, right now you may need to hold back on some features if supporting legacy Internet Explorer versions is your goal and you don't use a preprocessor such as BabelJs, but at some point the only browsers that don't support ES6 will be browsers that are unsupported by their vendors and inherently unsafe; so why stick with ES5 in particular? Or are you simply waiting for the moment all current browsers support ES6? I get not wanting to use bleeding edge features supported only in the latest developer edition of Chrome or Firefox, but at some point ES6 is supported in 100% of the browsers people can safely use, and a few years after that ES7, and so on.

profeta 10y ago
you are probably too young to remember the time when using <script type="javascript1.2"> was bold and bleeding edge. (probably got the syntax wrong, because, well, that what happens to memory when you are not too young)
spriggan3 10y ago
> That's a bold statement. Why EcmaScript 5 and not JavaScript 1.4 for that matter? Because most devices will run most of ES5, very few devices will run any ES6. Now there are transpilers sure, but I remember a time Javascript was about simplicity and not relying on a complex grunt pipeline + Babel. Now JS tooling is more complicated than Java's only with JSON in place of XML. The irony.
- lucasmullens 10y ago
  I think for most people the time you save using ES6 features is more than the time it takes to set up a build system, at least for larger projects.
  - alistproducer2 10y ago
    I would have to disagree. There's no way saving a few keystrokes on an arrow function or being able to use 'class' will ever compare to understanding, let alone debugging, gulp streams. IMO JS tooling has gone way overboard, but in code, as in any artform, everything is subjective.
spenuke 10y ago
I think you might be misreading the parent statement as "I will never write JS > ES5". I too find that the easiest to implement features are (not terribly surprisingly!) the least interesting; they are not worth the terrible friction that I'd see in my current organization. I have a hard enough time trying to get folks to write good test coverage and understand the gotchas of writing async code everywhere. So for me, there's way bigger fish to fry than (exaggerating a bit here) saving a few characters with arrow functions. But that's still not to say I won't ever use it.

profeta 10y ago

you are probably too young to remember the time when using <script type="javascript1.2"> was bold and bleeding edge. (probably got the syntax wrong, because, well, that what happens to memory when you are not too young)

spriggan3 10y ago

> That's a bold statement. Why EcmaScript 5 and not JavaScript 1.4 for that matter? Because most devices will run most of ES5, very few devices will run any ES6. Now there are transpilers sure, but I remember a time Javascript was about simplicity and not relying on a complex grunt pipeline + Babel. Now JS tooling is more complicated than Java's only with JSON in place of XML. The irony.

lucasmullens 10y ago
I think for most people the time you save using ES6 features is more than the time it takes to set up a build system, at least for larger projects.
- alistproducer2 10y ago
  I would have to disagree. There's no way saving a few keystrokes on an arrow function or being able to use 'class' will ever compare to understanding, let alone debugging, gulp streams. IMO JS tooling has gone way overboard, but in code, as in any artform, everything is subjective.

spenuke 10y ago

I think you might be misreading the parent statement as "I will never write JS > ES5". I too find that the easiest to implement features are (not terribly surprisingly!) the least interesting; they are not worth the terrible friction that I'd see in my current organization. I have a hard enough time trying to get folks to write good test coverage and understand the gotchas of writing async code everywhere. So for me, there's way bigger fish to fry than (exaggerating a bit here) saving a few characters with arrow functions. But that's still not to say I won't ever use it.