4 ms·

That's fair. My comment is probably off-base when it comes to the particular contents of this article. I guess I was speaking more to a general fatigue with ev

by adamkl 6y ago

That's fair. My comment is probably off-base when it comes to the particular contents of this article. I guess I was speaking more to a general fatigue with every new feature that is added to JavaScript/TypeScript. What was so wrong with Math.pow(x, y) that we needed a new operator for it? I think this is a question that could be asked of many additions to JavaScript/TypeScript over the years, and I think every (well-intentioned) addition has contributed to the language's current kitchen sink. New additions don't mean the old capabilities will go away (without breaking backwards compatibility). So yes, some developers will use the new power operator in net-new code, but all existing usages of Math.pow() will remain, and every new developer that learns JavaScript will now need to know both.

brlewis 6y ago
Ideally, JS would have been based on S expressions and consistency would naturally flow from the syntax. But that ship has sailed, and occasionally it makes sense to add a new infix operator for succinctness. https://github.com/tc39/proposal-exponentiation-operator#informative https://github.com/tc39/proposal-exponentiation-operator#inf... With prettier, one can make an old style go away.
Silhouette 6y ago
New additions don't mean the old capabilities will go away (without breaking backwards compatibility). This is something any popular programming language has to wrestle with. There is a lot of merit in Python's philosophy of having one, and preferably only one, obvious way to do something. Otherwise, even if each different way is perfectly good in its own right, you still have more for anyone learning the language to know, and you get different representations of the same idea appearing in the same code base for no particular reason. I do think JavaScript has more of a problem with this than most languages because of its rapid changes and ambiguous standardisation (the de jure of annual ES standards vs. the realities of what is supported in real time in each browser, or Node version, or Babel preset). Does anyone really have time to check whether some new function on Array's prototype or some new syntax like the examples in this article is available in every target they need to support yet? I'm guessing most of us still use Babel in our build process for front-end code, even if the relatively new parts of JS we're using are supported natively everywhere we need them by now. But then you get things like modules and imports, and you still find Node's story with these is a muddle. Things we've taken for granted for years now on the front end don't always work out of the box as you might expect on the back end, and there are at least two competing styles. And this is arguably the most important and fundamental tool a programming language needs for building larger applications!
- brlewis 6y ago
  Why would one check if the new syntax is available rather than just use browserslist? https://github.com/browserslist/browserslist-example#babel https://github.com/browserslist/browserslist-example#babel
  - Silhouette 6y ago
    For one thing, Node exists. If you are writing server-side or automation code, you probably aren't using tools like Babel and Browserslist.

by adamkl 6y ago

brlewis 6y ago

Ideally, JS would have been based on S expressions and consistency would naturally flow from the syntax. But that ship has sailed, and occasionally it makes sense to add a new infix operator for succinctness. https://github.com/tc39/proposal-exponentiation-operator#informative https://github.com/tc39/proposal-exponentiation-operator#inf... With prettier, one can make an old style go away.

Silhouette 6y ago

New additions don't mean the old capabilities will go away (without breaking backwards compatibility). This is something any popular programming language has to wrestle with. There is a lot of merit in Python's philosophy of having one, and preferably only one, obvious way to do something. Otherwise, even if each different way is perfectly good in its own right, you still have more for anyone learning the language to know, and you get different representations of the same idea appearing in the same code base for no particular reason. I do think JavaScript has more of a problem with this than most languages because of its rapid changes and ambiguous standardisation (the de jure of annual ES standards vs. the realities of what is supported in real time in each browser, or Node version, or Babel preset). Does anyone really have time to check whether some new function on Array's prototype or some new syntax like the examples in this article is available in every target they need to support yet? I'm guessing most of us still use Babel in our build process for front-end code, even if the relatively new parts of JS we're using are supported natively everywhere we need them by now. But then you get things like modules and imports, and you still find Node's story with these is a muddle. Things we've taken for granted for years now on the front end don't always work out of the box as you might expect on the back end, and there are at least two competing styles. And this is arguably the most important and fundamental tool a programming language needs for building larger applications!

brlewis 6y ago
Why would one check if the new syntax is available rather than just use browserslist? https://github.com/browserslist/browserslist-example#babel https://github.com/browserslist/browserslist-example#babel
- Silhouette 6y ago
  For one thing, Node exists. If you are writing server-side or automation code, you probably aren't using tools like Babel and Browserslist.