Predominantly JVM code?

[evbo]

Hi,

I've been working in ScalaJS projects since 2018. I love it, but the pain points I've noticed is like with any transpiler: compilation time.

One of the most unique benefits to ScalaJS is the access to Scala's awesome macros and the holy grail: JVM code reuse via cross building, enabling far greater automation and verification, plus JVM unit tests run in the blink of an eye with zero compilation time.

So this brings me to my question... How does Laminar feel about 99.99% JVM codebase? What if all js types were converted to JVM types (or generics) where possible? Could the event system be emulated in a pure JVM test fixture? Could my components mostly exist in the JVM?

I have done this successfully with ScalaJS frameworks like Slinky, where my (hooks) are simply calling JVM functions to where only views (div and other tags) live in the ScalaJS code. However, due to the frameworks, it's always been an uphill battle trying to get more code in the JVM. I've also implemented awful JVM-based test fixtures that emulate React events: storing state in hashmaps that reference when they should fire updates based on the React hooks that depend on them (using scala reflection to determine dependencies at compile-time).

This has always stuck out to me as so valuable, how does this community feel about JVM-driven JS? Only using JS types when dictated by 3rd party libraries or for handling HTML events/etc? What might be holding this approach back?

[raquo]

In my personal experience Scala.js compiler is pretty fast for incremental updates, it's the webpack stage that takes up the most time. Somehow it got worse in the last couple years (not specific to Laminar), but I'm not sure if that's due to newer versions, or something with my hardware (SSD fragmentation, CPU sidechannel attacks mitigation, etc.). That's for compiling the runtime bundle. I forget if webpack is used for running scala.js tests or not, but if it is, switching to a faster bundler such as vite might help.

Either way, compilation time isn't something that we can fix at Laminar level. Laminar code is simple with no macros and very few implicits. It's up to the platform and the hardware to efficiently compile that.

Rearchitecting Laminar to run on the JVM would be very hard, and would introduce a lot of user-visible complexity.

Laminar components need access to the DOM. In node.js world, this can be emulated by jsdom, a project that is orders of magnitude bigger than Laminar. Emulating the DOM properly in the JVM would take a similar effort. Creating macros that would translate JVM code written against that emulator into code written against scala-js-dom interfaces would take yet more work.

And in the end, you will still have a bunch of subtle differences between JVM and JS environments that you can't test for (because you're running tests on the JVM) – those will only creep up in production.

And we didn't even touch on Airstream. It's a very small and simple streaming / state propagation library. It can be such, precisely because it doesn't care about the JVM. It has no backend features like backpressure or multithreading support. If it were made to run on the JVM, people would start using it on the JVM and asking for those kinds of things, and adding all that would turn it into a huge complicated library.

The only part of Laminar that readily runs on the JVM is Scala-DOM-Types. So if someone wanted to generate some HTML code on the JVM using those types, they could do that (although with considerably more setup code than if they used ScalaTags). Maybe I'll make a small static site generator based on that idea some day (or maybe not).

So, even though this is surely not the answer you were hoping for, I hope that you can see how this approach is just not feasible.