Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of JavaScript

blog.chromium.org

Post reply on HN
Print view View original

111–115 of 115 posts

Re: The Future of JavaScript

#111

Post by substack »

samth wrote: post #110
samth wrote: post #92

Earlier quoted context omitted.

I'll try to separate out the different issues you're raising here, and respond to each individually. 1. What if I want to have my module be a function, the way that $ in jQuery is both a function and a namespace for the rest of the functionality? This is an important use case, and so we're going to support it in ES6 modules. You'll be able to say: module $ at "http://jquery.com/jquery.min.js"; $(...) $.ajax(...) 2. M…

Since it came up on twitter, here's how you'd implement the `$` module I describe above: export function ajax(...) { ... }; // NB: not how jQuery actually works ;) export this(query) { return document.find(query); }; The `export this` syntax specifies how the module instance object behaves when called as a function.

Thanks for this. I'm glad that using a single export function will at least be possible. I'm still pessimistic about the amount of syntax being introduced here.

In particular, I still really dislike the special import "local renaming" syntax since it seems so unnecessary compared to just having an import keyword that returns an object and letting the programmer extract and manipulate the relevant entries. You would still get the static analysis benefits of having static imports without all the awkward complexity of the current proposal. Wouldn't it just be the same thing to Object.freeze() the export object but without any syntax magic necessary?

Plus, overloading `module` to do loading AND defining with the `module Bar at "uri"` form seems really wrong. Why can't it JUST do defining and just let import do all the loading?

Re: The Future of JavaScript

#112

Post by samth »

substack wrote: post #111
samth wrote: post #110

Earlier quoted context omitted.

Since it came up on twitter, here's how you'd implement the `$` module I describe above: export function ajax(...) { ... }; // NB: not how jQuery actually works ;) export this(query) { return document.find(query); }; The `export this` syntax specifies how the module instance object behaves when called as a function.

Thanks for this. I'm glad that using a single export function will at least be possible. I'm still pessimistic about the amount of syntax being introduced here. In particular, I still really dislike the special import "local renaming" syntax since it seems so unnecessary compared to just having an import keyword that returns an object and letting the programmer extract and manipulate the relevant entries. You would s…

First, if you want to just use objects-as-prefixes, the way require(...) works in node today, that's easy to do:

    module m at "blah.com";
    ... references to m go here ...
We also want to support other use cases, like binding the exports to names available in your local scope. We understand that not everyone likes that style, but I don't think the language should mandate a particular side in that fight.

Second, the `module m at "URL"` form above is a definition of `m`. It's just that you're allowed to refer to that binding as an object too. Would you rather have:

    module m at "example.com";
    import m;
That just seems like unnecessary typing to me.

Re: The Future of JavaScript

#113

Post by substack »

samth wrote: post #112
substack wrote: post #111

Earlier quoted context omitted.

Thanks for this. I'm glad that using a single export function will at least be possible. I'm still pessimistic about the amount of syntax being introduced here. In particular, I still really dislike the special import "local renaming" syntax since it seems so unnecessary compared to just having an import keyword that returns an object and letting the programmer extract and manipulate the relevant entries. You would s…

First, if you want to just use objects-as-prefixes, the way require(...) works in node today, that's easy to do: module m at "blah.com"; ... references to m go here ... We also want to support other use cases, like binding the exports to names available in your local scope. We understand that not everyone likes that style, but I don't think the language should mandate a particular side in that fight. Second, the `mod…

I mean why does `module` pull down resources? Shouldn't that be import's job?

Re: The Future of JavaScript

#114

Post by samth »

substack wrote: post #113
samth wrote: post #112

Earlier quoted context omitted.

First, if you want to just use objects-as-prefixes, the way require(...) works in node today, that's easy to do: module m at "blah.com"; ... references to m go here ... We also want to support other use cases, like binding the exports to names available in your local scope. We understand that not everyone likes that style, but I don't think the language should mandate a particular side in that fight. Second, the `mod…

I mean why does `module` pull down resources? Shouldn't that be import's job?

There are two reasons:

1. `module` is about defining the modules that you're using in your program, some of which might be remote resources. `import` is about bringing names into scope.

2. Using `module` this way lets you, the client, decide on names for modules, which means we don't have to rely on module authors to come up with and use naming conventions (net.substack.airport, anyone?).

This feeds back into 1, where we use bindings to reference modules, even remote ones.

Also, if a module is never referenced or imported, then the resources shouldn't need to be pulled down at all. So partly it depends on the way you look at things.

Re: The Future of JavaScript

#115

Post by RobertWHurst »

ootachi wrote: post #76
substack wrote: post #61

I really dislike what they're doing with modules because it's such a step back from the commonjs-inspired require() that node uses. In node, require() just returns a value. That value is usually an object but often it's just a function. Why should a module that encapsulates exactly one function return anything else but that one function? In ES.next, you've got to use pythonesque `import y from Bar` statements which i…

You haven't considered optimization -- with closed modules, the compiler can statically know, for instance, that "Math.sin" is actually the sine function and can compile that straight down to the hardware instruction. No speculation or guards are necessary. Additionally, your static analysis must be unsound if modules are mutable. The problem is not figuring out which module is being imported, it's figuring out wheth…

I don't think you get it. The right way to require a module in commonjs is var baz = require('baz'). The reason its better is because I can accomplish just as much as the ridiculous ES6 modules and its simple. We don't need to add complexity if it doesn't get us anywhere. I'm not convinced that static analysis is worth it. Existing module systems work just fine without this shit.
Post reply on HN