This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-10
Channels
- # aws (3)
- # beginners (186)
- # boot (25)
- # cider (2)
- # cljsrn (57)
- # clojure (161)
- # clojure-boston (1)
- # clojure-dusseldorf (11)
- # clojure-italy (5)
- # clojure-russia (20)
- # clojure-serbia (1)
- # clojure-spec (10)
- # clojure-uk (16)
- # clojurescript (207)
- # community-development (86)
- # core-async (2)
- # cursive (40)
- # datascript (1)
- # datomic (2)
- # editors (5)
- # emacs (8)
- # funcool (1)
- # gsoc (2)
- # hoplon (2)
- # jobs (5)
- # leiningen (3)
- # liberator (18)
- # luminus (18)
- # off-topic (106)
- # om (2)
- # onyx (5)
- # pedestal (7)
- # powderkeg (7)
- # re-frame (7)
- # remote-jobs (1)
- # ring-swagger (4)
- # rum (5)
- # slack-help (1)
- # untangled (11)
- # yada (48)
@yogthos Yep, I tried the way you described in the article. I’m still very new to clojure. Seemed a bit complicated and just can’t shake the feeling that there’s a gotcha there somewhere for more complex examples, based on the assumption “if it would work well in all cases it would be in the library (like it is in rum) and people would not spend so much energy getting it to work with Nashorn”
Thank you for the book, blogposts & luminus. Really helpful when getting started with clojure & clojurescript. 🙂
@claudiu glad I helped, and I don't think there's any fundamental obstacle for doing server side rendering in reagent it's just the effort hasn't been put into adding that into the library, a lot of the implementation could be taken directly from rum actually. I keep meaning to take a look at that if I get the time. 🙂 I can't really recommend nashorn approach, I tried that before and found that it doesn't really work well for non-trivial cases. If server side rendering is important in your case, then rum is a good option.
yep. It’s down to rum and om-next so far. Got further in 2 days with rum than with om-next in 2 weeks 🙂 . But trying to see if I can get the hang of om-next since it does seem to reduce a lot of complexity once you learn it.
a couple of problems I see with om next are that it’s very opinionated and monolithic in nature
when you work with something like reagent or rum, you can adapt them to the needs of your application fairly easily
and you can add libraries, such as re-frame or push, on top of them that make sense for your use case
om next requires a full buyin into the way it does things, and you have to structure your app around it
there’s also aspect of API stability, reagent API hasn’t had regressions over time, and changes have been additive
on the other hand om next is completely different from om, and if you built your app using om you effectively have to rewrite large parts of it to use om next
not sure either 🙂 really hard to grasp the concepts and workflow for om-next (or at least it was for me). But since it’s starting to make sense now I’m rebuilding a subsection of my app until I make a decision.
It’s monolithic & full buy might be considered a plus. Since at the end of the day the codebase is consistent and a lot of the boilerplate is removed. Like the of having the pluses of a framework but not having the lack of flexibility.
it’s always good to do spikes using different approaches to see which one works best for you 🙂
personally I found that re-frame works best for the types of projects I do, but that might be just me 🙂