31–40 of 74 posts
So I've been looking at Elm recently, what would the advantages/disadvantages for something like Elm over Om/Om Next?
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.
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.
The new plan sounds a lot like Redux.
It's pretty different. It's not flux or flux-like. And almost every Redux example or tutorial does use ES6 or more. As far as the platform, I had an easier time learning ClojureScript and Leiningen than Gulp/Webpack/Babel. Not saying that Redux isn't easier, though. It's very nice.
The new plan sounds a lot like Redux.
No, Redux is far more like Om Now. In fact, Om Now was one of the early influencers for the single atom app state idea. The only difference is that, instead of using cursors, Redux uses flux-style actions for mutations. You select data from the app state by digging into the app state manually, exactly like you would in Om Now. It's a common misconception (I fell for this too) that simply having a single atom app stat…
Earlier quoted context omitted.
No, Redux is far more like Om Now. In fact, Om Now was one of the early influencers for the single atom app state idea. The only difference is that, instead of using cursors, Redux uses flux-style actions for mutations. You select data from the app state by digging into the app state manually, exactly like you would in Om Now. It's a common misconception (I fell for this too) that simply having a single atom app stat…
Om's "parser" and query syntax seems to decouple state read/writes from components in the same way that action creators do, with similar benefits. Reading through Om.next didn't change that impression, is there any other resource I should look at?
Not sure what else to say, actions and queries are completely different things.
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 don’t think the last part is true. Browsers don’t repaint (nor they reflow) the page until it’s really needed. So if you have a loop that modifies the DOM multiple times, but does not read from the DOM, there performance hit described by the author should not occur.
Earlier quoted context omitted.
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 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.
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?
Om.next takes code you writes and makes it go.