Fork me on GitHub
#proton
<
2016-07-18
>
tgg15:07:02

@thheller: was thinking about the namespacing cljs.core issue again; is there any reason not to try and detect and reuse an existing cljs.core instance? supposing it has the right version

tgg15:07:50

Was thinking of writing a cljs package and thought what if I end up with three cljs.cores loaded into memory!

thheller15:07:24

@tgg the problem is that they must coordinate with each other

thheller15:07:44

lib A loads goog/base.js

thheller15:07:58

lib B also loads its goog/base.js

thheller15:07:10

so if A did any modification to goog

thheller15:07:14

B will override it

thheller15:07:00

shadow-build will disable goog.provide for example, but proto-repl enables it again and tries to provide cljs.repl again which is an error in closure

thheller15:07:20

cljs.core is not the problem

tgg15:07:39

no sorry I realise that; I really meant all the cljs assets required for a reasonable runtime

tgg15:07:43

but you're right

tgg15:07:36

although; is there a cheap hash one can do to check for modifications? would that be a potential work around?

thheller15:07:42

closure is sort of at odds with the whole node.js ecosystem

thheller15:07:50

since closure expects to optimize the whole program

tgg15:07:56

oh christ yeah

tgg15:07:14

overlooked you saying closure there; just parsed it as clojure in my head

tgg15:07:04

sorry; not much help at all with that!

thheller15:07:13

to be quite honest

thheller15:07:50

node.js packages written in cljs are far from ideal

tgg15:07:13

think that's a byproduct of closure compiler?

thheller15:07:19

no it isn't used

thheller15:07:45

it is the way closure style code is organized

thheller15:07:57

goog.provide and goog.require

thheller15:07:12

is a completely different style from node require

tgg15:07:33

it does feel as if there should be a more 'native' node.js approach to clojurescript

thheller15:07:22

well ... 😛

thheller15:07:53

the problem is that there is no "default" way to package things for node

thheller15:07:58

it is all optimized for the browser

thheller15:07:10

node has totally different concerns

thheller15:07:21

and you really need to generate different code for the two

thheller15:07:57

and the thing I did with shadow-build

thheller15:07:07

doesn't really work unless everyone uses it

thheller15:07:38

or sharing the cljs.core instances like you suggested

thheller15:07:43

only works if everyone does

tgg15:07:50

yeah 😐

tgg15:07:00

if only atom had been written in cljs from the start!

thheller15:07:24

yeah same story with React 😉

tgg15:07:49

thanks for going over that @thheller, interesting stuff

tgg15:07:55

lots to mull over

thheller15:07:24

I'm not even sure how the node.js world deals with stuff like this

thheller15:07:38

conflicting dependencies and such

tgg15:07:57

well christ; we've all seen the dependency graphs that nodejs spits out

thheller15:07:01

the thing is that you really WANT to share cljs.core instances

thheller15:07:53

but how do you make sure both use the same version 😛

thheller15:07:15

since libs are always lib+cljs.core

thheller15:07:24

and cljs.core is not standalone

tgg15:07:38

would be a great project ☝️

tgg15:07:40

standalone cljs

thheller15:07:46

not possible

tgg15:07:50

it's fairly heavily wired into closure isn't it?

thheller15:07:09

well maybe possible

thheller15:07:15

but there is the whole macro side of things

thheller15:07:32

it is built for whole program optimization aka closure compiler yes

thheller15:07:16

funny enough there is work being done to compile ES6 type import or export stuff to closure

thheller15:07:20

but not the other way arround

thheller15:07:30

at least not that I have found

thheller15:07:41

but I don't use node so I don't really care 🙂

thheller15:07:05

just annoying for hybrid stuff like atom/proton

tgg15:07:37

Potential for a proton ecosystem to depend on a single/organised set of cljs.core instances though?

tgg15:07:56

I certainly write now with a mind to proton > atom

thheller15:07:13

well I can certainly imagine a packaging step that won't load cljs.core if it is loaded

thheller15:07:37

but that again only works if everyone does it

thheller15:07:53

and doesn't deal with the whole version thing

thheller15:07:24

but it is just a packaging thing

thheller15:07:17

for example if you run lein run -m build/release on proton

thheller15:07:52

it creates a plugin.js that is just some setup code + goog/base.js + cljs/core.js etc concatenated together

thheller15:07:36

ehm sorry not release the dev-repl one

thheller15:07:47

release runs through the compiler

thheller15:07:12

but you really don't need it since :simple doesn't do much and :advanced is pretty much impossible for node

tgg15:07:34

makes sense

thheller15:07:58

so if you instead of just concatenating things together

thheller15:07:23

you wrap it in if (!thing.exists) { ..code.. }

thheller15:07:30

there would be no conflicts

tgg15:07:12

sounds feasible to me; might experiment

thheller15:07:27

again only if everyone does it and you ignore versions

thheller15:07:45

since it completely bypasses what node and npm try to do

thheller15:07:56

I hate node 😛

tgg15:07:13

yeah; not a particularly big fan myself