@shaunlebron: cljs.repl APIs are public

hello everyone a cljsc question. I want to generate a standalone js file from my cljs. Is there a way to do this with lein cljsbuild ?

I think you mean friends...

or is using cljsc a requirement ?

@shriphani: making standalone files is definitely supported

ClojureScript has no “runtime” component

right.

so…. how ?

my google fu is failing me

@shriphani: that’s just simply how ClojureScript works if you use any optimization setting other than :none

I see

@dnolen: okay, I thought that was the purpose of the cljs.*.api namespaces, to indicate stable public APIs. which other namespaces are public?

@shaunlebron: cljs.repl is the only real exception to the rule.

okay, noted

@dnolen: another question. Can I get a minified js file with only my stuff and everything else that I can throw into a CDN ?

sorry - unclear. js only with my stuff. dependencies and goog.* in a separate file

@shriphani: when using any optimization level other than :none you end up with a single JavaScript file.

@shriphani: if you haven’t gone through the Quick Start I highly recommend it. It covers all the basics.

@dnolen: going through it right now. thanks.

@dnolen: can you confirm these parsed cljs.repl symbols should be public: https://github.com/cljsinfo/api-refs/tree/catalog#cljscompilerapi

@shaunlebron: well probably need to go in there and mark some helper things private. A lot of it is public but not everything.

@dnolen: okay, I’ll cherry-pick symbols from cljs.repl for the reference until then

@dnolen What is the end goal exactly of being able to compile the cljs compiler to js? Since the Closure compiler is a big part of cljs compilation, I'm curious how that could be used from within cljs.

is anyone using cljc and Prismatic Schema together? i’m really struggling with can’t-find-var compilation errors for this library when i use it in a .cljc file

@robert-stuttaford what's the error message exactly?

"Caused by: java.lang.RuntimeException: No such var: su/NamedError"

we reference schema.utils/NamedError directly

@danielcompton: ^^

Does the same code work without cljc?

i’ll test

I'd be surprised if it's a cljc issue, that's meant to be pretty transparent

Does ^:const on defs actually do anything in ? Should I bother?

@danielcompton: are you using Schema?

its not cljc, you’re right. for some daft reason, i’m getting this: java.lang.RuntimeException: No such var: s/EnumSchema when i try (require ‘[schema.core :as s]) s/EnumSchema EnumSchema itself: https://github.com/Prismatic/schema/blob/27668958099092a17b5c31db68824cda0914d08f/src/cljx/schema/core.cljx#L295

i should totally be able to do this but i’m not. clj and cljs both bugging out

do i use require or import for defrecord / deftype declarations?

ah. import.

fixed! -mutter,mutter-

@danielcompton: thanks for your awesome reader conditionals post. helped me switch very easily! http://danielcompton.net/2015/06/10/clojure-reader-conditionals-by-example

@jrychter: ^:const prevents redefining and also facilitates use in case. See CLJS-806.

Also discussed here https://github.com/clojure/clojurescript/wiki/Differences-from-Clojure#special-forms

@aengelberg: there a significant number of scenarios where having the compiler compiled to JavaScript benefits.

for some applications JVM requirement is burden or non-starter - Electron or Raspberry Pi

for online tutorials it’s nice to drop evaluator service component - just static files

also for simple scripting, while it’s unclear yet, I suspect a bootstrapped ClojureScript will just start / run, use less memory faster for very short lived processes.

those are the concrete benefits

@aengelberg: Closure is an important part but it’s role is primarily to deal with shipping to typical JavaScript clients where network latency dominates. That aspect is less useful in the above scenarios.

I’d also like an iPad app that has a stand-alone built-in REPL (w/o network access) that runs right in JavaScriptCore. (Maybe a future React Native project.)

@mfikes: right iOS is another place where getting a JVM is … unlikely

@mfikes: Ok. But it doesn't influence the way the code is compiled — no need to use it for optimization purposes, then.

https://twitter.com/mraleph/status/610351876077428736

hilarious

😆

@dnolen: I'm curious. How come you stick with the separate ns for macros pattern (ie. cljs.env.macros) instead of putting them in cljs.env now that that is a .cljc?

@thheller: reader conditionals don’t change how macros work in ClojureScript

you cannot mix macros into ClojureScript source, and a bootstrapped compiler isn’t going to change that

breaks portability

I'm aware of that. But you can put them behind $?(:clj ...) and (:require-macros [cljs.env :refer ...])?

just saves the extra file?

hrm just didn’t try that as it wasn’t clear to me that it wouldn’t have issues.

other than that no real reason

be cool if you could

ok, not important really. just was curious if there was a reason other than habit

I don't see why you shouldn't be able to mix macros in as long as they are hidden for cljs

thheller: hrm actually the problem with that is if the body of the macro is different, which in this case they are slightly different.

@thheller: ^

and macros just see :clj there’s no way to communicate that the macros are being loaded into a :cljs context

not yet anyway

@dnolen not sure I understand what you mean? as long as its behind #?(:clj ...) cljs doesn't see it at all and it would be the same like it is now in cljs/env/macros.clj

same macro rules apply after all

@thheller: what you showed about shows loading the same ns with :require-macros to get the macros.

But those macros are not the right macros.

ah, I see it now. There are still macros in cljs.env

right so your approach works if the macros themselves are portable

ah this is confusing. One macro expands to clojure and one to cljs. Didn't notice that.

well once cljs can compile itself (and do macro expansion) you should be able to put them behind #?(:cljs ...)

@dnolen IIRC the closure library is prominent in compiled cljs code. What if the cljs-in-cljs->js target code depends on closure lib code that was compiled away (or had their names minified) by the initial cljs->js compile (using :advanced optimization)? Perhaps you've thought of this and are taking care of it, but that's the part that seems non obvious to me.

@aengelberg: closure lib is not really all that prominent in cljs.core. goog.base, goog.string, goog.object, goog.array. That’s about it.

@thheller: right only works if you are already bootstrapped, but really that makes it generally unusable

@aengelberg: advanced compilation and optional bootstrap are just orthogonal goals

that is if you’re using bootstrapped compiler you probably don’t care about the size of the generated code

which you won’t in the use cases I outlined above

this is why bootstrap will always be optional - it’s a benefit with significant tradeoffs at odds with how ClojureScript is leveraged today.

So will goog.string (etc) always be there in the "host environment" without closure compiler obfuscation?

Not sure if "host environment" is the right term in this case

Yes no minification no tree shaking

Though nothing will preclude applying Closure to the generated source yourself

Curious about @jrychter ’s earlier question; wrote up some exposition on ^:const for case: http://blog.fikesfarm.com/posts/2015-06-15-clojurescript-case-constants.html Hope it helps!

Can you core.match againts ^:consts? Or do we still need a let binding indirection?

@mfikes: hey, cool! This is a great explanation. My (uninformed) thinking was more along the lines of "make something ^:const and avoid var lookups when it's used".

@jrychter: Yeah. Me too, given the Clojure semantics of ^:const.

mfikes just posted an article about seeing emitted js for a cljs expression in the repl: http://blog.fikesfarm.com/posts/2015-06-15-see-js-in-cljs-repl.html

Just published a small post for GSoC week 3 : http://mneise.github.io/posts/2015-06-15-week-3.html 😉

nice!

@maria I love reading these. Thanks!

@bhagany: glad you find them useful

maria: great stuff!

@nullptr: thank you

@maria: Awesome! One question brewing in my mind: How do we reference symbols in the resulting generated Closure libs from ClojureScript? I succeeded by using a “fully qualified” munged symbol that bakes in the file path, but was wondering if shorter names can be used. If this hasn’t been sorted yet—cool—am just curious.

Here is the “munged” example: (module$libs$german.hello)

@mfikes: You can refer to the module as if it would be a regular Google Closure module, e.g.:

(ns hello-world.core
  (:require [greeting :as g]
            [goog.string :as string]))

(enable-console-print!)

(println (string/startsWith "Hello" "H"))
(println (g/hello "Welt!"))

@maria: That’s awesome!

or you can even use refer:

(ns hello-world.core
  (:require [greeting :refer [hello]]))

(enable-console-print!)

(println (hello "Welt!"))

@maria: does this mean that we’ll need to recursively reference all dependencies of a lib we want to use?

@danielcompton: yes.

not sure yet, if we can change anything about that.

Hmm. Perhaps Closure would handle loading transitive dependencies?

One example, greeting refers to german, which doesn’t have to be explicitly loaded.

maybe…there are still some things we need to figure out 😉

Also, what will happen if you depend on a library which has two versions of the same package somewhere in its dependency tree?

Just questions, I’m sure you can work them out, I’m looking forward to this

@danielcompton: not quite sure how this could happen. Do you mean in case the user specifies two different versions of the library in the compiler options?

@danielcompton: that's not really a problem as we just rely on Maven to prevent stuff like that.

that is we're not going to suddenly adopt NPM semantics

Sorry, I’ll rephrase my question. I don’t fully understand everything that’s going on so maybe this isn’t an issue. If we have a commonjs JS library query which relies on liba and libb, and liba and libb both depend on different versions of promise-lib, will this cause any issues?

No new issues than those that already exist under Maven

but if we’re interoperating with common JS, won’t we have two :foreign-libs entries with the same :provides but from different versions?

Not possible under Maven as I said :)

That seems like a fairly common case for JS libraries though no?

I’m not sure what you mean

JS has no native notion of packages or dependencies

Hmm, I think I may be getting things confused with how NPM does it

yeah NPM isn’t JavaScript Also the NPM way doesn’t work for clients. Which is why Bower exists.

And more or less why we don’t use either for the most part and the quick rise of CLJSJS to popularity

So does that mean you won’t be able to just use arbitrary NPM packages in CLJS with this patch?

NPM integration doesn’t really have that much to do with generic CommonJS support.

the work doesn’t preclude someone else leveraging it for NPM but it’s orthogonal

gotcha. I think that’s where I was getting confused

Q? for OM users: is it a bad idea to do

:target js/document.body

Thanks for patiently clarifying

np

@meow: only insofar as that’s a bit weird as Google Closure encourages inlining scripts into body for latency reasons

@dnolen: okay, thanks

things are getting serious now https://github.com/clojure/clojurescript/commit/a65f7b75b592691c314f378559cdd2a43936b3cc

dnolen: that guidance was pre async loading, i wonder if it's changed since

@nullptr: nothing has changed to my knowledge

oh if you mean async loading in head perhaps

but the really you still want to insert the script tag exactly when enough of the page has loaded

right, i mean the former not the latter -- they definitely are still doing that

early days of closure they were loading script in iframes and controlling the dom of the parent -- not sure that's still common ...

@dnolen: defmacro, way cool, some serious fu...

Everybody: Don't bother David for the next four hours and a self-hosting ClojureScript will pop out the other end. :)

Wait, he is building ClojureScript in ClojureScript - head explodes...

Yeah, let him work on it ;)

Exciting stuff.

@shaunlebron: Just ran across this, very nice. Some really good links at the end, too. (One has a minor typo - the "ClojureScript Style Guide" is the "Clojure Style Guide") Thanks for putting it together! https://github.com/shaunlebron/ClojureScript-Syntax-in-15-minutes