Luminus – A Clojure Web Framework | Hacker News Reader

Luminus – A Clojure Web Framework

luminusweb.com

224 pointsNaac43 comments

If you're interested in this, check out the book about web development in clojure[0] from the author of luminus, I haven't yet read it all, but I really liked the first few chapters.

[0]: https://pragprog.com/book/dswdcloj3/web-development-with-clo...

"Reagent is the recommended approach for building ClojureScript applications with Luminus."

Reagent is nice, but if you want global state management, re-frame adds most familiar concepts from redux but without as much boilerplate: https://github.com/day8/re-frame

I tried using reagent but wasn’t a fan of the atoms everywhere approach. Fine for small projectS IMO.

Do you mean cursors everywhere, or actual atoms? I maintained a fairly large project (3 man years or so) that used local atoms only for ephemeral components where you'd want to lose their state when hidden.

Components were passed cursors in to a single global atom, which more or less worked OK.

I think I'd use the re-frame model starting from scratch, but managing the app's state was probably not a top 5 problem for me. Every program is different of course!

Integrating external libraries, validating data, server side rendering, caching remote queries and tracking down compilation/logic errors would probably be my top 5. This was 5 years ago though.

Keechma looks better than re-frame imo https://github.com/keechma/keechma

Wish it had tutorials for newbies like me.

I am the author of the Keechma framework. If you have any questions please ping me on the Clojurians Slack (#keechma channel). I’ll be happy to help

I'm partial to kee-frame[0], which is the controller model from keechma implemented in re-frame. It's a tiny library but quite a nice starting place.

[0]https://github.com/ingesolvoll/kee-frame

re-frame still adds way too much boilerplate for my tastes, especially on solo projects. I personally greatly prefer to use reagent directly over using re-frame.

We've had a great experience building a mid-size app with re-frame. Sure, writing subscription and event handlers and wiring it all together seems like a lot of boilerplate when you could just fetch().then(), but in the long run the architecture really pays off.

It's not perfect, I do lament the boilerplateyness myself, but I have not seen anything better in my decade of web dev.

I think one thing re-frame does well is cascading events. One event might trigger other events, etc. There is also a library for orchestrating re-frame events: https://github.com/day8/re-frame-async-flow-fx

I think using re-frame rather than just building event loops yourself with channels and atoms give you some advantage in terms of existing libraries and utilities.

Yes. I now use Rum + Datascript + core.async for event sourcing. Here is the entirety of my reactive event-loop handling, inspired by Tonsky's Cat Chat (https://tonsky.me/blog/datascript-chat/):

    ; One Macro in events.clj:

    (defmacro go-loop-sub [pub key binding & body]
      (let [[db-bind & bindings] binding]
        `(let [ch# (cljs.core.async/chan)]
           (cljs.core.async/sub ~pub ~key ch#)
           (go-loop []
             (let [event# (rest (cljs.core.async/<! ch#))
                   ~db-bind @yourproject.data.core/conn
                   ~(vec bindings) event#
                   result# (do ~@body)]
               (when result#
                 (yourproject.data.core/transact! yourproject.data.core/conn result#)))))
             (recur)))))

    ;; Usage (at top of core file)

    (defonce conn (d/create-conn schema))
    (defonce event-bus (async/chan))
    (defonce event-pub (async/pub event-bus first))

    ;; For each event you want to dispatch on:

    (go-loop-sub event-pub :todo/add-item [db {:as data :keys [text]}]
      ;; Query db here. Any tx-data you return will get transacted.
      [{:db/id -1
        :todo/text text}])

    ;; To display some reactive queries in DataScript:

    (rum/defc root-component
      < rum/reactive [conn]
      (let [db (rum/react conn)
            todos (d/q '[:find ?todo ?text
                         :where [?todo :todo/text ?text]]
                       db)]
        [:div "Todos: " (pr-str todos)]))

That's it. You don't need re-frame.

I use those same 3 in a similar way, it's great. I do really appreciate the design of the effects/coeffects concept in re-frame, I often use that concept. I just don't find I ever need re-frame.

Hm, really? Maybe you're missing a layer of indirection if that's so?

Usually I end up wrapping things myself so I have one "setup-handler :name" function/macro that creates the subscription and event db handler for me. There are also existing libraries that does this for you, if writing it yourself is not wanted.

One example of such library: https://gitlab.com/nikperic/reframe-utils

`reg-basic-sub` has this outcome:

  (reg-basic-sub :common/active-page)

  ;; Equivalent to
  (reg-basic-sub :common/active-page :common/active-page)

  ;; Equivalent to
  (reg-sub
    :common/active-page
    (fn [db _]
      (:common/active-page db)))

For solo projects that don’t need all the boilerplate I think Hoplon is an even better option (there’s a Luminus profile for it). It’s kinda like Svelte: it doesn’t use a vdom and makes interacting with the actual dom really simple: http://hoplon.io/

Clarification: Re-frame is not an alternative to reagent, it's a framework or pattern utilizing reagent.

Indeed, you wouldn't (probably) use re-frame unless you're also using reagent (although you could).

I think vga805 is referring to the "atom pattern" where you have a atom on the outside and/or inside the components that you interact directly with, which is mostly (but not always) replaced by subscriptions and setting up dispatches.

So re-frame would replace the typical state management pattern you use when you're using reagent, but it wouldn't replace the view layer.

Extra clarification I guess...

Reagent is good for starting if you are new to React, but quickly becomes limiting.

I found Rum (https://github.com/tonsky/rum) to be a much more flexible choice. It doesn't force you into a single way of doing things, but rather offers a composable way of adding behavior to components using mixins. Especially for larger and more complex applications this proves to be a good tool.

Another thing which I really like about Rum is "isomorphic rendering" (not a good name, but I didn't invent it) — pre-rendering the DOM on the server instead of shipping an empty page to the client and requiring the client to render everything using JavaScript.

Reagent and rum both wrap react right? Do they mirror the react hook logic in some way? E.g rum/react might be a ones to one with reacts use state hook.

Yes, Reagent and Rum are both wrappers around React.

I think React hooks arrived much later and from what I've read about them, they solve a problem that does not exist in Clojure/ClojureScript.

`rum/react` lets your components auto-update when an atom changes.

Just in case - Luminus has options for adding re-frame and kee-frame (an add-on which adds a lot of convenience stuff to re-frame) to a new project.

Fulcro is also worth a look. I've been using it for a few projects and have been happy with it so far.

I've been trying it out as well, enjoying it so far. Link: https://fulcro.fulcrologic.com/

I tried fulcro but the amount of concepts you needed to learn was a bit too much. Unfortunately I was experimenting with electron which made it more complicated. It sounds a great framework if you have the right requirements but personally I found reagent/reframe alot simpler for my use case.

Also, the fulcro docs are thorough but it didn't click for me, I left with some questions unanswered.

That I can agree with, I use re-frame quite a bit in my day job, it's straightforward and lets you get things done.

I'm also of the opinion that the Fulcro docs are very substantial, but aren't always easy to get your question answered. I've been blogging little bits and pieces of things that I've figured out that I don't think were super easy to discover, considering the amount of work that's gone into it, I'm hopeful that the situation will improve.

However it's an interesting change to see something designed that's trying to be a complete end to end solution, take the new RAD tools for example[0], there's some cool stuff going on there. There's a demo[1] available as well.

- [0] https://github.com/fulcrologic/fulcro-rad

- [1] https://github.com/fulcrologic/fulcro-rad-demo

Will take a look, tks

Re-frame is enjoyable and the concepts are straightforward, unfortunately Fulcro suffers from the same problem as Om which is that the concepts just make you feel stupid..

Hey, where's your blog? I'd like to take a look at those bits too!

folcon.github.io :)...

I find myself going to the youtube videos a lot. There's a lot of new concepts in Fulcro. I'm surprised how long it's taking me to figure it out, but I haven't given up yet, and so far I'm liking it. I'm hoping that the investment proves worthwhile.

I saw the videos, they are helpful but I couldnt make my project work somehow.

I get it. Also, the community is active in their Clojurians Slack channel #fulcro

Haven't myself dived into Fulcro too much (mostly do ClojureScript so don't need the full stack) but always found interesting ideas to borrow from.

Especially around the UI State Machines that they have lots of docs around. http://book.fulcrologic.com/#_ui_state_machines

We just re-evaluated our choices and selected Fulcro. Below is a slightly edited version of how we came to this conclusion.

As a business building an extremely ambitious product on a tight budget, we want to be able to:

* Focus as much time and thought on building features that bring value to our customers, rather than, for example, building a bespoke protocol between the browser and back-end if a better alternative is available.

* Share early iterations of our application with everyone in our organization easily. Capture feedback and push out new iterations quickly.

* Be able to support new customers immediately. Our feature road-map will always be in constant flux, but at no point should our ability to make changes with confidence be compromised. In addition to feature development, tests and automation must be priorities. Our development and production environments must match.

* Be ready to onboard new team members. "Works on my laptop" is never acceptable. Enough of our application must be documented and automated so that anyone with a technical background "reasonably proficient" in our work can contribute without requiring hand-holding. Or course, we'd never turn down a request for help.

Our requirements are:

* Clojure, Clojurescript, and Datomic are immutable choices. We love these solutions for their simplicity and expressiveness. We believe these are the best choices available for achieving our long-term business goals.

* Be measurable. Our work should be guided by data not guesswork.

* Be testable. The entire application should have 100% test coverage as measured by its acceptance or integration tests (not unit tests). Changes should be made with confidence.

* Be performant. As builders of both the front-end and back-end components, we should encourage cooperation between them, not purposefully isolate them. Our customers and the end-user experience should be our priorities, not artificial divisions between software components or technical teams. Each component of the application should cooperate to support progressive enhancement where every URL is a real URL that, when requested, returns a server-side rendered page view. Further actions by the user result in browser-side changes through API calls and minimal component updates.

* Be pragmatic. We should be eager to innovate when the need arises. However, we should be humble enough to understand that sometimes, as software developers, we can become enamored with new toys that are entertaining, and possibly educational, but offer little business value. We should choose existing solutions to our problems that are acceptable enough over building our own solutions simply because we want to. For example, a standards-based protocol, like https://github.com/edn-query-language/eql, that allows clients to craft their own queries with little to no server-side updates is preferable to our current bespoke solution.

* Be documented and supported. Our choices should have active, helpful, and inclusive development communities built around them.

Our choices are:

* Rum, https://github.com/tonsky/rum

  Rum is a solid piece of software, created and maintained by @tonsky, that
  provides a minimal wrapper around react for creating client-side components,
  and supports server-side rendering. Although rum does not provide a protocol
  between client and server, nor a client component state-management solution.

* Reagent, https://github.com/reagent-project/reagent

  Together with Re-frame, https://github.com/Day8/re-frame, this is by far the
  most popular choice for building reactive client components in
  Clojurescript. These do not include the server-side solutions we need.

* Hoplon, http://hoplon.io

  Hoplon was created in-house at AdZerk, and later spun-out as an open source
  project. Hoplon is a complete solution although it uses a less intuitive
  spreadsheet-like method for building applications with little obvious
  advantage, and would not be compatible with Datomic without considerable
  effort.

* Luminus, https://luminusweb.com

  Luminus is a complete solution like Ruby-on-Rails, and is tightly coupled to
  SQL. Like Hoplon, Luminus would not be compatible with Datomic without
  considerable effort.

* Pedestal, http://pedestal.io

  Pedestal is supported by Cognitect, the custodians of Clojure and the
  creators of Datomic. Except Pedestal is best suited for building server-side
  APIs, and applications that need to stream data in "near real-time" to large
  numbers of concurrently connected clients.

* Fulcro, https://fulcro.fulcrologic.com/

  Fulcro is based on Om.Next, provides both front-end and back-end components
  that work well together, includes tools for building and debugging both,
  supports server-side rendering, and is supported by a diverse
  community. Paid commercial support is provided by the core developer team at
  Fulcro Logic.

* Datomic Cloud, https://www.datomic.com

  Datomic Cloud is a special version of the Datomic database that is tightly
  integrated with AWS. Datomic Cloud includes a set of Cloud Formation
  templates for running Datomic in AWS, and taking advantage of AWS specific
  features, such as auto-scaling groups and load-balancers for distributing
  traffic across a cluster of Datomic peers. Datomic Cloud also includes Ions,
  https://docs.datomic.com/cloud/ions/ions.html, to help run Clojure functions
  as AWS Lambdas. Cognitech claims Datomic Cloud is a suitable framework for
  building complete applications. Unfortunately Datomic Cloud alone is
  insufficient. Datomic Cloud lacks a framework for building and testing
  client-side applications, and a protocol for interacting with Ions.

Did you consider re-frame?

Yes, we considered both reagent and re-frame together. Around the time om.next was announced myself and a handful of others built a commercial product based on reagent, re-frame, and om.next. I only have good things to say about them, but there's a lot that they don't do and Fulcro's client-side solution is equally pleasant.

I tried using Luminus once and got super super super super super confused since I am new to Clojure development. I ended up learning the basics with Ring, Compojure, and Component.

I felt like learning these things separately vs. learning something like Luminus was way better to understand what was going on "under the hood". I bet if I went back to try Luminus now I would enjoy it but from my experience it was not very beginner friendly.

If you want to build simple/basic routing + RESTful services I suggest: https://github.com/ertugrulcetin/patika

Disclaimer: I wrote it.

Is this new? Or are there some new features? When I was writing Clojure a few years ago I thought that Luminus was the name of the framework of choice then.

I don't really think Luminus is really a framework, it is more like a template to get started with a curated list of libraries that has changed over time.

I believe Luminus has had some pretty major changes over the years such as changing the default webserver, routing library and dependency injection system.

Yup, Luminus is really just a curated (and occasionally updated) set of libraries put together by https://github.com/yogthos

Most Clojure devs find frameworks in the traditional sense quite limiting. Fulcro is probably the most framework-like thing in Clojure-land at the moment.

Looks like the website (and probably docs) was updated. Looks good imo.

The other template i like is chestnut https://github.com/plexus/chestnut

Another backend mini-framework is Roll.

https://github.com/dimovich/roll

Reply on news.ycombinator.com