Thank you!

There is a lot to unpack here :-)

I'll take a look this week!

I'd like to see this land in multiple PRs. That is, many of the improvements proposed here are not related to the lazy loading and we can land those first before making The Big Change.

Yes I was going to do that originally but then I had to change a couple of things in order to get lazy loading working such as changing some polyfills to ponyfills because they are trying to define properties that I’m currently setting. For example the URL polyfill can’t access globalThis.URL since that’s the property I’m loading and setting (will cause nasty errors and seg faults).
And since this PR is a breaking change of the APIs it might be better to do a big bang.
Another idea is to create a pre-release branch until we have found a way forward we’re happy with (regarding the naming and APIs etc)

Phew, that was a long read!

Before I begin, thanks a ton for doing this! Let's unpack.

There is no way I am merging such a large PR, we need to break this down into individual self-contained changes that slowly work towards the end goal, and once all changes are in, it would be virtually equivalent to this PR. I have refrained from making comments while reading the code, because it's just too much to review at once.

So, here how I think we can begin to break it down:

• console improvements
• path improvements
• Blob improvements
• URL improvements
• Native uuidv4 (note the current proposed implementation seems to use a static seed, which sounds bad)
• Native text encode / decode
• Optimized script runner: this I'd like us to keep the same syntax as the current CLI, but just avoid the JS roundtrip in there are no more arguments
• Break apart the stdlib into individual modules like tjs:assert, tjs:path, etc. (we should probably move ffi here, to tjs:ffi

Things NOT to do (yet):

• Run prettier or any not currently existing linter: it just adds churn at this point. Let's focus on the changes themselves, then maybe consider linting the whole project in one single pass.

All these things can be done under the current internal "architecture". They won't bring that big speedup from the lazy loading, but they'll get us ready-er for it.

Now on to the big one.

LAZY LOAD ALL THE THINGS!

On this step we'd move to lazy loading all the big things. I'd like us to do this in a couple of steps:

• Introduce the mechanism and lazy load a couple of the biggest offenders
• Make sure the "internal" modules are not loadable by user code
• Gradually migrate the rest of the modules

An important part for me on this last step, due to the complexity it adds will be to define a way by which we'll measure. Also, how will we know we haven't regressed in startup speed? Perhaps there needs to be a test that checks for this with some baseline, so make sure it stays that way.

Hope that makes sense! Happy to work together towards this goal. It'll take a bit of time, but we'll get there.

Yes that sounds like a plan! I'll get to it!

One module we also would migrate is the TextEncoder which is terribly slow. And again, the more modules we can move to native the better. I will close this one and work according to the plan :)

Thanks for your review!

Awesome! I think the migration to having the stdlib in separate modules (again, lol) and having them lazy-loaded can be done in parallel.

Let me know where you plan to start and I can tackle some of the items too.

Awesome! I think the migration to having the stdlib in separate modules (again, lol) and having them lazy-loaded can be done in parallel.

Let me know where you plan to start and I can tackle some of the items too.

I’m currently very limited time wise and will not likely have the bandwidth to do this ☹️ Feel free to take what you need from my mega-pr and do this step by step

👍 sounds good!