It comes with a proven starter template repository on GitHub (tested on MacOS, Linux).
@note: Windows users should install this template using yarn, not npm because it will probably produce errors with npm. If you haven’t installed yarn, do this first:
// it doesnt work if using npm install --global yarn (according to some report)
npm i yarn
Key Features:
SEO Friendly
Load Fast to achieve “A” Grade Page Speed score
Async Load Babylon to improve UX (user experience)
Code Splitting with Tree Shaking to reduce bundle size
An option to write in pure Javascript or Typescript (or mixing both)
Intuitive developer experience with HMR (Hot Module Reload)
Jest Test working setup
Modular Architecture for a flexible, maintainable and scalable app
Production ready with detailed bundle analyzer.
If there is anything you’d like to add, plz let me know.
The philosophy is to make it newbie friendly, and pro happy.
A newbie might go in and try to show the boundingBox, and not know that Babylon requires ‘@babylonjs/core/Rendering/boundingBoxRenderer’ for it to work.
Whereas by the time you get to code pruning optimization for production, chances are you already know what you are doing. You can easily comment out the exports you do not need, like explained in the Doc block inside that file.
For ease if use, I left common exports that are frequently used (at least from my personal experience).
Also in production build, it seems Webpack will strip out all unused exports anyway (though I haven’t tested this completely).
Just realized I might have misunderstood your question. All Babylon imports should come from a single babylon.js for these reasons:
Abstract away internal dependencies of Babylon packages
Make your project framework agnostic, so that you can easily swap/combine any 3D library in the future (Three.js for example, though I see no reason of doing that )
Easy to maintain (example: if a polyfill is need for WebGPU, do you not have to hunt down all views importing Babylon. Or perhaps you want to replace the default CSG with a cooler one, like you mentioned.)
Actually I don’t need any localization at all.
But when I open localhost:3000 it opens at localhost:3000/ru with errors.
Is there a way to use your template straight out of the box?
I did fork and then yarn and yarn dev. Didn’t touch anything in files.
I see the problem. It’s because your comp has ru set by default. But the default template has no ru page setup, and Next.js being too smart, tried to redirect you to a non-existing page.
This was only tested to work in Node.js v12.22.1. as stated, on MacOS. It could be problem with the yarn itself.
Try to remove this file: /babylon-next/repos/web/components/Preload.js - it is not used, only for reference, but that’s the only place the next/router was imported.
You can verify this yourself by searching for next/router in the entire repo, it’s not used anywhere. Perhaps you have stale cache from another next.js setup in your yarn.
NVM would be good for this purpose if you are not using it yet. Next.js is quite picky about Node versions, hence I explicitly mentioned the tested Node version that I currently use myself in production.
This is one of the reasons many people struggle with Next.js setup. But the upside is there is much less headache after you get the initial setup working, compared to CRA - easy to start, hard to customize.
But the boilerplate should work in Windows, because that rimraf package is only used as extra developer tool for ease of use.
If it’s because of rimraf that you are having problems to get it running in Windows, then we can remove it from the template. I do not have Windows, so if you could test that would be great.
)
