Fork me on GitHub
#shadow-cljs
<
2017-09-25
>
thheller07:09:18

@bolasblack make-browser-overrides is new, will fix. it doesn’t support "foo":false yet which is used to “ignore” certain require calls in the browser

thheller07:09:05

the cache issue I found and fixed

thheller07:09:28

@bolasblack do you know which npm package caused that error? need to find a package I can test my fix with 😛

thheller07:09:34

nvm found one

bolasblack12:09:52

I think aws-sdk caused this issue

bolasblack12:09:46

And I got another exception:

package airtable tries to map request but it doesn't exist
{:from "request", :to "xhr", :package-name "airtable"}
ExceptionInfo: package airtable tries to map request but it doesn't exist
        clojure.core/ex-info (core.clj:4725)
        clojure.core/ex-info (core.clj:4725)
        shadow.build.npm/make-browser-overrides/fn--19590 (npm.clj:33)
        clojure.core/fn--7874/fn--7876 (core.clj:6716)

bolasblack12:09:00

I'm trying to use the package airtable in nodejs, and current shadow-cljs.edn :target is :npm-module

thheller14:09:31

@bolasblack I think I fixed that, I’ll make a release now so you can test it

thheller14:09:48

"browser": {
    "lib/aws.js": "./lib/browser.js",
    "fs": false,
    "./global.js": "./browser.js",
    "./lib/node_loader.js": "./lib/browser_loader.js"
  },

thheller14:09:17

fun times though … "lib/aws.js" should be "./lib/aws.js" 😛

thheller14:09:12

are you running node?

thheller14:09:21

or :js-provider :closure?

thheller14:09:46

nvm :npm-module thats :js-provider :require

thheller14:09:51

yeah definitely fixed

bolasblack03:09:38

Hi thheller, https://github.com/bolasblack/airtable-notifier-temp this is the example project. I'm trying to create a project runing on nodejs, check records changing in Airtable per minutes

bolasblack03:09:12

I tried 2.0.0-alpha8, and get the error:

java.lang.AssertionError: Assert failed: (cljs-util/is-file-instance? cache-root)
        at shadow.cljs.devtools.config$make_cache_dir.invokeStatic(config.clj:112)
        at shadow.cljs.devtools.config$make_cache_dir.invoke(config.clj:112)
        at shadow.cljs.devtools.server.worker.impl$build_configure.invokeStatic(impl.clj:116)
        at shadow.cljs.devtools.server.worker.impl$build_configure.invoke(impl.clj:90)
        at shadow.cljs.devtools.server.worker.impl$fn__21954.invokeStatic(impl.clj:207)
        at shadow.cljs.devtools.server.worker.impl$fn__21954.invoke(impl.clj:199)
        at clojure.lang.MultiFn.invoke(MultiFn.java:233)
        at shadow.cljs.devtools.server.util$server_thread$fn__21838$fn__21839$fn__21843.invoke(util.clj:159)
        at shadow.cljs.devtools.server.util$server_thread$fn__21838$fn__21839.invoke(util.clj:158)
        at shadow.cljs.devtools.server.util$server_thread$fn__21838.invoke(util.clj:143)
        at clojure.core.async$thread_call$fn__7981.invoke(async.clj:442)
        at clojure.lang.AFn.run(AFn.java:22)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:748)

Jon15:09:21

I got an idea,

Jon15:09:26

do you think it's possible that we bundle ClojureScript projects with a shared library called clojure-x.x.x.js and put this file in CDN?

Jon15:09:01

if people are building multiple page websites, they can share this library without bundling it into each project

Jon15:09:33

meanwhile, there might be people who want to try ClojureScript as a part of project, like using :target :npm-module.

Jon15:09:05

not sure about this part, but we have to make sure when he imports the package, he does not require ClojureScript multiple times

thheller15:09:48

@jiyinyiyong this would only be possible without :advanced optimizations …

thheller15:09:10

also wouldn’t solve any issues I’m aware off

Jon15:09:54

😥 then how about multi pages website?

Jon15:09:05

how do you share common code?

thheller15:09:07

code splitting via webpack or :modules?

Jon15:09:04

I don't think code splitting is enough

Jon15:09:36

say you split module a.js and b.js into libs.js in project A,

Jon15:09:55

not assurance that in project B libs.js is the same

thheller15:09:03

not sure what you are after? cross project splitting is never safe

thheller15:09:45

multi page website is one project with multiple “entries”?

Jon15:09:21

may be several projects, not sure

thheller15:09:32

in CLJS for :browser target you can :modules {:shared {:entries [cljs.core]} :page-a {:entries [app.page-a] :depends-on #{:shared}}, ...}

thheller15:09:57

but no you cannot create something like jquery.js that is included in every project and never changed

thheller15:09:23

well you could with a whole bunch of effort and sacrificing :advanced .. so not sure that would be worth anything

Jon15:09:46

:thinking_face: getting more and more confused about scaling ClojureScript into multiple pages

thheller15:09:09

:modules is the way to go for :browser

Jon15:09:56

if we have a solution for hosting ClojureScript libraries on CDN, that would be another factor to convince others of using ClojureScript. Anyway...

thheller15:09:26

that just isn’t feasible for cljs, it just doesn’t work with :advanced

thheller15:09:37

also not really an issue to be honest

thheller15:09:52

CDN is not a selling argument

thheller15:09:27

play with :modules, it does all the code splitting you could ever want

Jon15:09:45

but if some has like 10 websites, each using ClojureScript, what's the best solution to reduce the bundle sizes?

Jon15:09:16

by compiling with a single instance of shadow-cljs and rely on :modules?

thheller15:09:34

if the 10 websites are in one CLJS build use :modules

thheller15:09:59

if by websites you mean different domains, they shouldn’t share anything anyways

Jon15:09:45

but we used to do it for jquery, react, vue, lots of them...

thheller15:09:04

“used to do it” … do you still do it?

thheller15:09:25

and yes it works for those libs since they don’t do :advanced optimizations …

thheller15:09:35

yes, that pattern will not work with CLJS

thheller15:09:56

it could work but only without :advanced, which would mean you’d download MORE

thheller15:09:11

so the opposite of what you want to achieve

Jon15:09:16

😅 how about :simple

thheller15:09:34

that is without :advanced … anything that is not :advanced

Jon15:09:04

alright...

thheller15:09:20

look at it this way

Jon15:09:35

so the cljs runtime library will be huge?

thheller15:09:35

you can have a CDN/cljs.js that is 2mb

thheller15:09:53

or you can have your-site/cljs.js that is 50kb

Jon15:09:55

😱 even gzipped?

thheller15:09:15

I don’t know the exact size … but it is a whole lot bigger

Jon15:09:33

😱 can't imagine..

thheller15:09:44

also your-site/cljs.js will only contain code that your-site uses. so no useless code is executed

thheller15:09:53

ie. FASTER than generic builds

thheller15:09:32

don’t think that something is the best solution in the world only because the JS world is doing it

thheller15:09:44

there are other options. each with its own pros/cons

Jon15:09:33

I don't have numbers to compare, just have to believe old experience 😞

thheller15:09:57

I don’t buy the whole CDN argument either

thheller15:09:19

do the files in the image above actually come from a CDN?

thheller15:09:47

btw. google is using the closure compiler for pretty much all their public projects. I think they know a thing or two about optimizing download sizes

thheller15:09:52

service worker … so no CDN

Jon15:09:30

from CDN... only the first time they are downloaded

thheller15:09:57

why are they using shadow? 😛

thheller15:09:14

really I wouldn’t worry about it too much

Jon15:09:16

well, at least I'm convinced now...

Jon15:09:33

what "shadow"?

thheller15:09:34

you can still do react,vue,jquery as externals from a CDN

thheller15:09:47

their domain is

Jon15:09:21

wow... surprised me too, didn't notice

Jon15:09:46

many of us learn English at an older age, I guess

Jon15:09:32

then how about using ClojureScript partially in a Webpack projects?

Jon15:09:51

like creating a package with cljs, or packages... then require them in Webpack,

Jon15:09:27

it seems that there will be multiple versions of runtime library, if the code are precompiled to js or somehow

thheller16:09:09

you are free to do that if you want … it just won’t be optimal

thheller16:09:04

and no you are not supposed to use multiple “optimized” libs in one project

thheller16:09:18

that is not “whole program optimization”

Jon16:09:59

javascript ecosystem is a mess 🙂

thheller16:09:59

I really don’t understand what problem you are trying to solve. is there an actual problem you have right now that is not just theoretical?

thheller16:09:21

only because it is not what the JS world does doesn’t mean its better or worse

thheller16:09:25

its just different

thheller16:09:01

:advanced is totally optional .. nobody forces you do use it

Jon16:09:23

when I'm learning new things, I just want to use my old technology and try if it works well.. and I'm not alone.

Jon16:09:51

I think many people from js world would try it in those ways too.

thheller16:09:55

but how do you learn new things if you expect them to be identical to old things?

thheller16:09:25

it is absolutely true that CLJS (and shadow-cljs) needs better documentation for these topics

Jon16:09:51

only I tried then I realized it's just different

thheller16:09:54

even a comparison would be desirable showing the pros/cons of both

Jon16:09:07

examples I think 🙂

thheller16:09:18

its just hard making comparisons without good real world examples

Jon16:09:39

do you create real world projects in cljs?

thheller16:09:56

its just rare to find someone that has experience with the JS solutions and the CLJS ones

thheller16:09:06

yes I do .. but they weren’t JS before

Jon16:09:29

yeah... totally two languages and two ecosystems

thheller16:09:14

I have never used webpack in an actual project for example

thheller16:09:22

in my pre-CLJS days it didn’t exist

Jon16:09:54

I think webpack is older than you think

Jon16:09:48

"Mar 4, 2012 – Sep 23, 2017"

thheller16:09:44

well maybe it existed but I never heard of it back then

thheller16:09:00

I have been on my own CLJS tooling since mid-2013

Jon16:09:00

me too..

Jon16:09:21

that's like four years

thheller16:09:27

shadow-build had the first public release on 14 Dec 2013

thheller16:09:34

but I had used it for a while before then

thheller16:09:38

and lein-cljsbuild before that

Jon16:09:12

...almost 4

thheller16:09:16

so yeah .. safe to say webpack didn’t exist when I was doing pure JS work 😉

thheller16:09:38

I think I never used actual JS tools back then either

thheller16:09:46

just a bunch of custom shell scripts + coffescript

thheller16:09:18

node didn’t exist either … I’m old 😉

Jon16:09:38

I was using CoffeeScript too, it's like in Shanghai there's only one company choosing CoffeeScript as primary language. Now no company...

bolasblack02:09:27

Not only one company, the company I'm working for is also worked with CoffeeScript as the main programming language in backend and frontend. After nodejs 6.x and react, we start use JavaScript because of ES6 feature

thheller16:09:52

I wouldn’t use it again either

Jon16:09:58

Node was born in 2009~

thheller16:09:20

I only used it because I was doing ruby at the time and coffeescript looked more like ruby than JS

thheller16:09:45

really? ok guess it did exist then 😉

Jon16:09:55

well. CoffeeScript was my first language to create real world apps..

thheller16:09:02

it wasn’t commonly used though … all my tooling was ruby based

Jon16:09:32

before that I learnt to write scripts in Python. learnt C in classes also but never really know how to use it.

Jon16:09:46

Ruby was cool..

Jon16:09:19

we just have Ruby Conf in China a week a ago... however it was full of other languages

thheller16:09:33

I went from Pascal, Perl, PHP2, JS, Ruby, CoffeeScript, Erlang, Clojure

thheller16:09:43

with a bit of C and python inbetween

Jon16:09:47

😂 like Haskell, Elixir, Erlang. I heard they talked about that

thheller16:09:52

oh and I forgot Java for a very long time 🙂

Jon16:09:07

Much longer history...

thheller16:09:24

yeah been doing (professionally) this since 1998 or so 😉

Jon16:09:56

almost 20 years, like several people I just met...

thheller16:09:01

learned coding earlier

Jon16:09:13

not many people in China say they have written code for almost 20 years..

thheller16:09:05

well it took me a couple of years to unlearn some crap, wish I started functional earlier 🙂

thheller16:09:10

soo much time wasted on OOP

Jon16:09:12

I'm not sure if you hate on the same parts of OOP as I do... I don't know much about OOP, although heard a lot.

Jon16:09:55

React is using OOP even it learned a lot from FP. It appears OOP is still the mainstream

thheller16:09:45

well it isn’t all bad, sometimes it is useful

thheller16:09:12

the Clojure “data-first” approach is better though

Jon16:09:21

agreed, but hard to explain it.

Jon16:09:07

I feel the most when people say Redux is so complicated. and I think it should not be like that.

Jon16:09:02

oh, just old topic, actually someone told me he wants to use ClojureScript in his project, partially. and I recommended shadow-cljs somehow...

Jon16:09:52

on WeChat, we have a group, chatty but half the topics are related to Clojure(Script)

thheller16:09:26

I see whenever someones “stars” shadow-cljs on github … most of the people are from your region

thheller16:09:53

not too many stars yet … once I finish the 2.0 release I will start blogging

thheller16:09:13

with examples and stuff. need to get better documentation.

thheller16:09:37

just have to finish the JS integration story since that has been bothering me for quite a while now

Jon16:09:14

only people speaking Chinese are related to me. Too many languages in Asia

Jon16:09:39

like more then 3 months?

thheller16:09:32

well since day #1 but cljsjs was a good enough fix for me since I basically only used cljsjs.react

thheller16:09:42

everything else I wrote myself instead of using JS libs

Jon16:09:31

reinventing everything.

thheller16:09:59

yeah … good because you learn how everything works .. bad because it takes way too much time from doing actual useful stuff 😉

Jon16:09:49

to he honest I don't like doing that

Jon16:09:53

even though it's good to learn things in detail, but there are too many things to learn, and working in a startup company in my age, I feel not good

Jon16:09:49

so most the time I spent just looking for solutions.

thheller16:09:19

yeah but sometimes the solution is 3 lines of code instead of some generic library

Jon16:09:40

which means?

thheller16:09:54

that using a library is not always the best solution

Jon16:09:28

right... that happened a lot on npm

Jon16:09:56

3 lines of code can be a nice solution sometimes ;D

thheller16:09:33

lots of code on npm is also written by inexperienced coders, so sometimes their solution may not be “good” either

thheller16:09:52

vetting dependencies is sometimes more work than just writing it yourself

thheller16:09:10

blindly using dependencies often creates more issues than they solve

thheller16:09:45

programming is hard …

Jon16:09:21

I know that, many js programmers do not have computer science background. I'm one of them.

thheller16:09:51

I have no formal education either … I learned programming by reading a book when I was 14 or so

thheller16:09:57

lots of trial and error since then

thheller16:09:15

I still don’t know how to program really .. always amazed why anything works at all 😉

Jon16:09:24

I was learning math, but felt so boring, and taught myself using Linux and creating webpages.

Jon16:09:13

programming like in the old days, can't image. papers and holes?

Jon16:09:20

or tape?

thheller17:09:41

hehe I started on a 286sx with 6mhz

thheller17:09:06

I remember how upgrading to 8mb of RAM was huge

Jon17:09:16

Windows?

thheller17:09:20

thats so insane compared to today

thheller17:09:31

no. no windows back then, just DOS

Jon17:09:54

oh, IBM...

Jon17:09:52

guess I have never seen it

Jon17:09:10

so late, going to bed. bye

bolasblack02:09:27

Not only one company, the company I'm working for is also worked with CoffeeScript as the main programming language in backend and frontend. After nodejs 6.x and react, we start use JavaScript because of ES6 feature