As I understand it, webmake is the same thing as requirejs+optimizer: the
only difference is webmake uses sync require syntax and requirejs+optimizer
uses async syntax. In the end you have all 100+ files loading as a single
file.
Opposed to this, consider just using requirejs without its optimizer: Then
you have 100+ files loading whenever they're needed sometimes with 10-20
requests at once perhaps which is also not optimal.
A third existing option is to use requirejs and selectively optimize,
according to your knowledge of how the program works into different
"super-modules" each containing a bunch of your actual modules. The problem
with this is that it is work, and given reused modules in different areas
of an app which might be loaded at different times, you'd end up getting
the same code in more than one super-module.
My module loader (and streamline-require) is a blend of the first two
approaches to get an automatically optimized version of the third. As
you're developing, you just sync or async require exactly as it makes sense
for your program. You deploy, and bundling, cacheing are all optimized
automatically.
On Tuesday, March 27, 2012 4:22:26 PM UTC-7, deitch wrote:
>
> Actually, modules-webmake looks pretty cool. I am still trying to wrap my
> head around it, and how it is different than labjs or any of the other
> loaders, or browserify or other converters.
>
> So, I would write code in the CommonJS style, but have it available to the
> browser? I still need to write for the browser (jQuery, DOM, non-V8
> limitations, etc.), but rather than *assuming* I have stuff in, say,
> APP.utils.foo, I could just do
>
> var foo = require('./util/foo');
>
> and this would do the right thing, and render it up for the browser to
> use?
>
> I could see how the programmatic might be useful. I add a line:
>
> <script src="/myassets.js"></script>
>
> then have expressjs intercept it, run Webmake, then minify and gzip the
> source. To prevent redoing, it could cache the result in memory or even on
> disk. If it exists, serve it out; if not, Webmake+minify+gzip and serve it
> out.
>
> Q: does this have any impact on browser render times? This takes all 100+
> files and makes them a single file, as opposed to loading multiple in
> parallel.
>
> Cool.
>
>
> On Tuesday, March 27, 2012 10:34:34 AM UTC+2, Mariusz Nowak wrote:
>>
>> Guys, check https://github.com/medikoo/find-requires
>>
>> --
>> Mariusz Nowak
>> https://github.com/medikoo
>> http://twitter.com/medikoo
>>
>> On Tuesday, March 27, 2012 10:26:32 AM UTC+2, Bruno Jouhier wrote:
>>>
>>> Same way you do it: regexp
>>>
>>> On Monday, March 26, 2012 9:49:28 PM UTC+2, meelash wrote:
>>>>
>>>> btw, bruno, how do you do the dependency analysis? A full parser?
>>>>
>>>> On Monday, March 26, 2012 12:01:41 AM UTC-7, Bruno Jouhier wrote:
>>>>>
>>>>> I have a similar thing. Not fully packaged but I published it a while
>>>>> ago: https://github.com/Sage/streamline-require
>>>>>
>>>>> It analyzes the dependencies server side and supports both synchronous
>>>>> and asynchonous requires. Like yours, it returns the entire dependency
>>>>> graph in one shot. So the client gets everything it needs in one
>>>>> roundtrip.
>>>>> It also monitors changes to the source tree and returns a 304 if the
>>>>> browser has an up-to-date version.
>>>>>
>>>>> There is one further refinement: when you request additional module
>>>>> asynchronously, the client sends to the server the list of modules that
>>>>> it
>>>>> had requested before and the server computed the list of dependencies of
>>>>> the new modules as well as the list of dependencies of the modules that
>>>>> had
>>>>> been requested before and it sends back to the client a single response
>>>>> with the modules of the first list that are not in the second list. So,
>>>>> if
>>>>> the client had gotten A, B, C, D, E, F in a first require and requests G
>>>>> which requires B, C, and H, the server only returns G and H to the
>>>>> client.
>>>>> I the client then requests I which requires C, F and H and J, the server
>>>>> returns only I and J.
>>>>>
>>>>> Overall, this is extremely fast.
>>>>>
>>>>> I was doing the dependency analysis client side before and loading the
>>>>> modules one by one. Terrible in comparison.
>>>>>
>>>>> Bruno
>>>>>
>>>>> On Sunday, March 25, 2012 1:04:52 AM UTC+1, meelash wrote:
>>>>>>
>>>>>> tl;dr - Client-side require with a server-side component that caches
>>>>>> dependencies, bundles them, and caches the bundles. Need feedback on
>>>>>> the concept, syntax. Need suggestions/contributions on
>>>>>> implementation.
>>>>>> Although, this works for me, it is almost just a proof-of-concept,
>>>>>> needs work.
>>>>>>
>>>>>>
>>>>>> As part of a project I'm working on, I spent a few hours writing a
>>>>>> little client-side module loader with a server-side component
>>>>>> enabling
>>>>>> what I think is a pretty neat meaning to CommonJS module syntax. This
>>>>>> morning I pulled it out of the rest of my project and attempted to
>>>>>> package it in a useful way for others to use.
>>>>>>
>>>>>> The basic idea is this- in your client-side code, you can use require
>>>>>> in either a "synchronous" or asynchronous fashion-
>>>>>> module1 = require('some/path.js');
>>>>>> require('some/other/path.js', function(err,result){module2 =
>>>>>> result;});
>>>>>>
>>>>>> An asynchronous require makes a call to the server component to get
>>>>>> the file in question, but before returning the file, the server
>>>>>> parses
>>>>>> it, finds all the synchronous require calls, loads those files as
>>>>>> well
>>>>>> and returning the whole thing as a package. That way, when the
>>>>>> original file that was asynchronously loaded is executed and comes to
>>>>>> one of those synchronous require calls, that file is already there,
>>>>>> and the require is actually synchronous.
>>>>>>
>>>>>> At this point, maybe this screencast demo will help to clarify how it
>>>>>> works:
>>>>>> http://screencast.com/t/nOU53BRYUAX<http://screencast.com/t/nOU53BRYUAX>
>>>>>>
>>>>>>
>>>>>> Put another way:
>>>>>> If I async require fileA, and fileA has synchronous dependencies on
>>>>>> fileB, and fileC, and an asynchronous dependency on fileD, the
>>>>>> server-
>>>>>> side component will return (in a single "bundle") and keep in memory
>>>>>> fileA, fileB, and fileC, not fileD, and it will execute fileA.
>>>>>> The client-side also separates fetching the files and eval'ing them
>>>>>> (the method of getting files is xhr+eval). So, let's say fileA has
>>>>>> require('fileB'); that executes when the file is parsed and executed
>>>>>> on the client, but require('fileC') is inside a function somewhere.
>>>>>> Then fileA will first be eval'ed, then fileB when it comes across
>>>>>> that, and the text of fileC will just be in memory, not eval'ed until
>>>>>> that function is called or some other require to it is called by any
>>>>>> other part of the program.
>>>>>>
>>>>>> Another example-
>>>>>> fileA has dependencies fileB, fileC, fileD, fileE, fileF
>>>>>> fileG has dependencies fileC, fileE, fileH
>>>>>>
>>>>>> When I call require('fileA', function(err,result){return 'yay';});,
>>>>>> the module loader will load fileA, fileB, fileC, fileD, fileE, and
>>>>>> fileF all in a single bundle.
>>>>>> If I, after that, call require('fileG', function(err,result){return
>>>>>> 'yay';});, the module loader will only load fileG and fileH!
>>>>>>
>>>>>> Hopefully, that's clear....
>>>>>>
>>>>>> The advantages-
>>>>>> Being aware of the difference in synchronous and asynchronous require
>>>>>> in your client-side code make it extremely natural to break all your
>>>>>> client-side code into small reusable chunks- there is no penalty and
>>>>>> you don't have to "optimize" later by deciding what to package
>>>>>> together and what to package separately.
>>>>>> Handling dependencies becomes nothing. You don't have to think about
>>>>>> it.
>>>>>> The server can have a "deployment" mode, where it caches what the
>>>>>> dependencies of a file are and doesn't ever need to parse that file
>>>>>> again.
>>>>>> In "deployment" mode, the server can also cache bundles of multiple
>>>>>> files that are requested together, so when another client requests
>>>>>> that same bundle, it is already in memory.
>>>>>>
>>>>>> To sum up:
>>>>>> xhr+eval-when-necessary client-side module loader
>>>>>> both synchronous-ish and asynchronous require in your client
>>>>>> side-code
>>>>>> --the synchronous require is actually a command to the server-side
>>>>>> component to bundle
>>>>>> server-side component
>>>>>> --parses for dependencies and bundles them together
>>>>>> --can cache dependency parsing results and whole bundles
>>>>>>
>>>>>>
>>>>>> So- thoughts? Is this a horrible idea? Are there some gotchas that
>>>>>> I'm
>>>>>> missing?
>>>>>>
>>>>>> Specific advice needed-
>>>>>> • How to package this in a way that it can be easily used in other
>>>>>> projects? How can I make it integrate seamlessly with existing
>>>>>> servers
>>>>>> and make it compatible with different transport mechanisms?
>>>>>> • How to handle path resolution?
>>>>>> • Suggestions for licensing?
>>>>>> • Suggestions for a name- (Mundlejs is a portmanteau of Module and
>>>>>> Bundle- didn't really think long about it)
>>>>>>
>>>>>> Things that need to be (properly)implemented:
>>>>>> • server-side "parsing" is just a brittle regexp right now:
>>>>>> (line.match /require\('(.*)'\)/)
>>>>>> • neither type of server-side caching is implemented (pretty easy to
>>>>>> do)
>>>>>> • uniquely identify clients and keep the server away of what modules
>>>>>> they already have, so we can just send the diff of cached modules-
>>>>>> currently, I'm sending the entire list of already cached modules with
>>>>>> every xhr call, so the server doesn't load a dependency twice.
>>>>>> • proper compatibility with module specifications (i.e. CommonJS)-
>>>>>> right now, it's just require and module.exports
>>>>>>
>>>>>>
>>>>>> Code is available here:
>>>>>> https://github.com/meelash/Mundlejs<https://github.com/meelash/Mundlejs>
>>>>>>
>>>>>> To test it:
>>>>>> from Mundlejs/tests/, run
>>>>>> node server.js
>>>>>> visit http://127.0.0.1:1337/ and open your browser console.
>>>>>
>>>>>
--
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 nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
