I kneed I kneeed

I also want one!!!!!

do those stickers ship to portugal

@mfikes of many hours ago: I too am really looking forward to a new edition of ClojureScript: Up and Running. Anyone have any idea when that's likely to happen?

Hey, has anyone written up a comparison of https://github.com/cemerick/clojurescript.test and cljs.test?

@chrisoakman: what's the trick to get a sticker?

https://twitter.com/cursiveclojure/status/618321628540309504

@shaunlebron: ^ hey now

is that bad?

@entrobe: no, definitely awesome

super awesome, good on ya, @shaunlebron

I'm having trouble getting Boot to require my Clj macros in Cljs. Asked in #C053K90BR, but not getting an answer and it's a bit time-sensitive.

In build.boot, I have (set-env! :source-paths #{"src/clj" "src/cljs"} ..., but when I :require-macros my clj macro in cljs, boot complains: clojure.lang.ExceptionInfo: No such namespace: plus.utils at line 1 ...

Does Boot need a special setting to compile macros?

@petrus doubtful. Just needs to be on the classpath.

however src/clj/plus/utils.clj must exist

namespaces and location on the classpath must directly correspond

@dnolen: checked that. Does boot need any special dependencies, like clojure itself to allow this?

@petrus: I would keep checking, what you are describing is close to impossible

something is wrong with your classpath configuration

investigating anything but your classpath is a wild goose chase

@petrus: like Lein, boot should have a way to dump the computed classpath

Got it working. My mistake was that I added plus.utils to app.cljs.edn.

And it was complaining because that wasn't a cljs path, but a clj path 😕

screwed myself because the error was so similar

right but rule of thumb whenever you see an error like that

don’t look for weird reasons

it’s always simple

the compiler could not resolve the namespace on the classpath

that’s it

thanks

Having built a moderately-sized ClojureScript app, I'm now wondering: how do people handle upgrades/deploys? I do need to restart the JVM. My client-side code uses Sente and can handle disconnects/reconnects, but that doesn't help much if the CSRF tokens are invalid after a JVM restart. I'm looking for advice (perhaps somebody wrote a blog post or a book chapter :))

And BTW, the app is now live with a demo at https://partsbox.io/ — I'm very happy with the performance I'm getting pretty much out of the box. I used ClojureScript, React, Rum, DataScript, Sente+Transit on the client side and RethinkDB on the server side.

@jrychter: runs pretty smooth, is the source up online?

curious to see the source of your 'edit' inputs

they're slick and I'll be looking to implement something similar shortly

@samueldev: no, no plans to open-source the whole thing, but I can definitely share some code. Do you mean my "input+button" component? (edit+OK)?

I haven't found a good way to generalize the UI components. It seems the web requires a thousand various forms of an edit component, each one with subtly different behavior.

exactly that

some plain text of a property of a part

with an edit link

which turns it into a big input with a save button

my branch of cljs.tools.reader running via JavaScriptCore is now under 2X of the JVM version 😄

Nice!

@jrychter: Looks great!

That is incredibly cool; I suppose this bodes well for an "Om Native"

40ms on my work machine to parse 10000 lines of cljs.core via JVM tools.reader, 70ms under JSC

Not really Om, but more like CLJS as a great option on iOS.

@teslanick: well this is much bigger than Om Native

neither V8 nor SpiderMonkey are shabby

@samueldev: if you use Rum, I can send you the code for my input+button component. The 'edit' thing is actually done in the parent component.

@jrychter I'd recommend filling out demo / demo in the login form when you use the button

@jwm I second that, took me a sec to find the small text telling me how to log into the demo

hehe it's just because I am extreeeemely lazy

only when it comes to demo apps for some reason

@jwm I'd actually prefer to just log the user in automatically, but there is only so much time… Thanks for the comments, though. I thought this was obvious and it seems I'm wrong.

no it is obvious

I mean

It's obvious

people are just stupid

in the sense that it took me less than 5s to fidn it

find*

but its not as obvious as taking me 0.1s to find it

😛

yeah its one of those 5seconds for each and every person or 5 seconds for you to add hehe

@dnolen: That’s seriously awesome!

I guess I could quickly add placeholder text, that would be more visible.

@andrewmcveigh: yeah coming up on 100X faster than master 😉

@dnolen: hah. Not surprised!

@dnolen: impressive

yeah the goal is for ClojureScript under JS engines to be no worse than 2X over the JVM version

optimizing tools.reader is a good step towards showing this can be done

I’m trying to port a library from cljx to cljc … having never really used either before. The Clojure version seems to build and test fine but there seems like some kind of issue with the cljsbuild. main.js always ends up the same length no matter what changes I make, and doesn’t seem to include any function names I’d expect from my code. And when I try lein cljsbuild tests I get ERROR: cemerick.cljs.test was not required., even though it was. Any pointers on where to begin looking to debug this for a complete Clojurescript and cljsbuild novice?

@dnolen: thanks to perf work like this, I can build apps that get impressive performance out of the box. I mean, I haven't even started to seriously think about performance.

@jrychter: interestingly bootstrapping has mostly been useful to determine code gen issues with :optimizations :none.

the main benefit here is that you’ll see less disparity between :none and the higher optimizations settings

and that’s definitely a good thing

I’m kinda ambivalent about perf on core libs. Obviously it’s crucial, but on the other hand it means the implementation is less … nice

It would be awesome to have a reference implementation, that wasn’t concerned with perf at all.

An interesting data point: I'm seeing some disadvantages to compiling the entire app with Closure. It works great for single-page apps, but not necessarily so well for larger sites (like E-commerce).

@andrewmcveigh: for core libs it’s critical, I don’t see why implementation matters much for critical machinery.

@jrychter: I’m assuming you haven’t looked into modules, this is what Google does

@dnolen: just for looking at, reading, learning.

@andrewmcveigh: right that’s just a different thing entirely

sure.

but I generally don’t want to use software that was written for reading/learning

No one like @dnolen to make you look silly 😄 — yeah, this might help.

@andrewmcveigh: but to your point, no I would not copy most of the changes I made to tools.reader

but tools.reader isn’t a typical application - it’s one giant hot loop

@dnolen: no, I agree. Just musing

@andrewmcveigh: one interesting thing is that a lot of these optimizations are quite boring and could be automated if we had more / better type inference

a future Google Summer of Code project perhaps

Now that would be great.

yeah I started on it at one point but got busy with other things, definitely doable in a summer

@jwm @samueldev Thanks for your comments on the demo login — I now implemented auto-login. So, if you click the "instant demo" link, it will automatically log you in.

@jrychter: when registering, I was able to define a password shorter than 8 chars - don't know if that's intended

@zoldar: yes, that's intended. Less than 8 chars is seriously too short these days.

@zoldar: Oops, you meant you were able to define it — that's a bug, then

@jrychter:

@jrychter: actually, when I simply press enter having empty password input it also seems to proceed but locks on spinner

@zoldar: the password length check is missing completely. Forgot about it. Will be fixed.

@jrychter I'm not an expert on usability but standard input for a password may make some people edgy, especially when they are working on a computer somewhere in public

@zoldar: I thought about this — and I don't know which is better. If I go with a password field, then I'd need two of them. And, do many people really still use "normal" passwords instead of auto-generating them via 1Password or similar?

what I’ve done in the past is had a “show” button integrated into a single password field, that toggles it between a password and a text input

@jrychter: you'd surprised how that's still a quite niche practice 😉 however in case of a subset of your potential clients it may look different

and, many many people still type in normal passwords 😞

even people who are otherwise savvy to 2FA

@mattly oh, that's a neat idea, thanks!

yeah, nice idea indeed, need to remember that

@jrychter: is the ability to define storage with an empty name intentional?

@zoldar: well, not necessarily, but it doesn't matter. If you want an empty name, that's fine, they are referenced by id anyway.

@jrychter: While I can't create a part with an existing name, I can rename a part as such

@zoldar: thanks. I'd suggest you direct-message me with these, as they are not of much interest to the other folks here

@jrychter: yeah, true, sorry

hmm

I wonder why I haven't seen create user prompts with random password feature built in

What do you mean? For registration?

yeah

I know they have oauth integration but it'd be cool to see random password as a default capability

that’s a good idea too

though for new stuff I have control over, I’m going with a medium-style passwordless signup

you can set a password later if you want, but otherwise it just sends temporary login emails

if something demands a password, then it should also demand 2FA

https://www.youtube.com/watch?v=ByNs9TG30E8

enjoy!

dnolen: thanks for sharing, have been looking forward to this

Already on HN

@dnolen: any other great talks online (buy you) that I've missed over the last month or so?

@bhauman: I think EuroClojure beat QCon by 5 weeks so … 😉

@dnolen: Watching now! Been waiting for either of those videos to pop up.

Using secretary for routing, how could I add metadata to describe the permissions of a route, so that I can extract it later on? Having no luck with (with-meta {:perm :private} (defroute my-route "/user/:id" [id] ...)

@petrus: Your with-meta parameters are switched.

@petrus: also, typically a def* macro should take the metadata of the symbol you provide and merge that into the metadata on the created var (defroute ^{:perm :private} my-route ...) though I can make no promise that secretary properly implements this

because calling with-meta on a var doesn't alter the var, so just calling with-meta wrapping the defroute is not sufficient to actually attach any metadata to the actual var as stored in the ns

note that with-meta doesn't even actually work, but the ^{} syntax does what we expect

@dnolen: amazing talk sooo exciting...

@bhauman: glad you liked it!

@dnolen: cursors give you contextual update as well

@bhauman: will probably be showing off some Om Next via Figwheel at TXJS

@dnolen: sweet!!

@bhauman: they do but components annotated with queries have all the context they actually need.

and in the end it’s just more flexible wrt. swapping in a new kind of store

whether that is DataScript or actual Datomic

@dnolen: indeed it seems much much better. Will reflect more on it. Maybe falling back to local state more for app state makes sense.

app-state = ui-state

@bhauman: the programming model really doesn’t change that much actually

I just can stop answering questions about cursor bugs / issues

@dnolen: excellent, excellent talk

@dnolen: this is very very cool

@bhauman: fingers crossed 😉 but I’m hopeful. Things have been moving a bit slower since queries introduce a new kind of state.

so you have app-state, component local-state, and component local queries

users only really have to juggle queries & local-state. But it means the implementation needs more thought.

still I think the visibility benefits are pretty huge

you can always ask your app for the total data it needs at any point in time.

and ask for whatever query represents it’s current state

it’s more REST than REST!

@dnolen: that part of the demo was priceless.

@dnolen: oh and here is all our data

I feel like these models might work well for relational/graph-traversal kinds of data use-cases, but not as well for things like aggregations. I'm in the middle of writing a bunch of stuff on top of elasticsearch (where things are generally denormalized), and hoping to use something like om.next/datascript for app state at least, and write facades for the other stuff. Just thinking out loud, but I wonder if anyone's considered the limits of the relay/graphql model and how to account for different views (of varying complexity) on possibly the same data.

and here is our complete query

@gtrak: aggregations don’t need to happen in restricted query language

gtrak: its still very flexible right?

@gtrak: you can escape the model easiliy

@gtrak: aggregations are often complex, potentially things you don’t want to compute on the fly, or need to be collected from elsewhere

that’s the whole point of adopting the Falcor/JSONGraph router idea

any key can be virtual and not sourced from a real DB or whatever

ah, there's the missing piece then

yes, it’s really worth not just watching the talk, but going back through the Relay/GraphQL & Falcor/JSONGraph talks for more context

and gap-filling

only so much I could cram into 50 minutes

I watched the falcor talk earlier today . though keys are not functions, but the path to the key might be enough to build around.

yeah but they are thinking about arbitrary functions

and Relay/GraphQL at FB already supports that

which of these things Clojure(Script) applications should adopt only time will tell

we're stock react.js at the moment, but i'm looking for use-cases to shove cljs in there as well

i feel like this query domain is going to be a good one for that

@dnolen so when is om next gonna be a thing we can get our hands on? the issues you described (and subsequent resolutions via om next) are all precisely the answers to questions I found myself asking when I built an om app this past weekend

@samueldev: all development happens on Om master

word

basics working, but need to sort through queries and some other things before I make any kind of bigger announcement

the amd/commonjs modules work and jvm-less bootstrapping is exciting for npm projects, for those of us who don't get to work in a pure cljs codebase, and I'm guessing what the clojure community comes up with for query infrastructure will be easier to adapt than relay whenever that drops.

@gtrak: right though the amount of work to make a JVM-less thing work with NPM is … significant

more realistic to have a Lein/boot NPM plugin that transforms NPM modules into something CLJS can use

yea, ideally it needs good two-way interop, IME javascript guys aren't going out of their way to learn a new build system to use a language they can't understand.

@gtrak it’s just a non-goal, we’re on the JVM, we just don’t have the time to care that much about the NPM ecosystem or tooling

so if somebody else builds that great - we’re not going to do anything beyond what I talked about at EuroClojure

having to boot up a jvm for closure advanced-mode once for a production build makes sense to me (we don't want to port that), and there's no multiplatform tools.nrepl, but, I think if it were easy enough to, say, write a webpack loader for cljs source, that would be good for my team.

@gtrak: that doesn’t make any sense to me. Google Closure is WebPack for JS part except that it does way more.

if you’re talking about accommodating a Node.js server-side team - that’s just way out of scope.

nah, not talking about server-side

combining ClojureScript with non-Closure tooling doesn’t make much sense.

the distinction i'm making is the cljs tooling currently calls closure, the webpack loader is inverted, so more generally, just need to be able to compile files via external calls from JS.

which I think probably isn't that hard, and is work needed to support repl loading.

I’m having a hard time understanding what you are suggesting or why you can’t just call out to Closure, build your CLJS and then load that via WebPack

either Closure controls the build, or WebPack controls build

both seem feasible today

@gtrak: I found this talk very enlightening https://www.youtube.com/watch?v=WQLzZf34FJ8

ooo, thanks

Watching the EuroClojure Om Next talk, and man is it a relief to see the confusion / issue we've been having with Om (function closures being at odds with React) addressed.

that was a great talk

really got my hyped up and in a problematic way wanting to wait hehe

I'm writing CLJS to target Node following the wiki, and I noticed that I change the optimizations option to :advanced, my main function isn't receiving any command line arguments. Printing out js/arguments gives me #js {:0 nil}, while under normal optimization it returns what I passed in: #js {:0 ("sample.txt")}. Is there something else I need?

So seriously, Elm is amazing, and mostly not due to the language. The attention paid to approachability for new devs is incredible.

(no offence to all present who toil long and hard on CLJS tooling, of course)

Evan's talk at Curry On is definitely worth a watch when the videos go up.

it probably helps that it's a js-only lang

@cfleming: yeah I’ve been following Elm since the very beginning, very cool stuff and Evan is a great presenter. Looking forward to seeing the presentation.

@dnolen: Yeah, I talked to him for a while, really smart, nice guy.

@cfleming: this said while all these things are important, none of that work has ever translated into many serious users of Elm - I talked to the folks at Prezi about this when I was at Craft.

@dnolen: True, I'm actually not sure how long it's been around - I feel like I've started seeing people talking about it in the last 6 months or so?

I saw it presented at StrangeLoop in 2012

Ok, so it's been a while.

I keep tabs on pretty much every serious compile to JavaScript project

My experience so far has been pretty much everything thing that people complain about wrt. to ClojureScript are pretty much exactly the reasons anyone uses it in anger at all.

JVM dependencies, Closure integration, no eval, etc. etc.

cfleming: I have heard the opposite when it comes to actually trying to create something larger. But my sample is just one dev. the gist is easy to start easy to create demos but when you get past that ...

Sure, and I think some things (like Light table, for example) are often very beginner friendly but lack features that actual users need.

@bhauman: Snap.

But it seems like we're not far from having both in CLJS, and I'm pretty inspired to try to get there.

@cfleming: but I think Evan’s points are bigger than Elm so I enthusiastically checkout everything he ever does/says.

it's consistently good stuff.

Otherwise I'll be teaching my daughter Elm and moving her to CLJS later

cfleming: I do wonder if Elm solves the FRP graph or if it creates a bunch of stateful cells?

@dnolen: Oh absolutely, in his talk he basically showed no code at all and didn't mention FRP at all - I still only have a vague idea of what Elm even looks like.

@cfleming: yes I would say his more recent “mission” is to get the great ideas out into the open away from academic jargon

@dnolen: Right, he talked a lot about that, and even suggested friendlier alternatives for phrases that functional PLs tend to use in their blurb.

he presented last year at my studio in Brooklyn, was an awesome talk on Arrow-ized FRP and Elm’s innovations around that.

Nice, that would have been great.

@dnolen: just created a react class hot loading proxy thing. https://gist.github.com/bhauman/b39cfad51c9d48037b69 it's hilarious that I haven't really had the need for one.

@bhauman: I haven’t used FRP in anger but I will say that I generally just don’t like it. It feels too much like Rx (for obvious reasons). A matter of taste but I just want to write code, not wire together combinators.

@dnolen: I agree, I tried it with great interest with FlapJax but eventually the implicit state got seriously unweildy

@dnolen: react really does it for me

my experience with react in js is that 6 months later, only the people that have tried systems like clojure or haskell have any idea how to use it right.

'a discipline of immutability' is hard to teach

@dnolen: if you get a chance to look at the gist above and reflect on wether something like this will have a place in or alongside Om Next.

@bhagany: not sure what I’m looking at

oops

@gtrak: at the same time it looks like there is some serious momentum. Dan Abramov's Redux is getting some real traction very quickly

being forced to use cljs would make it easier for junior devs to have fewer decisions to make

@dnolen: gotcha

@bhauman: is this because you want to hot load a specific component?

and not re-render the whole thing?

@dnolen: local state isn't preserved across reloads

@bhauman: yeah you won’t even need this

oh wow

how are you doing this?

in Om Next you have helpers now to set a components props and force re-render

React warns but the warnings are meaningless

nice

already confirmed w/ the React team, they’re there to catch JavaScript mistakes

but for ClojureScript irrelevant

@dnolen: very cool

@bhauman: yea, using a well-documented lib would certainly make things easier, some of the pain is from preexisting ember.js work

@bhauman: https://github.com/omcljs/om/blob/master/src/om/next.cljs#L136

I've done dirty, dirty things

and https://github.com/omcljs/om/blob/master/src/om/next.cljs#L211

@bhauman: I even confirmed with Sebastien Markbage that this is in fact how Relay works

except they have deeper hooks to avoid the warnings I believe.

@bhauman: so basically you easily write a thing that drives

@dnolen: can we update the underlying class though?

@bhauman: we just make a normal JavaScript class for every component

@dnolen: lifecycle hooks and all?

I dumped all the functional stuff, creates too many problems

it’s just JS classes

so easy to patch at runtime.

and with queries you can get very crazy

@dnolen: oh!!!!! so the new classes have methods on the prototype and thus they are reloadable.!!!!!

@dnolen: gotcha

I didn’t show this but query fragments have the component class as metadata

all kinds of madness is possible

@dnolen: oh and this is very cool

@bhauman: yeah, just change the prototype

no more protocols in the way

@dnolen: this is soo soo sweet, well time to dump that code I just wrote.

lol

well it was kind of an exercise to show Dan what a hot reloader looks like in CLJS

@bhauman: we also build an entire index that we keep up to date.

so possible to get at every mounted component

@dnolen: this is just getting better

for some reason

learn from your mistakes 😉

@dnolen: I'm looking at your defui* code and I'm thinking you may want to use a defonce on line https://github.com/omcljs/om/blob/master/src/om/next.clj#L127 as this will keep the local state stable across live class changes 😉

@dnolen: unless I'm completely wrong about that

@bhauman: I think this needs to be configurable please open an issue about this

@bhauman: I’m thinking the best way is with a Closure define

we can read this out in the macro

and then easy to configure with all build tools

:closure-defines {:om-hot-load true}

Darn didn't know about closure defines.

lol, there really are a dizzying array of options

I'm using a pattern in the gist above. defui -> redefui

not even sure myself how I keep track of it all 😛

@dnolen: where is that available in macro namespace?

@dnolen: not namespace but env

(get-in @env/*compiler* [:options :closure-defines :om-hot-load])

Gotcha!

I'm a gonna use that for devcards as well

Right now it's just in options :devcards true

Issue filed

@bhauman: thanks!

@dnolen: The Node.js section of the CLJS quick start says: "...we do not output main.js to the out directory. This is important due to the way that Node.js resolves JavaScript source files."

@dnolen: Does Node.js require the js output in the root of the project, or in CWD, or something?

no it’s a bit more subtle than that

we need to hack Node.js so it can load Google Closure namespaces

Ok

maybe you can put it in :output-dir but never tested that nor worked on support for that

as it’s really not that important for application dev

Ok, having the generated JS output in the module root causes problems for Cursive, since I can only exclude directories from indexing

@cfleming: patch welcome, I’m not going to work on this

it’s the smallest population of ClojureScript users by far

Ok, fair enough. So currently, the hack looks in CWD for the JS files?

it does not

everything is relevant to the location of goog

we use a version of Google Closure’s own hack for Node.js

originally worked on by Nick Santos when he was at Google on the Closure Compiler team

https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/bootstrap_node.js

Ok. I'll try :output-dir, and if that doesn't work I'll see whether I can find time to investigate.

is the relevant file, this is what the main file will load

I’m pretty tired of working on Node.js support

if people want to use it, fix it

Ok. This is for a user on the ML, I'll see if they feel like fixing it

yes I’m done working on things I don’t use

the ball is now in the community’s court