My take on ESM and the npm proposal isn't what you expect. [Thread]
-
Show this thread
-
The vast majority of developers don't have an opinion about the module syntax. They use whatever they use and are happy as long as it works.
1 reply 1 retweet 6 likesShow this thread -
In that context, breaks are unacceptable. But also, you have to reposition what the developer expectations are here, given that there aren't strong preferences and what they have is working just fine.
1 reply 0 retweets 2 likesShow this thread -
React people started using ESM cause React told them to. They expect this syntax, they don't expect the spec's semantics entirely because they are running through compilers anyway.
1 reply 0 retweets 4 likesShow this thread -
The problem is that this doesn't work in Node.js today, so Node.js is violating a growing expectation of the developer community.
1 reply 0 retweets 4 likesShow this thread -
However, nobody expects to use a new file extension, so the Node.js proposal is already out alignment with expectations. Being that these aren't strong preferences we should expect adoption to be minimal and existing workflows to continue.
1 reply 0 retweets 9 likesShow this thread -
The npm proposal turns ESM adoption into a breaking change, which is not what I or anyone would expect when adopting new syntax. Again, people don't really give a shit about module syntax, so why eat a breaking change?
3 replies 0 retweets 7 likesShow this thread -
Back to the Node.js proposal, it drops hooks which breaks code coverage, another expectation violated when adopting it.
3 replies 0 retweets 1 likeShow this thread -
In summary, both proposals are making compromises that violate the expectations of the average developer. For something that most developers don't have strong preferences for that isn't a good idea.
3 replies 0 retweets 4 likesShow this thread
Heh, agree pretty much with all this. Feel that nobody wants to make any breaking changes tho, but there's no other way to reconcile ESM with CJS. In that case choosing the path of least breakage would be desirable, right?
-
-
Replying to @yoshuawuyts
I'm still pissed we are in this situation because Node.js weren't in TC39 until after the spec was finalized, mostly because the project wasn't in a healthy enough place to participate until then.
1 reply 0 retweets 2 likes -
Replying to @mikeal @yoshuawuyts
They also rammed the spec to final noting implementations in Babel and compilers but no browsers or Node which makes me furious.
3 replies 0 retweets 6 likes - 1 more reply
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.