[x3d-public] [x3dom-developers] Prototype

[Cecile Muller]

Hello 3D people (and hi Eric, long time no see :-)


It sounds like we're kinda coming back to the discussion we had some months
ago.
Basically PROTOs were good back when you wanted to have them directly in
the scenegraph, whereas JS-based modules/components (or emscripten-compiled
modules, but that has its own challenges) are easier for engines to
implement nowadays because webdev over the years has dealt with modularity,
so it had time to iterate models used in various real-world applications,
not just 3D:

 - ES3
  function XYZ()
  new XYZ()

 - ES5
  Object.create

 - ES6 (now renamed ES2015, long story)
   class
   import/export

- conventions like CommonJS and AMD


X3DOM already has such components (
http://x3dom.org/docs-old/components/index.html) and unlike classic protos,
they allow you to use modern javascript. Even if classic protos were to be
implemented in the engine one day, it would only be syntaxic sugar that
internally produces these components.

Web Components would have been be nice sugar (once it's available natively,
polyfills have a performance cost otherwise) if you intend to keep using
the DOM to store the scenegraph, however a virtual DOM also works to store
scenegraphs and is fast to diff for changes when you want to use
uni-directional data flow as the web is moving away from 2-way binding. But
that's another story and it's anyway up to each engine to decide what they
prefer using, both have their benefits.

Also if one doesn't want to use X3DOM and didn't go for the obvious choices
Unreal or Unity, Three.js or Babylon would be safer choices, they have way
more users and quality maintainers.


See you,
Cecile
http://xkcd.com/927/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20150217/915d8ca6/attachment.html>