The thing is jspm, browserify and webpack are not exactly comparable. They do some different things and do them differently.
What I was trying to say is basically this:
If you ask a general question people will answer based on their perspective, which isn't necessarily aligned with your requirements and thus not really helping your decision making.
You should focus on your specific requirements and work from there.
For me, gulp takes care of pre-build/deployment issues, so I don't need those features from webpack. On the other end, jspm, beside including a module loader (systemJs) is also a 'package manager' that is comparable to bower but more generic. I find this to be very useful when you start mixing packages from different sources that use different module systems.
assuming you don't have development time to waste - do not make a research topic out of selecting build tools - choose one - start working - don't use features you don't need - if you encounter issues - try something else
-just build your product!-
(ps, I like jspm, but really, just pick one and move on to real coding)
I agree that it's better to have a small module, but currently it's only me on this and the codebase is actually not that large. So even though some features may be extracted, we're talking about starting 1-js-file repositories and that just seems like too much of an overhead at this point (in other words, it will just make my life harder).
Besides, keep in mind that it could be a lot clearer with a gentler/partitioned introduction + demonstration + sample usage repo. I will hopefully get to it at some point (any help is welcome ;) ).
what do you mean? the title?
Just in case it's not clear, this is a wrapper around js objects that gives them some extra functionality. It's hard to group those features into a one liner, but the github repository's readme.md has a code walkthrough that explains the interesting parts.
update: I've extracted the code comments so the readme contains interleaved markdown and code instead of a big code walkthrough, is that more readable?
- Parameters are currently assumed to be from a safe source (works for many use-cases, but yes, it is something to be wary of).
- The eval access is supposedly more efficient (as polymer guys claim, but I'm not aware of a benchmark)
- Unlike the 'nester' lib and many others, this key-path lib is designed to separate the path input processing (mainly parsing) from object access. This allows for caching/memoizing and for treating the paths as comparable objects (e.g., checking if 'prop[3]'==='prop["3"]').