zlacker

>>nathan+(OP)
I don’t want to be a party pooper, but from my very cursory look at the page, I don’t think this will go much farther than a very small community. I feel like you’re adding a lot of complexity compared to normal backhand/frontend/websetvices Scenario that everybody already understand.

>>kamma4+QJ
With that mindset, should we just stop trying to improve anything regarding backend/frontend/webservices since "everybody already understand it"?

>>diggan+CN
I second the OP - I'm not sure where the big prize is. I have a feeling that whomever wrote the article thinks there is a 10x (or 100x) improvement to be made, but I was not able to see it.

I find the syntax very clunky, and I have been programming professional Clojure for at least 10 years. It reminds me of clojure.async - wonderful idea, but if you use the wrong sigil at the wrong place, you are dead in the water. Been there, done that - thanks but no thanks.

OTOH I know who Nathan is, so I'm sure there is a gem hidden somewhere. But the article did not convince me that I should go the Rama way for my next webapp. I doubt the average JS programmer will be convinced. Maybe someone else will find the gem, polish it, and everybody will be using a derivative in 5 years.

>>kimi+1R
I would have expected better from HN that to shoot down smart people tinkering with potentially elegant solutions to complex problems. It’s something we should embrace.

Having said that, as a long term Clojure developer myself, I’m also not a big fan of this approach myself (I try to avoid libraries that use a lot of macros, and instead prefer a more “data driven” approach, which is also why I’m not a fan of spec), but I’m not one to judge.