Fork me on GitHub
#shadow-cljs
<
2017-10-14
>
Jon03:10:38

I remembered you said you had some solutions

Jon03:10:08

I think we need to make sure that they are available on the docs

Jon03:10:18

at least people can Google them

thheller07:10:59

what do you mean?

thheller07:10:28

the loader? yeah that needs docs

Jon09:10:09

does shadow-cljs consume JavaScript code?

thheller09:10:34

hmm? I don’t understand the question

Jon09:10:04

heard in the video, now ClojureScript compiler can load JavaScript files directly?

Jon09:10:19

maybe CommonJS files, via Closure Compiler

Jon09:10:33

just js files, but not in a npm package

thheller09:10:52

yes you can do that

thheller09:10:01

(:require ["some-name" :as foo])

Jon09:10:18

not sure why I would write JavaScript in my project though...

thheller09:10:33

:js-options {:resolve {"some-name" {:target :file :file "path/to/file.js"}}}

thheller09:10:43

the part thats missing is the jsx support

thheller09:10:55

I have some ideas around that but its unfinished

Jon09:10:11

sounds nice~

thheller09:10:32

just ignore the video … most things just do not apply

Jon09:10:37

configs much shorter in shadow-cljs

Jon09:10:02

do not apply to shadow-cljs, or to current version of ClojureScript compiler?

thheller09:10:10

do not apply to shadow-cljs

thheller09:10:15

we do things differently

thheller09:10:23

the CLJS stuff has way too many issues to be viable

Jon09:10:39

😛 sounds like....

Jon09:10:10

do you believe shadow-cljs's solutions are better?

thheller09:10:16

one thing I learned from antonios talk is that I need to blog more 🙂

thheller09:10:33

yes I do. well .. otherwise I wouldn’t have built them 😉

Jon09:10:33

I agree with that.

Jon09:10:55

being a user, I just feel that, maybe I don't need those features, but when I need, I do hope they are there. switching to other languages can be hard choices

thheller09:10:04

I’ll try to write short blog posts about certain features I implemented

thheller09:10:27

but often things are really not relevant to the user, just to someone interested in the compiler stuff

Jon09:10:37

and Tweets 😉

thheller09:10:59

IMHO the JS integration is much more reliable in shadow-cljs, I even started some work yesterday to almost completely remove the need for :externs

Jon09:10:14

really, we can solve the problems that was solved by externs now?

thheller09:10:47

not totally no but good enough for most cases

thheller09:10:09

React works completely without externs

thheller09:10:19

as will most other libs

thheller09:10:46

but anyways .. its a bit too early, needs some tuning. first steps are promising though

Jon09:10:02

but how? is that part of code not processed by Google Closure Compiler?

thheller09:10:25

I just generate the externs …

thheller09:10:37

so its still using externs .. but you don’t have to write them

Jon09:10:45

interesting

thheller09:10:27

I’ll definitely write a longer post about that

thheller09:10:48

I sort of changed my mind on the whole subject recently

thheller09:10:08

it is much more important that users have a good experience and don’t run into as many :advanced issues

thheller09:10:18

than it is to save a few KB of js

Jon09:10:38

yeah, I think so... for people from JavaScript it's more important.

thheller09:10:40

I always was pretty obsessed with file sizes

thheller09:10:54

but thats nonsense if your program doesn’t work

thheller09:10:12

so I’ll provide the automated way first … and let the user optimize if they want to

Jon09:10:14

Uglify was not good years back, when Closure Compiler was good. but people chose Uglify..

thheller09:10:31

mhuerbert did a comparison yesterday in his app which went from 601kb with manual externs to 603kb with generated externs

thheller09:10:39

so its really not that bad

thheller09:10:01

I’ll finish a few things then you can help me test as well

Jon09:10:05

gzipped and the difference even smaller

Jon09:10:23

okay 🙂

thheller09:10:50

gotta go afk for a few, bbl

Jon09:10:51

wait, I'm not sure I used much npm packages in existing projects...

thheller09:10:22

you already ran into the shortid issue, which would be covered by the new stuff

Jon09:10:10

maybe time to use more npm packages now

thheller11:10:37

guess I broke it with the 2.0 and never updated

thheller17:10:36

I hate blogging

thheller19:10:57

I just added support for generating externs from files such as this

thheller19:10:06

# untyped externs will be generated by this file
# the filename must match the <id-of-build>.txt

# properties are just listed one per line
propertyA
propertyB

# globals are prefixed by global:
global:someGlobal

thheller19:10:25

externs/<your-build-id>.txt

thheller19:10:41

I think that should cover the last remaining issues

thheller19:10:10

needs some more testing, will write blog post sometime soon

mhuebert21:10:45

on a little vacation this weekend so not much keyboard time. re externs from a txt file: i think externs are more likely to be re-used on a per-library basis, vs. per-build. if i get the externs working for some JS lib once, i may want to re-use in other projects/builds.

mhuebert21:10:55

nice post about bootstrap. i also want to do some writing yet about how useful this is for projects like maria

mhuebert21:10:37

not sure how many manual externs one will have to define, but could it also be included as a vector of strings in :js-options? ["propertyA" "propertyB"]

mhuebert21:10:56

just an idea, not sure of all the tradeoffs