5 ms·

> ClojureScript is not that easy to integrate with the JS ecosystem. I know, there’s been a lot of improvements done in this space over the years, and I’m sure

> ClojureScript is not that easy to integrate with the JS ecosystem. I know, there’s been a lot of improvements done in this space over the years, and I’m sure someone will immediately point me to relevant docs, but it’s still the extra mile you need to go when compared to regular JS codebase This always kills me. Clojure(script) is one of the neatest languages I've ever used, but it is just such a pain to work with. I spent hours getting NPM imports working in a project, when it ought to take seconds. It really makes it hard to recommend, even though the language itself is amazing.

jaxn 5y ago
I have also spent hours getting npm packages to work in JS before.
Cthulhu_ 5y ago
I just wonder why not just write straight JS? Adding a layer on top just means you have more complexities and steps to worry about. And clearly, in this case it was a big compromise in terms of performance and bundle size.
- keymone 5y ago
  You'd have to torture me before I would make a conscious choice to pick JS over Clojure.
  - michaelcampbell 5y ago
    It sounds like that's exactly what happened to the GP.
    - keymone 5y ago
      GP didn’t pick JS for a rewrite either, so yes, I’m pretty sure GP is with me on that.
      - xfer 5y ago
        Yes they did, maybe take a look at the repo, the core vt layer is rust everything around it is in js(it's not cljs, you might ponder why not).
        keymone 5y ago
        Well sure, but the important parts aren’t in JS. I can understand the argument that to provide npm library you may need to touch that garbage of a language, I’m just happy others do it for me.
        xfer 5y ago
        The entire project used to be cljs, so obviously it's done on purpose, that is stated in the article.
        keymone 5y ago
        what is done on purpose?
- Scarbutt 5y ago
  Yep, the author learnt their lesson. I bet they won't be using cljs again, not even for non-performant apps.
  - kaliszad 5y ago
    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. We have looked at the cljs code (e.g. https://github.com/asciinema/vt-clj/blob/master/src/asciinema/vt/screen.cljc 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 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.
    - Scarbutt 5y ago
      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.
      - 5y ago
nojito 5y ago
Fable is becoming the best way to compile to JS. https://fable.io/ https://fable.io/

jaxn 5y ago

I have also spent hours getting npm packages to work in JS before.

Cthulhu_ 5y ago

I just wonder why not just write straight JS? Adding a layer on top just means you have more complexities and steps to worry about. And clearly, in this case it was a big compromise in terms of performance and bundle size.

keymone 5y ago
You'd have to torture me before I would make a conscious choice to pick JS over Clojure.
- michaelcampbell 5y ago
  It sounds like that's exactly what happened to the GP.
  - keymone 5y ago
    GP didn’t pick JS for a rewrite either, so yes, I’m pretty sure GP is with me on that.
    - xfer 5y ago
      Yes they did, maybe take a look at the repo, the core vt layer is rust everything around it is in js(it's not cljs, you might ponder why not).
      - keymone 5y ago
        Well sure, but the important parts aren’t in JS. I can understand the argument that to provide npm library you may need to touch that garbage of a language, I’m just happy others do it for me.
        xfer 5y ago
        The entire project used to be cljs, so obviously it's done on purpose, that is stated in the article.
        keymone 5y ago
        what is done on purpose?
Scarbutt 5y ago
Yep, the author learnt their lesson. I bet they won't be using cljs again, not even for non-performant apps.
- kaliszad 5y ago
  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. We have looked at the cljs code (e.g. https://github.com/asciinema/vt-clj/blob/master/src/asciinema/vt/screen.cljc 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 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.
  - Scarbutt 5y ago
    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.
    - 5y ago

nojito 5y ago

Fable is becoming the best way to compile to JS. https://fable.io/ https://fable.io/