6 ms·

Since this thread/Clojurescript is getting some love I'd like to express something to a hopefully receptive audience: There was a point where Clojurescript and

Since this thread/Clojurescript is getting some love I'd like to express something to a hopefully receptive audience: There was a point where Clojurescript and Javascript sort of walked hand-in-hand during the advent of when React started to make sense in the minds of the community[0]. It felt really exciting because of the cross pollination that was happening between the two languages, Redux felt very familiar, and we have re-frame for clojurescript. There was a ton of promise with Apollo.js and an improvement on the `connect` functionality by upgrading to a proper query language for getting state into a component versus wrapping functions around multiple `state.some.path` `state.some.other.path`. David Nolen built om.next around that very idea, it was basically Apollo.js lite, and it was very exciting scientifically but never quite caught on because maybe it was a little clunky. But using datomic pull query syntax to fetch state for use in a component was thrilling. (if you got this far and decided you hate me and your eyes are rolling so hard I get it lol) And this was all years ago now. All that excitement and progress and effort seems to have been trapped inside of Typescript, and React hooks, and did everyone forget? 0: https://swannodette.github.io/2013/12/17/the-future-of-javascript-mvcs/ https://swannodette.github.io/2013/12/17/the-future-of-javas...

frankiesardo 5y ago
Fulcro is getting a lot of love lately and a passionate community of users around it. So no, it's not forgotten, just migrated https://book.fulcrologic.com https://book.fulcrologic.com
- knubie 5y ago
  Just to add some context for the OP, Fulcro is kind of an evolution on om.next.
  - iLemming 5y ago
    AFAIK, albeit it was initially based on the ideas implemented in Om.Next, modern versions of Fulcro are very different today. I think Om.Next was just a collection of a few, rather conceptual, abstract objectives, quite experimental (perhaps even ahead of their time) and untested in production. Too bad that Cognitect couldn't give David Nolen a carte-blanche and let him work on it 100% of his work time. I'd rather live in a world where libraries like Om.Next become popular, and not stuff like Angular. ps.: I used Angular. And I loved it. Angular made sense. Sometime around 2009-2010. But it stopped making sense. And I stopped liking it. You still can build awesome things with it, and people still do. And I still don't like it.
frankiesardo 5y ago
Also: cross pollination is still happening as libraries like Recoil implement some of the ideas sitting in Reframe for vanilla React. On the ClojureScript side, I would like to see more projects integrating with platforms like Nextjs and Gatsby.
- adamkl 5y ago
  There is nothing that says ClojureScript can’t be used on the server side and integrate with the platforms you mentioned. It’s likely just a matter of writing wrapper libraries similar to what was done for many Java libraries. The hard part is that most Clojure devs default to using the JVM server side so there’s not much appetite there to do the work to embrace JS server side frameworks.
  - frankiesardo 5y ago
    It's actually a bit more convoluted because of how these frameworks compile JS into various artefacts https://clojureverse.org/t/creating-websites-with-shadow-cljs-gatsby-or-next-js/2912 https://clojureverse.org/t/creating-websites-with-shadow-clj... But you're right, for most "serious" projects, people tend to reach for the JVM. Yet, I think a strong ClojureScript presence on the JAMstack would benefit beginners a lot.
pandeiro 5y ago
My impression is that CLJS, while an amazing way to write frontends with react, suffered from an incomplete/fractured tooling ecosystem, with the official maintainers leaning on the community to develop the 'batteries' and several good but incomplete and unofficial solutions being offered (lein-cljsbuild, figwheel, boot, etc). I'm not actively involved with CLJS development anymore but last I checked that still continued, with tools like figwheel/deps.edn/shadow-cljs all sort of doing similar things differently, and there being good-but-not-as-good-as-clojure support in different editors like emacs, intellij and vscode. Similarly, there were a number of different, but still alpha quality ways, to use cljs with react native, all suffering from some major pain points.
- frankiesardo 5y ago
  I shared a similar opinion a while ago, but lately (last two years perhaps?) the general consensus is pretty much shadow-cljs which has stellar support for node modules. shadow-expo also integrates with RN effortlessly. Cursive is really good at handling cljs too, with jump-to-definition and refactoring without using a REPL
  - pandeiro 5y ago
    Do you know if shadow-cljs support source maps for React Native? (Their absence was a really significant pain point when I worked on a production CLJS/RN app.)
    - raspasov 5y ago
      You need two source maps: one produced by ClojureScript and one produced by RN Metro. When you get an error with a stack trace from RN, you need to walk the source maps in the correct order to find where the error in the CLJS code originated. I wrote some custom code to do this but I haven’t polished it/made it into a lib at this point.
      - pandeiro 5y ago
        Sure, I understand. But that's several orders of magnitude less useful than what one gets in eg the chrome devtools console from a CLJS webapp. I found this to be a major timesink when debugging things, and never came up with a good bulletproof solution to automate this traversal. It was especially painful with random breakages due to NPM's automatic dependency/transitive dependency upgrades due to version ranges (ie, things that don't just fix themselves by checking out a previous known good version).
city41 5y ago
I never did try om.next, but to this day Reagent is my favorite way to interact with React. I too was hopeful ClojureScript would become more mainstream. I haven't coded in Clojure in years now because unfortunately I just don't see any companies I did or would work for ever adopting it.
brundolf 5y ago
I don't have any specific knowledge of the community dynamics you're talking about, but I have opinions about these technologies, and can speculate: Personally I find it harder and harder these days to justify writing code that doesn't have static types. Even for personal projects, if I'm writing more than 100 lines, I want editor checks and standardized documentation. Particularly when I'm not doing anything wildly novel, and particularly (but not exclusively) for larger projects. It's not hard for me to imagine industry reaching a similar conclusion, especially when the novelty of most of the web apps being cranked out tends to be lower, and the scale tends to be larger. And where industry goes, hobbyists tend to go so that they get to put relevant stuff on their resume (not to mention paid employees who release in-house tooling and libraries as open source).
- ledauphin 5y ago
  this rings pretty true to me. I have a whole host of reasons for wishing I could switch our group into the Clojure ecosystem, but a huge thing holding me back is not feeling confident that I understand how spec 2 would help us efficiently solve the documentation and pre-runtime correctness verification problems that static typing (Flow and typescript and mypy) give us.
  - slifin 5y ago
    Spec isn't directly for static analysis Spec is for specification which can be used for more things than precompile problem checking Clj-kondo is for precompile static analysis that also supports minimal typing
robertlagrant 5y ago
I remember the original Om already being really exciting.

frankiesardo 5y ago

Fulcro is getting a lot of love lately and a passionate community of users around it. So no, it's not forgotten, just migrated https://book.fulcrologic.com https://book.fulcrologic.com

knubie 5y ago
Just to add some context for the OP, Fulcro is kind of an evolution on om.next.
- iLemming 5y ago
  AFAIK, albeit it was initially based on the ideas implemented in Om.Next, modern versions of Fulcro are very different today. I think Om.Next was just a collection of a few, rather conceptual, abstract objectives, quite experimental (perhaps even ahead of their time) and untested in production. Too bad that Cognitect couldn't give David Nolen a carte-blanche and let him work on it 100% of his work time. I'd rather live in a world where libraries like Om.Next become popular, and not stuff like Angular. ps.: I used Angular. And I loved it. Angular made sense. Sometime around 2009-2010. But it stopped making sense. And I stopped liking it. You still can build awesome things with it, and people still do. And I still don't like it.

frankiesardo 5y ago

Also: cross pollination is still happening as libraries like Recoil implement some of the ideas sitting in Reframe for vanilla React. On the ClojureScript side, I would like to see more projects integrating with platforms like Nextjs and Gatsby.

adamkl 5y ago
There is nothing that says ClojureScript can’t be used on the server side and integrate with the platforms you mentioned. It’s likely just a matter of writing wrapper libraries similar to what was done for many Java libraries. The hard part is that most Clojure devs default to using the JVM server side so there’s not much appetite there to do the work to embrace JS server side frameworks.
- frankiesardo 5y ago
  It's actually a bit more convoluted because of how these frameworks compile JS into various artefacts https://clojureverse.org/t/creating-websites-with-shadow-cljs-gatsby-or-next-js/2912 https://clojureverse.org/t/creating-websites-with-shadow-clj... But you're right, for most "serious" projects, people tend to reach for the JVM. Yet, I think a strong ClojureScript presence on the JAMstack would benefit beginners a lot.

pandeiro 5y ago

My impression is that CLJS, while an amazing way to write frontends with react, suffered from an incomplete/fractured tooling ecosystem, with the official maintainers leaning on the community to develop the 'batteries' and several good but incomplete and unofficial solutions being offered (lein-cljsbuild, figwheel, boot, etc). I'm not actively involved with CLJS development anymore but last I checked that still continued, with tools like figwheel/deps.edn/shadow-cljs all sort of doing similar things differently, and there being good-but-not-as-good-as-clojure support in different editors like emacs, intellij and vscode. Similarly, there were a number of different, but still alpha quality ways, to use cljs with react native, all suffering from some major pain points.

frankiesardo 5y ago
I shared a similar opinion a while ago, but lately (last two years perhaps?) the general consensus is pretty much shadow-cljs which has stellar support for node modules. shadow-expo also integrates with RN effortlessly. Cursive is really good at handling cljs too, with jump-to-definition and refactoring without using a REPL
- pandeiro 5y ago
  Do you know if shadow-cljs support source maps for React Native? (Their absence was a really significant pain point when I worked on a production CLJS/RN app.)
  - raspasov 5y ago
    You need two source maps: one produced by ClojureScript and one produced by RN Metro. When you get an error with a stack trace from RN, you need to walk the source maps in the correct order to find where the error in the CLJS code originated. I wrote some custom code to do this but I haven’t polished it/made it into a lib at this point.
    - pandeiro 5y ago
      Sure, I understand. But that's several orders of magnitude less useful than what one gets in eg the chrome devtools console from a CLJS webapp. I found this to be a major timesink when debugging things, and never came up with a good bulletproof solution to automate this traversal. It was especially painful with random breakages due to NPM's automatic dependency/transitive dependency upgrades due to version ranges (ie, things that don't just fix themselves by checking out a previous known good version).

city41 5y ago

I never did try om.next, but to this day Reagent is my favorite way to interact with React. I too was hopeful ClojureScript would become more mainstream. I haven't coded in Clojure in years now because unfortunately I just don't see any companies I did or would work for ever adopting it.

brundolf 5y ago

I don't have any specific knowledge of the community dynamics you're talking about, but I have opinions about these technologies, and can speculate: Personally I find it harder and harder these days to justify writing code that doesn't have static types. Even for personal projects, if I'm writing more than 100 lines, I want editor checks and standardized documentation. Particularly when I'm not doing anything wildly novel, and particularly (but not exclusively) for larger projects. It's not hard for me to imagine industry reaching a similar conclusion, especially when the novelty of most of the web apps being cranked out tends to be lower, and the scale tends to be larger. And where industry goes, hobbyists tend to go so that they get to put relevant stuff on their resume (not to mention paid employees who release in-house tooling and libraries as open source).

ledauphin 5y ago
this rings pretty true to me. I have a whole host of reasons for wishing I could switch our group into the Clojure ecosystem, but a huge thing holding me back is not feeling confident that I understand how spec 2 would help us efficiently solve the documentation and pre-runtime correctness verification problems that static typing (Flow and typescript and mypy) give us.
- slifin 5y ago
  Spec isn't directly for static analysis Spec is for specification which can be used for more things than precompile problem checking Clj-kondo is for precompile static analysis that also supports minimal typing

robertlagrant 5y ago

I remember the original Om already being really exciting.