I followed the instructions at NPM Support | Babylon.js Documentation and complied a project with no problems.
For those who may don’t want to repeat all setup steps - here it is: GitHub - eldinor/BabylonTS-NPM-Minimal: Babylon Typescript NPM Support Minimal
The best way for you during development would be the webpack dev server (GitHub - webpack/webpack-dev-server: Serves a webpack app. Updates the browser on changes. Documentation https://webpack.js.org/configuration/dev-server/.), but it is not a part of the scope of this tutorial.
Seems that hot reload function would be very useful for small projects. Feel free to commit if you know how
Docs improvement - see also Babylon.js Ease of Use
Is it possible to add here the information how to add webpack dev server? - NPM Support | Babylon.js Documentation
In this way the example will be complete, finally.
It seems to be not very complicated.
I would do it myself but I don’t know much about webpack so I can do it only by trial and error method, which may finally lead to errors which I wouldn’t be able to recognize.
@PirateJC is the master of the doc
@jeremy-coleman please do not get @PirateJC starting on Jokes please…
Like a golden path leading to actual pirate treasure?
First @jeremy-coleman keep the pirate jokes coming! The are VERY welcome here!
@labris yup we can definitely add that to the doc, but I think @RaananW is probably the most qualified web expert here to propose the right content for the update. Raanan what do you think?
I caution against getting in the business of documenting webpack configs.
I tend to agree. And disagree
I disagree because I think we should have some explanation on how to bundle, but we should offer other setups as well. Just like there is a Vue and React section in the doc. If anyone will ever contribute Angular, it would be awesome
I agree, because there are easier methods to check your project. especially if you are getting started and just use a .js and and .html files. a simple http server would suffice.
I’ll have a chat with @PirateJC about it later today
i agree just a index.html and a js file sucks, but that doesnt mean you have to explain how to use webpack. a link to a starter repo on the babylonjs org’s github with install and start instructions is what people need. Basically, what i’d hate to see is "first add these dependencies to your package.json, next create a ‘webpack.config.js’ file and add this configuration, next add a section to your package.json scripts section and add “start: webpack serve”. People struggle hard with webpack, dont you put that evil on them ricky bobby. It would seriously be easier to draw a triangle with cargo/rust using wgpu than it would be with getting instructions on setting up webpack.
It doesn’t suck. it’s a basic setup for beginners. I don’t use it, I don’t want to use it, but this is the easiest to start with.
And I don’t agree that us showing how to add a simple webpack configuration is a bad thing. Webpack is one of many. What would you have them do? Webpack is the starting point of many people trying to bundle stuff. Yes, there are others. And Webpack is working.
People who don’t know what npm is will struggle as well. Should we explain what yarn is? pnpm? node? what node version should you use?
You are forgetting that the users vary from experts to beginners to people coming from other languages, to designers with no understanding in development. We need to be sure that you will be able to host a simple site. We need to make sure you can deploy and host your own experience. I am all for using the latest and the greatest, but… the js community can’t even agree on best practices for the simplest thing. So we need to make sure everyone get it to work.
HTML + js? there you go.
Webpack? here sir.
Rollup? you are awesome.
Directly loading modules in the browser? Coming soon
I am imaging a scenario where “setup instructions” is the first thing people see. Perhaps, using create react app without react could be a good option. It has docs on testing, build, and deployment instructions all handled for you. Then, maybe put all the other instructions in advanced / diving deeper under “bundle strategies” or something along those lines.
you and I can write webpack configs from the top of our head. I can’t reiterate enough how difficult that is for most people.
btw that should work for your angular request too. (Using angular inside create react app)
.GitHub - jeremy-coleman/react-ng-host
havn’t checked that in a lonngg time but, it worked at the time lol. I think i did some hackering so passing props through components worked, idk. anyway, the point is create react app shouldn’t be limiting in any way.
Not very happy about this one
My personal opinion about predefined templates is that they contain too much undocumented magic. But there are simple webpack-oriented templates we can use. a typescript-webpack template, similar to the react-create-app (that simply prepares your project structure).
I get what you are saying, and you know that I mostly agree with you. We just need to be sure we support everyone, and that everyone can get started. templates can also be a bit overwhelming to some. I guess some will be happy to copy-paste some code from the page instead of running an npm/npx script that asks them so many questions.
But sometimes they can save a lot of time to users, even the simplest ones. Also, a lot of users still don’t want to use TS, so minimal JS template would be good (example with Vite - GitHub - sotovviktor/babylonjs-project)
create react app can be annoying, because the author who originally implemented the typescript stuff clearly doesnt actually use typescript and forced bad settings (same guy moved to nextjs team). Still, I think its getting better now. I dont like webpack and i dont like create react app, but for a starter template, i think its the best option, here’s why:
CRA includes aliases for for react-native to react-native-web out of the box. This should facilitate babylon native interop. here is a basic example without changes to the default config. GitHub - fadiquader/react-native-web-mobx
support for babel macros, which is, imo one of the best and most under-utilized features in the js ecosystem. babel-plugin-glsl macro is great and brings with it a decade of glsl modules.
jest testing already set up that reruns only changed files.
very good performance for static builds. the service worker setup they use makes sites load very fast.
It’s extensible as any webpack config through craco, rescripts, or react-scripts-override to easily add additional plugins.
many asset types are already handled. see this r3f game. GitHub - akarlsten/cuberun: A small 3D game built with react-three-fiber . If you check the src files, its using audio and gltf files with just the default configuration.
Maintained and ubiquitous
CRA doesn’t stand to profit from your build taking longer or forcing you into specific api patterns, like nextjs and gatsby. It also doesn’t collect telemetry.
I also suggest creating a .env file and adding:
TSC_COMPILE_ON_ERROR = true
DISABLE_ESLINT_PLUGIN = true
SKIP_PREFLIGHT_CHECK = true
You will still get linting and typescript editor feedback, it just makes webpack not throw errors that aren’t actually runtime errors. It’s super confusing to get some webpack lint error that actually does not effect the runtime.
don’t forget snowpack community template - it’s a one liner to get up and running. no git/config/copying files/etc. needed:
Snowpack community template - Demos and projects - Babylon.js (babylonjs.com)
I can get a Typescript and GUI NPM running on CRA in 5 minutes without any custom config and in my opinion also it is the best option.
Check out this r3f racing game - it is a showcase for feasibility of React in gaming: pmndrs/racing-game: Open source racing game developed by everyone willing (github.com)
yea, i think react makes a lot of sense as basically a virtual scene graph manager. btw, i was thinking react-babylonjs could use a es6 proxy to avoid those 30k lines of code:)
All the typings are not bundled at least (that is most of generated code). in v4 I will be introducing importing via side-effects to fix tree-shacking. but even a vanilla with no dependencies can be a good option for composition.
Also, I want to reduce that generated code to all run off small configurations and dynamically generate prop handlers maybe even without checking types, but then I would lose capability to write custom reconciler for handling props like Vector3/Color3 with external projects like
react-spring. anyway, those are all ideas and i have less and less free time unfortunately…
…back to the original topic I think there are lots of good options out there, but I like the idea of CLIs that scaffold starter projects as that seems the easiest way for beginners and experts alike.