I can see why Clojure is seen that way ("advanced", "powerful"), but a big piece of it’s design is Rich Hickey’s view that "we can make the same software we're making today with dramatically simpler stuff."
Learning Clojure has made working in other languages much harder for me - pretty much all of my Clojure programming is functions plus transforming data structures (mostly maps). So few concepts to keep in your head!
The majority of my work is in TypeScript these days, and I always write the most Clojure-y TypeScript I can manage.
I found ClojureScript worth it a few years ago. I’ve written two frontend apps (desktop-style interactive single-page applications meant for longer sessions) of reasonable size in ClojureScript. There’s a lot of non-glue code there (in fact mostly non-glue code, given the interactivity and statefulness of the applications).
Very little language and library churn has made maintaining them very straightforward really, and I won’t be rewriting them any time soon. Being able to use DataScript nearly made the choice worth it on it’s own!
The reason I’m mostly using TypeScript these days (for new things & backend code) is that it’s just too helpful for typing the data structures and reducing the "how many things do I have to keep in my head" burden. My TypeScript (like my ClojureScript) is mostly just functions and data structures (avoiding classes, inheritance, etc), and I avoid using any of the more complicated TypeScript features as much as possible.
It’s kind of heretical, but if Clojure had a well-adopted gradual structural type system (essentially what TypeScript has done for JavaScript) then I would find it hard to not pick Clojure for most things.
When I was looking into ClojureScript I was kind of concerned at the complexity of writing applications in ReFrame which seems to be what most of the community is using. I've developed apps in this kind of event-emitting/event handler style before in JavaScript and found it quickly got quite out of hand. For my next app I will want to go with something like React-Query that in a sort of declarative way handles all your data fetching for you, and lets you decouple your components from the getting ahold of the data they depend on. I also searched far and wide for some kind of framework/library that supports SSR+CSR like Next.js but I don't think there's anything ready yet except maybe https://github.com/pitch-io/uix.
The rules engine direction is definitely an interesting one, hopefully there’s more exploration into that in the future.
For my needs now I actually wrote something pretty hacky[1] to get a 'reactive' version of DataScript’s Entity API.
As Nikita mentions in the article, I’ve found that most of the time I don’t really need queries in the UI, and so the entity API ends up fitting quite well – except that it’s non-reactive.
The `reactive-entity` library implements a reactive version of (most of?) the entity API, so you can pass entities in/through components, and then the components only re-render when the attributes accessed within those components change (including attributes accessed on other entities through refs).
Loads of room for improvement but I’ve used it successfully in a couple of projects.
Not sure which model you have, but I have the MA750i. Really pleased with them.
Used to have VSonic GR07s, but the cable became broken. The build quality on the MA750i seems much better, so I’m not expecting the same outcome for these.
Using Markdown means no constraint on what software you use to edit your posts, which is really nice.
Another advantage to using a static site generator is your blog will be (generally) fast to load, secure, and it will be really easy to find somewhere to host it for a low cost (or even for free).
I completely agree with this. I am working on a web application at the moment, and the server is very minimal. It just handles supplies a JSON-returning REST API, the index page, and some WebSockets stuff.
Doing things this way is quite nice, and forces separation between the client application and the server application. It makes the web application just a client, on an equal footing with any other client (iOS app, Android app, desktop application etc).
Learning Clojure has made working in other languages much harder for me - pretty much all of my Clojure programming is functions plus transforming data structures (mostly maps). So few concepts to keep in your head!
The majority of my work is in TypeScript these days, and I always write the most Clojure-y TypeScript I can manage.