On Wednesday, December 31, 2014 12:17:11 AM UTC+1, David Nolen wrote: > > Supporting both Node.js and the Browser has been a goal since the > initial release. There's nothing new going on here except more & > better.
What is tooling and what is CLJS? At which point does it make sense to address an issue in CLJS rather than a library. Given that probably no one will use the Node.JS REPL the way you described in your blog post other than for experiments. It will probably be mostly used via tools (eg. lein-cljsbuild, lein-figwheel, etc ...) Does the Node REPL even need to be in CLJS itself? Clojure has a variety of "contrib" (eg. core.async, core.typed, data.json, ...), shouldn't we maybe split into contrib? Why do we have clojure.browser.*? These things are dangerously out of date and incomplete. I tripped over that when I started. > > As to the reliance on files this is directly result of the desire to > improve start time performance of REPLs and cold builds. I don't see > any better solutions when performance and sharing analysis information > across runs/processes is the goal. Again, why is that the job of core CLJS? Granted we will probably always end up with files so it is a pretty safe bet. > > > Should we try to refactor the build process overall? Or am I imagining > > things? > > Refactoring means needless churn. At this point it's preferable to do > things incrementally behind feature flags. Again I also don't see why > much of this work can't be done via patches to cljs.build.api. Well, easier said than done. A lot of stuff I'm looking at requires significant changes and some even break backwards compatibility. Obviously these things can (and should) take quite a long time and consideration which is why I think they should not be in CLJS core. Take CLJS-851 [1] as a simple example. The fact that most people still are required to manually require goog/base.js + app.js MANUALLY in the HTML in development but not in production is completely ridiculous to me. A seemingly simple change of adding :main suddenly has very big implications overall as it ties into [2] since given a :main you can always compile in dependency order. Which brings me back to my question: What exactly needs to be in CLJS? Given that most tools will extend base functionality in one way or another anyways? CLJS doesn't even support multiple source-paths and tools rely on a simple "hack" I wrote about 2 years ago [3]. Note that this hack does not work with :main since you may use namespaces from the another source-path which is not known to CLJS (given that we just map over them). Sorry this is starting to turn into a rant, which isn't helpful. I do believe refactoring is necessary. /thomas [1] http://dev.clojure.org/jira/browse/CLJS-851 [2] http://dev.clojure.org/jira/browse/CLJS-927 [3] https://github.com/emezeske/lein-cljsbuild/blob/3625516e82701ee89109875ea60d2d4035ef02e0/support/src/cljsbuild/compiler.clj#L64-L67 -- 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 http://groups.google.com/group/clojurescript.
