Saying ESM and CJS differ in ways that are problematic
1: It's too bad Node doesn't operate in a consensus-seeking fashion (or limits the seeking to elected reps?) because I still think
-
-
I cant vote but CTC does seek quorum
-
Browser rollout certainly affected things, so did handoff without impl of standard
-
There is still a great deal of community concern about mjs. But it's screaming into the void because "The CTC Decides"
-
Thats generally how most standards have worked from my perspective
-
The process of developing ESM involved a huge amount of discussion with node folks leading tohttp://blog.izs.me/post/25906678790/on-es-6-modules …
-
But not about impl and rollout
End of conversation
New conversation -
-
-
2: there's a way to satisfy everyone's constraints. But all I hear is that the proposal I lobbed over the wall has been rejected.
-
3/3: As you know, many of us concerned about .mjs are open to conversation and compromise. But we're not in the room.
-
As stated before CTC meeting are open, even if you dont vote (like me)
-
My fear is .mjs leads to another fork. I don't think the alternative 'in defense of js' does. Maybe community vote is the answer here.
-
I think informing the community goes pretty well. No one likes the conclusion, but it makes sense. Have to avoid knee jerk votes.
-
.mjs doesn't mean "use module" or a package.json approach can't be added after. Core just doesn't plan for many ways to do things first iter
-
Each way you add to do it adds overall burden and division
End of conversation
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.