This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-01-03
Channels
- # admin-announcements (91)
- # announcements (1)
- # beginners (5)
- # boot (228)
- # cljs-dev (9)
- # cljsrn (12)
- # clojars (13)
- # clojure (175)
- # clojure-art (6)
- # clojure-russia (46)
- # clojurescript (35)
- # core-matrix (62)
- # cursive (10)
- # datomic (5)
- # hoplon (119)
- # ldnclj (11)
- # leiningen (7)
- # mount (3)
- # om (21)
- # reagent (2)
- # slack-help (1)
- # spacemacs (1)
Out of curiosity, what's the overall plan for 2.6.0?
And is there an ETA?
There isn't a milestone on GitHub for 2.6 (just 2.5.0 - completed, past - 3.0.0 and "future")
https://github.com/magomimmo/modern-cljs has been fully ported to latest 2.5.5
stable release of boot
@magomimmo: wow thit looks great
it's a good idea to dive into the build tools, even for a introductory tutorial
@pesterhazy: I still have to decide about the next tutorial: three choices at the moment:
just yesterday I wrestled with lein cljsbuild
, if you don't know the ins and outs of the clojurescript build pipeline, it's a nightmare
I was say that the choices at the moment are the following: core.async
, react stuff
, dependencies scope and other housekeeping stuff
I would probably do reagent or something, to show the modern alternative to the domina stuff you showcased.
reagent would be cool (though possibly incompatible with some of the other tutorials like enlive)
wow there's so much stuff in modern cljs that I should check out!
personally, more housekeeping documentation would be great as well
yeah, re-frame already assumes familiarity with reagent
I'm not sure if it would be friendlier for a beginner or not, but for example the ability to use mixins in rum is powerful.
I should admit that I never took a look at OM, because recently I worked a lot on nodejs on SoC. But anything touched by @dnolen gets diamantine in a moment
Well, to me om.prev is too confusing and verbose and om.next while largely aligns with what I think will be the future of webapps - it just tackles problem a newcomer won't have for a while.
There's also quiescent and brutha, I think, but I have no experience with those at all, so I'm not sure how they compare.
@jaen: and @pesterhazy what about a tutorial on making a lib portable?
Hmm, that sounds interesting, but I think showing people the proper alternative to domina/jayq/etc. is more important
sure, but I have many tutorials to be added. even on electron, react native, etc…they will take some time and efforts, but I enjoy to be useful for someone
Maybe a little too specialized...
yes to both of you….I’ll take the time to think about the order….I still have to find a way to leave some room for UX designers in the new web…the SPA model seems to be a little aggressive with them…there should be a way (enfocus/enlive like) to keep them in touch with us as programmers
Well, there's https://github.com/ckirkendall/kioo if your designer can deal only in HTML and CSS and nothing more
Using it with boot-middleman so they have more familiar Ruby workflow is a pretty good way to not let designers to be alienated
thanks! I’m going to take a look at it….my god, you know any single lib on the clojure planet
I've used kioo though, even contributed a few fixes. It's great if you have HTML templates from an outsourced designer (that was my use case)
I just realised that kioo
is by the same guy I did somestuff in the past on enfocus...
But creating form-2 components with reagent was a bit annoying - you basically had to have two functions - one for the component, and the other one that is the form-2 you close over things in.
I guess you could somehow work around it using the function underlying the deftemplate
macro, but didn't experiment in that direction though.
@magomimmo: re: designers, have you looked at hoplon?
@micha: not in depth. Next week I’ll have a long list of reading with hoplon in the very first place
hoplon is i think the most approachable way for designers etc to make web apps without just copying jquery snippets blindly from stackoverflow
@jaen: yes, but i don't think that's a big win for most designers, except maybe just because their editors are already set up for it
Well, I was talking about designers that know HTML+CSS as well. Hiccup is an alien syntax for them, and one that requires them at least some knowledge of Clojure. I just thought that hoplon template syntax was just like hiccup but with parens instead of brackets, but if you say HTML can be used it is already a big win, since most people will feel more comfortable with that, instead of something alien as sexps.
if the designer gets too freaked out by syntax when the semantics is the same, then i don't think it's worth the time to try to help them progress
And I'm not sure I would call HTML+CSS which are basically markup languages with no means of abstractions. And understanding how to do HTML+CSS does not implicitly mean such a person would be comfortable with creating abstractions.
if that's a problem then i would say don't waste your time, let them just make templates or whatever
Well, I see programmers freak out over (
in lisps instead of {
like in C all the time. And I - under maybe a mistaken impression - designers would probably be even less comfortable with something alien. Though maybe I'm wrong, since HAML caught on.
Yeah, so I was saying things like kioo are good in that it doesn't force designer out of their comfort zones if they don't feel comfortable leaving their workflow.
Sure, that's a noble goal, but sometimes you have to adapt - I couldn't force people to write hiccup so I used kioo.
But if you say you can use write HTML with Hoplon then that's neat, it could probably work in that case as well.
so it was impractical to work with them to develop their skills because they were subcontracting and in another time zone etc
like if you're a backend type of programmer and you need to make a ui for a prototype, you're in the same position as a designer who needs to prototype some behavior into their static template
@jaen As a dyed-in=the=wool backend java dev, I am quite excited about being able to write ui for my stuff.
Well, hoplon doesn't let you write desktop applications and vice-versa for Swing, so it's a bit different, but yeah - writing something like Holpon or Reagent is certainly far, far more pleasant than imperatively bashing together GUI in Swing (had to do that for university one-semester Java course, never want to touch that again).
Though I think Clojure has Seesaw which is a Clojure sandpapering over Swing. Didn't use it though, so not sure how well it works in practice.
There are also other interesting desktop GUI projects (in no particular order) - https://github.com/friemen/async-ui, https://github.com/FlatGUI/flatgui, https://github.com/aaronc/fx-clj - each of which is probably better than Swing as well.
Question: if I want to hack on boot-cljs
(i.e. use a local git branch), how do I do that?
Well yeah, virtual doms are just performance optimisations. Which makes it quite interesting how Hoplon compares in that regard.
@pesterhazy: I think you hack and then do boot build-jar
which should install the JAR in your local maven repository
@jaen, isn't there a way to use my checkout directly, i.e. without building a jar for every change?
but really it's there so you can think of the dom as a functional transformation over immutable data etc
Yeah, but you can do the this state -> dom
pure function thing without virtual dom as well if I understand correctly.
well you'd have to dump the entire dom and recreate from scratch for each little change
@pesterhazy: it seems there's a built-in checkouts task https://github.com/boot-clj/boot/blob/7605a731902a77b577ad1aa869166612568d866d/boot/core/src/boot/task/built_in.clj#L69-L119
@micha, great to hear!
Hmm, yeah tires would be a performance optimisation. Back in the day vehicles didn't have tires, yet they also fulfilled their task.
@laforge49: all that reactive stuff remembers me the so called active values
from the frame languages of 30 years ago or even the constrain propagation language (at those times I even get into the thesis by Guy Steel <ftp://publications.ai.mit.edu/ai-publications/pdf/AITR-595.pdf>)
@magomimmo: yes!
i think there are things to be learned from ms excel too though, to improve on the amulet model
@micha: with boot
I’m getting everyday closer to my dev experience on my LISP machine of the 80’s...
excel is a really great example of software that helps you program without needing to know how to design abstractions or architect software
hoplon emulates that: the ui is a chart that reacts to spreadsheet values in "worksheets"
@magomimmo: did you really have a lisp machine workstation?
Everything was just there. that was the true immediate feedback environment, I mean totally immediate
@micha: imperative OO languages are like Ptolemaic epicycles compared with Copernican point of view. They are just false
Well, they are not false in the way it is how computers work. But they feel false in the way it is not how computation should be described.
A friend wanted to learn programming and I'm explaining it to her starting from the lambda calculus and she just gets it. I don't think it would have been as easy if I decided to go the imperative route first.
it's the stormtroopers who are patrolling the streets and kicking in doors to get terrorists or whatever
It's probably the biggest things that makes me want Racket to be the next stop after lambda calculus and not Clojure.
but like no jedi lisp programmer is going to make an xml parsing library that works as well as the terrible java things with millions of lines of code
Yeah, I'm wondering if it's something inherent to them lisps, like described this bipolar lisp programmer archetype article.
Yeah, the choice of JVM certainly has it's upsides in that it facilitates reuse of all that code.
and making clojure a hosted language rather than having a cumbersone foreign function interface
https://github.com/pixie-lang/pixie/blob/master/examples/mandelbrot.pxi doesn't look all that cumbersome to me for example.
But JVM has an edge over native ecosystem in that it was explicitly used in a lot of domains people weren't so keen to use C/C++ in, so there's usually easier to find libraries for certain tasks on JVM.
@magomimmo: I second @micha and I would suggest Hoplon for a chapter in modern cljs - I get the react fascination with om reagent etc but it seems to me like they are “overreacting” excuse the pun to the whole react thing and I don’t want to go down a react rabbit hole — btw I have thoroughly enjoyed modern cljs and I learned a lot keep it up
Seems like this clojars outage was a gift, because it spurred work to make Boot more robust.
@danielsz: I am aware of the library, but I think I'm missing some context - what exactly do you want to draw my attention towards?
@jaen Just asking. I had a look yesterday at the talk James Reeves gave about the library. It falls in line neatly with what we're doing with system. I am planning to implement the endpoint and handler component. It's kind of powerful.
@danielsz: Ah, I thought you were referring to something and it just slipped my mind. I'm aware of duct, but didn't play around with it so far. Is the talk on it on ClojureTV or somewhere?
Also in terms of structuring of applications with component I thought juxt's modular was interesting, let me find the relevant part.
It had marker protocols of sorts the components then filtered out from dependencies automatically.
https://github.com/juxt/modular/blob/master/modules/http-kit/src/modular/http_kit.clj#L16
And then there were components that provided bidi routes and could be mounted under contexts
Simplicity is nice, I have some unconscious overengineering bias that bites me in the end '
@jaen: Haha. I've had discussions with Malcolm about juxt, but it's not a good fit for system. I think Yadda is his best work. (Althoug I haven't had a chance to play with it).
Yeah, it looks like an interesting alternative to liberator, but recently I've been doing mostly multimethod dispatch on events shuttled through sente instead of REST APIs so I had little incentive to try it yet.
@jaen yeah, I do that too. REST API for stuff that touches the database, all the rest via message dispatch.