-
Notifications
You must be signed in to change notification settings - Fork 42
Encouraging users to use experimental features to reach better outcomes #122
Comments
While it’s certainly great to get feedback, I think it is very dangerous to actively encourage people to use experimental features. Anyone who needs encouragement to use an experimental feature is very likely to not understand the inherent dangers of doing so. |
I guess encouraging does imply making it too easy. How about making it at least possible instead… Personal Account: Since I used to author everything in With With that same notion where I want to be experimenting on the thing itself and not a piped approximation of it, I have spent almost a year waiting for upstream changes to the tooling I am used to. Since I was observing very closely, I appreciated more than everyone the amount of work involved in adding support for ES modules. I also realized that the idea of This left us with the following:
Did I not do the effort? Let's just say that the PR's are there but the amount of work it takes to patch a stale PR with new releases that continue to add essential tooling features like So I cannot really provide the community with much about experimental modules aside from the fact that I believe that they are not ready for use case feedback from the community, unless they are ready to reset how they go about everything else. Hope this alternative perspective can highlight the deeper aspects of the issue, not the polarizing headline. |
no matter what extension we end up using (and please get comfortable with the idea of mjs, its already been drafted to ietf) people are going to have to make changes.
maybe i'm misunderstanding you but we already have |
I see no problem with the implication that it’s currently very difficult to get useful experience with the experimental feature - this is largely because after 3-4 years of working on it, we decided to start the information gathering process from scratch with this working group. I don’t think we need implementation experience right now - what we need to focus on is agreeing on the use cases we will support/prioritize, and the features those necessitate, and then we can talk about what implementations would provide them, and then build one - and then we can worry about seeking feedback. |
What editor? Sounds like something the editor should fix - should be simple enough to PR in :)
Well, "real" ESM modules aren't ready yet - that's the sad truth. People are working on fixing that (you included!) but the fact some stuff is missing is a fact and we need to fix that before modules are "ready" for prime time. I don't want to encourage users to use it for stuff other than experimentation until then and existing tools like
Definitely helpful 👍 |
@SMotaal Thanks for your personal anecdote. I think it’s very useful for stories like yours to be part of the conversation, to keep the user experience front and center. In #42 I argued that Node should remove its current In particular, I would be very surprised if |
The reaction isn't really relevant; there's use cases that necessitate "a file extension", and there's just no way we'll ever obtain consensus on any solution that doesn't include that. Both of those examples achieve "not needing .mjs" by disregarding/marginalizing/ignoring critical use cases of some of the members of this working group. |
I really want to avoid making this another My initial thought behind this thread was to let everyone express how much Opting to support or hold back is a call that each tool makes independently, but for users it only takes one tool holding back to either make it not possible to experiment or to have to do so by dropping that tool altogether and maybe not just for experimentation when predictability is questioned. |
If I read the responses I get across issues and feature requests over at TypeScript, I can clearly see that there is a very strong force within the team to keep the syntax (aside from obvious type aspects) on par with ES, refusing adding new features or upgrading old features that are not compliant. Although I was once all the way into TypeScript sugaring, like many, with the promotion of all the new ES features by the community, we have reached a point where at least for me, I just need to strip out type annotations (and maybe just affix the paths). Some of us are now experimenting with fast type-stripping without any deeply rooted overhead of a type checking engine at runtime (but the flux is making efforts very challenging). If I were to venture a guess and hopefully I get corrected if I am wrong, TypeScript is now positioned well as a core development experience enhancing tool for pure JavaScript separate from mixed and pure TypeScript projects. At the very least, Those are the kind of things that require consideration in a package-centric module system, and experimented on by those who are in a position to do so. |
@GeoffreyBooth about locking out experimental features, can you elaborate on your view a little bit? I realize experimental kinda of throws curveballs all over the place and wonder if you have an alternative take on how to find and refine all the edge cases? |
I'm a huge -1 on removing the implementation we currently have and I highly
doubt the technical project would support a move like that
While individuals may not be satisfied with some of the UX, large portions
of the implementation have nothing to do with file extensions.
This thread feels like it is veering in a very unproductive direction. I'd
like to advise scoping it to a desired outcome or closing it.
…On Tue, Jun 12, 2018, 7:35 AM Saleh Abdel Motaal ***@***.***> wrote:
@GeoffreyBooth <https:/GeoffreyBooth> about locking out
experimental features, can you elaborate on your view a little bit? I
realize experimental kinda of throws curveballs all over the place and
wonder if you have an alternative take on how to find and refine all the
edge cases?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#122 (comment)>, or mute
the thread
<https:/notifications/unsubscribe-auth/AAecVya1bwAlsC4Q2Dn0fyGYPCwgMAH4ks5t76dzgaJpZM4UXMWD>
.
|
I am for closing... I was hoping a far more constructive path, but I guess everyone reads a little less of what the other may be implying so trying to elaborate seems to create more miscommunication instead, not productive is the most suitable conclusion 👍 |
I’m not sure why @SMotaal and @MylesBorins are calling this discussion unproductive, but I assume it’s because I brought up @MylesBorins makes a good point that there’s lots of non-user-facing parts of People will start using features that are released, even if they’re flagged, and I don’t see the benefit of the community experimenting with an API that seems likely to change, perhaps significantly. Or put another way, there’s no point in including |
@GeoffreyBooth seeing people use the current implementation has been (at least for me) quite useful. people aren't using it for their server deploys, they're messing with it on weekends for fun. i see at least three or four people messing with it every week and talking to them about their expectations, what worked, what didn't, etc has been fantastic. i think if we were able to connect to that and continue evolving the current design asynchronously from this group, we might really be able to connect the user story and the implementation soundly when the time comes. |
Both
--experimental-modules
and--experimental-vm-modules
have proven invaluable not only to Node's own implementation efforts, but to the community at large. The real benefits however can be limited if the typical day-to-day developer tooling has to be omitted when experimenting due to incompatibilities that may be remedied under similar experimental flags.I think it is important for any project to have a clear direction when it comes to releasing experimental support, more specifically when it comes to tooling and interoperability.
The text was updated successfully, but these errors were encountered: