Fork me on GitHub

clojurescript was superior to javascript at the time it was created


however, as of today, poor integration with the js environment is the biggest crutch


i have the dubious pleasure of writing frontend in typescript on a daily basis and it is better than i expected it to be, however the biggest drawback is writing tsx. hiccup is the most convenient way to write ui

👍 1
respatialized15:08:15 Not sure if you've seen this project, but a hiccup syntax for HTML with typechecking seems pretty useful. Wish the hiccup convention were more widespread!

👍 1

By the way, the loss of Karsten Schmidt to typescript is an irreparable loss for the clojure community

😢 1

is a one-man army


A lisp modeled after clojure, integrating better with the js ecosystem including async/await and allowing to write macros is 110% of what I dream of


@huxley cherry already supports those

❤️ 2

that's why I'm here and getting excited 🙂

🎉 2

PSA: the JSX in cherry is currently a quick hack that doesn't work properly. It needs better integration throughout the compiler and I'll work on this in the coming time (to both support it in cherry and #clavascript)


I want a REPL and hot-reload 😄. When these two appear, it's quite possible I'll start building things in Cherry, even if it's unstable/alpha honestly 😄

💯 2

BTW, how far are we from these two targets? Also, do you think there'll be an "watch" mode like Shadow-CLJS, where hot-reload works, etc?


@mauricio.szabo Me too :) But hot-reload tbh is already supported by JS frameworks. You can try the vite example for example


It depends on your use case. For browser, hot reloading is already taken care of by the JS tooling


Note that the JSX stuff is currently broken (just a prototype) but there's also a React example which a createElement macro


Yeah, but my hot-reloadings are weird 😄. Shadow makes it extremely easy to handle the cases, but when I searched for JS tooling that do the same, they all need my app to be "aware" that it'll be reloaded, which is not ideal...


Roadmap-ish idea: • Extract common code from cherry and clavascript • Make JSX work in common compiler code so both clava and cherry will benefit • Solve the macro problem. Still need to figure some things out there (support JVM compile time or only JS) • Focus on REPL experience / hot reloading

👍 3

I will also start using it in earnest once there's an nREPL situation 🙂


Will it support eval and macros?


@didibus cherry already supports macros, but how it works will likely change. eval: the compiler should be available as a library in both JS and JVM so this is how you can get eval : you will pay the cost of bringing in the whole compiler though


I'm thinking along the lines of people asking for REPL support and hot-reload.


I would want that from the REPL, I can also define macros and maybe run eval, ideally, similar to self-hosted cljs REPLs. That gives you the full Clojure REPL feel.


But like you said, probably beyond REPL, I would not want to include the compiler itself in the output.


You can also do this with scittle and nbb today btw


But it's not as easy to pull this off with a compiler compared to an interpreter. In self-hosted you can't define macros in the REPL I think


I've defined macros in the REPL with self-hosted clojurescript.


But, I use an Android app called Replete, which uses self-hosted ClojureScript to give you a ClojureScript repl on Android, so maybe it does some more shenanigans on top to allow me to define macros, not sure.


> Self-hosted CLJS is capable of compiling CLJS at runtime and does support macros but requires at least 2MB of JS so it isn’t practical for most build targets.


> support JVM compile time or only JS You meant, define macros in JVM thing, to keep the same semantics as ClojureScript have today, or move all to CLJS only?


yes. the compiler also currently works in babashka, which may be nice to preserve


except macros don't, they are assumed to be ran inside JS now (first compiled to JS code), which wont' work currently with bb or JVM