5 ms·

We use pedestal+fulcro3+pathom om.next was before that, but it seems to be almost abandoned, also fulcro author have solved a lot of depressing pain points of

We use pedestal+fulcro3+pathom om.next was before that, but it seems to be almost abandoned, also fulcro author have solved a lot of depressing pain points of om.next. Those three work like a perfect Lego.

lgessler 7y ago
I'm thinking of writing a project with a similar stack, is there any chance your code is open source? Also, what's your experience with Fulcro been like? Do you have any thoughts about it in comparison with other Clojure SPA libraries like re-frame?
- juskrey 7y ago
  Projects are closed source, so I can share only some general architectural examples. Experience was like.. two weeks of hair pulling, gallons of coffee and no weekends, followed by intense relief and gratitude to fulcro author Tony Kay (also pathom author Wilker Lúcio) for all that not always obvious things which make great sense in the long run. This happened to me with several great Clojure things, so I immediately knew good experience was just around the corner. Oh and his online book http://book.fulcrologic.com/ http://book.fulcrologic.com/ has great general SPA insights. Three pretty serious apps with fulcro so far.
kccqzy 7y ago
We used om before om.next was a thing (back in 2014). Seeing the abandoned state of om and om.next and how it even had trouble keeping up with the latest React releases, and after maintaining a fork for a few months we switched to TypeScript. Burned once; not again.
mnm1 7y ago
What made you choose pedestal over compojure/compojure-api or other alternatives? Similarly, why fulcro3 over something like reagent/re-frame. I have used the latter choices and am considering switching for the my next project.
- juskrey 7y ago
  I was mostly ok with compojure, but ring was driving everyone mad for big applications with lots of wrappers and handlers, with exploding complexity as APIs grew. Pedestal, on the other hand, is offering compact single data structure with linear complexity increase, plus very neat async functionality out of the box. As for fulcro3, I have chosen it first because it was kind of successor of om.next, and in om.next I was in love with its transactional data model and all that pull syntax, - fulcro3 turned out to be even better with that. I was and am still using reagent for simpler setups, but query language and transactions is what helps to keep sanity with larger projects.

lgessler 7y ago

I'm thinking of writing a project with a similar stack, is there any chance your code is open source? Also, what's your experience with Fulcro been like? Do you have any thoughts about it in comparison with other Clojure SPA libraries like re-frame?

juskrey 7y ago
Projects are closed source, so I can share only some general architectural examples. Experience was like.. two weeks of hair pulling, gallons of coffee and no weekends, followed by intense relief and gratitude to fulcro author Tony Kay (also pathom author Wilker Lúcio) for all that not always obvious things which make great sense in the long run. This happened to me with several great Clojure things, so I immediately knew good experience was just around the corner. Oh and his online book http://book.fulcrologic.com/ http://book.fulcrologic.com/ has great general SPA insights. Three pretty serious apps with fulcro so far.

kccqzy 7y ago

We used om before om.next was a thing (back in 2014). Seeing the abandoned state of om and om.next and how it even had trouble keeping up with the latest React releases, and after maintaining a fork for a few months we switched to TypeScript. Burned once; not again.

mnm1 7y ago

What made you choose pedestal over compojure/compojure-api or other alternatives? Similarly, why fulcro3 over something like reagent/re-frame. I have used the latter choices and am considering switching for the my next project.

juskrey 7y ago
I was mostly ok with compojure, but ring was driving everyone mad for big applications with lots of wrappers and handlers, with exploding complexity as APIs grew. Pedestal, on the other hand, is offering compact single data structure with linear complexity increase, plus very neat async functionality out of the box. As for fulcro3, I have chosen it first because it was kind of successor of om.next, and in om.next I was in love with its transactional data model and all that pull syntax, - fulcro3 turned out to be even better with that. I was and am still using reagent for simpler setups, but query language and transactions is what helps to keep sanity with larger projects.