Inline. On Saturday, July 22, 2017 7:47:32 AM CEST Bob Myers wrote: > Let me weigh in as an Angular programmer. > > Angular does not "encourage use of non-standard and/or unstable language > features". It encourages (indeed for all practical purposes mandates) the > use of TypeScript, which like it or not is a perfectly well-defined > language. > > The TypeScript designers walk a fine line between providing features that > the user base needs and wants, and getting too far out on the cutting edge. > IMHO, they have done a very good job threading this needle. They > religiously avoid adding features which are unstable or perceived as likely > to change. The TS discussion list is replete with requests for adding this > that or the other stage-0 feature, but such requests are invariably > rejected.
With regard to non-standard and/or unstable features: Examples for cases where TypeScript has actively harmed the ECMAScript ecosystem would be every instance where it was decided to mess with reserved words. `enum` and `interface` would be just two such examples. In fact, this has recently come up in the ecmascript-interfaces-proposal [1], which led to the (IMHO absurd) idea of introducing `interface` under the keyword `protocol`, just so that ECMAScript and TypeScript play nice together. Compatibility is nice, but ECMAScript can not be holding the bag for every "compiles to ES" type of language out there, especially if those languages decide to gamble with syntax and semantics when it comes to reserved words. That's really their own fault. CoffeeScript didn't make the mistake of claiming to be a superset of ECMAScript at any time. TypeScript did. Consequently, there must either incompatibilities between the two languages, or TypeScript will have to be versioned and made backwards-incompatible to follow ECMAScript. Both of which is equally horrendous and far from what I would still call "perfectly well- defined". [1] https://github.com/michaelficarra/ecmascript-interfaces-proposal/issues/3 > > I unfortunately sometimes get the impressions that the TC39 school views > the TypeScript guys as the crazy uncle beating off over in the corner, > while they define the "real" language at their own pace. Meanwhile, > thousands of applications involving millions of lines of code are being > developed in TS at high productivity levels, thanks not only to the > language features but the extraordinarily good tooling and ecosystem. It > would be a huge mistake to think that TypeScript is merely the CoffeeScript > of our time. > > With regard to the questionable comments in the post to which Isiah was > responding, no, platform and toolchain decisions are not made by ignorant, > copy-cat Asians. Nor are they usually made by non-technical PMs or other > people in suits, other than in the form of approving recommendations made > by forward-looking engineering management at the software or product > company which is outsourcing its development. If you are losing mind-share > with those folks, it's not their problem, it's your problem. Our > engineering managers have been through countless iterations of the platform > wars over the years, and usually have a finely honed sense of risk/benefit. > The risk/benefit equation for TypeScript is overwhelmingly positive. > > My two cents. > > Bob > > On Sat, Jul 22, 2017 at 4:31 AM, Isiah Meadows <isiahmead...@gmail.com> > > wrote: > > Most of these flashy frameworks (e.g. Angular, React, and Aurelia) > > encourage use of non-standard and/or unstable language features, even > > though they shouldn't, and it's a horrible idea to even recommend > > anything not at least stage 3 for general framework usage. (Note: I'm > > an active core developer for Mithril, a front-end framework whose > > community generally rejects the idea of embracing the latest and > > greatest without good pragmatic reason.) Decorators are stage 2, and > > the runtime API is still very much under flux. JSX is non-standard and > > Facebook has stated they don't intend on promoting it to become > > standard in any way. > > > > Conversely, a large number of TC39 people have to deal with large > > legacy projects and older browsers, and most of them work in large > > companies with very large, brittle code bases where introducing a new > > tool is often extremely costly, no matter what it is. Babel isn't an > > option for many of them, and even Rollup (ES modules) and Bublé > > (majority of useful ES6 language features) are difficult to introduce. > > > > To draw a comparison, consider the structure of ESLint (100k+ lines of > > pure, unprocessed ES6 minus modules) vs Babel (100k+ lines of Flow + > > JS with numerous transforms applied) and Angular (100k+ lines of > > TypeScript with some unstable features enabled). One is built from > > pure JS and has had no issues with language stability, the second with > > several non-standard additions and has had multiple wide-reaching > > refactorizations, and the third using decorators in both its API and > > implementation, whose spec's API went into significant flux around the > > time it was ready to go stable. (And BTW, Babel itself pulled > > decorator support because of the feature's instability.)
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
