4 ms·

I don't see how syntactic sugar makes any sense for javascript. Breaking compatibility is so severe because every browser needs to catch up, yet it doesn't actu

I don't see how syntactic sugar makes any sense for javascript. Breaking compatibility is so severe because every browser needs to catch up, yet it doesn't actually enable anything that couldn't be done before.

Nullabillity 4y ago
No compatibility is broken, old scripts will keep on working just fine. Scripts written for the new syntax won't work in old browsers, but that's the nature of evolving standards anyway.
- dmix 4y ago
  > Scripts written for the new syntax won't work in old browsers, And critically browsers are - for the most part - much more in sync these days across the board. A lot of web devs got burned through the years of IE6-IE11 and have a natural distaste for browser level changes. Pipes have been (formally) debated for 5yrs now by the JS people, so they aren't exactly being non-conservative about this one.
  - mmis1000 4y ago
    Unfortunately. If your web page need to deal with Chinese Android phones, you still need to deal with old browsers. Their android system somehow always shipped with broken auto-update of webview or chrome. Which results in people open your webpage with quite old browser version.
fnimick 4y ago
It lets a transpiler like Babel or Typescript use the new syntax and output the equivalent code that works on older browser. Same reason async/await was useful far before there was native browser support - you could immediately use it in your codebase and compile to a legacy browser target.
- CyberDildonics 4y ago
  If you're compiling to javascript anyway, why would you need a pipe operator in javascript instead of just nesting the function calls?
  - hajile 4y ago
    Because x |> f |> g |> h is much easier to read than h(g(f(x))) for most people.
    - CyberDildonics 4y ago
      If you're compiling from another language you would be using whatever syntactic sugar you want, why break compatibility just to have the compiled javascript look a little better?
      - nosianu 4y ago
        > If you're compiling from another language TypeScript isn't another language though. It is the latest official ECMAScript plus type annotations. Only some very, very few, rare, old stuff like enums really is different code. 99% of TypeScript is just "remove the types to get ECMAScript". That TypeScript, the tool,also adds a transpiler is a distraction that made a lot of people believe TS is a different language. But the TS folks have always taken great pain to only ever support features that are or are about to be in the ECMAScript standard, and not to deviate from it. That they did initially with some namespace stuff and enums was before ES2015, when JS was lacking some things many people thought were essential. Even then they only added less than a handful of "TypeScript-code". When you look at the Babel "transpiler" for Typescript, before they added a bit more for class stuff, it pretty much showed that "transpilation" of TS to JS - as long as you targeted a recent ES version - was achieved by doing nothing more than to remove all those type annotations. I'm still mad at the TS guiys for muddying the waters so much by confusing soooo many people by bundling type checking and transpilation in one tool. This could have been much more clear. I too stuck to using Flow for quite some time until I realized TypeScript really is Javascript, while Flow communicated in its architecture and usage already that it just "added types" (literally).
binarymax 4y ago
Indeed. The argument of “nested calls are hard to read” is strange, because this looks terrible
- usrusr 4y ago
  Anything looks better than nested calls once you have started to get used to the benefits of reading left-to-right. It's one of those pains you don't realize you have unless it suddenly goes away.
  - binarymax 4y ago
    Nested calls can be a code smell, sure. But easily fixable: one(two(three())); Becomes let a=three(); let b=two(a); one(b); Clean and easy, no sugar required.
    - usrusr 4y ago
      Lots of low-value names required. Those names will inevitably either be badly chosen or have taken far more time to make up than they are worth. That's assuming the code isn't written by that one guy on every team who stubbornly insists on var x = three(); x = two(x); one(x): (having the names certainly is nice to have in the debugger, but I'd rather have those intermediate results be an explicit debugger feature than junk taking up mental bandwidth all over the code, at all times)
      - binarymax 4y ago
        Good point and yours does look better :)
        usrusr 4y ago
        The beauty of not using variables is that they don't pollute scope: a promise to the reader that it's perfectly fine to forget about that inermeditate result immediately after seeing it passed into the next step of the pipeline. Otherwise, you never know if it will perhaps show up later for some unexpected purpose. In a left-to-right language, those values that do get a name implicitly stand out
pavlov 4y ago
Every browser these days just means Chromium and WebKit, so all it takes is that Google and Apple need to agree. Firefox usage is down to a rounding error, and they happily implement whatever the commercial duo decides the web should have.
qbasic_forever 4y ago
Browsers have established they can roll out changes behind feature flags, and the community adapts and adopts them. This is a solved problem. ES6 transition, await/async, string templates, etc. were major JS changes that required browsers and runtimes to change. They did. It was fine. They can do it again!
- CyberDildonics 4y ago
  Promise added a very valuable new capability, but this would just mean what you write doesn't work on any non updated browser for a very minor syntax improvement. If there are too many nested calls, assign some of the function results to variables first.
  - qbasic_forever 4y ago
    Async/await is pure syntactic sugar. Look at python 3.0 era coroutines that were iterator/generator based as an example of async coding without special keywords. JS did not need those keywords to enable coroutines and async coding. People were already making their own promises, coroutines, etc. long before the new keywords were added.
  - schwartzworld 4y ago
    Async await has been supported by every browser that's not IE for like 6 years, and it's easily polyfillable if you need to support earlier.

Nullabillity 4y ago

No compatibility is broken, old scripts will keep on working just fine. Scripts written for the new syntax won't work in old browsers, but that's the nature of evolving standards anyway.

dmix 4y ago
> Scripts written for the new syntax won't work in old browsers, And critically browsers are - for the most part - much more in sync these days across the board. A lot of web devs got burned through the years of IE6-IE11 and have a natural distaste for browser level changes. Pipes have been (formally) debated for 5yrs now by the JS people, so they aren't exactly being non-conservative about this one.
- mmis1000 4y ago
  Unfortunately. If your web page need to deal with Chinese Android phones, you still need to deal with old browsers. Their android system somehow always shipped with broken auto-update of webview or chrome. Which results in people open your webpage with quite old browser version.

fnimick 4y ago

It lets a transpiler like Babel or Typescript use the new syntax and output the equivalent code that works on older browser. Same reason async/await was useful far before there was native browser support - you could immediately use it in your codebase and compile to a legacy browser target.

CyberDildonics 4y ago
If you're compiling to javascript anyway, why would you need a pipe operator in javascript instead of just nesting the function calls?
- hajile 4y ago
  Because x |> f |> g |> h is much easier to read than h(g(f(x))) for most people.
  - CyberDildonics 4y ago
    If you're compiling from another language you would be using whatever syntactic sugar you want, why break compatibility just to have the compiled javascript look a little better?
    - nosianu 4y ago
      > If you're compiling from another language TypeScript isn't another language though. It is the latest official ECMAScript plus type annotations. Only some very, very few, rare, old stuff like enums really is different code. 99% of TypeScript is just "remove the types to get ECMAScript". That TypeScript, the tool,also adds a transpiler is a distraction that made a lot of people believe TS is a different language. But the TS folks have always taken great pain to only ever support features that are or are about to be in the ECMAScript standard, and not to deviate from it. That they did initially with some namespace stuff and enums was before ES2015, when JS was lacking some things many people thought were essential. Even then they only added less than a handful of "TypeScript-code". When you look at the Babel "transpiler" for Typescript, before they added a bit more for class stuff, it pretty much showed that "transpilation" of TS to JS - as long as you targeted a recent ES version - was achieved by doing nothing more than to remove all those type annotations. I'm still mad at the TS guiys for muddying the waters so much by confusing soooo many people by bundling type checking and transpilation in one tool. This could have been much more clear. I too stuck to using Flow for quite some time until I realized TypeScript really is Javascript, while Flow communicated in its architecture and usage already that it just "added types" (literally).

binarymax 4y ago

Indeed. The argument of “nested calls are hard to read” is strange, because this looks terrible

usrusr 4y ago
Anything looks better than nested calls once you have started to get used to the benefits of reading left-to-right. It's one of those pains you don't realize you have unless it suddenly goes away.
- binarymax 4y ago
  Nested calls can be a code smell, sure. But easily fixable: one(two(three())); Becomes let a=three(); let b=two(a); one(b); Clean and easy, no sugar required.
  - usrusr 4y ago
    Lots of low-value names required. Those names will inevitably either be badly chosen or have taken far more time to make up than they are worth. That's assuming the code isn't written by that one guy on every team who stubbornly insists on var x = three(); x = two(x); one(x): (having the names certainly is nice to have in the debugger, but I'd rather have those intermediate results be an explicit debugger feature than junk taking up mental bandwidth all over the code, at all times)
    - binarymax 4y ago
      Good point and yours does look better :)
      - usrusr 4y ago
        The beauty of not using variables is that they don't pollute scope: a promise to the reader that it's perfectly fine to forget about that inermeditate result immediately after seeing it passed into the next step of the pipeline. Otherwise, you never know if it will perhaps show up later for some unexpected purpose. In a left-to-right language, those values that do get a name implicitly stand out

pavlov 4y ago

Every browser these days just means Chromium and WebKit, so all it takes is that Google and Apple need to agree. Firefox usage is down to a rounding error, and they happily implement whatever the commercial duo decides the web should have.

qbasic_forever 4y ago

Browsers have established they can roll out changes behind feature flags, and the community adapts and adopts them. This is a solved problem. ES6 transition, await/async, string templates, etc. were major JS changes that required browsers and runtimes to change. They did. It was fine. They can do it again!

CyberDildonics 4y ago
Promise added a very valuable new capability, but this would just mean what you write doesn't work on any non updated browser for a very minor syntax improvement. If there are too many nested calls, assign some of the function results to variables first.
- qbasic_forever 4y ago
  Async/await is pure syntactic sugar. Look at python 3.0 era coroutines that were iterator/generator based as an example of async coding without special keywords. JS did not need those keywords to enable coroutines and async coding. People were already making their own promises, coroutines, etc. long before the new keywords were added.
- schwartzworld 4y ago
  Async await has been supported by every browser that's not IE for like 6 years, and it's easily polyfillable if you need to support earlier.