Suggested playground improvements

Announcements
1

Hi everyone,

I wrote a blog article about some improvements I want to make to the playground:

Improving the Babylon playground | LinkedIn

Those are just suggestions. I am looking for some feedback - what is missing, what is correct, and what can be improved. If you have any input, please feel free to write it here!

Thanks everyone :slight_smile:

12 Likes
2

The linking back and forth between doc attributes/methods at Babylon.js docs and (relevant) pgs doesn’t seem that great.

Been thinking to make some pgs lately, the new features sound great!

1 Like
3

Looks like great improvements :smiley:

FWIW: My main “pain points” with current PG:

  • Code I write in PG is very different from code in actual app. In PG it is e.g.
    const pos = new BABYLON.Vector3(...)
    while in real app it would be:
    import { Vector3 } from '@babylonjs/core/Maths/math.vector';
const pos = new Vector3(...)
    Consequence of this difference, is that it is cumbersome to copy/paste code between PG and actual app.
    I’m guessing large part of improving this relates to ESM packages.
    As a workaround I sometimes resort to other tools like codesandbox or stackblitz
  • Working with “external” assets (textures, models, sound, etc.) is a bit of a hassle - you have to upload somewhere else publicly accessible. Would be great if you could just include (drag’n drop maybe?) assets into a PG

Just my 2 cents :smiley:

1 Like
4

There are some interesting suggestions in there. I believe some of them to be related.
Like all the thingy about the management of dependancies and versioning feels to me like it should all work together (that’s points #2, 5, 6, 7). These would all be a ‘nice to have’ adding in my opinion. To which, I would actually extend the note from @pjoe regarding external assets. As food for thoughts, with the new architecture… :thinking: At some point, if you can use your own snippet server (#9), may be you could also use your own server as a reliable source for importing/exporting assets. May be even without the need of setting-up your own snippet server?

This brings me to point #10. I believe I would suggest a different approach for this.
Precisely, for (quote) “It is still unclear how we will deal with user detection. One thing for sure – we don’t want to add user authentication”, here would be my approach and suggestion:

For forking/ownership, add a ‘creator’ field/tag to the PG. In order to become the creator and use versioning, the user would need to be identified/logged-in. Else, it would fork like any other identified or unidentified user. My thought is that, if I want to take ownership of a PG, it makes sense to identify myself first. I believe it would also make the management/trust a lot easier. Of course, my two-cents only :grin:

Point #1 seems like kinda obvious. I don’t know who would oppose to this. Makes a lot of sense.
Point #11 is for me another ‘nice to have’ that should have little impact on the UI and would clearly improve the user experience. So, it’s a ‘YES :+1:’ for me for these two.

For the rest, I appreciate the extended support for various usecases. I can also read the comments about using react (not included at the moment), esm, npm, etc… however (and this will be for now my last comment/observation). It’s just ‘high-level’:

The playground is one of the unique advantages of BJS. It has multiple uses and - one of these - is also to drive and commit new users to the framework. In this sense, I believe it important to ensure that the changes/addings will not turn it into a ‘factory’. Adding all too much complexity to it. Its instinctive and simple use is (in my opinion) an asset and an advantage. We wanna make sure people (even not all too knowledgeable) continue to use the PG and get further involved with BJS. Again, my opinion only :grin:

And meanwhile, have a great weekend :sunglasses:

2 Likes
5

Here is a new suggestion :

6

Answered there :slight_smile:

1 Like