Hiccup

[den1k]

Here hiccup is transformed into react elements statically at macroexpansion time and otherwise at runtime. For the runtime case it should be easy to swap react for electric-dom2 calls but I'm not sure how reactive updates would work.

What's the current thinking on challenges to support hiccup for DOM generation?

[dustingetz]

Hiccup is our # 1 requested feature and we understand that lightweight syntax is important, especially for css-heavy views.

We will add hiccup, or something like it, eventually. in the meantime we haven’t actually figured out a great way to do it that doesn’t damage electric’s value prop in other ways.

We are confident that this can be done. However, Electric functions are more powerful than Reagent components (for example Reagent components return virtual dom but Electric functions return reactive values), so the idioms are different and there are more edge cases. So the Reagent-style syntax doesn't necessarily map 1:1 here.

We've POC'ed hiccup syntax twice (and at least one external user contributed an attempt). All attempts to date have ambiguous edge cases which cause problems in more complex compositions. And we can't yet forsee all the patterns Electric-dom needs to support.

Our approach right now is to prioritize correct unambiguous semantics over syntax, until the large scale idioms are clear and fully understood. The current syntax, while low-level, is 100% unambiguous and semantically precise. Once we are satisfied with the max-expressive-power patterns needed for complex apps, we will use that as a starting point for determining a lightweight syntax frontend.

[den1k]

Hiccup might be a force of habit after all. The more I use electric's syntax the more I find that it is actually more powerful and less of a headache than hiccup. Hiccup might be great for serialization (which doesn't make much sense in electric's case anyway). The only thing I'm looking forward to is more brevity but all the above makes sense; the foundation needs to be robust.

Since a lot of people have written a considerable amount of code in electric's current syntax, maybe it would be worthwhile to consider a code-rewriting tool in the future? Could also be a community effort. The highest friction I've experienced with electric as an early adopter has been rewriting between electric-domx versions.

[den1k]

bonus: it could be used on all existing electric examples

[dustingetz]

List of hiccup integration attempts (or other non-hiccup sugar over electric):

• @markaddleman slack thread gist
• Tatut https://github.com/hyperfiddle/electric/blob/master/src/contrib/element_syntax.cljc
• @milelo https://github.com/milelo/electric-hiccup
• Tiago Luchini https://github.com/luchiniatwork/hiccup-for-electric
• ... what others?

[dustingetz]

List of problem statements:

markup-heavy apps

todo need quote

familiarity

marciol: Interesting thread, I was thinking about electric these days and wondering if it'd be good to have hiccup as a way to capture more the attention of developers who are already familiarized with hiccup through reagent and other libraries using this syntax.

data-oriented programming

Mark Addleman: Ultimately, my motivating factor is cultural: I have a team of Clojure newbies who are falling in love with Clojure’s data oriented style and that they can solve almost any problem with the proper combination of map , reduce, and filter. I also need to build lots of UI quickly.

Electric is a new language with a different set of biases than Clojure. I began thinking about the pedology of my problem and realized I would spend a bunch of my time saying things like, “That doesn’t work here. Remember, you’re in Electric-land not in Clojure-land.” In an effort to reduce that problem, I wondered if hiccup would allow of a smoother on-ramp for developers moving from Python->Clojure->lots of UI.

Said another way, I was trying to explore the question, does hiccup reduce the seams between Clojure and Electric?

As a result of this exercise, I think I agree with @denik’s comment “Hiccup might be great for serialization (which doesn’t make much sense in electric’s case anyway)”

[dustingetz]

https://github.com/lynaghk/hicada

[dustingetz]

Quotes from people who changed their mind:

• Denik, above: Hiccup might be a force of habit after all. The more I use electric's syntax the more I find that it is actually more powerful and less of a headache than hiccup.
• telekid [slack]: FWIW after some initial grumbling, I'm not missing hiccup syntax as much as I thought I would
• jjttjj: I really like the electric dom syntax. I kind of even like that it's a little more verbose than things like hoplon for example, where in electric you must explicitly wrap props and text for example, because it makes sense to me that these should be explicit, since that is like, the granularity where things can change in your dom tree.
• grounded_sage: I know people complain about the authoring experience but I actually kind of like it haha
• nivekuil: wow does this model make for fast and fun prototyping of some ideas i've had bouncing around for a while. the effect model is seriously good

[eneroth]

FWIW, I don't have a preference for one over the other. For me, Hiccup is surface-level stuff, and semantics and performance matter more. But I've been through UIx and Fulcro as well, who have chosen to stay away from Hiccup because of performance and other reasons.

I remember Roman quoting that Hiccup parsing was a significant percentage of each rendering cycle at Pitch, before they moved to UIx.

[conjurernix]

My issue with the current dom API is not the "syntax" per say, I don't have a preference over hiccup or sexprs. It's the effectful evaluation that bothers me. Evaluating (dom/p (dom/text "Hello")) doesn't result to some object representing a dom node. It evaluates to nil, with the effect of creating a paragraph element and attaching it to the dome side-effectfully. Another example is dom/props is a side-effectful procedure that attaches the props to the 'current node' whatever that may be if you try to be more dynamic.

This leads to a whole lote unintuitive, unclojure-like API that I grew to like. This became very apparent to me when i tried creating reusable components and i wanted to have "higher-ordered" components, and the evaluation model caught me by surprise. https://clojurians.slack.com/archives/C7Q9GSHFV/p1715512802650349

I'm sure the more I use it the more used to it i'll get, but I'm also sure there'll be some other corner cases where the said effectful-ness will bite me in the a.

[conjurernix]

My issue with the current dom API is not the "syntax" per say, I don't have a preference over hiccup or sexprs. It's the effectful evaluation that bothers me. Evaluating (dom/p (dom/text "Hello")) doesn't result to some object representing a dom node. It evaluates to nil, with the effect of creating a paragraph element and attaching it to the dome side-effectfully. Another example is dom/props is a side-effectful procedur that attaches the props to the 'current node' whatever that may be if you try to be more dynamic.

This leads to a whole lote unintuitive, unclojure-like API that I grew to like. This became very apparent to me when i tried creating reusable components and i wanted to have "higher-ordered" components, and the evaluation model caught me by surprise. https://clojurians.slack.com/archives/C7Q9GSHFV/p1715512802650349

I'm sure the more I use it the more used to it i'll get, but I'm also sure there'll be some other corner cases where the said effectfulness will bite me in the a.

An update on this comment: https://clojurians.slack.com/archives/C7Q9GSHFV/p1716072530502729

TL;DR I grew quite fond of the current DOM API that electric provides.

[milelo]

The https://github.com/luchiniatwork/hiccup-for-electric proposal is the functionality I'd like to see - from my novice perspective. Any informed comments on this?
In summary it proposes a macro to provide syntactic sugar to the existing electric dom functions; a macro to convers a hiccup like form into the existing electric functions. dom/text handling is considered.

[den1k]

Closing as I opened the issue and came to the conclusion hiccup would be a limiting force in electric as described here

[milelo]

The https://github.com/luchiniatwork/hiccup-for-electric proposal is the functionality I'd like to see - from my novice perspective. Any informed comments on this? In summary it proposes a macro to provide syntactic sugar to the existing electric dom functions; a macro to convers a hiccup like form into the existing electric functions. dom/text handling is considered.

I've had a go at writing a fairly simple macro that allow hiccup and electric dom calls to be mixed without any apparent limitations. Ok its not pure hiccup but It is certainly vastly simplifying the examples I have.

[milelo]

I've created a library that provides hiccup-like syntactic sugar for Electric V2. This can be intermingled with regular electric syntax.

https://github.com/milelo/electric-hiccup.