Indication of MJS and CJS

[kungfooman]

Great work for the last patch, if you want more fun, you can rename file endings to *.mjs aswell, that indicates to all tools what they are dealing with.

At the same while renaming CommonJS to *.cjs, so everything "just werkz":

[ChrisCavs]

will this require changes to the rollup config? also is there an advantage to this outside of allowing users to execute the src folder code? ideally the src folder is not executed by consumers

[kungfooman]

will this require changes to the rollup config?

Yep, basically just input: 'src/aimless.js' -> input: 'src/aimless.mjs'

ideally the src folder is not executed by consumers

That is a fatal assumption you better forget about modern JavaScript.

Source code thrown through build tools in general is more:

• bug ridden
• accompanied by sourcemap issues
• minified / unreadable / undebuggable

[ChrisCavs]

Well i think the sales pitch for build tools has always been 2 things:

1. enable the use of ES6+ through babel
2. tree shake, minify, and/or take steps to minimize bundle size

Of the two, (2) is the essential piece, since every character of code written in frontend must be downloaded by clients before viewing the webpage. This means that minimizing size has always been the essential aim of high performing code that can run on any machine in the world.

It's also the reason that this library has no dependencies. Dependencies lead to large bundles which means more data needed to download in the browser, and therefore worse performance for the end user.

Importing src files ignores (1) and (2), despite the publishers best efforts. I'd argue that is more dangerous. src code is there for reference since the dist is unreadable.

[kungfooman]

Yep, I agree with all your points. Once developing is "done", an artifact needs to be generated, which is as small as it gets, supporting old ES5 browsers etc.

Before that, you are in the coding process, in which speed is key. Since you (as a dev - should use e.g. latest Chrome), you don't have all these restrictions for yourself.

I'm developing via ES6 using many different ES6 libs which I all pull in directly from /src/:

More than 800 files, including wasm files etc... several hundred ES6 files are in the first second, using around 500-600ms.

So why don't I just use a bunch of dist.js files? The reality of a dev is to constantly test different PR's and quickly test old code or write new code. If for every minuscule PR/test you first have to spawn a bunch of shells to start build/watch processes, you are wasting crucial "flow time" and get less work done.

For the end user, all this doesn't really matter, but you as a dev get more "quality work time" (which also serves the end users of course later).

[ChrisCavs]

I see what you're saying. a lot of stuff we do is centered around working with other devs, and improving that flow state. so why would we use tools that slow us down when we don't need to, instead use those tools only to enable performance of end user (production env, distributed release).

It's a good point, I don't think many people care about that level of optimization on the dev side. I'll test the rename and see if the generated bundle is still working as expected

[kungfooman]

s/completed/completely destroyed/ 😂

gg & gl