New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature: Browser equivalence #133

Closed
GeoffreyBooth opened this Issue Jun 18, 2018 · 4 comments

Comments

Projects
None yet
3 participants
@GeoffreyBooth
Copy link
Contributor

GeoffreyBooth commented Jun 18, 2018

Whenever Node.js is doing something with modules that browsers also do, Node.js and browsers do it the same way.

Use case 60.

@SMotaal

This comment has been minimized.

Copy link
Contributor

SMotaal commented Jun 20, 2018

I guess I did not see this when I opened #136 but this is exactly what I was exploring over the past several months, and very extensively most recently.

So the short of #136 is that should the current state of experimental modules not address "bare" specifiers, foremost, not to diminish from the importance of other interop aspects, releasing will most likely see people struggling to create ECMAScript modules that can be imported (ie does not throw uncatchable errors) across both paradigms. Emphasis is node's compatibility with browser norms, at least from developer's perspective due to untameable browser-restrictions compared to the greater reach and tooling possible in node. We have the honour and burden of provide a good narrative to this 😁.

@guybedford

This comment has been minimized.

Copy link
Contributor

guybedford commented Jul 18, 2018

I'd like to mark this as a duplicate of #107. I think it's clear that like Node we will follow the browser where necessary, and I think this is a fundamental requirement for #107 anyway.

@guybedford

This comment has been minimized.

Copy link
Contributor

guybedford commented Jul 18, 2018

Otherwise we could do this the other way around, and add to this feature "including the ability to have code that runs in both environments without a build".

@GeoffreyBooth

This comment has been minimized.

Copy link
Contributor

GeoffreyBooth commented Jul 18, 2018

This is broader than #107, so that would be included in this one. But this feature is basically a meta-feature like spec compliance, that's so broad it could encompass almost anything. I think we should keep them both open, as the specific ask in #107 would get lost in here; but we need to keep this as a top priority feature in its own right.

Edit: not open in the sense of GitHub issues, but rather both on the list of features.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment