Perhaps, you should ask a question, why didn't the author reverse the question? Something like "How on earth was my implementation in a JITed language 50x slower on a warmed-up benchmark?" Where is the output of the profiler showing the exact bottlenecks? Of course, you can look at the repo and deduce some stuff, but it is a good habit to mention some key points about the environment such as compiler/ language/ browser versions, compiler settings, the hardware used etc.
Could he use more appropriate data structures? Could he avoid all the schema stuff that doesn't really improve the readability? Could he use better data structures later avoiding slow functions like update-in and migrating the bottlenecks to transducers and transients perhaps?
The author just did a rewrite and that is totally ok. He is trying things out and that is also quite alright. He provided some rather high-level benchmarks that would be really time consuming the reproduce and explain in more detail.
To summarize, good that @sickill got a discussion going but it is best to step back and think about it in more depth. We all should apply more of this "extraordinary claims require extraordinary evidence" https://en.wikipedia.org/wiki/Sagan_standard
Yes, it is his free time and good explanations/ understanding take time. We should treat the blog entry accordingly. It is a good exercise in critical thinking and code review, if you actually take the time to at least run through the code briefly.
Performance was not his only pain point. He also had issues integrating with the JS ecosystem. IMO Clojurescript is not worth extra layer of complexity.
We are using shadow-cljs https://github.com/thheller/shadow-cljs and that integrates with npm just fine. It doesn't get much easier than that I guess and if you have trouble, you can contact Thomas Heller or other people on the Clojurians Slack-channel.
If I did any app or system, that could be written in Java or JavaScript (browser or Node.js) I would take Clojure or ClojureScript any day. I don't know how to match the comfort and power in a different language. If it turned out e.g. by using a profiler, I just need way better performance in some bottlenecks and after I have exhausted all options that a) a better algorithm b) better technology/ different approach such as Canvas/ WebGL you name it in addition to what Clojure(Script) performance features offer, I would perhaps consider learning to write a module in Rust/ WebAssembly or just use a bit more resources (if this was e.g. a money problem).
Besides embedded, really high-performance stuff, some parts of the infrastructure that need to be as efficient as possible or run without GC or need to talk to very special interfaces or a library, Clojure and ClojureScript or related dialects/ implementations are suited for pretty much everything else I can think of.
We should be thinking about how to implement a Clojure-like language in more places, perhaps even without a GC but with AOT compilation + interpreter for the REPL along the way of Babashka. We should explore how to have a REPL to multiple systems at once and handle them like it was a single machine to some degree. We should be thinking, how to make a running Clojure program interruptible easily (perhaps with an extra setting), like it was a program in the shell. We should think about adding a Clojure-like language to the browser natively so that programs don't have to load it like they do now and that a browser tab could have some kind of REPL that you could authenticate and connect to over a socket. That way, you could rewrite the code of the web app at runtime if allowed by the user.
And we definitely should design more APIs in much simpler way working more with data and less with invoking some specific functions. E.g. browser "history" could just be a vector/ array of maps/ objects or whatever instead of some finicky getters and setters that obscure the problem and are just another thing you have to learn to do useful work.
Could he use more appropriate data structures? Could he avoid all the schema stuff that doesn't really improve the readability? Could he use better data structures later avoiding slow functions like update-in and migrating the bottlenecks to transducers and transients perhaps?
The author just did a rewrite and that is totally ok. He is trying things out and that is also quite alright. He provided some rather high-level benchmarks that would be really time consuming the reproduce and explain in more detail.
We have looked at the cljs code (e.g. https://github.com/asciinema/vt-clj/blob/master/src/asciinem...) with my colleague and it definitely isn't the best possible Clojure(Script) code around from a readability nor it seems performance standpoint.
To summarize, good that @sickill got a discussion going but it is best to step back and think about it in more depth. We all should apply more of this "extraordinary claims require extraordinary evidence" https://en.wikipedia.org/wiki/Sagan_standard Yes, it is his free time and good explanations/ understanding take time. We should treat the blog entry accordingly. It is a good exercise in critical thinking and code review, if you actually take the time to at least run through the code briefly.