This is the first post of a new weekly series I'll be embarking on named TWIL (This week I learned). It will cover weekly programming and tech discoveries/mishaps that I encounter.
So I tried to learn React. It went something like this: Okay, I understand the library, but how on planet earth do I include and run it? Do I use Gulp? Dafuq is webpack? What is this CommonJS, AMD, and UMD stuff? And I need to include Babelify? Browserify? Wut???
Master Build Process Diagram
One of the first mind-blowing things I figured out was that you could
npm install client-side code (e.g. Redux). Sure, they get placed in the node_modules folder, but that's okay. No matter if you're using ES6 or require, putting them in node_modules allows you to import them just like how you do in a Node.JS application.
But how do I include these libs on the client side??
That's where tools like Gulp and Webpack come in. At their very core, Gulp and Webpack don't really do much. Their abilities go something along the lines of "I can find some files in some directory, do something to them, and then spit them back out somewhere else." Essentially, a glorified copy-and-paste tool.
In come the Transpilers, Loaders, and Plugins
When I say "transpilers" and "plugins", I mean things like:
- Browserify (Find and include modules in builds)
- Uglify (Compress and minify files)
These are the things that make Gulp and Webpack so powerful. In essence, they act like "powerups" that Gulp and Webpack can make use of. For example, you can tell them to "find .js files, use uglify to compress and minify them, and then spit them out as one file in a build directory"
The beauty of Browserify
Remember the problem we had earlier of using stuff from node_modules in the client side? Browserify solves that by scanning your imports and packaging them into your output file in a smart way. In other words, it looks at your source file, plucks all the required modules from node_modules and other places, and puts it all together into a single file such that just works. Pretty cool, eh?
Okay, I can compile JS code now. What's AMD, UMD, and CommonJS?
import MyModule from 'my-module' (ES6),
var MyModule = require('my-module') (CommonJS), and other standards. There's a great writeup on how all this came about on Medium.
The story goes like this: Some dude on the magical interwebs got tired of all this mismatched horsepoop and made the "Universal Module Definition". Another specification you ask?? No, not really. It's just some special code that makes your module compatible with AMD, CommonJS, and other standards all at the same time.
So which one should I use, and how should I use it?
Use whichever one you want that best fits your needs. I personally recommend UMD simply because it reduces a lot of headache if you need your code in another format sometime in the future.
To actually compile into one of these, just set the appropriate setting or install the appropriate plugin within Gulp/Webpack/Whatever you're using.
How does React play into this?
TL;DR. I want the meat of it.
Sorry, this is as simple of an explanation as I can write. I didn't even get into the technical details of using all these things.
But I really, really want a TL;DR