This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-10
Channels
- # babashka (37)
- # babashka-sci-dev (22)
- # beginners (16)
- # biff (12)
- # calva (40)
- # cider (6)
- # clj-kondo (7)
- # clojure (183)
- # clojure-austin (20)
- # clojure-doc (22)
- # clojure-europe (16)
- # clojure-nl (2)
- # clojure-norway (39)
- # clojure-romania (1)
- # clojure-uk (9)
- # clojuredesign-podcast (9)
- # clojurescript (29)
- # core-typed (66)
- # cursive (19)
- # data-science (14)
- # docker (5)
- # fulcro (6)
- # hyperfiddle (46)
- # java (5)
- # malli (19)
- # missionary (3)
- # off-topic (84)
- # pedestal (5)
- # portal (36)
- # reitit (35)
- # releases (2)
- # shadow-cljs (30)
- # web-security (2)
- # yamlscript (1)
https://clojure-doc.org/articles/ecosystem/web_development/ has been pretty much completely rewritten and expanded -- a lot had changed since the last time that page got worked on. I would love to get community feedback on the new page: corrections and important omissions, in particular!
Perhaps @UUSQUGUF3's #sitefox as a batteries included pure ClojureScript full-stack framework (https://github.com/chr15m/sitefox)
The https://shadow-cljs.org/ link in the Frontend Development section does not open anything for me. I recommend including a link to the very detailed and essential to follow Shadow-cljs user guide (it's what I regularly point everyone to who has problems starting a repl) https://shadow-cljs.github.io/docs/UsersGuide.html
Personally I would put figwheel-main and Shadow-cljs as the to common approaches, especially as there respective approaches are so different, e.g. • Shadow-cljs enables effective use of JavaScript libraries as Shadow-cljs is part of the JavaScript ecosystem (npm) • Figwheel-main builds on top of existing Clojure tooling, with the option to bundle JavaScript libraries
@U05254DQM Good call. Not sure where that Shadow link came from (I'll blame Copilot for inserting it). I've linked to the project repo (which describes the project and links to the user guide).
I don't really understand what you mean about shadow/figwheel? I happen to prefer figwheel but every time I bring it up, folks tell me it's hardly used and I should use shadow-cljs instead (and it seems like figwheel support in Calva is very much a second class citizen). I feel that page's comment about Figwheel is fair:
> An alternative build tool for ClojureScript is https://figwheel.org/, but this seems to be less popular than shadow-cljs
these days.
(figwheel-main hasn't been updated for a year and a half now, and has about one third the watches, forks, and stars of shadow-cljs 🤷:skin-tone-2: )
(I just moved the figwheel mention up to part of the build tool para, after shadow)
> You will want to start with the ClojureScript Quick Start and then probably look at shadow-cljs as a build tool. An alternative build tool for ClojureScript is figwheel-main, but this seems to be less popular than shadow-cljs these days.
It would be a shame to dismiss a valuable tool due to popularity or because of a lack of updates....
I agree. But lots of folks seem to dismiss it whenever I bring it up 😞
Whilst there are libraries, tools and editors I don't use, I would consider it quite arrogant if I dismissed them if they were of use to others. For example, there are several challenges I have with using Calva effectively but would not say 'just use editor x` instead. That isn't the Clojure community way. Negative or nonconstructive voices shouldn't prevent others from considering using something useful.
I hardly "dismissed" figwheel. I specifically added it to the doc page and merely noted it is less popular. Which is a fact. If I had omitted it, that would have been "dismissal". I'm frustrated enough already that every time I mention figwheel, people tell me to "just use shadow-cjls" instead...
I'm pretty sure John didn't meant that you "dismissed" figwheel but the people that you were referring to in your message right above his: > But lots of folks seem to dismiss it whenever I bring it up 😞 He probably wouldn't even have used the word "dismiss" without that message, which is now almost 24 hours old and probably not present in your immediate chat context memory 😅
I hope that's what he meant -- and that certainly makes more sense (but he had initially suggested changes to how I'd mentioned it in the page so I was trying get clarification on that). To me, shadow-cljs feels like a lot of "magic" since it has a modified cljs compiler and a lot of other stuff, whereas figwheel-main feels like "just" a build tool on top of plain cljs -- so I definitely agree with John's classification of them in the bullet points he gave.
I think it would be valuable for beginners to include the brief bullet points in the final page (or a similar commentary on the significant difference of approach between the two tools). If popularity is an important factor, perhaps include figures from the last Clojure survey published - i.e. 2022 shadow-cljs 75%, fighwheel-main 30% would be a clearer way of expressing that. Note: There is obviously some cross-over in tooling as there is another 60% use over lots of other tools in ClojureScript tools for interactive dev question...
The way I described ClojureScript tooling in the Practicalli ClojureScript book is...
The main tools to support the ClojureScript workflow:
* Figwheel - ClojureScript focused with the ability to bundle JavaScript npm packages (typically the simplest approach)
* Shadow-cljs - implementation of ClojureScipt for node.js and therefore deeply integrated into the npm infrastructure (initially more complex but potential simpler when managing a significant amount of npm packages and dependencies)
Hmm, when I characterized shadow-cljs as being deeply integrated into the npm infrastructure (something I didn't want), Thomas Heller was quick to correct me that you could use shadow-cljs without node/npm... so at this point, I'm leaving that section of the page alone and the folks who maintain the tools can submit PRs if they want...
You're writing the post I wanted to! I am also not a web developer, but I think the full spectrum rarely gets laid out in this SPA-filled neck of the woods.
All I wanted to do was make a simple full-stack website, and I have instead gone on a long hike and stepped into a bunch of bear traps looking for information about what I can use, and can't use.
I was going to cover this ground:
• tools available (repl, compile, build/package, devtools, editor plugins)
• plain HTML/CSS websites
◦ static using magnars/stasis or cryogen etc. for example
◦ server-rendered using hiccup, rum, potentially reading from a database
• interactive websites (but not yet fully dynamic; think local-first web apps)
◦ Add "vanilla" clojurescript to the above sites, optionally using plumatic/dommy + hipo, or goog.dom, or lilactown/dom (incremental DOM). cf. https://ericnormand.me/article/cljs-dom-manipulation
• dynamic websites (distinct because dynamism begets a slew of problems which beget slews of middleware, which is a lot)
◦ Interactive websites + live backend that accepts writes and updates
◦ Server-rendered interactivity using htmx
◦ The frameworks; luminus, biff etc.
• SPA web apps
◦ Pretty much every tutorial in the ClojureScript ecosystem
◦ The usual suspects; react wrappers and react alternatives
◦ hoplon
• Something completely different
◦ hyperfiddle/electric
◦ tatut/ripley (TIL!)
----
And that would be the end of it for me.
----
Link to very good documentation about:
• Comprehensive JS interop, explained with examples
◦ I am hard pressed to find resources that cover this well
• Known gotchas and constraints
◦ especially those imposed by google closure compiler
◦ e.g. I just ran into a wall trying to port code that uses import.meta.url
and learned from old slack threads that the google closure compiler does not support it, and nor does it support "ESM" index format, whatever that is. So now I have to first run the typescript example to inspect what it is doing and then try to write a variant that will work in Cljs land.
Lastly, if it makes sense, given that they are firmly JS territory (although, perhaps each deserves individual treatment):
• developing for react native
• developing for nodejs
• some other JS target (planck repl?)
Good point about static sites -- I probably should add something for those. I probably should mention Hoplon since I think it's more active these days? Maybe Juxt Site as well (I haven't look at it). I'm not qualified to link to anything -- I don't know enough cljs/js to even have an idea about what would be useful to know or not. PRs welcome 🙂
> I'm not qualified to link to anything - ... ... Likewise. I am quite at sea. The outline I posted orients around my specific struggles. I will raise a PR once I find my feet.
Added: static sites, scittle, hoplon, juxt site, cherry/squint. PRs for more options and more details always welcome!