Fork me on GitHub
#hoplon
<
2020-03-12
>
Bhougland14:03:01

Is this project still actively developed?

Bhougland14:03:18

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

micha14:03:42

thanks, glad you like them 🙂

Bhougland14:03:11

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?

micha14:03:42

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

micha14:03:17

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

micha14:03:07

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

micha14:03:32

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

micha14:03:59

are you new to clojure as well?

Bhougland14:03:37

Would panoply still be a good relevant demo?

Bhougland14:03:14

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

micha14:03:25

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

micha14:03:54

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

Bhougland14:03:08

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.

micha14:03:39

ah i personally like inline styles in hoplon

micha14:03:56

i make javelin cells containing the styles and they update reactively

Bhougland14:03:22

I thought it might be good for this use case

micha14:03:23

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

micha14:03:57

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

Bhougland14:03:58

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!

micha14:03:46

you can do a lot at first without a backend too

micha14:03:01

just have functions that mock up the backend endpoints

micha14:03:05

and use local storage

micha14:03:23

reduce the number of things to learn at the same time

Bhougland14:03:47

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

micha14:03:05

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

micha14:03:28

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

micha14:03:58

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

micha14:03:51

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

micha14:03:04

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

Bhougland14:03:10

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

micha14:03:30

i am not a svelte expert but it looks pretty cool

micha14:03:46

but hoplon does not have a virtual dom

micha14:03:16

instead you bind individual attributes of dom elements to reactive cells

Bhougland14:03:00

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)

micha14:03:38

reagent, for example, seems pretty similar to hoplon

micha14:03:18

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

micha14:03:56

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

Bhougland14:03:11

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.

micha14:03:35

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

micha14:03:04

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

Bhougland14:03:19

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

Bhougland14:03:55

Is that not needed because of the cell state machines?

jjttjj14:03:10

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

micha14:03:13

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

micha14:03:43

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

Bhougland14:03:54

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

micha14:03:07

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

micha14:03:29

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

Bhougland14:03:04

Any best practices that you follow to manage state?

micha14:03:08

we generally use unidirectional dataflow for sure

micha14:03:34

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

micha14:03:58

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

micha14:03:33

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

micha14:03:49

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

micha14:03:41

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

micha14:03:08

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

micha15:03:23

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

Bhougland15:03:58

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

micha15:03:38

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

micha15:03:11

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

Bhougland15:03:28

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

micha15:03:45

if those are javascript libraries then yes 🙂

micha15:03:02

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

Bhougland15:03:36

Vega is a JavaScript library and oz is a clojure wrapper

jjttjj15:03:47

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

Bhougland15:03:22

@jjttjj this is exactly why I want to try hoplon

rlander15:03:26

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

jjttjj15:03:53

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

👍 4
micha15:03:46

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

micha15:03:59

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

rlander15:03:13

@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.

👍 4
micha15:03:16

i'm making business apps though, not games

rlander15:03:25

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"

Bhougland15:03:50

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

jjttjj15:03:54

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

micha15:03:58

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

rlander15:03:41

@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.

Bhougland15:03:10

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

rlander15:03:33

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

Bhougland15:03:59

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

micha15:03:26

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

micha15:03:44

like how clojure has strong concepts of identity and equality

micha15:03:55

immutable colletions

rlander15:03:07

@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.

👍 4
Bhougland15:03:03

@rlander I will check out your project. Thanks!

rlander15:03:32

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

micha15:03:43

hahai have to remember how to log into reddit now

Bhougland15:03:02

But aren't cells just reference types?

jjttjj15:03:22

@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)

Bhougland15:03:47

My project only consist of an idea at this point

jjttjj15:03:07

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

rlander15:03:07

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

jjttjj15:03:00

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

Bhougland15:03:32

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

rlander15:03:45

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

rlander15:03:36

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

rlander15:03:50

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

jjttjj15:03:54

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

rlander15:03:15

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

jjttjj15:03:46

Yeah I do similar these days

rlander15:03:15

shadow-cljs is absolutely awesome

Bhougland15:03:31

The hoplon mobile site doesn't refer correctly in mobile

alandipert15:03:43

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

micha15:03:56

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

micha15:03:17

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

micha15:03:26

i haven't been doing frontend stuff for a while

jjttjj15:03:33

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

jjttjj15:03:18

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 🙂

rlander15:03:45

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

jjttjj15:03:15

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

rlander15:03:33

ah ok. I'm using 7.2

rlander15:03:05

Thanks for the link

jjttjj15:03:10

gotcha. I think there still might be other bugs

rlander15:03:13

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

jjttjj15:03:41

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

micha15:03:22

i like that

jjttjj15:03:29

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

Bhougland15:03:00

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

Bhougland15:03:45

Or am I out to lunch on my understanding?

alandipert15:03:34

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

Bhougland15:03:26

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

alandipert15:03:49

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

alandipert16:03:39

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

jjttjj16:03:22

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

jjttjj16:03:59

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

jjttjj16:03:43

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!

jjttjj16:03:05

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

micha16:03:22

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

micha16:03:56

not sure if it's better, but different 🙂

jjttjj16:03:02

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

jjttjj16:03:36

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

jjttjj16:03:50

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

micha16:03:27

the code walking parts are not strictly necessary

jjttjj16:03:49

True but I like the magic of cell= :)

micha16:03:55

ah right on

jjttjj16:03:14

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

jjttjj16:03:44

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

micha16:03:12

i wonder if riddley works with cljs

jjttjj16:03:33

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

micha16:03:43

riddley makes the code walking stuff easier to understand i think

jjttjj16:03:01

yeah I need to look closer at it

micha16:03:10

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

micha16:03:28

riddley does that for you, mostly

alandipert16:03:34

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

alandipert16:03:36

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

alandipert16:03:42

as part of some kinda hoplon PR refresh

alandipert16:03:47

public relations that is

micha19:03:11

sounds like an interesting idea

dave20:03:45

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

dave20:03:16

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

micha20:03:12

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

micha20:03:41

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

micha20:03:21

i like having both

dave20:03:02

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

dave20:03:23

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

micha20:03:49

haha you can do that though, no?

micha20:03:54

just don't use cell=?

dave20:03:24

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

dave20:03:05

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

alandipert20:03:17

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

micha20:03:42

it does do that at runtime, actually

micha20:03:02

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

alandipert20:03:09

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

micha20:03:24

both expand to the same thing basically

alandipert20:03:07

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

alandipert20:03:52

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

alandipert20:03:00

i think we are smarter now and it could be tighter

alandipert20:03:16

maybe i will do this

alandipert20:03:13

it would be cool if macros could emit comments

micha20:03:24

(comment ...)

alandipert20:03:25

i guess the comment macro

alandipert20:03:41

occupies a token position though

micha20:03:01

(doto nil "my comment") yea

micha20:03:07

or whatever

alandipert20:03:21

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

alandipert20:03:27

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

alandipert20:03:47

e.g. using only JS native types and macros

Bhougland21:03:17

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

alandipert21:03:07

@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)

alandipert21:03:52

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

micha21:03:38

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

micha21:03:50

so it's the web for me for now

micha21:03:31

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

jjttjj22:03:00

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