Clojurians Log v2

@anthonykfranco, if you're curious what a JSX-like approach might look like, you can see what @jyn514 has been experimenting with: https://codeberg.org/jyn514/flower. It's a static site generator, not React, but the goal is HTML containing code. Talk here: https://www.youtube.com/watch?v=IYY_loaWi7U Not exactly what you're looking for in terms of features, but you might fight it interesting nonetheless.

@seancorfield basically it'd be the same reasons that I'd prefer to use HTML and Selmer or HugSQL. I don't have a problem, conceptually, with a world that has many lingua franca DSL's and one general purpose language for applications (Clojure), and I think the mindshare around things like HTML, CSS, and SQL will outlive any re-invention of them built within the Clojure ecosystem, and that I will benefit both from my decades of existing experience with them and the world's decades of existing experience with them. JSX to me has always been ergonomic HTML in JS. This is just my reasoning so that you know where I'm coming from. I'm not trying to convince you to change your mind. I'm wondering if anyone has tried to create ergonomic HTML in Clojure in a React context, but it does kind of seem like the answer is not really, which is fine, I just wasn't sure if I was missing something

> ergonomic HTML in Clojure in a React context But what does "in Clojure" here mean? Something like a JSX compiler that's launched inside a Clojure process?

@p-himik essentially when I look at re-frame or reagent, what I see is markup described with a CLJS DSL instead of HTML/JSX

I guess what I'm asking about is if anyone has made a .cljsx

Yeah, I get that. But I cannot even imagine anything that would be JSX working from inside Clojure, that's at the same time not a different syntax and not a simple JSX-compiler-written-in-Clojure.

Right, JSX itself handles it with a transpile step

Selmer could be considered "vanilla HTML in Clojure", in a way. Same with HugSQL and "vanilla SQL in Clojure". But they both receive a template string and produce another string. JSX is also like that, but only if you squint so hard that you almost stop seeing at all.

Or perhaps another approach like a .html “partial” template that's used anywhere JSX would be expected

> the mindshare around things like HTML, CSS, and SQL will outlive any re-invention of them built within the Clojure ecosystem Just so I get it out of my brain, because it keeps bothering me and I want it to go away. You might be right here, but any project that anyone writes with the probability of almost 1 will become irrelevant much earlier than any of the widely used syntaxes in the Clojure world. There, now it can leave my brain. :)

> like a .html “partial” template that's used anywhere JSX would be expected This is as vague as it gets, I'm afraid. Where would JSX be expected? What does it mean? How can it be made relevant to CLJS at all?

Even if you end up inventing something that lets you write and compile things like

(defn styled-text [{:keys [style text]}]
  
    text
  )

So I should just write React with JSX is your point? That any utility of reframe or other approaches is entirely voided by wanting to express markup in HTML?

I'm not trying to prescribe, I'm trying to understand your vision. The last question in my message above is in the context of the next to last question, and all the previous unanswered questions. Because I still have no idea what the original question really means. :)

"Markup in HTML" is not JSX at all though. JSX is not HTML, it's not markup.

The vision is essentially being able to copy and paste HTML (with tiny modifications) into a front-end heavy SPA the same way that it can be done in the React ecosystem. I haven't looked into Selmer for this use case, but that already may be the answer. I'm not too precious on colocating the markup in the same file (although that's pretty cool in JSX)

The goal being CLJS for logic and HTML-ish for the returned markup

I think Selmer might be as close as you can get but I guess I'm still not really sure what you're asking for -- can you show some pseudo-code that represents your ask/idea? And, to be honest, I kinda hate writing XML / HTML / JSX so [:span {:style (:style data)} text] feels much cleaner to me than <span style={{data.style}}>{{text}}</span> (Selmer's closest equivalent).

At work, we adopted Selmer for "large" HTML (templates) so that our UI/UX folks could work directly on it. We even built a little "preview" app that they could write a .json file for embedded data and then run the app against HTML (Selmer) files to render it. But we use Hiccup for "small" HTML fragments (and for XML).

If it's specifically HTML and not JSX, then yes, Selmer is definitely one of the answers. Albeit it's Clojure-only, so no CLJS usage. I think there were some other templating libraries though. And making one yourself, with the behavior that you need, isn't all that hard. Selmer is kinda big with a few kloc, but it's also not something for a single person - it's a widely used project.

It's not that we prefer to write

[:ul
 [:li "a"]
 [:li "b"]
 [:li "c"]]

  
a
  
b
  
c

(into [:ul]
      (for [v ["a" "b" "c"]]
        [:li v]))

True, in Selmer that becomes:

<ul>
{% for v in items %}
  <li>{{v}}</li>
{% endfor %}
</ul>

Regardless of the ugliness - the fact that it's possible in Selmer only shows that it's a frequent enough need. If you want to do anything that's not built into the template language of Selmer, you have to go out of your way to add it. You can't just use Clojure or whatever - Selmer is a different language that has to be learned. Same with JSX, albeit it's much more familiar to people that already know JS.

(that said, adding new tags and filters in Selmer is just a matter of adding a fn call in your Clojure code)

which is a lot more ugly.

OP doesn't need to be convinced of the benefits of functional programming, he's already been convinced for 10 years. Just has to make business decisions sometimes

Even Sean explained a business case for Selmer. I just asked a question. Thank you for the responses

I hope you can excuse the punditry here. :) After all, we're in #beginners, and questioners here are approached as such.

As a related aside, before we adopted Clojure at work (2011), we tried to adopt Scala (2009) and it was partly due to its support for inline XML expressions -- very similar to JSX, I feel. But you can tell how I feel about that now 🙂

@p-himik I do appreciate passion!

I did attempt Scala many years ago, and I really just couldn't get into it. From what I understand, the language developers felt the same way and changed it since then? Or something lol

It has undergone numerous backwards-incompatible changes in its pursuit of perfection. Maybe the process is still underway, I dare not check. :)

"Keep the DSL" here is just sticking to JSX, building those files separately, and consuming the result from Clojure. Some companies do that - specific components in React with JSX, glue code in CLJS. "Make it Clojure" would be Hiccup or macros with something that spits out React elements - Reagent, its clones, UIx, etc.

Yup, hiccup.

I may have asked my question in a convoluted matter. Basically, I'd prefer to use JSX over the hiccup route, but I don't see a straightforward path to do so, unlike the other swappable options in the different arenas I mentioned. Meaning using reagent is committing to the Clojure approach, but there doesn't seem to be a reagent-except-JSX option

Oh. It may be difficult to find support for such a route because anyone who understands both hiccup and jsx, and is free to choose, would never use jsx.

There is a contingent of people who want to use React from Clojure without hiccup (that is to say, without Reagent), perhaps https://github.com/pitch-io/uix is of interest. I wouldn't go that route, however, because, to me, doing so is giving up one of the main advantages of cljs for frontend development; which is the fact that views (html) can be expressed reasonably as data (in hiccup). This data orientation is not a trivial thing, it's worth understanding deeply. --- Interestingly (in the context of your question), it's exactly the same the reason we strongly prefer HoneySQL to anything, the important data can be expressed as data (not as a string).

@anthonykfranco "Basically, I'd prefer to use JSX over the hiccup route" I'm curious as to your reasons? Is it because JSX is familiar and Hiccup is not? Or is there something more fundamental you dislike about Hiccup, compared to JSX? At work, I maintain both our React.js frontend and our Clojure backend, and I hate working with the JSX stuff 🙂 I have considered using Squint for new pieces of the frontend tho', since its JSX support is much more like Hiccup: https://github.com/squint-cljs/squint#jsx