I have this Scala fileobject-literal.scala :

//>usingscala3.4.2//>usingjsVersion1.16.0//>usingjsModefull//>usingjsModuleKindes//>usingdeporg.scala-js:scalajs-library_2.13:1.16.0importscala.scalajs.js.annotation.*importscala.scalajs.js@JSExportTopLevel("testObj1")valtestObj1= js.Dynamic.literal(a=1, b=2)@JSExportTopLevel("testObj2")valtestObj2=new js.Object:vala=1valb=2

and compile it using Scala CLI version: 1.4.3:

scala-cli --power package --js -f object-literal.scala

The relevant generated js output (formatted using prettier):

function$c_Lobject$minusliteral$package$(){$n_Lobject$minusliteral$package$=this;$t_Lobject$minusliteral$package$__testObj1=$m_sjs_js_special_package$().ar($m_sr_ScalaRunTime$().az(new($d_T2.r().C)([new$c_T2("a",1),new$c_T2("b",2)])));$t_Lobject$minusliteral$package$__testObj2=(()=>{varthis$6={};this$6.a=0;this$6.b=0;this$6.a=1;this$6.b=2;returnthis$6;})();}

I assume that using above scala-cli configuration, all available optimizations are applied to compiling and linking the code.
But no object literal was generated, as stated in the docs. Instead, a pretty complex expression is emitted.

Using an anonymous js.Object instance as intestObj2 comes closer to a native object definition.

Background: Seeing how easy it is to compile scala to js using scala-cli, I was hoping to develop a concise and lightweight DSL with scala.js on top of an audio processing library using a verbose js API, and to use this DSL alongside the rest of a js/ts codebase. But seeing that js.Dynamic.literal - which would be needed a lot - is emitting pretty complex code, i am worrying about too much overhead with such a solution.