This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-12
Channels
- # announcements (65)
- # aws (1)
- # babashka (12)
- # beginners (111)
- # bristol-clojurians (1)
- # cider (32)
- # clj-kondo (55)
- # clojars (3)
- # clojure (71)
- # clojure-europe (17)
- # clojure-france (4)
- # clojure-italy (36)
- # clojure-losangeles (8)
- # clojure-nl (6)
- # clojure-uk (115)
- # clojurescript (2)
- # datomic (99)
- # fulcro (32)
- # graalvm (12)
- # graphql (20)
- # hoplon (203)
- # meander (56)
- # mount (3)
- # off-topic (17)
- # pathom (17)
- # reitit (22)
- # shadow-cljs (32)
- # spacemacs (9)
- # tools-deps (19)
- # vim (25)
- # vscode (3)
That was fast! Btw, I just watch two YouTube speaches of yours. Loved them, very convincing.
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
most of the CSS frameworks i'm familiar with have APIs consisting of classes that are composed on DOM elements
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
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.
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!
if you have large databases you can run into performance issues if you store them in cells
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
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)
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
It is comforting that it does have convergence with reframe and reagent. What do you think of the URL driving data like in keechma?
I love hoplon and use it daily, I do think the main repo could use a little love/tidying up
http://Keechma.com it is based on reagent/reframe
hoplon just provides DOM bindings for javelin, which provides reactive spreadsheet-like cells
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 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 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
@benjamin.hougland your post is at the top of /r/Clojure 😃
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
@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 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.
@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.
@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.
The thing with Hoplon is that you only have to learn one new concept: cells. The rest is just plain cljs.
@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)
(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 🙂
But at this point I think Jquery should be dropped. Or at least a jquery-less alternative ( like goog) should work 100%.
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.
http://hoplon.io would benefit from a facelift, i can't believe it's been 5 years since we updated 😯
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 🙂
@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
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?
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
@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!
@jjttjj did you see https://github.com/hoplon/hoplonfx, i tried a different approach to attributes there
actually today I'm currently trying to implemnt javelin for https://github.com/borkdude/sci
The goal being an in browser repl ui where i can just type in hoplon dom code that renders right next to it
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
a lot of the complexity in the javelin macro is keeping track of lexical bindings and so on
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
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
you can use it if you want, or not if you don't, it's just an extra affordance for convenience
i guess i'm more curious about what an alternate universe hoplon would look like that required you to specify the inputs to formulas
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
haha true
well it expands to what formula-of does, not a formula-of form
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
i guess the comment macro
occupies a token position though
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