I am not the most experienced user around here but I think re-frame is a fine place to start, and the “Getting Started” for re-frame will get you hot reloading, a great debugger with re-frame-10x, a component library (re-com), etc. If you just want to get to work on a frontend it seems like a reasonable way to do that.

Thanks James - one thing I’m confused a bit about is do I also need something like Uix, or does re-frame “cover” what’s being offered by Uix as well?

Re-frame and reagent works together.

reagent, re-frame and shadow.cljs is a good place to start. There are some examples here and there if you look for it

I think it depends on your requirements first of fore most. YMMV of course

I'd say that entirely depends on what you app needs to do. SPA don't take longer at all as a basis. They take longer the more complicated you make them, ie. add features that a regular "dumb" page couldn't do.

To put the above into my own words - the same functionality would mean similar or exactly the same complexity achievable via reasonable means. And there are definitely things that DPAs can't do reasonably well. IMO SPAs are strictly better if you don't take SEO into consideration.

It is theoretical discussion on average. But yeah for sure assuming while do SPA then do all this clever things like for example form validation.

I suspect that with Clojure(Script) you can even achieve quite a lot of both with just one code base. I have build a simple tic-tac-toe in the past where the actual logic was in .cljc files and worked on both Clojure and ClojureScript.

I would put it simple: - if you need a lot of user interactions and don't need SEO/public pages, go for SPA (shadow-cljs/helix is probably the best way to start) • if your pages are relatively static with most logic happening on backend, go for something like htmx (Biff clojure is a fantastic place to start)

Heh I see it a little opposite. Decision about SPA vs MPA in consequence make you to do all this features for user or not. But for what cost. This is what I am trying to answer myself.

If it makes project x5 of time or even x3 maybe not worth it and better focus on other aspects

Somehow all small startups are not SPA, at least this is my impression

Unless you have to, but I am talking about cases when you have a choice

If you can satisfy customer's needs with only server-rendered pages you'll definitely save a lot of time by not writing front-end app at all. But you can't build an app like let's say Figma or Slack purely on server-rendered pages. Slack might work, kinda, but it won't feel responsive and many features will be hard, if not impossible, to implement.

I would say it is a similar or sometimes even greater effort on the front end. You have to fight with asynchronous code and an impatient user. Of course, the end complexity differs significantly from app to app.

> You have to fight with asynchronous code and an impatient user. You have to do it with static websites to some extent as well. E.g. if the server is slow to respond, a user might press some "Submit" button multiple times, which is often undesirable.

Users always destroy a perfect application with their I/O needs 😄

"Damn internet users! They ruined internet!"

I've been reading a book about hypermedia systems and htmx. I'm implementing the exercises with Clojure, Ring and htmx. I'm really enjoying it! No overwhelming front complexity feels good 😅

Yeah HTMX is somewhere between and can give responsive feeling with minimum effort

I like a e-store use case. You can do SPA or MPA or use HTMX, but will it make user to buy from you? No. It doesn’t matter. At least this is my point of view.

I mean in most cases choice between SPA / MPA / HTMX etc. will not have effect on selling.

But can make development more costly

Do you agree with that?

Yes, users don't care about the technology you use. As long as they can complete the job they need in an acceptable time and effort. For e-store use case, I think htmx will be perfect. It gives you enough interactivity to feel modern, fast page render times and SEO.

What justify put extra effort in SPA then?

For many apps, it's the only choice. If interactions get more complex than just submitting form(s) on a page and read content, you'll likely need to go SPA route. Or if you can do most of your logic on client-side, then SPA is worth it. There are many things that go into that decision, and hard to give general advice.

Compared with a server-side app, an SPA adds a significant amount of extra technology to your stack, probably an extra build step, extra state ("is the data loaded yet") and overhead with data access (can't read directly from your database). It's certainly not a free lunch.

Yeah even with simplest solution we have to do: • extra layer on BE + FE for API • above means “double” tests for BE and FE which add another layer • consider security things it makes it harder • Network problems to fix on FE side • 2 editor windows when developing instead of 1 • 2 cicd • etc. And we even didn’t add clever SPA yet

fwiw i get a compile time error on subsequent builds after the initial (good) build when using :optimizations :simple

...main.js:14:0: ERROR - [JSC_MISSING_MODULE_OR_PROVIDE] Required namespace "module$...

not using foreign libs anymore but using :npm-deps like so: https://anmonteiro.com/2017/03/requiring-node-js-modules-from-clojurescript-namespaces/

but still the same issue ... first build works fine and subsequent auto builds by touching source seems to be missing goog.addDependency("../node_modules/idb-keyval/dist/compat.js",... in the :output-to file

but restart lein cljsbuild and the initial build isn't missing that line in the JS

Aha l'm not losing my mind ... https://github.com/emezeske/lein-cljsbuild/issues/493

Well if anyone runs into this I have a fork with just barely acceptable build times on auto (went from 0.9s > 1.9s). But I can add :npm-deps to browser targeted clojurescript without those deps disappearing

https://github.com/penpot/penpot

https://github.com/studistcorporation/blog-calendar/