[Vote] Which is your preferred way to use a build tool like shadow-cljs?

Projects shadow-cljs
1
  • Command line directly (eg. shadow-cljs)
  • Custom scripts (scripts/repl.clj, etc)
  • Embedded in other tool (eg. lein)
  • Embedded in Editor/IDE (eg. cursive, cider, …)
  • Other (please comment)

0 voters

Show results

Hello everyone,

I’m very curious about what people think is the best way to use any build tool for ClojureScript. While shadow-cljs supports all the modes listed above I’m beginning to wonder if it would be better for the tool to just run standalone and ignore the embedded option? Tools like lein-figwheel and lein-cljsbuild might suggest that you always run everything via lein but I’m beginning to think that this is not worth the trouble.

I’m torn myself since I’m still using the embedded version in an older project and for shadow-cljs itself (since its a CLJ project).

However the standalone version would enable certain optimizations that can’t be done when running in embedded. They need to mess with the Classloader/Classpath and other things that would potentially “destroy” the Clojure Runtime if used for anything else. The goal would be to enable restart-less changing of dependencies, better startup performance due to AOT and possibly other things. Running CLJS and CLJ separately would potentially also remove a whole bunch of dependency conflicts. Any tool is always going to use some dependency that you might also be using for the CLJ side of things. The CLJS compiler also does not benefit in any way from running alongside your CLJ app. The only thing you gain by running CLJS alongside CLJ is that you can run them in the same REPL but I feel that can be solved by better tool integration. Piggieback/nREPL and switching between CLJ/CLJS REPL is already pretty painful (IMHO).

The status-quo is definitely to use things via lein since Editors/IDEs like Cursive, cider, etc. expect it. They are however mostly built for Clojure and their integration with CLJS often feels second-class IMHO.

I have been toying with this idea of building a GUI for shadow-cljs (CLI interface isn’t going anywhere) since the GUI can simply display information better than a bit of text output in a shell somewhere. Clicking a few buttons or filling out forms is also generally easier than writing a config file by hand.

I think the only reason we are running CLJ/CLJS side-by-side in the same JVM (eg. figwheel, shadow-cljs) is due to developer UX current tools provide. Maybe I’m missing something?

1 Like
2

I have actually found the combination of CLJ/CLJS REPLs very confusing — esp. if the tooling is also a bit rough.

I’d rather have a single REPL that connects me directly to the browser, another for Node, another for JVM. If I have to do this by keeping 3 terminal tabs open, it’s no problem.

A GUI would be interesting but I don’t think it’s needed. A “wizard” a-la “yarn init” or “create-react-app” that asks a few questions and sets up some boilerplate to get you ready to go would be useful though!

2 Likes
3

I mean GUI in the very general sense. It could either be a standalone thing, a web page or something integrated in your Editor/IDE.

I was especially impressed with the configuration process of metabase. See https://www.metabase.com/docs/v0.28.0/setting-up-metabase.html

The command line can never provide this much detail/help and getting your first config up and running can be challenging. I’m not particularly fond of config templates so a GUI could provide an alternative.

The CLI will never go away since its important for automation/shell scripting but I still think that a GUI could provide something useful. It would be a ton of work though.

4

Of course, a GUI would be fantastic — esp. for newcomers to ClojureScript in general. But it would be a ton of work. Actually, it would be a fun side project for someone (or me?), and in the end it’d just have to spit out a shadow-cljs.edn file plus some boilerplate directory structure, right?

5

Yes, maybe you. :wink:

The config generator could certainly be a separate thing, maybe even just a webservice.

The tricky part with editing config files via code is that it is incredibly hard to preserve structure and comments. npm/yarn just work with JSON where this is a bit easier. This is not a problem however if you only edit the config with the GUI or don’t mind that it might destroy your formatting. I’m probably overthinking this …

6