I wrote some things down here: https://github.com/thheller/shadow-devtools/wiki/ClojureScript-for-the-browser#productionrelease-builds
Code splitting is done by the :modules, whether or not you want to use the loader is up to you. I personally don't but that is because I have a rather traditional website that actually has different pages and I can determine which modules are needed based on the page. If you have an actual SPA you probably want to use the loader. :module-hash-names and :bundle-foreign are the caching bits. I just added the :module-hash-names since that was still in my private build config, but that was in use for about 3 years. I had an idea for webpack, I'll let you know if it works out. On Friday, May 12, 2017 at 1:46:32 PM UTC+2, Jiyin Yiyong wrote: > I used ClojureScript for a year. Probably there are tricks from Closure > Compiler that I have no idea. > > > For the size, I saw some of the sites I often use have large JavaScript > size(with Disable Cache ticked): > > > weibo.com 1.2M > > > Twitter 437K > teambition.com 1.9M > > > > I don't think 84k is a very big deal, while it is for smaller websites. > Besides, we may cache and sure the cljs.core.js part, we may use Prepack in > the future. In my case it's tolerable. > > > Today, using tools like https://github.com/facebookincubator/create-react-app > and https://github.com/vuejs/vue-cli we almost get long time caching and code > splitting with only several lines of code, with assets(images, fronts) > bundling out of box. Hard to imagine we sell those people ClojureScript > without competitive features. > > > It would still be awesome if you can share about code splitting and permanent > caching in ClojureScript :) > > > On Fri, May 12, 2017 at 4:55 PM Thomas Heller <th.h...@gmail.com> wrote: > I'm way too biased towards the Closure Compiler and giving that up is simply > not an option for me. I am however very interested in making things simpler > for everyone. > > > > https://github.com/thheller/shadow-devtools/wiki/ClojureScript-for-node.js-libraries > > > > This is an example of how I intend to do that for node libraries, ie. > something you just require. This actually bundles things up in a UMD format > so the same can work for non-node environments. I would happily add a > :browser-umd target that solves some of the issues for webpack users. > > > > https://github.com/thheller/shadow-devtools/wiki/ClojureScript-for-the-browser > > > > I have used the underlying shadow-build for over 3 years now to do > code-splitting with permanent caching of generated files (ie. each generated > file has a unique name). I also recently added the :module-loader which lets > you async load modules on demand. > > > > Not sure what asset bundling does so no comment on that. > > > > I can't do anything about the JVM. I have been using it for too long so I may > be blind to the issues people are having with it. It isn't that bad? > > > > I would say there is actually a good solution to the issues you mention. They > just aren't available in the "mainstream" tools and I suck at writing > documentation. I'm happy to provide examples any time but need help with the > writing. > > > > Coming back to the webpack loader: I have a few ideas how I would write such > a thing. The issue I see, and why I don't, is that the end result is bad. > CLJS is built very much with the GCL in mind. cljs/core.js is 1.2MB (151KB > gzip) unoptimized. One large file is very non-idiomatic npm/webpack. That > also does not contain any user code. UglifyJS is able to shorten some of the > code but you still keep about 84K gzip'd. To me that is unacceptable. > > > > Web-targeted JS needs to be optimized as much as possible and currently that > means using the GCL. I don't want to create a "simple" solution that > sacrifices this just to make dev-time easier. > > > > I have been CLJS first for too long now to imagine which issues people are > having who are webpack first. Happy to discuss ideas or proposals. Maybe > there are ways (like the :node-library, :node-script) that could work even in > :advanced mode. > > > > > > > > On Friday, May 12, 2017 at 5:57:58 AM UTC+2, Jiyin Yiyong wrote: > > > It would be nice if we can require ClojureScript in JavaScript, and let > > Webpack to handle so many issues. > > > > > > > > > For Webpack use cases, I tried to sell ClojureScript to other front-end > > developers around me, but saw some problems: > > > > > > > > > * IMPORTANT: hard to install JVM. For JavaScript projects, installing > > Node.js(with npm inside) would be okay. It's very hard for JavaScript > > developers to pick up JVM and Boot(or Leiningen). > > > * IMPORTANT: long time caching and code splitting. We use these features in > > production for years. But I don't see a good solution in ClojureScript. > > > * Async code loading. For large projects some code can be loaded when a > > router is activated. No good solution found in ClojureScript. > > > * Assets bundling. Now we rely on Webpack to do that, result in using 2 > > tools. > > > > > > > > > Not sure if they can be solved if we have a ClojureScript running on > > Webpack. But there are many compiled-to-js languages support those features > > in by supporting Webpack already. That's the purpose behind the post. > > > > > > > > > Didn't try `node-jre`. I'm guessing we still need to debug JVM stuffs since > > it's running JVM? > > > > > > > > > On Fri, May 12, 2017 at 6:11 AM Shaun LeBron <shaunew...@gmail.com> wrote: > > > On Wednesday, May 10, 2017 at 11:45:02 PM UTC-5, Jiyin Yiyong wrote: > > > > > > > Already an old boring topic... I'm from JavaScript side and so many > > > people are building apps with Webpack. And so many of alt-js languages > > > got Webpack loaders: > > > > > > > > > > > > > > BuckleScript https://github.com/rrdelaney/bs-loader > > > > > > > PureScript https://github.com/ethul/purs-loader > > > > > > > Elm https://github.com/elm-community/elm-webpack-loader > > > > > > > Fable https://github.com/fable-compiler/Fable > > > > > > > > > > > > > > Exception: > > > > > > > > > > > > > > No Webpack for ReasonML > > > https://github.com/chenglou/reason-react-example/blob/master/webpack.config.js > > > > > > > > > > > > > > Can we make a loader for ClojureScript? > > > > > > > > > > > > > > Or how about the possibility? I guess Closure Compiler will get in the > > > why. But is it possible if I don't use dead code elimination from Closure > > > Compiler? I know many people need it but seriously no other solutions? > > > And how much does ClojureScript depend on Closure Library? > > > > > > > > > > > > I'm from the JS side as well, so I'm glad to see this question! Are you > > imagining something like the following? We should probably start by > > imagining why someone would want to require cljs this way and if it would > > even make sense to: > > > > > > > > > > > > ``` > > > > > > require('cljs!./src-cljs') // return all goog.provided namespaces? > > > > > > require('cljs!./src-cljs/foo/core.cljs') // return a single goog.provide > > namespace? > > > > > > ``` > > > > > > > > > > > > Either way I think it would need Closure Compiler to return a single asset > > for each require statement, if I understand webpack correctly. > > > > > > > > > > > > It's worth mentioning that the recent "node-jre" package allows users to > > install/use the full cljs JVM compiler in its fully glory through npm > > without any external dependencies, which I've tested here: > > https://github.com/cljs/tool > > > > > > > > > > > > I think it's possible—just unsure of webpack use-cases. Thoughts? > > > > > > > > > > > > -- > > > > > > Note that posts from new members are moderated - please be patient with > > your first post. > > > > > > --- > > > > > > You received this message because you are subscribed to a topic in the > > Google Groups "ClojureScript" group. > > > > > > To unsubscribe from this topic, visit > > https://groups.google.com/d/topic/clojurescript/HNuYCfPRtQw/unsubscribe. > > > > > > To unsubscribe from this group and all its topics, send an email to > > clojurescrip...@googlegroups.com. > > > > > > To post to this group, send email to clojur...@googlegroups.com. > > > > > > Visit this group at https://groups.google.com/group/clojurescript. > > > > -- > > Note that posts from new members are moderated - please be patient with your > first post. > > --- > > You received this message because you are subscribed to a topic in the Google > Groups "ClojureScript" group. > > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojurescript/HNuYCfPRtQw/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > clojurescrip...@googlegroups.com. > > To post to this group, send email to clojur...@googlegroups.com. > > Visit this group at https://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at https://groups.google.com/group/clojurescript.
