the write(... line is a shorthand property notation https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Object_initializer#method_definitions so something like:

(def myWritable (Writable. #js{:write (fn [chunk encoding callback] ,,,)}))

(require '["stream" :as stream])

(def ws (stream/Writable. #js {:write (fn [chunk encoding next] (js/console.log (.toString chunk) (next)))}))

(.write ws "ping!")

Thanks a lot guys 🙂

I love it and always go by it.

Navigating projects that have that separation is a chore.

Do you mind giving the pain points?

And maybe a view on why people think its a good idea to split it up?

You navigate between namespaces using either your IDE's capabilities or file tree browsing. If you don't have an IDE (e.g. when quickly looking something up on GitHub), you have to resolve to file tree browsing. So, within an IDE, you don't really need those directories - you can just navigate to the right ns. So separation by extension doesn't help here. And while using a file tree, it's much better to have everything together rather than incessantly switch between 3 directories. "Alright, this CLJS function calls this function which is in that namespace. Ah, crap, it's a macro - now I gotta go to a different dir. Ah, crap, that function is in a .cljc file, now I gotta switch once again." As to why people separate those files, I see only 2 reasons: • Desire to organize, even when that organization is detrimental • Minimizing the size of an uberjar by excluding the src/cljs directory. But I'm pretty sure this can be solved by simply excluding all *.cljs files instead

Flat is good. Generally a good rule of thumb for any data modelling, including source code directories.

I think at some size it's kind of a mess no matter what. You just need to make some kind of decision and learn to live with yourself lol

I used to prefer hierarchies, but at some point I realized that hierarchies don’t make things more ordered, it just makes for more places to look. So better to flatten things out, and only create levels when there’s enough sub-content to justify it. And when you do, group by functionality, not technology.

I’m much more likely to look for all the login stuff, than all the cljs files

> group by functionality, not technology Exactly. BTW Sean Corfield has a few posts in his blog on monorepos - definitely relevant for larger projects.

We don't have any .cljc or .cljs at work so I don't have much of an opinion on it. Two of the OSS projects I mention are primarily .cljc and do not separate out the few .cljs/`.clj` files into different trees. I think that separation makes sense when you have almost completely separate implementations for a common API in a library (`clojure.core.async` is like this, as I recall) because you end up with the same namespace in both trees -- so they must stay separate. But in (web) apps, you are rarely going to have that: you'll have some pure frontend code and some pure backend code and some shared code and they won't overlap in namespaces so it makes no sense to have separate trees.

(we may build a ClojureScript app at some point so I may have a stronger opinion at that point, but I suspect I'll be in the latter situation -- web app with no overlapping namespaces)

What I haven't figured out is why anyone would split .cljc into its own folder considering it can have namespaces clashing with both cljs and clj

Not sure what you mean there?

Well for instance, the bootstrap I'm using separates clj, cljs, and cljc. It uses the same namespace for each folder. So clj/app/home and cljs/app/home are both (ns app.home). Not a problem if you're only working with clj and cljs. The imports assume it's from their folder. But if you have a third similar namespace, cljc/app/home, then files from neither clj or cljs can import that cljc file, because they are gonna prioritize their own namespace. So I'm not sure why anyone would work with a separate cljc directory with name spaces that could potentially overshadow the other two.

Ah, got it. You mean there's less chance of accidentally blocking a ns if you keep them all in one tree.