An old talk (2012) so I'm not sure how accurate it is now, but Nolen discusses performance of ClojureScript. At the very least, you know someone cares and is thinking about it.
Can you explain why Om hurts your brain? I've heard other people say similar things, but I've never quite understood why. Is it cursors? Local component state?
OM components are complex. There are global transaction/message channels, component local state, an OO backpane, lifecycle functions, functional zippers, hierarchy organised data, etc. I can't understand how anyone could claim it to be simple.
Look at this example code, apparently held in such high regard that it is referenced off the front page of OM:
https://github.com/swannodette/om-sync
To me that is a ghastly, inexcusably complected hairball.
Don't get me wrong. I really like clojurescript. I program in it daily, on purpose. It is just that I'm shocked at the level of devotion and adulation for OM when there are really lovely alternatives like Reagent and Rum.
Some inaccuracies here about Om. There are no message channels. There are no functional zippers. Component local state and lifecycle are critical React integration points. Hierarchy organized data is not required - people have succeeded at integrating DataScript. om-sync isn't even an official thing, just got tired of people asking me about a basic example :)
If you don't like Om, that's really OK. The real goal of Om was always to inspire people to consider and research alternatives to traditional client-side MVC. 16 months in I would say with the large number of excellent alternatives, Om very much succeeded.
I hope Om Next accomplishes the same broad goal and convinces people to seriously consider the big ideas behind Relay/GraphQL, JSONGraph/Falcor, and Datomic.
No zippers? Why then does the official OM docs say "Cursors are conceptually related to functional lenses and zippers". Remember this thread relates to how simple or easy OM is to grok.
And no message channels? Why then does the intermediate tutorial plunge straight into the use of core.async?
I have no problem with OM being considered a grand experiment. I wouldn't use it but it has been an interesting idea generator. Please remember context here - I was responding to someone who claims astonishment that OM could be considered difficult to understand.
But, in terms of grand experiments, let's remember that Reagent came out at exactly the same time as OM. And Hoplon lead the way on Reative (FRP) long before either. So, having lived through it, I'd feel very uncomfortable with any overreaching claims about OM succeeding in inspiring all the others into the alternative MVC holy land. The others were there already.
I also feel that Om is very complex. I'm sure I've spent over 20 hours trying to wrap my head around it but didn't manage to do anything.
From the people that know it well, they all love it. But I don't seem to have the required knowledge to understand it. I feel somehow dumb by that. The docs aren't good also.
After that, I've tried reagent for 30 minutes and ended up with a lot of progress and I'm currently writing my first cljs small app. Everything seems to work and it's like clojure.
You have an atom and just have to write views in a hiccup style, everything magically works.
Maybe I will try Om later and get it, but it's not simple. I've been able to wrap my head around a lot of concepts with easy in my life, but Om felt too much.
"From the people that know it well, they all love it. But I don't seem to have the required knowledge to understand it. I feel somehow dumb by that."
When I get this feeling, it's often because I haven't yet experienced the problems the new thing is trying to solve. Is it possible Om is an attempt to solve problems you haven't encountered?
I have no personal experience with Clojurescript (love Clojure, though), so this is just a generic comment.
I'm learning clojurescript in addition to (eventually) learning Om. I feel like Om provides you a lower level of abstraction than Reagent which is good for building some complicated web apps. However, as a CLJS beginner, Reagent and the re-frame framework have been easy to dive into.
Pairing with someone who's built a few Om apps should get you up to speed in no more than 45 minutes. I've done it a few times now, and it just takes a few examples, building some components, and composing them together.
I think it's mostly a matter of personal preference. There are multiple React interfaces in ClojureScript: Om, Reagent, Rum, Quiescent being the most popular. Pick whichever you like.
I looked at Om, found it too verbose, and switched to Reagent. I then found it too limiting, so I ended up using Rum, which I think is the most flexible and the most minimalistic. I think it's great that we have the choice and that we can cross-polinate ideas between various libraries.
I use it every day, but there's always some aspect of its behaviour that it turns out I didn't understand the first time round. Perhaps that's because I jumped into the project with only a very rudimentary understanding of Om, just enough to complete a certain ticket. I've since then spent a lot of time going through the docs, but it just conceptually doesn't sit well with my brain. Sorry I can't give a more useful answer. Reagent on the other hand, which I haven't used in production, just "feels" better every time I play with it.
The thing that helped my understanding most was a recent project where I got to work with React directly. Also, reading the source.
So yes, it's mostly because I'm a little lazy, but Reagent doesn't seem to punish me for that same laziness. 😆
While not a specific answer, "feels" is a valid response IMO. Like mentioned elsewhere, using reify seems to throw people off, which falls in to the "feels" category I think.
I think part of the reason some people feel this way about Om is that it was built as an experiment - specifically an experiment about handling immutable state in React.
I find that Om has very strong opinions about doing state the clojure way, but is a very thin wrapper around the rest of React's API - which leads to a feeling of inconsistency.
Some of the stuff David's suggested will be part of "Om next" I think will address this.
The inconsistency part makes sense, I guess I just never thought it was a big deal. If you're going to use WillMount, it's either going to be with reify (Om) or meta (Reagent). Doesn't seem like an important distinction to me, but obviously it is to some people. And that's totally legitimate.
I wouldn't say less smart, it took me some time to get used to reify before feeling comfortable using it too. Think anonymous classes in Java for example, its almost the same thing.
This is not entirely accurate, the ClojureScript compiler actually internally propagates type information for further optimization. And nothing precludes a Typed ClojureScript which feeds even more information to the compiler.
Is your project open source? I'd love to see what you're doing. From my understanding of React/Om, Om shouldn't cause a full re-render if React wouldn't.
The immutability of Om/cljs means that the code for determining re-renders (shouldUpdate lifecycle method) is (always?) faster than React.
I made juice this morning: 2 oranges, 2 kiwi, and 1 grapefruit. Made two cups of juice for my wife and me. I don't know about the science of sugar, but eating 1 orange, 1 kiwi, and half a grapefruit doesn't seem excessive to me.
If you ate the fruit it would be much better for you. Instead you are basically taking something healthy overall, extracting the candy part out, and throwing away the parts that are best for you.
We started drinking juice to replace cereal in the morning and to increase our vegetable intake. This morning, I just happened to only use fruit.
I'd bet that eating the fruit & vegetables would be better. But at this point, neither my wife or I will be eating kale or celery for breakfast. Juicing helps us at least some vegetables in our diet. Baby steps.
If hewere drinking the fruit juice in place of Mountain Dew it might be better, but I doubt he was chugging Mountain Dew for breakfast before he started drinking fruit juice.
The problem is that people think fruit juice is healthy and nutritious, and they aren't aware they should limit consumption.
But if you ate that fruit you'd be full, and thus less likely to eat other stuff.
And that one cup of juice could be swigged down easily. You can see how some people would just pour another glass? (Especially if they think undiluted juice is healthy?)
Would you think that drinking more than 2/3's of a can of Coca Cola every morning would be healthy, if you were to add a bunch of vitamin C and whatever nutrients are present in Kiwi/Grapefruit to go along with it?
>> Ever use a juicer? Think about how many oranges it takes to make an 8 oz. glass. (It takes several, and if you tried to eat that many, you would be full halfway through due to the fiber.)
I was replying to that quote of yours, meaning that it doesn't take an excessive amount of fruit to make 8 oz. of juice.
I admitted that I don't know about the science of sugar, but I have a hard time believing that fresh fruit juice is equivalent to Coca Cola with some vitamins added in.
We won't open source, for a variety of reasons. One reason is that if we serendipitously meet the right dev/hiring manager, we will hire them and revive the project. Secondly, as all bigcos who randomly outsourced a dead project can tell you, OSSing a huge project solves no real problems. Thirdly, neither of us will run an OSS project for it, and fourthly, it's a bit of a beast. You can't just pop Charm on heroku and expect it to run at speed. So, no OSSing.
As for the architecture, it was a Rails app with fully-live Backbone/CoffeeScript UI, a tuned Ruby cron job for scraping mail (POP, IMAP), a Postgres database and I forget which full-text search engine because we must have tried all of them before we settled on one. Nothing terribly fancy.
I understand your hope that you can resurrect the project. I was more interested in OSS for the opportunity to learn through reading the code and looking through your server setup.
Romans 5:8 - But God demonstrates his own love for us in this: While we were still sinners, Christ died for us.
In the Romans verse, it explains that God has shown His love for everyone. He did it without expectations for something in return. He did it for people who couldn't repay Him. He did it for people that were His enemies. This is by definition unconditional and there isn't a single verse in the Bible that contradicts this.
Matthew 23:37 - O Jerusalem, Jerusalem, you who kill the prophets and stone those sent to you, how often I have longed to gather your children together, as a hen gathers her chicks under her wings, but you were not willing.
The Matthew verse shows that this love must be accepted. Jesus says that He wants to show His love in a close relationship, but the expressions of His love are rejected.
That Matthew verse also points to something that is often overlooked/misunderstood about hell. The worst thing about hell is not fire, darkness, demons, etc. The worst and most significant thing about hell is being separated from God. Heaven is where people have reciprocated God's love and experience complete intimacy with Him. Hell is where people have rejected God and experience complete separation from Him. With that understanding, it shows that it makes no sense to say "God sent someone to hell." Hell is the choice of someone that has rejected God's love. God, not being a rapist, does not force anyone to love Him.
>God, not being a rapist, does not force anyone to love Him.
Does anyone else find this quote hilarious? It's like saying "John, not being a rapist, does not force anyone to have sex with him" when the guy's presently in a backalley with his pants down and a knife at some chick's throat. He's not forcing the matter--he'll just kill them if they don't comply. That's clearly still a choice!
(Perhaps this is also why there are never any "legitimate" rapes??)
I think the data you're looking for has to come from having good relationships with your employees. For example, did you know the following about your ex-designer:
1) Is he married or looking to get married?
2) Does he have kids or plan to have them soon?
3) Has he had any serious health issues in his family (e.g. history of heart disease)?
Obviously, those type of questions can get you in trouble if they are asked on an employer->employee basis. But in the course of really getting to know someone, those types of things will come up. It's then on you to think about what you'd want in that situation and do it for them.
So if ex-designer was planning on having kids, you might consider the cost of the family plan and be willing to splurge on that at the expense of the beer and snacks budget (or something focused on single people).
My main problems with employers have been their ignorance and/or lack of concern about what is important to me. I had one company that bragged about fully paying for our health insurance. Well, the owners of the company all had several kids. I didn't even have a girlfriend at the time. Health insurance as a young, healthy, single guy was barely even on my radar. That was easily accessible data (which they had), and yet they didn't act on it at all.
Simply, put yourself in their shoes and ask, "What would I want in this situation?" Considering you were friends with the ex-designer, my thought would be that you could have probably spent more time thinking about what he wanted instead of just asking. For some reason, many people won't speak up about what they want. Many times they themselves don't know until someone shows it to them.
The whole class was about an hour. However, I spent about 20 minutes or so playing a different game which would get the kids excited about robots. I showed them some robots that exist today from current research and I actually had a little robot I made, which started walking when you clap. This way I introduced them the concept of a "brain" or computer residing inside the robot so that it would do stuff if you gave it the right instructions.
http://www.infoq.com/presentations/ClojureScript-Optimizatio...