search

kriskowal / mr

Montage Require: a CommonJS module system for front-end web application development
Other
4 stars 1 forks source link

Version 2 Discussion #2

Open kriskowal opened 9 years ago

kriskowal commented 9 years ago

This repository concerns the version 2 branch of Mr.

My intention for Mr v2 is to redo Mop outright. Mr already has a Mrs script suitable for creating bootstrapping scripts but, like Browserify, is not the complete story.

There are two key features of v2.

  1. The first is the new model for bootstrapping scripts built from modules.
  2. The second is the addition of translators, compilers, and optimizers.

Mr now has a story for creating stand-alone scripts like Browserify. It lacks a story for reactive builds or "watching" like Browserify and Webpack. It also lacks a story for sourcemaps.

  1. reactive builds
  2. source maps

The story for client side Node.js modules is to depend upon them directly and we could debate a more seamless integration, but I like explicit dependencies. This is of course open to debate.

Mop is not fast. The next generation of Mop needs to be incremental and I would like to enlist JS-Git for storing incremental build products and building trees directly from the object store. This would eliminate the need to keep resources in memory. We can just dump them to the object store and retain a hash in memory. We can also use a hidden name space for mapping input hashes to output hashes.

Source mapping probably needs to be added to the translator, compiler, and optimizer protocol, so that the new Mop can pick up maps and include them in build products.

I intend to take out mop integration for the interim, @stuk. I think it might make sense for Mop to be versioned alongside Mr and kept in the same repository going forward. I’m reserving the build directory for Mrs and Mop tooling.

Stuk commented 9 years ago

I agree, +lots on updating/redoing Mop/Mrs. I don't feel like can recommend them at the moment for the above reasons, and because Mop generates a large bundle including Mr and no-one is actively focused on maintaining them. It would be nice if I could :)

I do wonder what the selling point of Mop/Mrs over Browserify and Webpack is? It could be caching the results in Git, if that results in significantly faster builds. It could also involve building to a git branch, as that feature on collectionsjs.com is wonderful. Anything else?

Source mapping would be great, although debugging the uncompressed bundle isn't too painful if we need to prioritize. (Although I have come to love workspace mappings in the Chrome inspector the past few months, and that requires source maps.)

Versioning Mr and Mop in the same repo would reduce maintenance overhead, and god knows we need to make that as easy as possible.

In terms of what I can do, I'm happy to think about stuff and review code, but don't think I'll be able to dedicate loads of time to working on the nitty gritty right now.

tlrobinson commented 9 years ago

I think a good way to differentiate from browserify/webpack is to focus on the initial prototyping use-case, with a migration path to something more production-ready.

If I could drop in a script tag and get a module system with 6to5/JSX/CoffeeScript/TypeScript/etc compilation and source maps, and maybe even easy access to npm/bower/cdnjs packages (through some sort of community-run proxy, probably), and later setup a production build process (or something like browserify-middleware) that'd be pretty compelling. On Sun, Feb 8, 2015 at 3:36 PM Stuart Knightley notifications@github.com wrote:

I agree, +lots on updating/redoing Mop/Mrs. I don't feel like can recommend them at the moment for the above reasons, and because Mop generates a large bundle including Mr and no-one is actively focused on maintaining them. It would be nice if I could :)

I do wonder what the selling point of Mop/Mrs over Browserify and Webpack is? It could be caching the results in Git, if that results in significantly faster builds. It could also involve building to a git branch, as that feature on collectionsjs.com is wonderful. Anything else?

Source mapping would be great, although debugging the uncompressed bundle isn't too painful if we need to prioritize. (Although I have come to love workspace mappings in the Chrome inspector the past few months, and that requires source maps.)

Versioning Mr and Mop in the same repo would reduce maintenance overhead, and god knows we need to make that as easy as possible.

In terms of what I can do, I'm happy to think about stuff and review code, but don't think I'll be able to dedicate loads of time to working on the nitty gritty right now.

— Reply to this email directly or view it on GitHub https://github.com/kriskowal/mr/issues/2#issuecomment-73439746.