Getting started with ClojureScript and Noir #1(djhworld.github.com)
djhworld.github.com
Getting started with ClojureScript and Noir #1
http://djhworld.github.com/2012/02/12/getting-started-with-clojurescript-and-noir.html
11 comments
It might be worth checking out jayq[1] if you're just looking for a more straightforward DOM manipulating experience. Also, for clean interactions between Noir and ClojureScript, take a look at fetch[2].
[1] http://github.com/ibdknox/jayq [2] http://github.com/ibdknox/fetch
[1] http://github.com/ibdknox/jayq [2] http://github.com/ibdknox/fetch
If you're interested in more targeted training on building Clojure web apps, there is a 2 day class (taught by Chris Granger, creator of Noir) coming up prior to the Clojure/West conference (San Jose, class Mar 14-15, conf Mar 16-17). More info at http://clojurewest.org/training-clojure-web
I'll talk a fair amount about ClojureScript during the course too :)
A bit off topic, but I don't understand why Hiccup is so commonly used in the clojure community.
It seems like a step backward from other templating libraries... to build HTML layouts using the programming language.
Designers always mock up layouts in HTML first then integration is as simple as replacing mock content with variables/partials/etc. It would be a lot of extra work to translate that into Hiccups Clojure code.
Why not just use something like Enlive, where you can keep standard HTML and still keep the logic out of the views?
It seems like a step backward from other templating libraries... to build HTML layouts using the programming language.
Designers always mock up layouts in HTML first then integration is as simple as replacing mock content with variables/partials/etc. It would be a lot of extra work to translate that into Hiccups Clojure code.
Why not just use something like Enlive, where you can keep standard HTML and still keep the logic out of the views?
I suspect most Clojure web apps are built by smaller teams where the HTML is written by the same developers as the rest of the codebase.
Enlive also has a reputation for using confusing macros and having poor documentation. I've been told it's improved a lot, but it's hard to shake an impression like that sometimes. For better or worse, Hiccup is absolutely _obvious_, and that counts for a lot.
Enlive also has a reputation for using confusing macros and having poor documentation. I've been told it's improved a lot, but it's hard to shake an impression like that sometimes. For better or worse, Hiccup is absolutely _obvious_, and that counts for a lot.
Much more than that I've come to love that fact that it's Clojure and I can iterate over lists for example.
It's not spaghetti html wrapped inside $language, it's useful and you can work with it.
It's not spaghetti html wrapped inside $language, it's useful and you can work with it.
This is exactly why I prefer hiccup. I can operate on my interface code using the full power of the language, and it looks just like everything else in my project.
That's not to say Enlive isn't capable as well, but when I'm working on my own using Hiccup means one fewer context-switch when thinking about what I'm building.
That's not to say Enlive isn't capable as well, but when I'm working on my own using Hiccup means one fewer context-switch when thinking about what I'm building.
I think it rather depends on how homogeneous you plan on making the user interface to your web application. The more repetition in the design, the more you benefit from being able to factor it out into smaller components, and functions are obviously more suited to this than partials.
So if you're writing a web application with a small number of unique views that have been carefully constructed by a dedicated designer, then maybe Enlive is the better choice. But if you're designing a web application with many views that tend to share a lot of common traits, then by factoring out common UI elements into functions, you can often end up with a far smaller and cleaner view definition.
So if you're writing a web application with a small number of unique views that have been carefully constructed by a dedicated designer, then maybe Enlive is the better choice. But if you're designing a web application with many views that tend to share a lot of common traits, then by factoring out common UI elements into functions, you can often end up with a far smaller and cleaner view definition.
Thanks, a nice writeup. I am working through it right now.
I have been switching from Rails 3.x to Clojure and Noir a lot lately. A litte off topic, but these two web frameworks are really complementary: it seems like new web app projects are clearly better developed in either Rails or Noir - pretty clear cut.
- In Noir I was able to make the jump from "getting started" to "building my own app" fairly quickly.
- After getting a somewhat-viable backend, I hit a pretty steep learning curve trying to figure out how to hook in some Clojurescript.
- I started looking at Clojurescript One, however, I've found it to be a bit of a firehose. I'm intrigued by their development ideas, but I ultimately just want to pick and choose a few things that I can integrate into my existing Noir backend. The Clojurescript repl is pretty sweet though.
- I think I might just use the Domina library in isolation, and use the cljsbuild approach in this article. I will try to revisit Clojurescript One later as I gain a little more experience.