Re: [ClojureScript] Re: Any chance we can fit ClojureScript into Webpack ecosystem?
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 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 > 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. > -- 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.
Re: [ClojureScript] Re: Any chance we can fit ClojureScript into Webpack ecosystem?
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 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
Re: [ClojureScript] Re: Any chance we can fit ClojureScript into Webpack ecosystem?
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 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 > > rout
Re: [ClojureScript] Re: Any chance we can fit ClojureScript into Webpack ecosystem?
On Friday, May 12, 2017 at 1:55:24 AM UTC-7, Thomas Heller 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 looks very nice, with a colleague here we event went as far as thinking, what if we completely drop GCP support for node.js targets. We talked about this a bit on Clojurians, I like your idea to get closer to the node way. I am not a JS dev at all, but I understand the pain of existing JS devs when they approach the ClojureScript world. They need to change everything they know, not only learn a language but also new (JVM) tooling. Many say no thanks, which is a pity because they are missing out :D I have recently worked on a POC using Reason. The tooling is rough but it fits the JS ecosystem. The compiler is super fast (faster than Typescript even on my machine!). We ended up picking Typescript because of the tooling basically for a zero version of our stuff. I already don't like it that much ah ah. -- 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.
Re: [ClojureScript] Re: Any chance we can fit ClojureScript into Webpack ecosystem?
Time not enough to read every detail, but I found it great that most of my points are covered in the Wiki, code splitting, file hashing, async loading. However I think it's not we current have for all ClojureScript users, since it's implemented by yourself based on lein, like hashing https://github.com/thheller/shadow-devtools/blob/de6ede2add891aa798a3109c596ecafefdff94fe/src/main/shadow/cljs/devtools/targets/browser.clj#L235-L237 I'm a Boot user, and it became a problem. I heard about goog.module.ModuleManager before but never thought I could make use of it given that fact it was poorly documented... Your project is cool. On Fri, May 12, 2017 at 9:23 PM Thomas Heller wrote: > 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 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,
Re: [ClojureScript] Re: Any chance we can fit ClojureScript into Webpack ecosystem?
> However I think it's not we current have for all ClojureScript users, since > it's implemented by yourself based on lein That is incorrect. It is a pure Clojure library with no dependency on leiningen. I just happen to use leiningen and do not know enough about boot to create proper instructions for boot. You can use it via the REPL BOOT_CLOJURE_VERSION=1.9.0-alpha15 boot -d thheller/shadow-devtools:1.0.20170512-13 -s src repl (require '[shadow.cljs.devtools.api :as cljs]) (cljs/once :build-id) https://github.com/thheller/shadow-devtools/wiki/REPL Some ideas in boot don't play too well with the design I have in mind for shadow-devtools but you can use it just fine. -- 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.
Re: [ClojureScript] Re: Any chance we can fit ClojureScript into Webpack ecosystem?
Cool Hope one day it's in Lumo too XD On Sat, May 13, 2017 at 1:48 AM Thomas Heller wrote: > > > However I think it's not we current have for all ClojureScript users, > since it's implemented by yourself based on lein > > That is incorrect. It is a pure Clojure library with no dependency on > leiningen. I just happen to use leiningen and do not know enough about boot > to create proper instructions for boot. > > You can use it via the REPL > > BOOT_CLOJURE_VERSION=1.9.0-alpha15 boot -d > thheller/shadow-devtools:1.0.20170512-13 -s src repl > > (require '[shadow.cljs.devtools.api :as cljs]) > (cljs/once :build-id) > > https://github.com/thheller/shadow-devtools/wiki/REPL > > Some ideas in boot don't play too well with the design I have in mind for > shadow-devtools but you can use it just fine. > > -- > 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 > 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. > -- 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.
Re: [ClojureScript] Re: Any chance we can fit ClojureScript into Webpack ecosystem?
On Saturday, May 13, 2017 at 3:47:01 AM UTC+2, Jiyin Yiyong wrote: > Cool Hope one day it's in Lumo too XD Not by me but the features could certainly be ported. I spent quite a bit of time yesterday fighting through webpack sources trying to come up with an efficient way of doing things. The easy solution would be to make everything one-way which means JS can require CLJS but CLJS cannot require "local" JS, only modules from npm. So (js/require "react") would work but (js/require "./foo") would not. So in JS you would could say var x = require("webpack-cljs/cljs.core"). The way things are handled in webpack/npm means you must have a module-name which would be webpack-cljs or something along that line. But a package cannot depend on the local sources. Having sources to actually be side-by-side doesn't mirror too well to JS since you usually don't have namespaces there. Imagine src/index.js src/foo.js src-cljs/foo/bar.cljs In index.js you could say require("./webpack-cljs/foo.bar") and in the cljs file I could imagine (webpack/require "./foo") where it would always be relative context root (ie. src). The compiler would actually just generated a src/webpack-cljs/foo.bar.js. Same way it would for the module version. The problem with that is that people may start writing npm packages in CLJS where each package would contain its own version of cljs.core. That would be really really bad. Ideally I want src/index.js src/foo.js src/foo/bar.cljs but have not figured out how to do that yet. webpack has a ton of mutable state all over the place so trying to figure out what is going on is not that easy. I'll probably write the simple version today and see how things work out. -- 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.
Re: [ClojureScript] Re: Any chance we can fit ClojureScript into Webpack ecosystem?
> I'll probably write the simple version today and see how things work out. So the simple version sort of works. http://thheller.com/webpack-cljs-preview/index.html http://thheller.com/webpack-cljs-preview/bundle.js This was generated by "webpack -d" and index.js: --- var foo = require("webpack-cljs/dummy.foo"); console.log(foo.bar()); --- dummy/foo.cljs: --- (ns dummy.foo) (js/console.log "dummy.foo") (defn bar [] "bar") --- Nothing special but works well enough, still haven't figured out most of the webpack things though. Currently they shadow-devtools just runs independently and generates files into ./node_modules/webpack-cljs/dummy.foo.js to make the require "pretty" (I really do not like relative paths). Will polish things a bit and maybe provide a public repo tomorrow. Still convinced that this is a very bad idea though. ;) -- 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.
Re: [ClojureScript] Re: Any chance we can fit ClojureScript into Webpack ecosystem?
I started a new topic [1] for the implementation. You can find an example here: https://github.com/thheller/npm-module-example I'd be very interested in feedback from people that actually use webpack already. [1] https://groups.google.com/forum/?fromgroups#!topic/clojurescript/AGXku7Ous0Y -- 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.