41–50 of 74 posts
So I've been looking at Elm recently, what would the advantages/disadvantages for something like Elm over Om/Om Next?
Elm's HTML engine conceptually the same as React+Redux and Om Now. It's just a big single atom app state with ways to describe how to update it. It has all the same problems as Om Now (maybe not quite as bad because it doesn't have cursors, but it doesn't solve the data-as-a-graph problem).
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.
Earlier quoted context omitted.
I don't have experience with Om, but another comparable React wrapper in the Clojurescript world is Re-Frame, and it has a top-notch community. The original developers are still active, but there are many new contributors who are adding substantial new features and polish.
It's David Nolen and the way he runs his projects, making people sign Contributor Agreements and such. He wants to remain the BDFL which is fine, his project, but the downside is that people are less enthusiastic to contribute.
Earlier quoted context omitted.
I'd say 90% is pretty good for a single person. Open-source requires a community to work.
It is pretty good, but the community never seems to form. Maybe it is just the lisp NIH culture, maybe it is the way the projects are managed, but either way it doesn't make for production-ready software. You have to be able to support it yourself if you want to use it.
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.
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 trigger re-renders, but the benefits are huge. It's like the difference between using a database and manually managing files on disk for backend code.
My understanding is that Om Next will integrate nicely with Datascript, so you can keep using it once you upgrade.
If you're interested in learning more about building UIs with Datascript, I'm giving a talk on Monday at the datomic/datascript meetup: http://www.meetup.com/sf-datomic-datascript/. I'll be going over Dato (https://github.com/datodev/dato), a framework for building apps like Circle and Precursor.
Can anybody comment on how security is handled in Om? How do you ensure that certain parts of the database (which may depend on complicated rules) are not inadvertently exposed to the client?
In short that's up to the developer. It would be like asking how does Redux handle security? Well it doesn't, it just dispatches an action object to functions, the functions you wrote. Om.next takes code you writes and makes it go.
How does that work if multiple users are collaborating on the same state simultaneously?