This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-07-07
Channels
@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?
@shaunlebron: ^ hey now
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?
@dnolen: checked that. Does boot need any special dependencies, like clojure itself to allow this?
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
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.
@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.
my branch of cljs.tools.reader
running via JavaScriptCore is now under 2X of the JVM version 😄
Nice!
40ms on my work machine to parse 10000 lines of cljs.core via JVM 70ms under JSCtools.reader
,
@teslanick: well this is much bigger than Om Native
@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
@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.
yeah its one of those 5seconds for each and every person or 5 seconds for you to add hehe
@dnolen: That’s seriously awesome!
@andrewmcveigh: yeah coming up on 100X faster than master 😉
@dnolen: hah. Not surprised!
yeah the goal is for ClojureScript under JS engines to be no worse than 2X over the JVM version
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
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.
@dnolen: just for looking at, reading, learning.
@andrewmcveigh: right that’s just a different thing entirely
@andrewmcveigh: but to your point, no I would not copy most of the changes I made to tools.reader
@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
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
@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
@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
I know they have oauth integration but it'd be cool to see random password as a default capability
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
@dnolen: any other great talks online (buy you) that I've missed over the last month or 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: 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
@bhauman: they do but components annotated with queries have all the context they actually need.
@dnolen: indeed it seems much much better. Will reflect more on it. Maybe falling back to local state more for app state makes sense.
@bhauman: fingers crossed 😉 but I’m hopeful. Things have been moving a bit slower since queries introduce a new kind of state.
users only really have to juggle queries & local-state. But it means the implementation needs more thought.
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.
@gtrak: aggregations are often complex, potentially things you don’t want to compute on the fly, or need to be collected from elsewhere
yes, it’s really worth not just watching the talk, but going back through the Relay/GraphQL & Falcor/JSONGraph talks for more context
I watched the falcor talk earlier today . though keys are not functions, but the path to the key might be enough to build around.
we're stock react.js at the moment, but i'm looking for use-cases to shove cljs in there as well
@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
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.
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.
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
@gtrak: I found this talk very enlightening https://www.youtube.com/watch?v=WQLzZf34FJ8
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.
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.
@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.
@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?
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.
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.
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.
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.
@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
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.
@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.
@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
@bhauman: yea, using a well-documented lib would certainly make things easier, some of the pain is from preexisting ember.js work
@bhauman: I even confirmed with Sebastien Markbage that this is in fact how Relay works
@dnolen: oh!!!!! so the new classes have methods on the prototype and thus they are reloadable.!!!!!
@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: 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?
maybe you can put it in :output-dir
but never tested that nor worked on support for that
Ok, having the generated JS output in the module root causes problems for Cursive, since I can only exclude directories from indexing
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