Live data from Hacker News

Why We Use Om, and Why We’re Excited for Om Next

blog.circleci.com

71–74 of 74 posts

Re: Why We Use Om, and Why We’re Excited for Om Next

#71

does anyone know how challenging it is to add Datomic subscriptions to Om Next?

This is pretty easy, because Om Next is low level and by design it can integrate into any back end. However, there is very little "hand holding" right now and it can be daunting to understand exactly how to do it.

Re: Why We Use Om, and Why We’re Excited for Om Next

#72

I 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…

Exciting. Are you plan on recording the meetup? Cuz that would be awesome :)

Re: Why We Use Om, and Why We’re Excited for Om Next

#73
post #32

I 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.

What characteristics about these people makes them above average? I need some goals to set my sights on :)

Re: Why We Use Om, and Why We’re Excited for Om Next

#74
post #32

Earlier 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 :)

Intellectual curiosity, and a desire to experiment with new languages to be more productive/write cleaner code.
Post reply on HN