This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-01-27
Channels
- # announcements (1)
- # aws (10)
- # babashka (53)
- # calva (133)
- # clj-kondo (46)
- # cljdoc (6)
- # cljs-dev (33)
- # clojure (105)
- # clojure-boston (1)
- # clojure-europe (11)
- # clojure-nl (4)
- # clojure-poland (1)
- # clojure-switzerland (6)
- # clojure-uk (13)
- # clojurescript (106)
- # cursive (1)
- # datascript (2)
- # emacs (13)
- # events (1)
- # figwheel-main (4)
- # fulcro (17)
- # graphql (8)
- # heroku (2)
- # honeysql (8)
- # lsp (76)
- # luminus (30)
- # malli (12)
- # meander (23)
- # music (1)
- # nextjournal (83)
- # off-topic (6)
- # pathom (3)
- # polylith (19)
- # re-frame (8)
- # reagent (2)
- # reveal (3)
- # shadow-cljs (54)
- # sql (9)
- # testing (11)
- # tools-deps (15)
- # xtdb (14)
General question for you all… is there any compelling reason NOT to use a simple, server side design for a CRUD app these days?
A dashboard of tables, forms for adding/editing. That’s it.
When you start needing to link to something within 10k rows, maybe it’s time to start bringing in some async for searching
AJAX and re-frame are just so fun, lol… but it adds so much complexity. Other than, say, async searching, and partial page updates, is there anything else that server side cannot do almost as well?
That’s not going to happen in this case. It’s a small niche app
My last concern is if so much emphasis has been on client side, that perhaps server side capability is behind the cutting edge. But it doesn’t seem that’s the case with luminus.
Also note that if later you need the js, you don’t need an entire SPA to do the things you need. You can make small bits of JS/cljs and attach them to whatever you need them to work on
I’ve not done such an incremental approach, but I guess it would be a learning experience.
When you do an SPA, the general pattern is to attach the whole thing to <app>, which is usually the first child of <body>
But you can attach any thing to any other thing, so a <select id="mycomponent"> will also work in the tree
I’m sure I could use my other luminus re-frame apps as a guide. If it can be done as a template, it cannot be that difficult to add in.
Re-frame is generally working under the assumption of an SPA where everything is in the DB. Maybe just reagent would be a better use case for this?
Although this is all getting into design hypotheticals. The point is more that you can build pure server side to start, and add cljs where appropriate to cover features pure html rendering can’t accomplish
It’s been a while, but that could be true as well. I have an older, rather large reagent app from a few years ago I could also use as a guide.
I think you’ve convinced me. Straight server-side will mean faster dev time for me, and that’s key right now. Fancy features can come later.
I’m already looking forward to it. Clojure really shines on the backend, obviously.
It will be refreshing change to work without worrying about client/server interaction.
Oh, one more quick question… selmer vs hiccup? I’ve mostly used hiccup, but I’m flexible.
Oh wait… I’ll still need to maintain server-side html, even with hiccup.
I think that’s ultimately the reason I have gone with reagent. I almost never need to deal with raw html.
Can’t give you an answer on that one, all my work has been SPA stuff, dealing with long-running connections
@U061KMSM7 They're both great, but each has a different feel to it. Personally, I've preferred hiccup since it was born because I prefer to do as much as possible in Clojure-land, but I've heard compelling arguments for Selmer: You might want a UI designer unfamiliar with Clojure but familiar with HTML to edit templates, you may want to do your templates in something that's not Clojure-specific in case you move to another platform, it helps with SoC, etc. I'd recommend giving them both a try and seeing which approach feels better to you.