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. 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 <[email protected]> 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.) >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
