Getting started with ClojureScript and Noir #1
djhworld.github.com
djhworld.github.com
- 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.
[1] http://github.com/ibdknox/jayq [2] http://github.com/ibdknox/fetch
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?
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.
It's not spaghetti html wrapped inside $language, it's useful and you can work with it.
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.
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.