On application projects directories also affects which files are included in uberjar. Cljs files aren't necessary as it is already compiled into JS.

Hey, I'm trying to set up a remote nodejs repl following https://github.com/clojure/clojurescript/wiki/Remote-REPL but it fails with:TypeError: Cannot read property 'nameToPath' of undefined

file sync seems to be working fine but I don't see /tmp/cljs-repl-share/out

I also found this issue https://dev.clojure.org/jira/browse/CLJS-1933

@john I don’t think it’s idiomatic to intermingle @juhoteperi point is right on

Clojurescript compiler doesn’t really intermingle that much, so not evidence that this is a idiomatic pattern

And I would probably put .cljc under clj directory

Hey guys, could you comment on this suggestion: https://dev.clojure.org/jira/browse/CLJS-2376?focusedCommentId=48829#comment-48829 What do you think about metadata in ns form? Could it potentially break something?

I’ve always intermingled clj cljc and cljs. I don’t see the benefit of having separate directories. I just The the confusion of having to search multiple trees. Also sometimes I migrate a cljs to a cljc later (or the other way around) jumping directories with that sort of change just doesn’t make sense. If there is a compelling reason to not intermingle, it’d be great to here it. Perhaps I just haven’t seen it yet.

@juhoteperi just described a perfectly fine reason

you don’t want the deploy jar to include anything it doesn’t need

this is fairly standard practice - web assets end up somewhere else

anyways it’s a minor point - but to say intermingling is more or less idiomatic than not isn’t a supportable claim

lein has an option to exclude specified files from the uberjar, hasn't it? I agree that there's no widely accepted convention, although I don't see any reason not to intermingle, similar to mikerod

Hmm I see. Thanks for the explanation.

@just_crashed Yes, there are other ways to filter uberjar contents, but in those cases you have to create additional logic yourself, as you have lost the additional information the separate paths provide.

I don't see reason to intermingle as just putting files in separate paths doesn't cost anything. Editor should allow jumping between files in any path and moving files in git is easy anyway. But yes, this is minor thing.

is there anyone here who came from typescript and finally chose cljs, can you tell a story why?

If I'm working on a datomic/DB/SQL, pedestal/jetty, om/re-frame/react sort of stack, in a particular project, it's probably going to be most idiomatic to separate src/clj from src/cljs

But that could just as easily be called src/frontend and src/backend

I hadn't thought about the jarring scenario. That's an extra factor too

If I'm able to write 90% of my app in cljc though, I doubt I'd go about making split directories just for the sake of having them.

But 90% of the clj/cljs work out there is probably going to involve that frontend/backend architecture

@dnolen if I was writing a cross platform lib or data structure, would you still recommend separating out clj/c from cljs by directory?

@razum2um I am not 100% here or there yet, but I’ll write my thoughts on Typescript vs ClojureScript vs Reason/Bucklescript in a thread...

@razum2um I went through a similar path as @orestis except flow type then reason the cljs. My basic issue with flow is that it added a lot of work but still wasn’t complete or reliable enough to be worth it. Hard to know if something was actually typed. Reason is still basically an internal tool that is available for the public to play with. I’m looking for something that has power in rapid prototyping and is deployable. cljs so far fits that bill now that I can reliably use the npm ecosystem

@john no issues with cljc in clj dir

Breaking this out of that huge thread — does anyone have experience/ideas about how to introduce CLJS gradually into an existing system without having to do a big rewrite? Browser or Node.js perspectives are welcome.

@orestis again Google Closure is the answer

but it’s WIP

but as far as we can tell Google itself wants to leverage node_modules

the whole point of our deeper integration with Closure’s support for node_modules deps is that you could just replace your JS pipeline

that’s the long term goal

Ah, I was more asking about systemic approaches, like e.g. create a small self-contained CLJS library that exposes somehow a JS API... (first thing that comes to mind). There’s a technical perspective which I think CLJS easily wins, and there’s a social perspective because it’s an “alien” technology. My hope is that as people experience it up close and see it working, they’ll be more amenable to using it in other parts of the system.

you cannot incrementally adopt CLJS because you cannot incrementally adopt Closure

whole program optimization is an all or nothing thing

Surely though you can export a CLJS library as an opaque .js dump with some public API? I’ve used this approach with Typescript with good results.

@orestis if you have "world in an atom"-type architecture, maybe have a look at datascript, it has a js api

@orestis yes but it’s uninteresting outside of Node.js only

also dnolen's mori maybe?

every JS mapping you make will dupe CLJS runtime

but this just isn’t real problem

Rollup is the wakeup call

@dnolen Can you explain a bit “every JS mapping you make will dupe CLJS runtime” ?

in order to give JS users something you need to compile to JS

which means you dump the standard lib into your lib

but every CLJS exposure lib must do this

Ah, you mean that if say I export a “form validation” CLJS library and then a “data transformation” CLJS library, they will duplicate parts of the CLJS runtime because they wouldn’t be DCE’d together?

that’s exactly right

whole program optimization is all or nothing

separate compilation isn’t a thing

Gotcha — but still, you can plant a seed and keep adding functionality to that seed. It’s no worse than adding an npm dependency of similar scope.

but you can’t share anything across separate compilation artifacts

so it’s impractical in the general case

(i.e. browser)

Gotcha. Perhaps numbers will show how many X kb of npm dependencies are removed vs Y kb of CLJS/Closure dependencies gained.

https://www.npmjs.com/package/rollup

gets downloaded 1.2 million times a month

you only need to convince a fraction of these people we’ve taken the concept to a higher level

because you don’t need to make your lib work

many JS libs are boringly written

and Closure will destroy boringly written code

So your argument is, instead of starting by writing CLJS code, start by replacing all your build pipeline with CLJS?

absolutely

the groundwork is already laid

Wow, really? I’d never thought of that. So take an existing JS codebase, keep all the JS in and try to subsume it into a CLJS build pipeline?

all we need is more people to contribute to make it better

you can either wait for the current set of contributors to fix your problems

or you can fix your problems now and let that future arrive quickly

Is there an example somewhere of a project having side-by-side JS and CLJS? This really piques my interest. Getting CLJS in even as a compiler tool would be fantastic, since most projects will see an immediate tangible benefit of reduced bundle size for free.

@orestis it already works 🙂

we get bug reports about this stuff right now

the simplest case is greenfield ES6/Common.js code

if you’re doing that there’s nothing to do - we support that

the harder case is random NPM libs - because sometimes people write unnecessarily dynamic stuff - but in many cases those are boring PRs

Sorry, I mean, not pulling in code from npm, but your own “legacy” JS code.

for your own stuff it might just work yes

but it really depends on how fancy you got

people do unreasonably wacky stuff with their build pipelines

that’s not really in scope for our goals

stuff like this is why shadow-cljs is reasonable answer

but unlikely path for ClojureScript itself to pursue

Of course, yes. I see that this team relies on requirejs. I’ll have to see how closure plays with that.

anyways if you want to DCE the world - the ClojureScript/Closure way is the approach you should contribute to

and given that you have the Google behemoth behind it - I know where I’m placing my own bets

speaking of ... I took a create-react-app demo app and compiled it with shadow-cljs with basically zero changes. https://github.com/thheller/react-redux-realworld-example-app/tree/this-is-madness

could start using CLJS inside that project seamlessly

create-react-app is monstrosity, or was

it makes ClojureScript looks like a light salad

For me it’s not Google per-se, but the history of Google Closure and the proven for year code. Lots of behemoths have produced shiny things that are forgotten now.

last time I tried create-react-app it took 5 minutes on a 4-core machine and it generated 120mb of JavaScript

Hah, I’m building an Electron app and I can’t put it in Dropbox unzipped because of the million tiny files in node_modules 🙂

(This won’t be distributed to people, so I’m fine doing that)

@thheller The need for Babel there is to convert the JSX into JS?

exactly. I didn't integrate that yet but it could be automated as well

@orestis Closure isn’t very shiny and to be honest - I don’t think anyone uses it as much as we do

my point is rather that it’s like JVM - it’s not going anywhere

and it’s only going to get more robust

Well @dnolen and @thheller thank you both for your work and energy you are pouring into this, each from their own points. I hope that I will be able to contribute back one day, even by spreading the word.

@dnolen Funnily enough, I am using OpenLayers, which used to be a Closure-based library, but since have switched to ES6 modules. Not sure what the rationale behind it was, but I guess the non-shinyness of Closure played a part.

Closure can consume ES6 modules

so probably no difference from Closure perspective

ES6 is basically a modern way of writing ClosureJS. similar rules regarding static imports and such

so it makes more sense to write ES6 these days and get the same benefits either way

@orestis one problem here is that if you’re not in the ClojureScript community people don’t understand what Closure is doing

we’re the only ones following along

Hm, I’m curious though — they had a huge codebase full of goog.* stuff and now it’s completely gone.

it doesn’t matter

ES6 is just Closure stuff

by switching to ES6 they’re making it possible for others to consume, but nothing has really changed from their perspective

Oh, sure, it’s just a weird move to make all this effort. Probably yes, it’s easier to just say “use rollup to get tree-shaking”.

exactly

it’s about making it possible for non-Closure build stuff to consume

Well, I have to go. Thanks for the conversation @dnolen — I’ll try to write a blog post exploring this avenue soon.

@dnolen Do you mind if I quote you in a future blog post? I like the “long game” take. Of course I can run it by you before publishing.

sure

it’s just true, we’ve stuck by our principles over the last seven years to the varied complaints of the JS world who haven’t taken the time to understand the big picture

in the end I believe such complaints don’t matter - and surveys confirm - JS users are now 2nd behind Java

even though we refuse to adopt their ways

this isn’t going to change

https://groups.google.com/d/msg/clojure/WwocFhk45us/g7WujRYCQs0J

from right after the release of ClojureScript is a good reminder it’s important to give people what they actually need - and ignore what they believe they want

ohh, I remember that thread

interesting to review it now, 7 years later

To help ensure easier upgrades to future versions of Closure, the ClojureScript compiler test suite is now automatically executed daily using the latest Closure Compiler and Closure Library. (See http://github.com/cljs-oss/canary)

Quick namespacing question. If I create a namespace foo.core, and refer funcs from other namespaces with (:require [bar.core :refer baz]) Should I be able to access baz at the repl with (foo.core/baz) ? Not working in my current repl setup.

@jrbrodie77 At the REPL you need to do (require '[bar.core :refer [baz]])

Oh, I see what you are saying. No. Referring doesn't put the var in the namespace you are in.

You could do (bar.core/baz) or just (baz)

Also note that the "argument" to :refer is a collection of symbols to be referred.

hey guys, which framework would you recommend for making a simple website? I've searched for a bit, Luminus and fulcro look really good

I've been wanting to check out qlkit for a next web frontend project

And precept

Qlkit may be the simpler of the two though

Definitely exercise luminus and fulcro too

I guess they're frameworks in a different sense

I'm not as familiar with fulcro

I think I'll try out Luminus, as it targets beginners

You might want to check out re-frame too, as an alternative to fulcro

they’re both good frameworks (if that’s the right term), just different approaches.

thanks 👍

Also see yada. At least for the web server part, seems to have a lot of batteries included.