does anyone know how challenging it is to add Datomic subscriptions to Om Next?
Why We Use Om, and Why We’re Excited for Om Next
71–74 of 74 posts
Re: Why We Use Om, and Why We’re Excited for Om Next
#72I was the main author of Circle's frontend (the code is open-source: https://github.com/circleci/frontend ). I went on to build Precursor ( https://precursorapp.com ), which uses Datascript ( https://github.com/tonsky/datascript ) to accomplish a lot of the things that Om Next promises. If you haven't tried Datascript, you should really take a look! It does require a bit of work to make datascript transactions trigge…
Re: Why We Use Om, and Why We’re Excited for Om Next
#73I am surprised their backend is written in closure. I would think it make hiring developers much harder (smaller group of people know it) and training people a lot harder. You can jump on to a project and learn enough go to fix bugs in a day or so (less than a week for sure). I am not sure the same could be said about closure.
It definitely did not make hiring harder. In fact, it was probably easier, because at the time, Clojure was more unique. The people interested in working in rare languages tend to be above average. Also, I would avoid optimizing TTFBugFix the wrong way. You want the system to be easy to fix because it's well designed & documented, not because it's written in a language you already know.
Re: Why We Use Om, and Why We’re Excited for Om Next
#74Earlier quoted context omitted.
It definitely did not make hiring harder. In fact, it was probably easier, because at the time, Clojure was more unique. The people interested in working in rare languages tend to be above average. Also, I would avoid optimizing TTFBugFix the wrong way. You want the system to be easy to fix because it's well designed & documented, not because it's written in a language you already know.
What characteristics about these people makes them above average? I need some goals to set my sights on :)