Damn, premature send >_>, anyways:


The best thing about Node was always the promise of code sharing, and that 
definitely possible. The only problem here is that people think that you 
need to rewrite your code to node's module pattern in order for it to work 
in Node.js. This is definitely not the case. Node comes with a great file 
reading interface and ships a `vm` module that you can use to evaluate 
code. Armed with this knowledge you can leverage a "module system" that 
we've been working with for ages as front-end developers and that is 
globals. And there's nothing wrong with that.


I've always been annoyed by the fact that code that needed to be shared 
between environments needed to have this awful module bloat in order for it 
to work. You got node's module system, amd, ES6 imports and next week 
there's another hipster module system that you need to support. And for 
this reason i've written load:


https://github.com/3rd-Eden/load


Which basically reads your JavaScript file, loads it in the JavaScript 
virtual machine, read's out the exposed / added globals and exposes them. 
That it. No build system needed to make your code work. Just plain o'l 
JavaScript.

Op maandag 22 juli 2013 21:56:54 UTC+2 schreef 3rdEden het volgende:
>
> The best thing
>
> On Sunday, July 14, 2013 at 8:09 AM, Ryan Schmidt wrote:
>
> Years before I knew about node, I wrote two client-side JavaScript 
> libraries, one of which uses the other, each providing about half a dozen 
> classes. Now I would like to modernize these libraries to make them most 
> accessible to today's web developers.
>
> What is the best way to write my modules so they can be included in any 
> client-side or server-side JavaScript environment?
>
> I would like to publish them to npm. To that end, I've started switching 
> them to node-style require() and module.exports, but of course I can't use 
> those files in the browser ("module is not defined") without a build step 
> such as browserify, or adding boilerplate to each file, and I don't want to 
> bloat my library too much.
>
> I don't want to mandate that my users use an AMD loader, or a CommonJS 
> loader, or RequireJS or curl.js or anything else; I want my libraries to be 
> compatible with any script loading method of the user's choosing.
>
> Avoiding the build step during development would be nice too. I'd like to 
> be able to just include the dozen class files in script tags and use them.
>
> -- 
> -- 
> Job Board: http://jobs.nodejs.org/
> Posting guidelines: 
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> --- 
> You received this message because you are subscribed to the Google Groups 
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected].
> For more options, visit https://groups.google.com/groups/opt_out.
>
>  
>  

-- 
-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

--- 
You received this message because you are subscribed to the Google Groups 
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to