What other "regular" JS framework/libs do you use with ClojureScript (thinking about jQuery, Backbone, angular and the likes)?
About dommy, what made you choose DOM vs String generation (knowing the later could be faster in some situations/setups)?
And the last one, did you consider EDN? I'd guess you choose json for obvious performance reasons.
We don't use an MVC or components type framework, but ideas about how to setup those abstractions are percolating.
If anyone wants, email me at the address in my profile and I'll get you a discount code.
I looked at ClojureScript when it was first released, and came to the exact same conclusion. I'm very interested to know how debugging ClojureScript works out for you. From what I remember, the ClojureScript -> JavaScript step generated some code that could be fairly difficult to follow. Also, in your experience, how well does it integrate with other JavaScript libraries?
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.
Maybe one of the most difficult things coming into it is trying to relate it to something like BackBone.
However generally speaking in Clojure the culture is more about libraries than frameworks.
C2 http://keminglabs.com/c2/ which on the outset looks just like a ClojureScript version of d3 is actually a great library to use instead of a traditional front end framework.
Check the example implementation of the class TodoMVC list here: https://github.com/lynaghk/todoFRP/tree/master/todo/c2
It's uses normal Clojure data structures within atoms as the data model (https://github.com/lynaghk/todoFRP/blob/master/todo/c2/src/c...) and uses C2 to automatically update the UI (https://github.com/lynaghk/todoFRP/blob/master/todo/c2/src/c...). Very elegant.
I'm just starting to explore this area myself, but have already found it useful for a few smaller parts of our site.
We think traditional frontend frameworks - whether of the rails/django variety or the backbone variety, are generally rubbish in a nearly infinite number of ways. It's a style of programming based on wrapping weak mutation oriented idioms behind monolithic APIs and design patterns. We think default functional style and fine grained composability is the future, and mutation + oo design patterns + frameworks is the past.
What?
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!)
Very cool!
That is really weird. If there's one area where Clojure feels a bit strange to me it is numerical computation. I haven't fully looked into it yet but there's the whole underlying Java idiosynchrasies issue : for example where you need to wrap inside unchecked-int to dodge overflow issue or the fact that you need to be careful to be sure to fall back to primitives if you don't want to kill your perfs, etc.
In addition to that a lot of intensive computation do work really best when using mutable data structure. Which is sharp contrast with Clojure's main philosophy that favors avoiding mutability. Note that it cannot be done, it can, but it kinda feels "weird".
Then your question gets weirder: you ask about the advantages of ClojureScript server-side templating when the article specifically mentions using Clojure on the server and ClojureScript on the front-end (if I'm not mistaken).
I've played around with FRP in Haskell, and have found it much nicer than the more standard approaches to implementing UI logic. Before using FRP, my main UI experience was with Java Swing and web development, and FRP is definitely a step up. I've found it easier to write the code in the first place and then much easier to add new features and logic.
I've only used FRP with native UIs, but I think it would be very natural for web development as well. It's certainly a shift in philosophy and mindset, but one that I think is well worth overcoming.
Unfortunately, I do not know of a good tutorial for using FRP. I'm sure there are some out there, but I basically picked it up by reading academic papers which are not to everyone's taste. That said, I actually found some of the papers were clearer than the blog posts and SO questions I found online!
I'm probably going to write a basic FRP tutorial in Haskell some time soon, probably built around some very simple application (maybe John Conway's Game of Life). It really is a fun subject. Is anybody interested in something like that?
However, I can't find examples of systems of moderate (or big) size - nothing to get inspiration from, all examples I've seen are quite small and do too much by hand. They often select elements (like button to track click on) from whole document by id (and in big app this is pretty useless except for some top-level elements), or interwind templates with bindings to events and interaction between them is structured so that it feels like almost using globals. Directly changing top-level data from some inner template.
Anyway, I've got some ideas - display is easy though, what's hard is nicely structuring forms and buttons IMO - but it takes time to carve them out in code. I would love to read something on topic of structuring applications, which are more than a single input and a single list.
Elm: http://elm-lang.org/ and to some extent Meteor: http://docs.meteor.com/#reactivity
One of the thing that I love when developing under Emacs is that I can get real-time validation of my XML (eg XHTML) based on, say Relax NG. This even works nicely with multiple-major-mode (eg I can get realtime validation of the XML part, yet see JavaScript as JavaScript inside the same source file).
Now my question: with all these templating libraries like Jade, aren't you losing feature like real-time validation?
And when such a templating library comes out, it means every editor out there as to be modified so that it supports it?
Or is there some kind of a schema that can be used to perform real-time validation + auto-completion?
My point is: I definitely see the point as replacing Jade by Clojure because you can then manipulate your templates as data, which is gorgeous. But I don't see the point of using Jade in the first place...
Also out of the box, you get a repl to live test and evaluate template functions and data structure. It would only take a few lines of emacs lisp to take a string from the repl and pipe it through XHTML validation.
A little off topic, but I have been using Emacs to edit Lisp code since the early 1980s, but IMHO IntellJ with the Clojure plugin is a bit more efficient for writing and reading code.
That said, ClojureScript has not really clicked for me yet, but this article and the pointer to dommy is getting me closer to adopting ClojureScript.
I use Clojure + Compojure (and still Noir) + Hiccup for just about all of my web app development. Love Hiccup. Having (mostly) Hiccup on the client side with dommy looks very cool.
Even though this is a fair point, the comparison between the Jade solution and the Clojure one is invalid. Jade was conceived as a whitespace-significant language. Its biggest benefit over plain HTML (or HTML-based template engines like Moustache) is the usage of indentation to determine hierarchies.
The comparison would be more valid with something like http://domo-js.com, which is solving the exact same problem: using a single language (JS) for markup production – and even replacing CSS.
You can certainly take that approach in JS. domo-js isn't quite that, it would look more like:
["html" ["head" ["title" {class: "class1"} "Welcome to Domo"]]]
As we say in the post, you can totally pull all this off in JS, but I think if you're going to be manipulating nested data structures, it's better to have immutable data structures built in and the suite of functions that can manipulate them. Clojure makes building template structures really easy: persistent data structures, map/seq argument destructuring, keywords, sets, etc.
maybe HTML6 will have native functional dom manipulation and we can rewrite all our favorite javascript libraries to expose functional interfaces. one can dream.
Not even in JS the DOM and objects are the same - some properties of the DOM have 'magical behavior' attached.
ClojureScript does not provide any functional interface to the DOM - that would involve a Haskell-like model of programming (monads etc), which Clojure programmers rarely do in practice.
there is ongoing research into dom manipulaton in clojurescript - Conrad Barski presented one approach[1] at Conj 2012 where the dom is mirrored in clojurescript data structures, and then 'synced' with the dom - so that way the imperative ickyness is tucked away in the sync method - it remains to be seen if that can be made fast enough until we get a native persistent interface to the dom.
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)
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.
(1) Clojure core itself and readjust to functional programming (2) Understand how ClojureScript is translated into JS in order to do interop which will absolutely be necessary for any real project (3) Understand Clojure on the JVM in order to understand/write macros
Just for fun, I benchmarked my Hiccup port against the other candidates.
Compilation Mode: Whitespace {:crate 7.076333333333333, :jquery 1.4643333333333333, :dommy 2.1186666666666665, :hiccup-str 1.985, :hiccup-node 2.3476666666666666}
Running Hiccup and Dommy in advanced mode get's the time towards unoptimized jQuery.
Compilation Mode: Advanced (Crate and jQuery don't run in advanced mode) {:dommy 1.3436666666666666, :hiccup-str 1.0293333333333334, :hiccup-node 1.3506666666666665}
One thing to note: The original Prismatic tests were building jQuery Nodes and appended them to an UL element. Building strings and appending those to the node speeds the whole thing up a little bit further [3]. In the above benchmark :hiccup-node uses DOM nodes to append to the root, :hiccup-str uses Javascript strings.
I can only agree. Using a Hiccup like template system in Clojure is very nice.
[1] https://github.com/r0man/hiccup/tree/clojurescript [2] http://dev.clojure.org/display/design/Feature+Expressions [3] https://github.com/r0man/dommy/tree/hiccup
And I think client side have a bit different requirement compared to server side. At client side, I often need to manipulate specific element instead of root element which crate and dommy return. So I forked crate in order to get a collection of created elements as a hashmap. https://github.com/hozumi/crate-bind This is useful. I will create dommy version of this.
I prefer LiveScript for a number of reasons, starting with the fact that I just don't like brackets and parentheses enough to want to use them everywhere.
