It would be helpful to create an ECMAScript (ES) validation engine/linter for X3D (Extensible 3D) ES Scene Access Interface (SAI) code, instead of people flipping between X3D browsers, hoping that one of them will produce a bug report.  Segmentation faults aren’t nice either—unless you’ve got a C/C++ debugger handy.  A typical ES developer may not know how to run that kind of debugger.<div dir="auto"><br></div><div dir="auto">My idea would be to take a ES engine, probably Node.js, Deno, Bun, GraalJS, or a linter and add features specific to X3D ES SAI to ensure that our ES code doesn’t break or produce a segmentation fault when we load a scene, and users don’t have to test every browser for compatibility (WORA goal).</div><div dir="auto"><br></div><div dir="auto">Also incompatibilities between SAI implementations should be noted.</div><div dir="auto"><br></div><div dir="auto">I would like to collect “gotchas” people have discovered while developing ES SAI code.</div><div dir="auto"><br></div><div dir="auto">Recent errors for me include:</div><div dir="auto"><br></div><div dir="auto">1.  Global variables throw errors.  Global variables required to pass information between function calls (see 3).</div><div dir="auto"><br></div><div dir="auto">2.  Const and let not accepted.</div><div dir="auto"><br></div><div dir="auto">3.  function signature not implemented (deleteRoute), or differences in number of parameters.  Passing route between function calls requires global (see 1).</div><div dir="auto"><br></div><div dir="auto">4. console not implemented</div><div dir="auto"><br></div><div dir="auto">5.  Warn on usage of …array for long arrays.</div><div dir="auto"><br></div><div dir="auto">6.  ES6 import not accepted.</div><div dir="auto"><br></div><div dir="auto">7.  Differences between internal and external SAI.</div><div dir="auto"><br></div><div dir="auto">8.  Using native types vs X3D types.</div><div dir="auto"><br></div><div dir="auto">9. Linters complain about X3D stuff</div><div dir="auto"><br></div><div dir="auto">10.  “use strict”; not acceptable in some X3D browsers.</div><div dir="auto"><br></div><div dir="auto">More?</div><div dir="auto"><br></div><div dir="auto">If someone already knows of something like this, please share.</div><div dir="auto"><br></div><div dir="auto">Perhaps we only need to produce a linter, and not a full on parser.</div><div dir="auto"><br></div><div dir="auto">Perhaps we could consult with developers of the ES linters and ES parsers for the best way to proceed.</div><div dir="auto"><br></div><div dir="auto">I feel that NIST may be the best place to implement such a checker, at least in USA, but they may be overloaded.</div><div dir="auto"><br></div><div dir="auto">It really is a shot of dopamine when you figure out a bug that is preventing you from proceeding!</div><div dir="auto"><br></div><div dir="auto">Perhaps there should be an “X3D way” for developing in ES.</div><div dir="auto"><br></div><div dir="auto">John</div><div dir="auto"><br></div><div dir="auto"><br></div>