Matt DesLauriers

I am 100% in the camp of async/await, lack of support has been a paint point for me when teaching p5.js and trying to get students out of the p5-only...

EDIT: see updated issue ^

Using [open](https://www.npmjs.com/package/open) so far and it works well for my case. :+1:

How might this look with regard to budo? I'm trying to envision how a small GH pages site/demo like [this](https://github.com/mattdesl/three-glslify-example/blob/434984fda60eaec8335782607fb2e3c19c15119e/package.json#L27-L28) could use `wayfarer-to-server` to avoid having to manually write the...

This looks good; the only thing is that typically you end up with different dev and prod configurations; like using `installify` during development or `uglify` only during production. Any ideas...

I think browserify options could still be passed after the full stop, and maybe the flag could look something like this: ``` sh budo index.js:bundle.js --write=./static/ -- -t babelify -t...

More thoughts: - An ideal build step should include some or all of `uglify-js`, `envify` (or `loose-envify`), `bundle-collapser`, `factor-bundle`, [dead code elimination](https://github.com/zertosh/unreachable-branch-transform), etc. I'd rather just build a separate tool...

FWIW I implemented this in [canvas-sketch](https://github.com/mattdesl/canvas-sketch/) and it introduces a number of new considerations: - Introduces opinions about compression: uglify? bundle collapser? envify? minify HTML? etc... Also new flags like...

> Problem goes away completely with the budo --no-debug option I have a feeling this might not be a budo issue, but rather a browser issue. I've experienced a lot...

Is there any way I can reproduce this on my end?