4 ms·

You mean like how it breaks ES6 classes semantics by making members enumberables? Whoops (I know, if you look at my comment history I used that example all the

by shados 10y ago

You mean like how it breaks ES6 classes semantics by making members enumberables? Whoops (I know, if you look at my comment history I used that example all the time...but it's just such an easy one). When comes the time to pick between shinier output and correctness, TypeScript is perfectly happy to diverge from JavaScript, until it really has no choice (eg: when it moved to ES6 modules)

smt88 10y ago
Can you provide a link or a non-foobar code example? I tried to Google it, but Google is terrible. Edit: This is seriously driving me nuts that I can't find anything about it. I hope you see this and respond because I'm incredibly curious!
- shados 10y ago
  Just try it. Look at what is the output for the following code: class Cat { talk() { console.log('meow'); } } It's something along the lines of: var Cat = (function () { function Cat() { } Cat.prototype.talk = function () { console.log('meow'); }; return Cat; }()); The methods in that output will be enumerable. They shouldn't be. The reason is (most likely) that the output for non-enumerable class members is TERRIBLE (try the same thing on babel's "Try it out" page), thus why Babel provides loose mode. Still, it's the kind of very subtle things that can bite you in the rear big time. Then again, if you have good unit tests and move those over too, it won't be a problem I guess :) Also most likely not a problem if you use ES6 as the compile target.
  - smt88 10y ago
    Wait... are you saying that TypeScript's ES5 output doesn't conform to the ES6 standard??? Why would that matter? There's no standard for it! I thought you were saying that TS -> ES6 was not valid ES6. Also, properties set on the prototype will fail propertyIsEnumerable() and also hasOwnProperty(). for..in loops should always be filtered by hasOwnProperty() in any sane code base anyway. (I tested the TS output for that class in Node 5 and my own browser, and the property did not come up in the loop, so I just don't think this is an issue in reality.)
    - shados 10y ago
      The difference is actually somewhat subtle, but is shown here under class/enumerable. Same deal about classes requiring new (a lot of libs actually have bugs for only testing against compiled classes with older Babel and using .apply on classes): https://kangax.github.io/compat-table/es6/ https://kangax.github.io/compat-table/es6/ And all I was saying is that the spouting of "TS is a superset of ES6!" is not that simple, since most usage will be (for now) with the ES5 output, where it isn't compliant in subtle ways that do cause problems/bugs. Nothing more :) Obviously there's even cases here TS is compliant and Babel is not. Babel will call those bugs instead of spouting their compiler has no compromises like a lot of the comments here try to imply to convince people.

by shados 10y ago

smt88 10y ago

Can you provide a link or a non-foobar code example? I tried to Google it, but Google is terrible. Edit: This is seriously driving me nuts that I can't find anything about it. I hope you see this and respond because I'm incredibly curious!

shados 10y ago
Just try it. Look at what is the output for the following code: class Cat { talk() { console.log('meow'); } } It's something along the lines of: var Cat = (function () { function Cat() { } Cat.prototype.talk = function () { console.log('meow'); }; return Cat; }()); The methods in that output will be enumerable. They shouldn't be. The reason is (most likely) that the output for non-enumerable class members is TERRIBLE (try the same thing on babel's "Try it out" page), thus why Babel provides loose mode. Still, it's the kind of very subtle things that can bite you in the rear big time. Then again, if you have good unit tests and move those over too, it won't be a problem I guess :) Also most likely not a problem if you use ES6 as the compile target.
- smt88 10y ago
  Wait... are you saying that TypeScript's ES5 output doesn't conform to the ES6 standard??? Why would that matter? There's no standard for it! I thought you were saying that TS -> ES6 was not valid ES6. Also, properties set on the prototype will fail propertyIsEnumerable() and also hasOwnProperty(). for..in loops should always be filtered by hasOwnProperty() in any sane code base anyway. (I tested the TS output for that class in Node 5 and my own browser, and the property did not come up in the loop, so I just don't think this is an issue in reality.)
  - shados 10y ago
    The difference is actually somewhat subtle, but is shown here under class/enumerable. Same deal about classes requiring new (a lot of libs actually have bugs for only testing against compiled classes with older Babel and using .apply on classes): https://kangax.github.io/compat-table/es6/ https://kangax.github.io/compat-table/es6/ And all I was saying is that the spouting of "TS is a superset of ES6!" is not that simple, since most usage will be (for now) with the ES5 output, where it isn't compliant in subtle ways that do cause problems/bugs. Nothing more :) Obviously there's even cases here TS is compliant and Babel is not. Babel will call those bugs instead of spouting their compiler has no compromises like a lot of the comments here try to imply to convince people.