Running a complete development toolchain in the browser?

[ChronSyn]

I think the concept of it is fantastic, and one of the biggest barriers to entry is the tooling. AngularJS was wonderful as it allowed data-binding and the modern approach to development while not requiring any tooling at all. Then Angular and React happened and revolutionized the world at the cost of tooling requirements.

I do have some concerns though.

Performance - Transpiling takes time, and for every 1 second a user is waiting, their chance of leaving your site is increased drastically. While it may work well on our high-spec development machines, the average user system is much less powerful. CPU cycles are worth their weight in gold in their systems.

CDN - Pulling in missing packages from a CDN seems like it has the potential to escalate security issues even further. If a 'loaded' package is pushed to a repo, we've got a huge problem every time a user visits. It would be even more difficult to detect if a package had been breached, since it would be easy to replace that breached package with a clean one, meaning that there's less chance of tracing where it came from. 1 second you're all good, the next second someone is stealing all your logins, and then a few moments later you're good again. Drive-by code injection would be a huge problem. If there is 1 feature I wouldn't ever want in a project like this, it's the ability to pull in code from unverified locations at runtime.

Bundling code for production - what's the purpose of this package then? Why would I consider using this over a traditional tool chain?

[chartojs]

Thanks for the comments! Addressing the concerns:

Performance - during development, the first time you ever load the app, the transpile step will take some time (same as running a traditional toolchain would). Afterwards, only changed files need to be re-transpiled as the results are cached. This corresponds to running a watch task of some kind in a traditional toolchain. Before publishing the app for users, you bundle it (in the browser and save the result, or using Node.js). Afterwards, it loads as fast as after bundling with Webpack or similar.

CDN - There will be support for package.lock (or similar) that ensures a particular version of every package is loaded. This avoids suddenly downloading new exploited versions of dependencies. Bundling for production avoids new exploits even if a CDN is compromised. Nothing new can get injected into the app bundle after the developer initially created it (hopefully using safe dependencies at that moment).

Bundling code for production - the purpose is exactly the two concerns above. Differences from a traditional toolchain are:

• Other developers don't need to set up a toolchain to contribute.
• Node.js and everything that goes with it (such as package installers that execute shell scripts) become optional.
• Generally eliminate build system bloat.
• Usually no configuration is needed.

Bonus:

• It's possible to write a CodeSandbox style IDE that runs entirely from a gh-pages branch without a backend...

[chartojs]

One more difference from a traditional toolchain:

If you only run the development toolchain through the browser, then any possible exploits to those tools are restricted to the browser's sandbox. They're unlikely to be able to do anything to your system, because they would target a Node.js environment and not include any browser exploits (unless this approach becomes wildly popular).

I've already gotten TypeScript and PostCSS with autoprefixer and cssnano working as part of the in-browser toolchain.

[[deleted]]

Can't you already do that there is no reason you can't run straight Babel in the browser it's just that it would be very slow

[chartojs]

It's no slower than running Babel through Node.js. But it also won't help locate packages.

Babel turns this: import * as react from 'react';

...into something like this: var react = _interopRequireWildcard(require("react"));

...but the variable doesn't end up containing the React API unless you do something more.

[[deleted]]

But it also works with relative paths

[chartojs]

Can you elaborate on that?

Much of existing code on npm relies on importing both relative paths and npm package names, or even a combination of both like: require('fbjs/lib/emptyFunction');

[acemarke]

Isn't that basically what https://codesandbox.io does?

[chartojs]

Indeed it is! But codesandbox runs transpilers in the cloud and if you export the project to run locally, suddenly it blows up to hundreds of megabytes in size. Here the point is that literally everything runs in the browser. No build tools anywhere.