3 ms·

I honestly thought object/array spread/rest were already in ES2017. Maybe it's because I'm in my own little Babel/React world. I literally just had to stop and

I honestly thought object/array spread/rest were already in ES2017. Maybe it's because I'm in my own little Babel/React world. I literally just had to stop and go create-react-app and see if that specific use of rest/spread works and it does. Then I went to babel's docs and found it's part of TC-39. Maybe this is meta, but I wonder what it means for us in this ecosystem. Some of us have totally lost touch with whether the language features we use are supported by the runtime, or are even "canon". Right now I'm probably using a bunch of language features in different projects that are still proposals. I have a few handwoven .babelrc's in different projects that use all manner of things. I'm almost 40 now and looking back on my programming career, what we do with JS and language features is truly bizarre.

root_axis 9y ago
In other ecosystems you'd just use a language with features that you prefer, since you can't do that in a browser environment transpilers came along to fill the gap. It doesn't seem bizarre at all, it seems like a giant hack taken to the extreme, which is pretty common thing in the programming world.
shados 9y ago
Yeah, most people don't keep track of what features are "legitimate/standard" and which are not. It's even more problematic because some influential figures in the community push those non-standard features and encourage people to use them. Some are pretty harmless (object spread back when it wasn't standard), some are PROBABLY okay (class field declaration, pushed very hard in the React community because the ES6 class syntax with React kind of suck without it and they pushed THAT too early). Some, however, are downright dangerous, such as decorators (pushed pretty hard in the MobX world) or bind operator (used to be pushed in the RxJS community, though not as much lately with pipeable operators). Those things are not standard, and in the case of decorators, the version being pushed doesn't even match the latest proposal. These are the stuff of tech debt nightmare when used at scale. Yet most people using them have no idea what kind of hole they're digging themselves into, and it's hard to blame them. Can't really keep track of all of that when you have deadlines to meet.
sjellis 9y ago
"Right now I'm probably using a bunch of language features in different projects that are still proposals. I have a few handwoven .babelrc's in different projects that use all manner of things." This is one of the main reasons why I am increasingly interested in TypeScript: it gives you more features than JS, but in a way that is consistent and manageable between projects. It seems inevitable at this point that any large project is effectively going to be using a particular flavour of JS, with language or library extensions.
- WorldMaker 9y ago
  Typescript has been very good at sticking to Stage 3 proposals likely to be adopted by browsers, and providing "off ramps" if the specs change between Typescript implementation and browser adoption. (For instance, Typescript module syntax still recognizes a predecessor to ES Module import/export syntax, but it provides good warnings for the out-of-date syntax and between Typescript strict modes and tslint warnings as errors you can very quickly migrate a project over to the standard syntax.)

root_axis 9y ago

In other ecosystems you'd just use a language with features that you prefer, since you can't do that in a browser environment transpilers came along to fill the gap. It doesn't seem bizarre at all, it seems like a giant hack taken to the extreme, which is pretty common thing in the programming world.

shados 9y ago

Yeah, most people don't keep track of what features are "legitimate/standard" and which are not. It's even more problematic because some influential figures in the community push those non-standard features and encourage people to use them. Some are pretty harmless (object spread back when it wasn't standard), some are PROBABLY okay (class field declaration, pushed very hard in the React community because the ES6 class syntax with React kind of suck without it and they pushed THAT too early). Some, however, are downright dangerous, such as decorators (pushed pretty hard in the MobX world) or bind operator (used to be pushed in the RxJS community, though not as much lately with pipeable operators). Those things are not standard, and in the case of decorators, the version being pushed doesn't even match the latest proposal. These are the stuff of tech debt nightmare when used at scale. Yet most people using them have no idea what kind of hole they're digging themselves into, and it's hard to blame them. Can't really keep track of all of that when you have deadlines to meet.

sjellis 9y ago

"Right now I'm probably using a bunch of language features in different projects that are still proposals. I have a few handwoven .babelrc's in different projects that use all manner of things." This is one of the main reasons why I am increasingly interested in TypeScript: it gives you more features than JS, but in a way that is consistent and manageable between projects. It seems inevitable at this point that any large project is effectively going to be using a particular flavour of JS, with language or library extensions.

WorldMaker 9y ago
Typescript has been very good at sticking to Stage 3 proposals likely to be adopted by browsers, and providing "off ramps" if the specs change between Typescript implementation and browser adoption. (For instance, Typescript module syntax still recognizes a predecessor to ES Module import/export syntax, but it provides good warnings for the out-of-date syntax and between Typescript strict modes and tslint warnings as errors you can very quickly migrate a project over to the standard syntax.)