Is this project still actively developed?
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?
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
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!
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?
hoplon doesn't have a virtual dom so it works fine with js libraries usually
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
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 etc1👍
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.1👍
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
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
@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.1👍
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:
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
The hoplon mobile site doesn't refer correctly in mobile
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
ah ok. I'm using 7.2
Thanks for the link
gotcha. I think there still might be other bugs
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?
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
@alandipert btw, I liked your talk at clojure/west, finishing it up right now
@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
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
but i kind of doubt at this point that the hoplon way can even be improved upon much
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
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
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
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
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
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
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
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
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
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
i guess the comment macro
occupies a token position though
(doto nil "my comment") yea
when you're making compilers its nice to be able to spew metadata without affecting the construct you're buildin
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