| You raise fair points. >So, back to the same model as TypeScript. I beg to differ. There's a world of difference between: 1. a standardized feature with an official spec, which is subject to debate among the community, and of which it's viable to have multiple competing implementations; vs 2. a proprietary product that presents itself to be a superset of the core language (but isn't), is peddled by a single multinational, has a single implementation designed by an unaccountable elite in the employ of said multinational, which just so happens to be the original Dumbing Down The Computer Company >If ECMAScript had macros, page load times would skyrocket. >ECMAScript and/or browsers would have to define a way to distinguish JS-with-macros files and embedded scripts from plain old JS that doesn't require expansion. If you introduce them today by way of a polyfill, maybe. I'm not necessarily advocating for introducing native macros to ECMA-262 at the present juncture. But I can't help speculating what would've happened if they had caught on. If they were introduced at the point in history when people were first realizing transpilers were a thing; or designed into the language from the start; or a pre-existing metaprogramming-aware language was used in browsers, instead of Eich designing in 10 days an entire new language under the constraint that it also has to be an ad for Java - who knows where we would be as a civilization? What do you think? |