import.meta and TC39 process as a whole

[Isiah Meadows]

Inline

On Fri, Aug 4, 2017, 02:47 kai zhu <kaizhu256 at gmail.com> wrote:

>
> > I’m curious what the concerns were. You mentioned disliking the syntax,
> but I’m guessing there’s more to it than that?
>
> the concern is that es modules are starting to look like a solution in
> search of a problem.  its redundant and unnecessary on the server-side.
> and it continues to fail to solve an relevant pain-point for everyday
> programmers on the frontend-side now, or in the foreseeable future, while
> creating new ones.
>

First, it would be very nice on the server side and in CLI applications to
have a more efficient module system to implement, especially for larger
applications and in desktop applications being built with Electron and
NW.js, where startup time actually matters, and engines are presented with
the opportunity to garbage collect unused parts of modules.

Second, it pays off in spades on client side, due to much smaller bundles.
We already have features primarily targeting browsers (shared array buffers
and atomics - Node doesn't have threading support), so there's precedent,
and I feel even if it has no value anywhere else, the need in the client
side is more than enough. Oh, and having a module implementation built-in
alleviates the need for a separate script loader, and it makes prototyping
easier.

So there are pain points that having a good native module and script loader
would solve very well.


> > I’ve been experimenting with ES Modules over HTTP 2 for a few months. I
> used rollup to create my dep graph without actually bundling, then served
> requested modules as entry points with a server push for their deps. I
> imagine that it won’t be long brolefore generic tooling for this sort of
> approach emerges (my own solution is pretty hacky, just wanted to see how
> it might work).
>
> for most projects, dep-graph and tree-shaking have marginal benefits in
> frontend programming, given their complexity.  for all that extra work and
> boilerplate, the result is typically not anymore smaller, more efficient,
> or more maintainable than a pre-es6 rollup file.
>

Just because a feature exists doesn't mean you have to use it. I almost
never use proxies or shared memory/atomics, because I don't need them. I
also rarely use classes. You aren't obligated to use a feature you don't
like - there's a *lot* of people who avoid classes like the plague.


> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20170804/184eb8d7/attachment.html>