41–50 of 64 posts
Great article. I have spent a fair amount of time playing with ClojureScript, read "ClojureScript: Up and Running" and a lot of tutorial material on the web, and used it a bit in a customer project. 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…
Great article. I have spent a fair amount of time playing with ClojureScript, read "ClojureScript: Up and Running" and a lot of tutorial material on the web, and used it a bit in a customer project. 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…
I'd be curious to hear what you're not liking about it.
We use ClojureScript (and Clojure) at http://economi.co and I'm really enjoying it. 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…
Don't worry about how anything compares to frameworks, because they don't matter anymore. 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 grai…
Earlier quoted context omitted.
I'm new to programming and I want to start off on the right foot. I'd love to learn more about the differences. Where should I look?
We did a post a while back on the frameworks vs. libraries and our overall take on software engineering: http://blog.getprismatic.com/blog/2012/4/5/software-engineer...
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
the dom is a mutable data structure and the native (fast) dom apis expose mutable interfaces. so dynamic sites (you know, single page html5 apps doing all sorts of client-side dom manipulation) are either going to be slow, or are going to have an imperative core, which is where you need functional programming the most ;( maybe HTML6 will have native functional dom manipulation and we can rewrite all our favorite java…
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.
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?
If you're interested in a functional approach to UI code, check out functional reactive programming (FRP). It's a declarative way to specify UI logic which abstracts away much of the inherent messiness of using mutable state and callbacks. 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 Ja…
Earlier quoted context omitted.
Frankly at the moment, we're not using any external clojurescript libraries; we've tried many, but none quite meet our needs or the style we really like. We're internally phasing out jQuery selectors in favor of some code that we'll be releasing once we know it's battle-hardened and ready. We don't use an MVC or components type framework, but ideas about how to setup those abstractions are percolating.
I added two more questions while you where writing this reply probably.
I didn't actually consider EDN. I haven't see enough of a win over JSON to consider it, but that could just be misinformed.