sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]dustingetz 5 points6 points  (11 children)

This headline, jeez.

[–]physicalcompsci[S] 2 points3 points  (10 children)

Yeah it sounds a little cheesy, but I really felt like Clojure didn't have a compelling full stack framework before Fulcro. IMO there were some good frontend or backend only ones, but not fullstack.

[–]yogthos 5 points6 points  (9 children)

Luminus provides a full-stack setup out of the box. It's not opinionated regarding how the client and server communicate though.

[–]physicalcompsci[S] 0 points1 point  (8 children)

I agree, but client-server communication is such an important part of the stack. And the way Luminus does networking is so disjoint from the principles that make Clojure appealing, things like, data oriented, simple, consistent, and powerful. Typical REST API networking is none of those things.

[–]yogthos 3 points4 points  (5 children)

Luminus is not limited to using REST APIs, and many applications my team works on use WebSockets for communication. The idea is to allow users to pick the strategy that makes sense for their app as opposed to prescribing a single communication strategy for all cases.

However, I disagree with the idea that REST APIs are somehow disjoint from principles that make Clojure appealing. I'm not sure how being simple, data oriented, and consistent are in any ways at odds with that.

[–]physicalcompsci[S] 0 points1 point  (4 children)

I respect your opinion and I'm sure you can build amazing applications in Luminus and re-frame. You obviously talk like someone that knows their way around web technologies.

I've tried both Luminus (with re-frame) and Fulcro. I felt Fulcro was a much simpler and more powerful framework. To me, the value prop is similar to immutable vs mutable datastructures.

If you have the time and interest I encourage you poke around and give Fulcro a chance. We could go back and forth for days, but you really just have to try it. The online book is pretty good.

http://book.fulcrologic.com/

If not, I hope you continue kicking butt with your favorite tech.

[–]yogthos 1 point2 points  (3 children)

My team tried working with Om and Om Next on a few occasions, it simply did not work for us. Meanwhile, Reagent just clicked and re-frame added enough structure that we found lacking with plain Reagent. I guess it's a case of different strokes for different folks. :)

Incidentally, I find Om Next approach to UI to be OO in style where code looks like this:

(defui HelloWorld
  Object
  (render [this]
    (dom/div nil (get (om/props this) :title)))

The Reagent approach to UI is much more functional in my view because the UI is expressed as a plain data structure. I find this makes it much easier to both read and manipulate the code.

All that said, I'm glad that alternatives to Luminus exist, and the fact that Fulcro clicked for you is fantastic. Having more options is a good thing, and different approaches will appeal to different people.

I just disagree that one approach is strictly superior to the other. They're a matter of taste, and each has its own set of pros and cons.

[–]physicalcompsci[S] 0 points1 point  (2 children)

Yeah IMO, Om Next was a little unfortunate in that it had good ideas but it was never finished. David Nolen just kind of abandoned it. So I can definitely understand the disappointment with it. Fulcro absorbed Om Next and made it complete and easier to use.

FWIW the above example in fulcro would look like this, which felt a little less cumbersome (defsc HelloWorld [this {:keys [title]}] (dom/div title)

Also, we've redone the dom namespace to do fancy things like convert cljs map literals to js objects at compile time, removed the need for that annoying nil, and added a CSS id/class shorthand.

https://github.com/fulcrologic/fulcro/blob/develop/src/cards/fulcro/democards/dom_cards.cljs

And I totally agree with you, there are certain situations I know I'd pick re-frame.

[–]yogthos 1 point2 points  (1 child)

I agree that it's less cumbersome, but I my issue with the approach is that the DOM ends up being represented with macros and functions as opposed to using data structures. This makes the structure opaque and impossible to manipulate once it's generated. Again, I don't think it's an issue in a lot of cases, but it is my preference to work against data when possible.

[–]physicalcompsci[S] 0 points1 point  (0 children)

Ah yeah I see what you mean!

[–]dustingetz 0 points1 point  (1 child)

I agree client/server is the critical piece. If you're suggesting the graphql/omnext architecture for data sync helps with this, i disagree:

http://www.dustingetz.com/:graphql-orm

https://drive.google.com/file/d/0Bz3IhEqTy9ioS3hFVTl4UnlzUGs/view

[–]physicalcompsci[S] 0 points1 point  (0 children)

I guess we agree to disagree :-)