Jsx in playground + modernize the repository?

Feature requests
1

Playground could really use jsx support (react-babylonjs). It can be done in CodeSandbox, but it’s not very inviting.

I’m interested in contributing, but the barrier for the community to help out seems unnecessarily high.

I can manage, but it should be easy for someone to make a small improvement and not get demotivated by obscure directories and build processes (that take an hour and then fail).

Esbuild/vite = 1000x faster and easier than webpack. I know the team is busy, but version 5 would be a good time to improve this.

It would also be good to split the repository with something like lerna (monorepo from npm/github modules). It makes dependencies, releases, documentation and issues clearer and lowers the barrier. It’s not just about today, but also tomorrow.

1 Like
2

Hello!

Woot so much positivity :slight_smile: We do not have plan to support jsx in the Playground. This is simply not the goal of the PG. We want to keep it as simple as possible and supporting react.js, vue,js or any other UI framework is out of the scope.

We are working on making our build process more robust/thinner. @RaananW is actively working on it:

Yep! @RaananW is adding it for the new build system

2 Likes
3

@RaananW

I think the best fix would be to move to a module structure under babylonjs that is similar to lodash. Importantly, no existing client code would break as it is. As in, you import from babylonjs and you get everything currently exposed in the root babylonjs/babylon.js file – that would remain unchanged.

The strategy is basically put everything in a single folder, but dont export subfolders from the root index.js except the core. This allows you to add as much code as you want to the project without inflating the default export at all. So for example, you would import from babylon/materials and get what is currently @babylon/materials aka babylon-materials, just like you can now import from lodash/merge and only get merge.

This has an additional benefit of unifying everything under the single babylonjs package going forward. Organizing this is a bit tricky given that you guys are currently publishing under 2 namespaces. To start, I would make an announcement that all the @babylonjs/submodules should be considered private apis and babylon-submodules deprecated. The babylon-submodules would still need to published for backwards compatibility of client imports. Ideally, the babylonjs-submodules will be published as single-line re-exports of the @babylonjs/submodules. This is ideal because it would eliminate copies of bundles when third party plugins or even a lot of the internal tooling inside the babylon repo exports the same thing from different root namespaces. For a real world example, this would fix the problem of using babylonjs with react-babylonjs, which uses @babylonjs/core.

There are a few options from a developer ergonomics standpoint here, as in , the dx of actually working on the babylon codebase. Lets use the practical question of, where would the @babylon/core code live? Either in a @babylon/core package or in the babylonjs/core folder (basically how it is now). The babylon/core is the better option to develop with, by far. If you switch to lerna for developing, you’re only making maintenance harder, not easier in any way. My advice is to use lerna as a publishing tool, not an installation tool. Keep all of your dependencies in a single package.json file at the root, there’s truly no need to make it harder on yourself. Also, for an example of how to just use a nested node_modules instead of lerna, see the pouchdb repo GitHub - pouchdb/pouchdb: - PouchDB is a pocket-sized database.. Or, here is a very simple example using typescript’s build system .GitHub - jeremy-coleman/simple-ts-cra-monorepoish . If you’re really stuck on lerna though, the pixi monorepo is very well structured and has a similar strategy of internal @pixi/submodule development while hoisting everything to a bundle package. Additionally, arrow/js at master · apache/arrow · GitHub is a good example of single repo to multi-repo publishing using lerna/gulp. I can help set up a poc or even a variant of each.

Btw, this setup would allow you to trivially add variant builds to the babylonjs folder, for example, adding babylonjs/wgpu , babylonjs/webgl , and babylonjs/webgl2 folders that only re-export the minimally required stuff for each and apply any necessary revisions aka patching webgpu matrix math. You wouldnt need to and shouldn’t bundle this or publish this separately from babylonjs.

ignore this, just notes for me
.Vue + babylonjs experiment - #10 by jeremy-coleman

1 Like
4

Hey!

Thanks for the thorough post :slight_smile: These are all valid points!

You have to understand that there are a lot of other factors that need to be considered when changing our code structure and our package structure. And when we plan the revamp, we need to take them all under consideration.

I think we have already discussed that, but - we can’t just change our code structure and expect all of our users to adjust according to the changes we propose. These packages are used in production code and should still be used in production in the future.

Having said that - I am already in the process of changing the build system to support these changes, and will then work on making the core libraries of babylon side-effect free and totally modular. And yes, there will be (as it seems) a single package that will hold all of our core packages. I am asking for a little more patience :slight_smile:

2 Likes
5

One package is the biggest thing, so thats perfect. We havnt talked about it i think , maybe someone else? I understand the importance of backwards compat, everything i suggested is purposefully backwards compatible. I guess my only remaining concern is just for dev, lerna and monorepos can really suck ass to work with. Anywho, feel free to me if u want any help

6

Well, it shouldn’t be! :slight_smile:

Lerna is just an orchestrator - you don’t really have to use it, but it does make life a bit easier (in certain cases - publishing is one of them). And it will be transparent to most devs. Most tasks will be defined in package.json and might use lerna, but I don’t see a reason to use lerna directly. But this is TBD.

Anyhow, it should be very simple to use. This is one of my main concerns. A one time dependency installation should be enough and you should be able to start developing.

And as a side note - I am not stuck on lerna. I am experimenting with it. Lerna has its bad sides, as any tool has. I also experiment with rush, npm workspaces, and more. They all serve different purposes, and we will eventually choose the tools we are using as a team.

Probably, sorry 'bout that :wink:

1 Like