Clojurians Log v2

Is this project still actively developed?

yep

That was fast! Btw, I just watch two YouTube speaches of yours. Loved them, very convincing.

thanks, glad you like them 🙂

I am new at web programming and am looking at utility class CSS. Seems like it would be a good fit for Hopping. Is that the case?

i am not familiar with that CSS framework, but hoplon doesn't interfere with how you use CSS

it's easy in hoplon to conditionally assign classes to DOM elements reactively

most of the CSS frameworks i'm familiar with have APIs consisting of classes that are composed on DOM elements

very straightfoward and intuitive to do that with hoplon in your app

are you new to clojure as well?

Would panoply still be a good relevant demo?

Yes, I am still new to clojure. I have read a couple of books and have practed it for a while, and want to build something real

that one uses a number of libraries, might be helpful to use a minimum number of libraries at first

hoplon+javelin themselves don't do a lot, which i think is good

Utility class CSS is just a functional way to do CSS. This type of CSS is like tailwind and tacyons. It is actually close to inline styles.

ah i personally like inline styles in hoplon

i make javelin cells containing the styles and they update reactively

I thought it might be good for this use case

but a lot of times i have to use bootstrap or something, so then you make cells containing classes

yeah i really like the inline styles technique, because you can really get the most out of functional programming in CSS that way

Well, I will give it a whirl. I am going to try to create a small app based on the book "The Myth of Stress". It has worksheets you fill out that would seem to be very simple. I might drop in every now and again to ask questions. That's for the responses!

you can do a lot at first without a backend too

just have functions that mock up the backend endpoints

and use local storage

reduce the number of things to learn at the same time

Can you use datascript? Would it be a good fit?

you can use datascript, depending on how much data you have

if you have large databases you can run into performance issues if you store them in cells

i mean maybe those issues have been mitigated, i haven't done that in a while

but one thing about javelin is that cells test whether an updated value is equal to the previous value, it only propagates a change to formula cells when the value changes

so for a large datascript db the equality test can be expensive

Is the idea of updating the Dom similar to svelte in is?

yep!

Interesting

i am not a svelte expert but it looks pretty cool

but hoplon does not have a virtual dom

instead you bind individual attributes of dom elements to reactive cells

That is what I find so appealing. I love lisp and don't like the idea of having to learn about the whole React ecosystem (and being so tied to it)

reagent, for example, seems pretty similar to hoplon

and the reframe philosophy is basically the way you do things in hoplon naturally

so it's all sort of converged to the same basic techniques

By the way, I asked if hoplon was still maintained on r/clojure. I can remove the post, answer it, or let someone in the core team answer it if you want the response to be public. Let me know.

i'm not part of the core team btw, i haven't contributed anything lately, but the project is very much alive

there just isn't much need for changes at this point

It is comforting that it does have convergence with reframe and reagent. What do you think of the URL driving data like in keechma?

Is that not needed because of the cell state machines?

I love hoplon and use it daily, I do think the main repo could use a little love/tidying up

i'm not familiar with that, is that where state is stored in the url?

there was a project in like 2005 called seaside i believe that took that approach

http://Keechma.com it is based on reagent/reframe

hoplon just provides DOM bindings for javelin, which provides reactive spreadsheet-like cells

you can manage your state in any way you prefer, it's just clojure

Any best practices that you follow to manage state?

we generally use unidirectional dataflow for sure

cells will nudge you in that direction naturally, because formula cells are read-only

so you'll usually end up with unidirectional dataflow in your program

core.async is not used anywhere in javelin or hoplon, but that doesn't mean you can't incorporate that if you wanted to

but in my opinion it doesn't have a compelling story

but like consider the "ui components are decoupled and reusable" bullet point in the keechma features

in hoplon your ui components would not need to declare dependencies, because lisp has lexical scope

i personally find that lisp itself provides the abstraction i need for organizing the program components and so on

I appreciate the time and I will pop in again. Thanks to you both for the input!

https://github.com/hoplon/castra

that's an optional library you can use if you want

there is a diagram that shows how you can manage state with unidirectional dataflow

Can you use it with Vega charts, or libraries like OZ?

if those are javascript libraries then yes 🙂

hoplon doesn't have a virtual dom so it works fine with js libraries usually

Vega is a JavaScript library and oz is a clojure wrapper

I don't get the obsession with react these day. I see people recommend the react libs for cloure beginners all the time and think, this person now not only has to know html/css/clojure which are hard enough, but react too, as well as the subtle differences the cljs react libs introduce

@jjttjj this is exactly why I want to try hoplon

@benjamin.hougland your post is at the top of /r/Clojure 😃

https://old.reddit.com/r/Clojure/comments/fhgbcg/is_hoplon_still_maintained/

and all for what? React's main selling point in clojure is efficient rendering of elements, but at a kind of high cost of adding a layer that isn't compatible directly with the whole non-react ecosystem. I find the hardest part of building web apps is not ending up with a big pile of spaghetti code in 6 months, and i don't think the issues that react addresses (from a cljs perspective) help much with that. Because the real hard parts end up being state management, server interaction etc

yeah i don't think perf is a huge factor for the apps i make

we have very large hoplon apps that don't have perf issues

@jjttjj Yep. Every react project that I've been part of eventually had to come up with a few horrible hacks to accommodate dom-manipulating imperative libs.

i'm making business apps though, not games

I think Hoplon should ride the Svelte train. That's how I got back to Hoplon: I watched a pretty convincing talk by Svelte creator Rich Harris and though "Wait, I've seen these same arguments before... Hoplon... Maybe I should give it another try"

But isn't svelte supposed to be much faster than react? So I don't think the virtual Dom can claim that title.

yeah i hadn't seen Svelte, it does look cool, and like "hoplon for js"

@rlander yeah svelte was a breath of fresh air, i enjoyed his demos

@benjamin.hougland Although it is faster than React in most cases, I think the performance bit is the least important part but, because it grabs the attention of younger devs, it has more visibility than it should.

I want to test it more because I want to leverage my clojure knowledge as much as possible

@micha @alandipert Did you see the reddit post? I think its a nice opportunity to throw some love Hoplon's way.

Seems simpler. I am a consultant by trade, so I know spreadshe:joy: ets

seems to me that javelin might provide some advantages over js data in svelte

like how clojure has strong concepts of identity and equality

immutable colletions

@benjamin.hougland I can't say I have any relevant experience with Hoplon, but I've been writing react-based apps since 2015 and, after porting the Real World App to Hoplon (https://github.com/rlander/conduit) and using it in a few personal projects, I'm not going back to React. At least not for personal projects.

@rlander I will check out your project. Thanks!

The thing with Hoplon is that you only have to learn one new concept: cells. The rest is just plain cljs.

hahai have to remember how to log into reddit now

But aren't cells just reference types?

@benjamin.hougland Have you been able to introduce hoplon to you project without any issues? I remember hitting snags the last few times I tried to start from scratch from the main repo. It may have been toolchain issues with me though (I don't currently use boot)

My project only consist of an idea at this point

(minor snags, for example new changes being continually appended to dom instead of replacing old changes)

@benjamin.hougland yes, but they're more than plain atoms with watches.

I would love to help with a push to fix up any little issues and actively promote hoplon more though 🙂

I will give it a try and probably ask for lots of help:grin:

@jjttjj Me too.

I could take a look at the demos. Last time I tried them, most didn't work.

But at this point I think Jquery should be dropped. Or at least a jquery-less alternative ( like goog) should work 100%.

BTW, I love jquery, but in 2020 it's not the ideal marketing tagline "uses jquery".

I'm pretty sure the templates might not be working either. My problem personally is I use the tool.deps toolchain mainly now. For some reason I can't quite get boot working on Windows after a few attempts, and so it ends up being hard just to to get the hoplon template going and trying to debug it

@jjttjj They're not. I based the RealWorldApp off shadow-cljs because the boot-based templates were fairly old.

Yeah I do similar these days

shadow-cljs is absolutely awesome

agreed

The hoplon mobile site doesn't refer correctly in mobile

Render

http://hoplon.io would benefit from a facelift, i can't believe it's been 5 years since we updated 😯

yeah we ran into a jquery issue at work, around properties vs attributes

i don't remember if a PR was made to hoplon or not

i haven't been doing frontend stuff for a while

I think the prevalence of shadow might be another minor reason to remove jquery, as that kind of adds a very minor but diverging step to install the jquery dep via npm

i mean not that that's hard or a tricky problem, but I always start with the goog attribute providers anyway so I'm biased 🙂

I could not make the app work with the goog attr providers.

There was a bug I fixed somewhat recently, there might be others tho

https://github.com/hoplon/hoplon/pull/263

ah ok. I'm using 7.2

Thanks for the link

gotcha. I think there still might be other bugs

@jjttjj coincidentally, a few months ago I was prototyping a dom library and stumbled upon your repo: https://github.com/jjttjj/diy

I was just going to mention that! fwiw, i was messing with a super minimal dom library a little while ago, and gradually realized i just wnated it to be hoplon and eventually just gave up and kind of made it basically slightly more minimal fork of hoplon

i like that

it's now basically is just hoplon with things slightly rearranged internally in a way that im not even sure is better

Does the react cljs ecosystem still get the benefits of the Google clojure compiler? I image hoplon can use this feature of cljs better?

Closure

Or am I out to lunch on my understanding?

gclosure benefits cljs usage generally, i'm not sure if there are major differences in the level of benefit between hoplon and react-based libs

Oh okay

@alandipert btw, I liked your talk at clojure/west, finishing it up right now

On youtube

@benjamin.hougland oh, thanks! glad you like it

@jjttjj diy is really cool. is the main overlap between hlisp and javelin cell attributes?

@alandipert actually the readme is kinda outdated (I should fix that). I basically ended up scrapping the "mutator" idea sort of

and now I end up just using the diy.hoplon interface, which is pretty much at feature parity with hoplon besides a couple things like the html/`head` singletons

at one point the idea was to sort of separate parse-args and allow people to plug in their own functions to handle the reasulting attributes and children elems, so the hoplon implementation would basically just implement do!/on!

but i kind of doubt at this point that the hoplon way can even be improved upon much

@jjttjj did you see https://github.com/hoplon/hoplonfx, i tried a different approach to attributes there

not sure if it's better, but different 🙂

I did! and I've messed with your clojure PR for javelin a bit lately too

actually today I'm currently trying to implemnt javelin for https://github.com/borkdude/sci

so have been trying to wrap my head around the code walking parts

the code walking parts are not strictly necessary

True but I like the magic of cell= :)

ah right on

The goal being an in browser repl ui where i can just type in hoplon dom code that renders right next to it

(I think there are other way to do this besides sci)

i wonder if riddley works with cljs

probably not, but if it does you might look at https://github.com/hoplon/hoplonfx/blob/master/src/hoplonfx/cell.clj

yeah i was looking at that too after looking at your javelin clj stuff, not out of the box

riddley makes the code walking stuff easier to understand i think

yeah I need to look closer at it

a lot of the complexity in the javelin macro is keeping track of lexical bindings and so on

yeah

riddley does that for you, mostly

i have been doing a lot of CL lately and picked up a few new ways to macro, i wonder if applying them to cell= would be good

also i wonder about distancing boot and templates from hoplon in the docs

as part of some kinda hoplon PR refresh

public relations that is

sounds like an interesting idea

craig has turned me onto formula-of and formulet. personally, i'd be happy if hoplon didn't give you a cell= and you always had to explicitly specify what the inputs to the formula are

sometimes it can be difficult for the human to reason about what the inputs are when looking at a cell= expression

but the existence of cell= doesn't do any harm

you can use it if you want, or not if you don't, it's just an extra affordance for convenience

i like having both

i do, too, really. despite what i said above, i still use mostly cell=

i guess i'm more curious about what an alternate universe hoplon would look like that required you to specify the inputs to formulas

haha you can do that though, no?

just don't use cell=?

easier said than done when the codebase you're working on already uses cell= almost exclusively

i basically continue to use cell= for consistency, and then switch over to formula-of or formulet whenever either i don't trust the code walking that cell= does, or i don't understand what the inputs are

i think at runtime cell= could expand to code that knows what are cells, so i can imagine a compile time var that changes the behavior so that every cell= prints out its formula-of equivalent or something

it does do that at runtime, actually

haha true

that's how it can deal with things that are cells or not cells

well it expands to what formula-of does, not a formula-of form

both expand to the same thing basically

ok so a cell= substitute that sends you a PR when its compiled with a particulra option and run

execute()

man cell= is pretty hairy though, that would be good to clean up

i think we are smarter now and it could be tighter

maybe i will do this

it would be cool if macros could emit comments

(comment ...)

i guess the comment macro

occupies a token position though

(doto nil "my comment") yea

or whatever

yeah

when you're making compilers its nice to be able to spew metadata without affecting the construct you're buildin

yeah

has anyone experimented with making apps with cljs, but avoiding cljs data structures at runtime completely? i'm curious how small a deliverable can be that way

e.g. using only JS native types and macros

Is react native really the only way to create an app with the clojurescript ecosystem?

@benjamin.hougland i know micha evaluated this recently and landed on javafx instead of cljs for cross platform native apps (and created hoplonfx along the way)

more options may have become available since then, but i don't know of them

unfortunately i couldn't find a real-world way to compile javafx into a cross platform app

so it's the web for me for now

browsers are a lot better now in terms of exposing native capabilities than they were 5 years ago also

@dave out of curiosity, what issues with the code walking do you run into with cell= ?