fusionjs VS vctl-docs

b) Don't do intermediate builds at all. This is what we do for monorepo-internal packages at Uber. Basically, our framework lets you specify what parts of node_modules should be transpiled when compiling the service. So basically you just have a single compilation step and the performance cost is alleviated by leveraging babel cache. The upside of this approach is you only need one file watching daemon and you don't need to worry about BS related to intermediate compilation bugs, NPM publishing interface, etc.

I also worked on another framework which does ship with polyfills, but this one is very much a "we-call-you" framework, in the sense that it has an full-fledged, opinionated compiler with hundreds of hours worth of time spent on optimizations, and the inclusion of polyfills is also very much a deliberate choice made in the name of productivity.

We've gone down this rabbit hole with Fusion.js. The TL;DR: is core.js aims to be standard-compliant, which means it'll often pull in a lot of code to deal with obscure corner cases like dealing w/ Symbols.

At work we use another framework called Fusion.js. One thing that we find important is its plugin system, which allows colocating server/client/hydration logic by concerns, rather than by environment, meaning we could enable/disable, e.g. Redux hydration by registering a plugin, rather than peppering redux code in a bunch of disparate lifecycle hooks.

I haven't done a lot with it, but VMWare Fusion has a `vctl` command you can execute in Terminal:

https://github.com/VMwareFusion/vctl-docs/blob/master/docs/g...

Looks like it supports doing some kubernetes stuff using a `kind` cluster.

I've had pretty good experiences with Fusion, so, yeah, there's some real Docker alternatives up and coming. I think Docker's great, though, and I feel that we'd never have seen a `vctl` on a mac without it's existence.