can I see the hook code? I mean the hook should run fine for hot-reload stuff

whats the potential gain here? I mean solid is never gonna map quite right to CLJS, so you are just going to fight one footgun after the other?

Sure - the hook code is this one:

(defn babel-compile
  {:shadow.build/stage :compile-finish}
  [build-state]
  (update build-state :output
          (fn [output]
            (->> output
                 (map (fn [[k v]]
                        (if-let [babel (-> v :ns-info :meta :babble/config)]
                          [k (update v :js transform* babel)]
                          [k v])))
                 (into {})))))

Basically, I get the ns metadata to see if I should run babel on it, then I run transform* to transform the source - transform changed a lot, but in a nutshell is a node runtime (provided by Javet) that calls Babel with the shadow compile source code and returns a string with the transformed code

> whats the potential gain here? To explore if there's a way to run Babel in the "middle" of the process - basically, to compile ClojureScript to Javascript+JSX and run Babel to transform that to JS, and that be the final result. Maybe even give some support for this ticket: https://github.com/thheller/shadow-cljs/issues/190

And I'm sure I'll have other footguns, just thinking if there's a way around this - I really wish there was a better way for CLJS to integrate better in the JS world, even though I am well aware how crazy things are with bundlers and compilers and everything else.

BTW, the code that the hook was being applied to is:

(ns babble.core-test
  {:babble/config {:presets ["babel-preset-solid"]}})

(js* "<div>Hello, world</div>")

here I'm trying to get away from the JS world as much as possible and you want to get right back in 😛

hook seems like it should be fine, although you'd probably want to maintain some flag to not run babel when it already ran

:compile-finish is compiled every cycle, so :js will contain the already converted code unless the file itself was recompiled

but regardless, the client should be getting the transformed code

https://github.com/thheller/shadow-cljs/blob/47f3e66ad868a780387f52a739305c9cae3e5671/src/main/shadow/cljs/devtools/server/worker/impl.clj#L740-L769

the client ends up calling this to get the source for the recompiled files

so it just gets the :js basically, which should be the babel'd thing?

btw I have no interest in adding babel support in shadow-cljs itself, so don't plan on working on any PRs or so on that front

happy to add stuff so you can do it in hooks, but no chance of direct integration. babel is an absolute nightmare to work with and maintain

I also don't quite see the point. I mean the transformations done by the JSX translation things are probably not rocket science and could easily be done in a macro, without any babel. just pure CLJ.

javet looks interesting though, never seen that before

Ok, I imagined you didn't want to add Babel support - I'm completely fine with it, and I'm glad you consider adding stuff on hooks so that I can try something 👍. I'll try to do stuff in hooks, make a branch, and if things don't work out I'll update here

BTW, the point is that some tools transform JSX in a different way. Solid claims that it detects "static things" and "dynamic things" in JSX and compile everything to optimize the end Javascript code. These claims seems to be backed by third-part benchmarks too, so I'm curious if I can, let's say, have my (solid) cake and eat it too...

FWIW these benchmark numbers are with extremely basic optimizations https://github.com/thheller/js-framework-shadow-grove#light

I'm sure with some time invested it is possible to be even more on par with solid, with just pure CLJS

so I never saw the draw to adopt the JS-framework-of-the-day if we can do things just as well in CLJS ourselves 😛

> Solid claims that it detects "static things" and "dynamic things" in JSX

is absolutely trivial in CLJS and grove does it too 😉

FWIW DOM libs are all fast enough, even react. what matters more is how you handle data and how precise updates can be, so nothing any of the raw DOM libs cover. unfortunately something most benchmarks skip entirely.

yeah import isn't allowed to be added dynamically by hooks and really can't be made to work since at the stage it is at :compile-finish the set of compiled sources is final