ClojureScript Self-hosting Demo

[David Nolen]

Some more words & demos here http://swannodette.github.io/2015/07/29/clojurescript-17/

Cheers,

David

[Marc Fawzi]

Some basic and potentially naive questions:

I realize you need a bunch of things loaded in the browser to convert CLJS code to JS and eval it. I'm wondering about the below:

1. Does this means that i can run CLJS in the browser without the Google Closure library or is the compiler dependent on that? 

2. Is it possible now to load CLJS libraries into JS projects with similar ease to loading JS libraries/modules?

Sent from my iPhone

--
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 clojurescrip...@googlegroups.com.
To post to this group, send email to clojur...@googlegroups.com.
Visit this group at http://groups.google.com/group/clojurescript.

[David Nolen]

On Sun, Aug 2, 2015 at 7:30 PM, Marc Fawzi <marc....@gmail.com> wrote:

Some basic and potentially naive questions:

I realize you need a bunch of things loaded in the browser to convert CLJS code to JS and eval it. I'm wondering about the below:

1. Does this means that i can run CLJS in the browser without the Google Closure library or is the compiler dependent on that? 

cljs.core has only ever depended on goog.string, goog.array, goog.object. Nothing has changed here and nothing likely will.

 

2. Is it possible now to load CLJS libraries into JS projects with similar ease to loading JS libraries/modules?

Only if loading >300K of gzipped generated JavaScript is an acceptable tradeoff for "ease".

David

[Marc Fawzi]

<<
Only if loading >300K of gzipped generated JavaScript is an acceptable tradeoff for "ease".
>>

When prototyping a JS app that leverages a CLJS library for something where CLJS shines e.g working with data, i would probably consider loading the CLJS library and compiling it the browser because that feels natural. For production, maybe not so attractive.

Btw what consequence does this new capability has w/r/t macros? Does it make possible writing macros in cljs?

Again, potentially naive but i want to understand a bit more what this new capability means for the few random scenarios i could think of....

Thanks for adding this ability to an already powerful tool. It is pretty neat regardless of whether or not i know how it would make my life "easier" ...



Sent from my iPhone

[Mike Fikes]

Marc,

See this FAQ entry:

https://github.com/clojure/clojurescript/wiki/Bootstrapped-ClojureScript-FAQ#with-bootstrapped-clojurescript-can-we-now-have-namespaces-that-mix-both-macros-and-functions

- Mike

[kinleyd]

Hi all,

I've looked at the Optional Self-hosting section on the ClojureScript Github wiki. Would it be possible to have a more step-by-step set of instructions for experimentig with self hosting OR could someone point me to a resource which provides one?

Thanks,

Kinley

[David Nolen]

Kinley,

It should be considered an expert level feature. There's no official plans to document it further than the docstrings in the namespace. If someone in the community wants to write their own blog post go for it! :)

David

On Tue, Aug 4, 2015 at 1:59 AM, kinleyd <kin...@gmail.com> wrote:

Hi all,

I've looked at the Option Self-hosting section section on the ClojureScript Github wiki. Would it be possible to have a more step-by-step set of instructions for self hosting OR could someone point me to resource which provides one?

Thanks,

Kinley

[kinleyd]

Hi David,

Thanks for responding, and apologies for the double and poorly edited posts.

So, I'm going to roll up my sleeves and see if I can bungle my way through this. :)

Thank you for the awesome work you've been putting in on ClojureScript!

Kinley

[Nikita Beloglazov]

I've played a little bit with client-side compilation and don't entirely understand the role of *load-fn* when non-macros namespace is used (https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/js.cljs#L76).

I see the need to load source file with macros (so that they can be evaluated and change code), but if my namespace includes - how its source is used for compilation?

Example:

(ns my.ns
(:require [foo.bar :as bar]))

(defn say-hello [name]
(bar/print "Hello" name))

Why source of foo.bar is needed to compile this code? I believe (bar/print ...) will be compiled to foo.bar.print(...) any way.

[Derek Slager]

Macros are resolved at compile time, so bar/print will be transformed to the result of running the macro during compilation, not to something that's called at runtime. The "less trivial" example from David's post demonstrates the simplest possible scenario. The example code[1] loads a simple macro[2] via XHR, resulting in:

original source: (mult 4 4)

after macro is processed: (* 4 4)

after transpile to js: 4 * 4

Notice also that the reference to bar.core is gone in the transpiled source.

Derek

1. https://github.com/swannodette/swannodette.github.com/blob/master/code/blog/src/blog/cljs_next/core.cljs#L138

2. http://swannodette.github.io/assets/cljs/bar/core.clj

[Nikita Beloglazov]

Thanks, though I understand why we need to resolve macros. I don't understand why non-macros need be resolved. Like in my example bar/print is not a macro as macros ":include-macros true" is not specified in ns definition.

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/q9UaYC-X8XE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojurescrip...@googlegroups.com.

[Derek Slager]

Apologies for misunderstanding the question. While the client code would be compiled to foo.bar.print(...) as you point out, the environment still needs to load the code which will actually be invoked. A non-browser environment may load from the file system, a browser may load via XHR, etc.

Derek