@danielcompton what if u r doing jit on build? For FB, performance matters, every CPU tick on client.

Sure, I'm just wondering what the real world performance differences would be, given that the browsers do a lot of these optimisations already (in the background). I'm not saying it's bad or they shouldn't do it, I'm comparing it to what is already going on

@danielcompton apples and oranges, browser’s JIT optimization happens on zillions of user machines again and again, prepack’s AOT optimization happens once during the build on developer’s machine - think of it as constants folding and loops unrolling on steroids - for the price of potentially increased javascript payload size

for sure

I guess in the current form it is only effectively useable for init-heavy js apps, because it optimizes this init code path and not much further

and it will be always a tradeoff between code size and speed, but it is promising, it will give us more options how small/fast apps we can ship

Looking for libraries like this https://github.com/retrofox/is-array/blob/master/index.js (4k downloads in a day https://www.npmjs.com/package/is-array) Looks promising "resolve/evaluate" functions on build 😛

I know spec was recently split out from clojure, is the same true for cljs? Do we now need to include it explicitly in project.clj?

Someone else using clojurescript + spec on front + JSON on back? I'm trying to exchange qualified name. My first try was user/name. On parse, just regular browser js -> js->clj -> :user/name But on write, :user/name -> "name". There is some default workaround?

https://dev.clojure.org/jira/browse/CLJS-536

https://groups.google.com/forum/#!searchin/clojurescript/js-%3Eclj$20namespace%7Csort:relevance/clojurescript/irTvXCeX1o0/wMFi4__CBAAJ

For now I'm using with-redefs to name full-name where (def full-name #(str (namespace %)"/"(name %))). Will do for now. Hope to get this fix in some short time 🙂

Oh, bug was closed? Declined? 😐

@souenzzo Yes, because the solution would break existing code. The problem is that you're going form a higher fidelity source to a lower fidelity. So there's going to be some data loss.

But it's also a question of how to get types across JSON, for that sort of thing I suggest Transit: https://github.com/cognitect/transit-format

Hi all. New to CLSC. What resources you recommend to get started?

Been playing with Haskell for 9 months (not sure if that helps) and use JS daily at work.

@dnavas really really liked Learning ClojureScript from packtpub

https://funcool.github.io/clojurescript-unraveled/ seems nice also

This one's good: https://github.com/magomimmo/modern-cljs. It gets advanced pretty fast though

@dnavas welcome! I'm in the same boat, I've been playing with Clojure and Haskell off and on for a while now. I finally started a side project with ClojureScript recently, though.

@ksmithbaylor enjoying CLSC?

@claudiu @pesterhazy thanks!

Hi all. Can anyone help me to get a npm lib into a leinigen project with the new npm support ?

does CLSC have good WebGL support/bindings?

ana nu

any one use macOS 10.12.4 with emacs 25.2 cider 0.15.0? does cider-jack-in working right?

@dnavas definitely! It's been a blast.

@dnavas interop with JS is trivial outside of concerns about advanced compilation - http://thi.ng has a ton of stuff around WebGL

Okay, I've been investigating this a little bit. But just to put a button on it. There is simply no way for a function or macro to determine the namespace in which it was called, correct?

I guess that doesn't even make sense to say, because there's a whole call stack involved

Seems like there's no way around having the user supply my library the name of the namespace they want loaded by their web worker.

Even though they might have specified it under :main in their compiler options.

Hi all, I hope someone can help me think more intelligently about state in re-frame. We are building a SPA with a lot of forms and we argue about using local state in the component vs. putting it into the db. How do folks decide where to put state? Looking at the examples, the simple time color only uses db, but the todo mvc uses some local atoms. Consider a component that allows a user to page through a list of employees. The component gets the list of employees and the page size, but we keep the current page number as local state. There can be 3 instances of those components on the page at one time. Seems good. On the other hand, it seems that the whole point of re-frame is to keep all the state in one atom. What about a form to add a new record with 10-12 fields? Do you keep it in a local atom until it is validated and submitted to the server, and then put it in the DB? Thanks for any advice you may give. If this is not a good place to ask this kind of question, I apologize (also for the wall of text).

@john at runtime the namespace isn’t especially interesting - usually it’s just user or something for the entire lifetime of the app

maybe what you care about is the namespace in which the function that immediately calls your function was defined - which isn’t available

@jeffmad something to help think about the problem: what you are describing is a common question and I think maps closely to the MVC pattern. Some data belongs in the model (and hence the global database), and other data is purely about how the data is presented to the user, or view data.

I dislike local data as it's harder to test, and harder to debug, but I recognize that it's easier to store page offsets and the like locally and it's easier to manage.

ratoms at namespace scope are great for this in reagent

Except then they're opaque and impossible to test

where my page is defined in a namespace, and page view specific data goes in that ratom

but I can populate the atom in my test

it’s not that bad

it’s not closed over, it’s namespaced

ah, I misread

but doesn't that keep you to having one global ratom for all your controls?

at namespace level = global

If I need two paging controls, what do I do?

the global ratom is for my data, and then each namespace level - OK that’s global too - has things only that view cares about

where the namespace defines some viewing state

it’s not the only way to organize an app of course (reusable components go in another utility namespace)

but the each page has a namespace, state of that page goes in ratom belonging to that namespace, that works pretty well for me

@jeffmad but I would say this: try to keep the components easy to test, easy to inspect, and easy to reuse.

Would anyone be able to help this person out? They're trying to use cljs.spec, but somehow s/def is not defined. https://www.reddit.com/r/Clojure/comments/6939wb/looking_for_a_guide_or_tutorial_using_cljsspec/

@noisesmith Well, you know, in the HTML file, you'll put <script type="text/javascript">require("my_ns.core");</script>... something to start things up. :main eliminates that boilerplate. But the webworker still needs something similar to launch.

That makes sense @tbaldridge thank you so much for your thoughts, Tim and @noisesmith

@john sure you require some namespace, that doesn’t put you in it

@john trying to do some sort of webworker framework?

seems for some reason the functions from spec.cljs are there, but not the macros defined in spec.cljc. Any idea what could cause that? The code itself runs fine for me, so I'm guessing it's their tooling that's messing up. They're using boot+lighttable.

yessir

I assume your users are calling some function like (invoke-webworker foo 42) and you want to go find foo. If that's the case, make the api be (invoke-webworker qualified-symbol & args). Then users can do (invoke-webworker `foo 42).

no

The worker must be launched, just like the main thread, right?...

right

Sorry, I'm way confused, but... The worker needs similar accommodations as the main thread. It needs at a minimum a script file. I have that working (without user input)

In compile mode :advanced everything works fine

in :none, I need to create a shim that loads cljs_deps

Which is always in the same place. fine

@john you could try https://github.com/thheller/shadow-devtools/wiki/ClojureScript-for-the-browser#web-workers ... it supports packaging web worker .js files properly

so they behave the same in :none and :advanced but properly split the code so worker only code is only in the worker file

But, in :none, I believe I must supply a require(namespace)

yeah, I worked on that sort of stuff before...it's not easy

if you put functions in vanilla collections instead of namespaces, I think this stuff becomes much simpler

it is easy ...

Best solution I could find was to say that you had to use :simple or :advanced to use webworkers

oh, but what @thheller is suggesting looks better, my work was back before modules were a thing in CLJS

I know it feels weird to have a hashmap like {:f f :g g} but directly passing things like this around and using them for lookup avoids the complexities of trying to use namespaces

@thheller your module solution is ultimately the way

But would my whole framework have to depend on devtools?

devtools is a build library .. no runtime dependencies

ok while in dev the REPL etc .. but nothing for production builds

But, would users of my library have to use devtools?

uhm anyone that wants to build the worker has to yes. the library itself no

CLJS proper doesn't support the :web-worker extension. so no other build tool supports it, only shadow-devtools (well and shadow-build which actually does this)

hmmm... And your not doing any runtime jazz to solve, directly, the problem I was looking to solve. You simply solve it at runtime, where the user still supplies their desired launch namespace, just at compile time rather than run time. Yeah, that's what it looks like

nope it just bundles up the generated js properly

Cross module code motion is going to be clutch for this whole webworker thing

basically really it just abuses :modules and then prepends importScripts(...) to load the dependencies

with some more tricks to make :none work

If we can transparently move around dependencies for webworkers, depending on what they call, it'll make workers performant and usable. Otherwise, at least in my lib as it is currently written, your whole app gets loaded up in every worker.

Probably similar to all the tricks I've put in at runtime. All that's left is the namespace to launch

this will still load all dependent code in the worker

oh

But because you're using modules, you should be able to leverage some code motion, right?

code that is only ever called in the worker will be in the worker

but whatever the worker depends on will also be loaded by it

oh

But it won't compile any non dependent code into the worker, correct?

(in theory)

so if you have :worker depends on :app it will contain app code

but if you have a :worker depends on :common and :app depends on :common, no app code will be in the worker

depends on how you structure the modules but yes

exactly

I'd think the user would put react in :app

I'm calling it screen in my lib. Might call it UI. I'm toying with the idea of pushing as much code as possible off the screen thread.

yeah react would be moved to screen probably unless you use anything in the worker that requires anything screen related

I like this screen / common / worker convention

It'll be interesting to see if it actually works - the whole module / code motion with workers (and my lib) thing

I still suspect that namespaces are useful within a single entity, while compiling code, but any solution for communication between entities should avoid indirection via namespaces and exchange data directly (perhaps I’m missing some nuance here though…)

@noisesmith yeah, I'm not sure we're on the same page. I'm not using namespaces to make calls between entities. We only need the namespace at launch time of the worker

oh, don’t mind me then - that’s just a configuration question, and not the kind of thing I was thinking of at all

pardon my airheadedness

lol I'm always grateful for your advice and thinking. This lib is brushing up against the limits of my capabilities and I'll need all the advice I can get.

Hopefully it's interesting enough that others will get involved too

Like, I could make the namespace declaration part of the API itself, like (def t (f/thread {:conf-map {:main "some.core"}})) Or I could have the user declare the :main once, at the top of some ns.. Which is better? Not sure

Or make them use shadow-devtools and somehow tie that in

I was close to releasing an alpha, but then I stumbled on a macro that makes everything way easier, obviating half my code base lol

So going through a few refactors now

@john namespaces do not exist at runtime in :advanced so not sure why you'd need them?

but yeah bundling the worker properly is a build tool issue imho

Yeah, it would be a shame to force a user to supply a launch namespace, when it's only necessary while not in :advanced mode

oh it is just as necessary in :advanced mode, even more so

In advanced mode, all I do is hand the single "your.js" to the worker and it works without a specified launch namespace. And I'm able to determine that at runtime using...

well, I have two ways

yeah I know the other "solutions" that exist today ...

but having the worker-only code in the main app.js is not something I like

one, just grab the last (.getElementsByTagName js/document "SCRIPT"), which may be too hacky

brb

eh, I guess that was my only method of grabbing the script name, atm

Another thing I'm doing at the moment: dynamically generating the worker file as a blob at runtime. This is convenient because when the user launches the thing, we can supply initialization data a priori. I just figured that feature out, so I need to refactor. Right now, all workers launch with the same code. With this new feature, lots of message passing initialization code can be removed.

I can send (and let the user send) any amount of custom launch code.

So, I'm toying with the idea of splitting this out into multiple libraries. One that just provides a thread sort of functionality. Another that provides executor pool funcitonality. And a third that emulates agents

And I can build agents on threads just by passing in custom launch code. I think the general pieces are falling into place.

But for now I think I'm just going to put them in separate namespaces

Actually, if I made the thread/agent constructor function itself a macro, then I could pull in the ns of the caller env, but then that'd be a macro... no mas

what's a good way to write "rest of list" ? is & the universal symbol for that?

[x & xs]

does CLSC have an official router?

@john Have you looked into the :preloads compiler option to load the ClojureScript Dependencies you need?

When I was trying to get modules working for :none and :advanced optimizations that's the route I found to be the cleanest

@spinningtopsofdoom interesting. I def hadn't considered that one. I'll look into it. Thanks!

@jeffmad my advice: wherever possible absolutely keep data in app-db. BTW, there's a #re-frame channel which may provide more responses

i'm having a problem getting my profiles and builds respected in my build scripts with cljsbuild when running via cron. anyone ran into this?

using syntax like lein do clean, with-profile prod cljsbuild once foo

and it seems to ignore with-profile prod