Echo JS 0.11.0

Code splitting with module bundlers is the pinnacle of modern JavaScript's problem with overcomplexity. We're talking about using bundlers to un-bundle the bundles they create.

Just create one bundle for shared code, and separate bundles for pages or components that aren't always rendered. Inject those bundles in script tags when you need them.

Booooo this is a marketing pitch.

1) What do you mean by functional representation? One of the reasons I stopped using React is that its components rely on inheritance, and I prefer functional JS.
2) You can use JSX with Vue.

I tried switching to fuse-box from browserify. It was a bit faster than straight browserify, but not faster than browserify with persistify. My bundles were taking between 350-650 ms with 21 files adding up to 230k - not a large project by any means.

Ultimately I had to switch back to browserify because I do two different builds, one for dev with sourcemaps, and one for production without sourcemaps. The .fusebox cache was getting screwed up when I switched builds, causing runtime failures because modules were missing. I could remove the cache every time I start a watch or a build, but it takes 3.5 seconds to build from an empty cache, which is crazy slow.

Thanks for the thoughtful comments! I think I should clarify something, though - I was not arguing for using npm scripts over task runners. I was only discussing a DIY solution for watching file changes if you're already using npm scripts, which are slowly displacing task runners according to surveys.

Since you bring it up, though, I think it's worth noting that 1) You generally shouldn't be actually writing build commands in your package.json (which leads to the && problem), you should just be executing .js or .sh files, and 2) those files can contain as much declarative or procedural logic as you want, including the full power of node, and the freedom to require and chain js plugins just like you would in a gulpfile. I tend to use shell scripts because they're more compact and sometimes faster, which is why I brought up CLIs - but you can always just run a js file with node and require whatever js modules you want.

And to your last point, the reason I (personally) try to avoid dependencies is not because of bloat, it's because dependencies are points of failure. When maintaining a large project over the course of years, you constantly have to watch for new versions of your dependencies. More than once I've been thrown into panic mode at work because a minor patch to a dev dependency caused a build break that started blocking a business-critical bug. 

Luckily, Yarn's deterministic installs have solved that surprise bug issue for me, but dependencies still cause me the extra work of keeping up with releases. 

The important thing, though, is that we're all productive and enjoying our stacks. Build your code the way you like to!!!

Very cool. I tried this approach too, and while there are exif libraries that make extracting the data a breeze, I've found that devices don't tag photos consistently, and a lot of people don't give their camera location access.

love when tech bloggers are surprisingly funny.

I was hoping the next npm major version was gonna be a direct response to Yarn. Looks like they were busy with other fixes. Here's hoping 5.0 has some huge speed improvements and a deterministic install.

This is great, but what I really want is a tool that will do both transpilation and minification in one step, with source maps.

If my app is so resource intensive that I want to make sure the event queue is clear before I do anything, there's no way I'm going to add a library that creates new event listeners for 9 of the most common DOM events. When I want to run some fairly quick code after the event queue empties, I just put it in a setTimeout(fn, 0). If it's a heftier task then I'd consider using a web worker to run it in a different thread.