what do you guys use for serving files in dev (without figwheel) ? I am trying to find an alternative to lein-simpleton

from command-line I usually fire python -m SimpleHTTPServer

@darwin oh thanks! I found a bug in lein-simpleton and proposed a PR but no answer in long time..

but it's Fogus so I cannot say anything, cause he taught me Clojure through The Joy of Clojure 😄

@richiardiandrea: if you really need some server in clojure, you could use ring and lein-ring

I did it here, before I figwheel started to be good-enough for my needs: https://github.com/binaryage/cljs-devtools-sample/commit/60bf1b2d20bafce8c340780464cfedc051ff140b

also what I did in my previous projects was to setup nginx to serve some local folders

thank again, yes ring will be straightforward! but an alias and lein-shell might do

yep, it is not worth it to spin yet another JVM just for a simple static HTTP server

@darwin the alias is comfy: "browser-repl" ^{:doc "Clean, build and launch the browser demo repl."} ["do" "clean" ["cljsbuild" "once" "browser-repl"] ["shell" "python" "-m" "SimpleHTTPServer"]]

no actually I need to specify the folder too 😄

I need to emit a different module system to Google Closure from the ClojureScript compiler ala the :modules compiler option; i.e. splitting namespaces into seperate module files, but not in Closure format. The use case is that we have a JavaScript engine running inside mail servers which supports a Node.js/CommonJS-esque module system, and only loading certain modules at runtime has a massive impact on performance at large scales. Is there any work on supporting emitting other module systems ? Would it be feasible for me to modify the ClojureScript compiler myself ? If so any tips on where to start looking ?

how can I define css like this in clojurescript?:

.row-eq-height {
  display: -webkit-box;
  display: -webkit-flex;
  display: -ms-flexbox;
  display:         flex;
}

@superstructor: You could also ask on #C07UQ678E since this is a more advanced question.

@josh.freckleton: You could also ask on #C06DTLT5X

Could someone confirm if figwheel supports the :module option in :compiler, i.e. in the context of code splitting?

did any body used React Select in clojure script ?

@superstructor: the :module compiler option are not about javascript modules. they solve different issues. the :modules option is only about splitting the final compiled output into multiple files, but that is AFTER the whole program was optimized.

only loading certain modules at runtime is exactly what the whole program optimization is about

but you need to feed the whole program into the compiler

something node.js/commonjs isn't built for or particularly good at

there are solutions if you only want a commonjs module so you can load it into your server

so you can do var app = require('./my-cljs-thing')

@superstructor: such a change is out of scope for ClojureScript, we’re unlikely to ever support generating other JS module systems.

when incrementally compiling, what determines what files are compiled again? I have some projects where only the file I edited is recompiled but others where almost all files seem to be recompiled

Is that related to macro usage perhaps?

@martinklepsch: don't know the exact semantics for cljs but :recompile-dependents defaults to true I believe, so whenever you edit a file all files that depend on it are recompiled as well.

so if you have files that are used all over the place you'll see a lot of recompiles

@thheller: "all files that depend on it" as in the full tree or one level?

not sure on that one ... in shadow-build it is one level

but it is a different implementation so it might be full tree in cljs

I have a file that requires nothing but still some 30 files are recompiled

ignore that of course it's about files that depend on the changed file

exactly 😉

@martinklepsch: @thheller: at the moment it’s full tree

@martinklepsch: there is a ticket for recompiling on macros http://dev.clojure.org/jira/browse/CLJS-1490

Let's say I have a namespace foobar.colors where I define some basic colors I want to use. I can then refer to those colors by just using colors/red. Then I want to create a namespace for colors with an alpha channel, or maybe colors that look more "dirty" or "broken". I'd like to make sure that these two namespaces have the same names defined as the namespace with the basic colors. This way I can be sure that alphacolors/red always works, or I can even change which namespace I refer to as colors. Is there any sane way to make sure the namespaces stay in sync, or should I just hope that I'm disciplined enough?

@kauko I think namespaces are some of the least programmable parts of Clojure(Script)

so I would say no 😕

alright

@kauko: if I understand what you are saying, it reminded me of this post http://side-effects-bang.blogspot.com/2015/06/importing-vars-in-clojurescript.html

Thank you for the link! It's a step in the right direction, but not quite

Contrasting to the post you linked, what I'd like to do is force myself (or a team member) to define and overwrite vars defined in the "core"

Not just import them

this is not what namespaces are for - and I can’t personally say anything good about the topics covered in that blogpost

as more time passes the more I believe the inability to do var and namespace hijinks in ClojureScript is actually a killer feature

@kauko: what I would recommend is to take a more data oriented approach: put the legal color names in a set, define in foobar.colors values for them in a map, and then validate all the other namespaces with the same set

@bensu Yeah, I was thinking something like that actually. But how would I do the validation?

Unit tests? 😄

where you define your map you check that the keys used are in your canonical set

or use something like schema.

Yeah, actually I think I now know how I'd do it. Thank you guys!

speaking of namespaces, I’ve thought it odd that namespaces are not values (whereas modules in python & javascript are values). I can’t pass a namespace as an argument to a function, and then inside of that function get a var from that namespace. In clojure I can do (find-var (symbol ns-name var-name)), but that feels super hacky, and in clojurescript I can’t do it at all. Has there been any discussion of this?

@jaredly: the reason is quite simple ... :advanced optimisations

so implementation details dictate language design decisions?

@jaredly: it’s not an implementation detail

it’s like one of the very first things that Rich Hickey decided upon when creating ClojureScript

to me it is the absolute killer feature of cljs

😄 ok, sorry for the snark. but I don’t think that what I propose is necessarily in opposition to advanced optomisations

I cringe every time I look at a moderately large js lib

use of namespaces as first-class values could be statically analyzable

@jaredly: it sounds like a protocol (instead of a namespace) is what you want. faster dispatch than find-var thing in clj too.

protocols don’t have all of the properties I’m looking for, but do allow some amount of dispatch

[i've also wanted fancier namespaces at times, but we use the tools we have 😉 ]

@jaredly: theoretically possible - but it’s seems like a non-trivial amount of work - you would need to prove that the cost of such analysis and it’s affect on code size is worth it.

the current data points are of course against such work

bootstrapped cannot use advanced optimization so you get a 10X increase in code size

against such work b/c inertia? also — if we do the work for auto-js-externs, it seems this wouldn’t bee too far out of the way

such experiments would be interesting but first you need ClojureScript only analysis global passes

@jaredly: these things are not really the same category of problem at all

the auto-js-externs things needs local analysis only to work in the current proposal

wrt. CLJS tailored global passes higher priority in the queue than supporting something like what you suggesting would be early DCE

since that has a much more important real benefit for more users

faster advanced compilation

so lack of interest atm is more about missing pieces and higher priority things if we had the missing pieces

none of which to say if it was easy to implement such a thing today it shouldn’t be tried - but it’s not easy to do yet.

cool, thanks for the explanation!

I've got a question regarding namespaces, i.e. defmethod & defmulti . Currently trying to follow https://rasterize.io/blog/cljs-dynamic-module-loading.html to incorporate code splitting. At some point in the blogpost the author writes: This is a win, because defmethods can appear in any file I don't fully understand this, can you write a defmulti in namespace a and without requiring namespace a, implementing a defmethod in namespace b?

@iwankaramazow: no

but you can prevent every implementor from being loaded together

Ok, thanks. I'll trail & error into a solution.

Woohoo it works, farewell webpack, hello google closure modules 😄

I'm compiling my CLJS tests to run on node.js, but whenever I run them in node (`node target/test/test.js`) I'm getting cannot find module 'react'

I know this is not a very detailed description, but I'm not quite sure where to start looking

the react.inc.js file is there, everything seems fine

@thheller @dnolen thanks for your responses earlier re other JS module systems / :modules compiler option. Yes, at the moment I already do require(‘compiled-cljs-file.js’); which works fine. The issue for me is that once I want more than one CLJS thing (e.g. cljs-thing-A.js and cljs-thing-B.js) with the currently available compiler options I have two possibilities: (1) compile cljs-thing-A.js and cljs-thing-B.js into entirely seperate builds, which will duplicate all common code and libraries between the two; e.g. :cljs-base will be duplicated across both files. (2) compile both cljs-thing-A.js and cljs-thing-B.js into one monolithic file cljs-thing.js that is the entire software that must be loaded in its entirety. Neither of these options is very acceptable for mail servers handling hundreds of millions of messages with many JavaScript virtual machines in threads. Simply just the parse time and memory use with loading the code into the JavaScript engine is enough of a concern. Although inferior in every other way to ClojureScript, with vanilla JavaScript we currently have control over exactly which parts of the code are loaded into memory in a given JavaScript virtual machine instance. So I am trying to work out a way to move to ClojureScript without losing that control. Any suggestions ?

@superstructor: given your constraints ClojureScript may just not be a good fit for your problem

I don’t see how you can really get around having to load the large standard library

@dnolen: I’m happy to load the standard library once, but twice or ten times (depending on number of modules), is not ideal. Ultimately we plan to move this to an external JVM service running Clojure, but ClojureScript is a great bridge solution as it runs on the virtual machine that is already in production, and is inter-operable with the existing JavaScript implementation while we port it.

@superstructor: yes I understand why it might be desirable but it just isn’t possible and it’s not a priority

@dnolen: ok thanks, appreciate that. One last question, you don't think it is possible for me to modify the CLJS/closure compiler or compile with :modules then modify the compiled source or hack the closure module system to load the cljs-base (and other “modules” / files) via require() just for my own impl ?

@superstructor: so a couple of pointers

first under :none for Node.js we already use a modified shim provided by Google Closure so that goog.require invokes Node.js require

I don’t know enough about your problem (and I don’t have time at the moment to consider it further) but you may be able to work something out here if you just give up Google Closure passes altogether

so, by giving up Google Closure you mean not using the Google Closure stage of compilation ?

doing some with :modules may be possible but the feature was written almost entirely around the Web use case so I don’t know anything about it’s relevance for Node.js

@superstructor: yes Google Closure is only applied at :optimizations higher than :none

@dnolen: ok great, those are some really helpful pointers. Thanks so much 😄

in theory you could just supply your own loader thingy instead of relying on the machinery in goog.base

a lot of the REPLs (standard ones and Figwheel) demonstrate detailed hijacking of the code loading machinery

since they cannot use the standard mechanism (script tags added before document body close)

@dnolen: awesome, thanks. I’ll explore all those options and post my solution here / GitHub once I have one.

technically, in my case it is a bunch of SpiderMonkey engine threads running inside a C++ mail server, but I think if I come up with anything it will also be useful for Node.js use cases.

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

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

https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/repl/node.clj

@superstructor: definitely deep end of the pool if you aren’t familiar with how the REPLs interact with JS environments, but you might be be able to glean something from these

I can run my CLJS tests in node.js if I npm install react but this seems unnecessary to me

@dnolen: thanks, deep end of the pool sounds like fun 😉

@superstructor: I don't quite understand your use-case that would lead to loading the standard library twice?

just do 3 different builds A, B, A+B?

@thheller: well, you currently have two possibilities - either compile your entire program into one file, or duplicate the standard library across N files ?

:modules and node aren't great friends as soon as you use any optimization other than :none

no I mean for your server problem

as far as I understand it you either want to run it with A or B or both

but in completely seperate VMs

so lets say you have A.js, B.js and A-and-B.js

instead of loading A.js and B.js you load the combined one

which takes care of loading the stdlib twice

or just run in :none which would be totally fine as well

@thheller: sorry I possibly explained that poorly by simplifying the example. We actually have something like 35 modules (so A, B, C, D, E…) implementing different parts, and some N number of modules get loaded depending on different things like the message, or the logic being applied to the message. The multiple VMs are just for parallelization of handling multiple messages through the mail server at the same time. So although your right, it wouldn’t be feasible to make combined builds for all the possibilities.

@anmonteiro: you might want to poke around at the Om Next Node.js testing scripts for ideas where you may be going wrong?

@dnolen: I have copied from there and it doesn't work

I can't find anything different

@anmonteiro: :target :nodejs?

i.e. I can run the Om tests, but not mine

yep

@superstructor: ah hmm ... :none might be for you then

also tried :optimizations :simple and still get the error

@anmonteiro: output structure matters too

my :main is not inside the out dir

I've also been re-reading https://github.com/clojure/clojurescript/wiki/Quick-Start#running-clojurescript-on-nodejs

although honestly loading everything together but optimized will probably consume less memory than loading only parts on demand

especially if the servers are running for a while they will eventually have loaded everything anyways?

@anmonteiro: and you see all the expected React stuff in the output dir?

@thheller: hmm maybe your right, I should just try loading everything and see if that is feasible. A monolithic file would be the most simple option.

there's react.dom.inc.js and react.inc.js...

I suppose that's all

this is a project which requires Om

and I think that React in this project is just used by Om

I don't have it anywhere else

@anmonteiro: and out/cljs_deps.js shows a goog.addDependency(…) entry for the React stuff?

@thheller: loading our entire ClojureScript codebase into SpiderMonkey takes about 700ms, caching reduces that to about 100ms, maybe I can look into getting that number small enough so its not a problem.

why is load time to important?

if the server runs for 24h a day

700ms should not matter?

goog.addDependency("../react.inc.js", ['cljsjs.react'], []);
goog.addDependency("../react-dom.inc.js", ['cljsjs.react.dom'], ['cljsjs.react']);

@anmonteiro: ok that’s the problem

loading React DOM will blow up in Node.js

and lead to your cryptic error

it shows up in Om's cljs_deps.js too..

@anmonteiro: I’m looking at it right now it doesn't

I ran into this bug and made sure to drop any dom nses in my test ns requires

cleaning and compiling again

@thheller: maybe your right I could be taking the wrong approach, loading everything at once and caching might be OK. I’ll look into this as well. Thanks.

@superstructor: while not via a npm module, the process described here would work just as well for cljs

https://github.com/google/closure-library#using-with-nodejs

@dnolen: OK that was it, thanks! What I was saying was that I see what I've pasted above in the Om's deps.cljs, but none of the other dependencies use it. In my case these were getting used in other dependencies which created the problem

thanks once again

@anmonteiro: glad to hear it's fixed, when Node.js requires go wrong it can be a real head scratcher

at some point I looked at how to detect stuff like this - but I didn’t get very far

@dnolen: the strangest thing was that npm install react solved the problem

even when React.DOM was required

hrm … yeah dunno

maybe something to do with the npm React being more up-to-date or different somehow?

hrm let me check the version

it is indeed 0.14.7, not sure if it matters

higher than 0.14.3 that Om is requiring