OK, as I see it the Securable Modules proposal has struck a very nice balance of providing namespaced modules with a reasonable syntax and even decent compatibility with the browser environment. It *is* different from what browser JS programmers are used to. But, many JS programmers who have worked on larger frontend systems have gotten used to working in namespaces of one kind or another.
Said Peter Higgins of Dojo on irc today: "i was reading over the sjs list couldn't help but feel like the module loader was just a scopeable version of dojo.require"
Tom Robinson has converted Jack to use an implementation, and the modules and requires statements look pretty clean to me:
At this point, I'm +1 on Securable Modules. I'd like to get a sense of where other people stand. To keep things neat, let's keep this thread to +1 / 0 / -1 and discuss any remaining issues with the proposal in separate threads. Restating objections in a separate thread is not a bad idea, given how much traffic has gone by and how the module proposal has changed over time.
Also, keep in mind everything does not need to be 100% perfect. What we want is a good starting point and direction forward, and to me this looks good.
Thanks to everyone involved for bringing modules to this point, because they do literally sit underneath everything else we'll be doing.
> OK, as I see it the Securable Modules proposal has struck a very nice > balance of providing namespaced modules with a reasonable syntax and > even decent compatibility with the browser environment. It *is* > different from what browser JS programmers are used to. But, many JS > programmers who have worked on larger frontend systems have gotten > used to working in namespaces of one kind or another.
> Said Peter Higgins of Dojo on irc today: "i was reading over the sjs > list couldn't help but feel like the module loader was just a > scopeable version of dojo.require"
> Tom Robinson has converted Jack to use an implementation, and the > modules and requires statements look pretty clean to me:
> At this point, I'm +1 on Securable Modules. I'd like to get a sense of > where other people stand. To keep things neat, let's keep this thread > to +1 / 0 / -1 and discuss any remaining issues with the proposal in > separate threads. Restating objections in a separate thread is not a > bad idea, given how much traffic has gone by and how the module > proposal has changed over time.
> Also, keep in mind everything does not need to be 100% perfect. What > we want is a good starting point and direction forward, and to me this > looks good.
> Thanks to everyone involved for bringing modules to this point, > because they do literally sit underneath everything else we'll be > doing.
> OK, as I see it the Securable Modules proposal has struck a very nice
> balance of providing namespaced modules with a reasonable syntax and
> even decent compatibility with the browser environment. It *is*
> different from what browser JS programmers are used to. But, many JS
> programmers who have worked on larger frontend systems have gotten
> used to working in namespaces of one kind or another.
> Said Peter Higgins of Dojo on irc today: "i was reading over the sjs
> list couldn't help but feel like the module loader was just a
> scopeable version of dojo.require"
> Tom Robinson has converted Jack to use an implementation, and the
> modules and requires statements look pretty clean to me:
> At this point, I'm +1 on Securable Modules. I'd like to get a sense of
> where other people stand. To keep things neat, let's keep this thread
> to +1 / 0 / -1 and discuss any remaining issues with the proposal in
> separate threads. Restating objections in a separate thread is not a
> bad idea, given how much traffic has gone by and how the module
> proposal has changed over time.
> Also, keep in mind everything does not need to be 100% perfect. What
> we want is a good starting point and direction forward, and to me this
> looks good.
> Thanks to everyone involved for bringing modules to this point,
> because they do literally sit underneath everything else we'll be
> doing.
> [...] keep in mind everything does not need to be 100% perfect. What > we want is a good starting point and direction forward, and to me this > looks good.
> OK, as I see it the Securable Modules proposal has struck a very nice
> balance of providing namespaced modules with a reasonable syntax and
> even decent compatibility with the browser environment. It *is*
> different from what browser JS programmers are used to. But, many JS
> programmers who have worked on larger frontend systems have gotten
> used to working in namespaces of one kind or another.
> Said Peter Higgins of Dojo on irc today: "i was reading over the sjs
> list couldn't help but feel like the module loader was just a
> scopeable version of dojo.require"
> Tom Robinson has converted Jack to use an implementation, and the
> modules and requires statements look pretty clean to me:
> At this point, I'm +1 on Securable Modules. I'd like to get a sense of
> where other people stand. To keep things neat, let's keep this thread
> to +1 / 0 / -1 and discuss any remaining issues with the proposal in
> separate threads. Restating objections in a separate thread is not a
> bad idea, given how much traffic has gone by and how the module
> proposal has changed over time.
> Also, keep in mind everything does not need to be 100% perfect. What
> we want is a good starting point and direction forward, and to me this
> looks good.
> Thanks to everyone involved for bringing modules to this point,
> because they do literally sit underneath everything else we'll be
> doing.
> At this point, I'm +1 on Securable Modules. I'd like to get a sense of > where other people stand. To keep things neat, let's keep this thread > to +1 / 0 / -1 and discuss any remaining issues with the proposal in > separate threads. Restating objections in a separate thread is not a > bad idea, given how much traffic has gone by and how the module > proposal has changed over time.
> On Feb 6, 2009, at 10:05 PM, Kevin Dangoor wrote:
>> At this point, I'm +1 on Securable Modules. I'd like to get a sense of
>> where other people stand. To keep things neat, let's keep this thread
>> to +1 / 0 / -1 and discuss any remaining issues with the proposal in
>> separate threads. Restating objections in a separate thread is not a
>> bad idea, given how much traffic has gone by and how the module
>> proposal has changed over time.
> OK, as I see it the Securable Modules proposal has struck a very nice
> balance of providing namespaced modules with a reasonable syntax and
> even decent compatibility with the browser environment. It *is*
> different from what browser JS programmers are used to. But, many JS
> programmers who have worked on larger frontend systems have gotten
> used to working in namespaces of one kind or another.
> Said Peter Higgins of Dojo on irc today: "i was reading over the sjs
> list couldn't help but feel like the module loader was just a
> scopeable version of dojo.require"
> Tom Robinson has converted Jack to use an implementation, and the
> modules and requires statements look pretty clean to me:
> At this point, I'm +1 on Securable Modules. I'd like to get a sense of
> where other people stand. To keep things neat, let's keep this thread
> to +1 / 0 / -1 and discuss any remaining issues with the proposal in
> separate threads. Restating objections in a separate thread is not a
> bad idea, given how much traffic has gone by and how the module
> proposal has changed over time.
> Also, keep in mind everything does not need to be 100% perfect. What
> we want is a good starting point and direction forward, and to me this
> looks good.
> Thanks to everyone involved for bringing modules to this point,
> because they do literally sit underneath everything else we'll be
> doing.
