This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-21
Channels
- # aws (1)
- # aws-lambda (1)
- # beginners (27)
- # boot (16)
- # cider (1)
- # clara (54)
- # cljs-dev (4)
- # cljsjs (8)
- # cljsrn (25)
- # clojure (148)
- # clojure-dev (2)
- # clojure-finland (1)
- # clojure-france (18)
- # clojure-italy (10)
- # clojure-nl (3)
- # clojure-russia (27)
- # clojure-sg (2)
- # clojure-uk (17)
- # clojurebridge (6)
- # clojurescript (70)
- # core-async (1)
- # css (6)
- # cursive (35)
- # data-science (3)
- # datomic (22)
- # events (4)
- # jobs (18)
- # jobs-discuss (14)
- # leiningen (4)
- # lumo (22)
- # off-topic (20)
- # om (5)
- # om-next (1)
- # onyx (47)
- # pedestal (107)
- # re-frame (43)
- # reagent (1)
- # ring (2)
- # ring-swagger (2)
- # rum (18)
- # sql (15)
- # unrepl (4)
- # vim (61)
- # yada (3)
Well, if I require cljs.test in my figwheel REPL and I load my test namespace I can get test results. What are the advantage of using JS environment (apart from autoreload test) ?
Hi, can anyone help me with an issue with targeting nodejs? My issue is that the generated cljs.core.load_file
calls have the wrong path for require
d libs from cljsjs. From my initial investigation it looks like perhaps the asset-path isn't obeyed for the nodejs target. Any help appreciated 🙂
Hi,what is the best way to work with svg with cljs and react? Are there any libraries? Thanks.
@cmal ymmv but I just put svg tags in my hiccup in reagent and it just worked
perhaps you want something with a friendlier UI though
@cmal I made a go board using that https://github.com/rbuchmann/reago/blob/master/src/reago/board.cljs
is there a way to compress this inot a single *.gz/zip file, have the browser download it, unzip it, and load it ?
Here's a library for unzipping in the browser https://gildas-lormeau.github.io/zip.js/
@qqq: I'd wager the more common solution to this problem is to try to minify and combine them into very few files, and then use gzip compression on the web server when you serve them, which the browser will natively decompress
So like ClojureScript can output a single .js file. Possibly you could use webpack to minify/combine the css + fonts
@qqq Once the files are downloaded once they should be cached by the browser, so I don't think you should care about trying to bundle them.
@timgilbert @tbaldridge : I'm trying to minimize load time
Right, but once they visit your site once, the file are cached and they're super fast.
Any gzipping is going to ruin that caching and make load times worse.
I'm not entirely convinced that having the js side of things unzip files in memory before they can be used will help you re: load time
Right, and for JS files Closure advanced compilation will get you the most bang for the buck
Huh, gzip doesn't prevent caching and it is usually beneficial for text files (html, js, css). Loading gzipped content + decompressing is usually faster then loading uncompressed content.
But this is not something that application usually needs to implement. Nginx or varnish or such can take care of this.
@juhoteperi right, but what was begin discussed was bundling all your css, fonts, images etc into a single tarball and shipping that as one file.
Not only does that not help with caching at all (change one file the whole bundle changes), but I'm not even sure it's possible.
Okay, I missed the context
but yes, I agree, almost all text traffic should be compressed at the HTTP level.
Yeah, the bug in my reasoning was: 1) Loading 20 different files? We're bottlencked by slowest one. Let's bundle it into one zip file. However, the end result of this is that we lose caching, since if one of the 20 file changes, the entire zip changes.
If you have 15 JS files, concat them into 1, If you have 5 css files concat them into 1, then you have 2 files
@qqq if you can, make sure you're using HTTP/2. It's a big difference when you request many files. And obviously gz or brotli. Openresty FTW
Though this has the same problem with caching
Well, probably those fonts don't change often (or ever) so just make sure they have very long http cache max-age so users only load them once. With proper cache options the browser doesn't even need to ask server if the files have been changed.
well, use the version in the url so new version gets loaded each time the version changes
or calculate hash for the files and use that as url, so if it happens that only some of the files change in TeX update, only the changed files need to be loaded
hello! I’m trying to consume a npm dependency using :npm-deps and ClojureScript 1.9.521. When I run this:
(b/build "src"
{:optimizations :simple
:target :nodejs
:npm-deps {"bcrypt-pbkdf" "1.0.1"}
:infer-externs true
:output-to "main.js"})
I get:
Caused by: java.lang.RuntimeException: INTERNAL COMPILER ERROR.
Please report this problem.
null
Node(NAME BCRYPT_HASHSIZE): /Users/alistair/Code/clj/alphabay/node_modules/bcrypt-pbkdf/index.js:469:4
BCRYPT_HASHSIZE = 32;
Parent(VAR): /Users/alistair/Code/clj/alphabay/node_modules/bcrypt-pbkdf/index.js:468:0
var BCRYPT_BLOCKS = 8,
even though the same process works fine for e.g. left-pad (I’ve been following along with https://anmonteiro.com/2017/03/requiring-node-js-modules-from-clojurescript-namespaces/)
interestingly, the file that’s giving errors compiles fine in the web interface to the closure compiler: http://bit.ly/2p43aXJ
@atroche The problem could be caused by module processing pass, which is not used if you pass the file directly to Closure
Yeah, something like :foreign-libs [{:file "src" :module-type :commonjs}]
and create test JS file in the folder
@atroche still some rough edges in Closure
gotcha. is there any use in my trying to get the cljs compiler to use a newer version of closure? or is that playing with fire?
Cljs compiler already uses the latest Closure release
oh, interesting, what’s with google-closure-library vs closure-compiler-unshaded? the former at least seems to be on an older version?
closure library is just a JS core library
closure compiler is what actually compiles & optimizes JS
(in the JVM)
np, happy to help
@atroche you can try building Closure from master too
though I recommend keeping whatever CLJS ships with
Seems to be caused somehow by deffing two vars and exposing those on module.exports:
❯ cat foozz/bar.js
var BCRYPT_BLOCKS = 8,
BCRYPT_HASHSIZE = 32;
module.exports = {
BLOCKS: BCRYPT_BLOCKS,
HASHSIZE: BCRYPT_HASHSIZE,
};
~/tmp master*
❯ java -jar closure-compiler-v20170409.jar --js foozz/bar.js --process_common_js_modules
if both vars have their own var
it works
I'll report this to closure-compiler repo