Bringing functional to the frontend – Clojure and ClojureScript for the web
blog.getprismatic.com
Bringing functional to the frontend – Clojure and ClojureScript for the web
1–10 of 64 posts
Re: Bringing functional to the frontend – Clojure and ClojureScript for the web
#2Author here. Happy to answer any questions or comments.
Re: Bringing functional to the frontend – Clojure and ClojureScript for the web
#3I really love Clojure, but it still feels a bit heavy-weight for anything but numerical computation. However, I'd ignore that if the performance gains were significant. What are the performance advantages of ClojureScript server-side templating compared to client-side Javascript templating? The vogue style these days seems to be a one-page app where the clicks take barely any time, because the jQuery/Zeppo/Underscore selectors are all cached.
Re: Bringing functional to the frontend – Clojure and ClojureScript for the web
#4I really love Clojure, but it still feels a bit heavy-weight for anything but numerical computation. However, I'd ignore that if the performance gains were significant. What are the performance advantages of ClojureScript server-side templating compared to client-side Javascript templating? The vogue style these days seems to be a one-page app where the clicks take barely any time, because the jQuery/Zeppo/Underscore…
While you can use ClojureScript (CLJS) server-side running on say node.js, the largest benefit is as a replacement for client-side JS (ClojureScript converts to JS at compile-time).
You can actually use all the libraries you mentioned (jQuery, underscore) from ClojureScript. What CLJS really brings to the table are a set of abstractions and data structures that make it easier to write strong reusable functional code. In fact, alot of underscore comes built into CLJS and I think much of what jQuery buys you can be handled as a good CLJS library (but more on that soon!)
Re: Bringing functional to the frontend – Clojure and ClojureScript for the web
#5Author here. Happy to answer any questions or comments.
I really want to like ClojureScript, particularly since the idea of using the same language all around the app appeals to me, but it's not quite the same language. Have you found this to be a pain in practice? I'm specifically wondering about require-macros and lack of support for ~ and ~@, although I'm also curious if you were bit by any of the other differences between Clojure and ClojureScript.
Re: Bringing functional to the frontend – Clojure and ClojureScript for the web
#6I really love Clojure, but it still feels a bit heavy-weight for anything but numerical computation. However, I'd ignore that if the performance gains were significant. What are the performance advantages of ClojureScript server-side templating compared to client-side Javascript templating? The vogue style these days seems to be a one-page app where the clicks take barely any time, because the jQuery/Zeppo/Underscore…
While you can use ClojureScript (CLJS) server-side running on say node.js, the largest benefit is as a replacement for client-side JS (ClojureScript converts to JS at compile-time). You can actually use all the libraries you mentioned (jQuery, underscore) from ClojureScript. What CLJS really brings to the table are a set of abstractions and data structures that make it easier to write strong reusable functional code.…
The idea of decomposing jQuery into small libraries Clojure-style is very appealing. The advantage would be building the specific Javascript file needed by the client at request time, and caching intelligently to prevent doing this too much. The extra benefit would be, you could break out the pieces of jQuery devoted to patching cross-browser issues, and only include the ones you really cared about.
Very cool!
Re: Bringing functional to the frontend – Clojure and ClojureScript for the web
#7Author here. Happy to answer any questions or comments.
I really want to like ClojureScript, particularly since the idea of using the same language all around the app appeals to me, but it's not quite the same language. Have you found this to be a pain in practice? I'm specifically wondering about require-macros and lack of support for ~ and ~@, although I'm also curious if you were bit by any of the other differences between Clojure and ClojureScript.
Indeed it's not the same language. I wasn't bit by the macro differences (which are probably the largest non-interop difference) since I tend not to use macros in my Clojure or ClojureScript code. Macros are going to be different since the macro compile host (JVM) is different than the run host (Javascript VM).
Other than macros and the VM interop (ugh I think (.-length str) is an eye-sore for property acesss), the core of the language is close enough that I Don't think of it 90% of the time.
Re: Bringing functional to the frontend – Clojure and ClojureScript for the web
#8On server-side templating - did you consider a selector-based approach like cgrand's Enlive?
As I see it, it brings the best of both worlds (the comprehensibility of "logicful" templating, the maintainability of strictly separating presentation and data transformations)
Re: Bringing functional to the frontend – Clojure and ClojureScript for the web
#9Earlier quoted context omitted.
While you can use ClojureScript (CLJS) server-side running on say node.js, the largest benefit is as a replacement for client-side JS (ClojureScript converts to JS at compile-time). You can actually use all the libraries you mentioned (jQuery, underscore) from ClojureScript. What CLJS really brings to the table are a set of abstractions and data structures that make it easier to write strong reusable functional code.…
The idea of decomposing jQuery into small libraries Clojure-style is very appealing. The advantage would be building the specific Javascript file needed by the client at request time, and caching intelligently to prevent doing this too much. The extra benefit would be, you could break out the pieces of jQuery devoted to patching cross-browser issues, and only include the ones you really cared about. Very cool!
Yeah absolutely. One of the better CLJS features is getting the Google Closure modules and explicit dependencies.
We'll probably add dom selectors and/or manipulation and wheter it's the same library as dommy (github.com/prismatic/dommy) or a different one will depend on if the selectors borrow the same abstractions and syntax as templating.
Re: Bringing functional to the frontend – Clojure and ClojureScript for the web
#10On server-side templating - did you consider a selector-based approach like cgrand's Enlive? As I see it, it brings the best of both worlds (the comprehensibility of "logicful" templating, the maintainability of strictly separating presentation and data transformations)
No, but I think enlive is great.
To me and the team, most of our functions are making Clojure data structures and thinking of templating as converting data to dom elements or HTML strings seems the most compatible with that way of thinking. But both are definitely valid.