How a Clojure pet project turned into a full-blown cloud-computing web-app
slideshare.net
slideshare.net
Their blog has an excellent article (http://www.hackers-with-attitude.com/2009/08/intertactive-pr...) on using Clojure interactively with GAE.
That said, if your site is always going to be small, you'll be able to do a lot of database queries much faster with MySQL, Redis, or what have you than with App Engine. The scalability wouldn't matter, so if you don't want to worry about database limitations, then it's a point against.
If your site is small enough, you may be able to host for free on AppEngine. Even if it's not that small, AppEngine doesn't charge for availability, just for usage. In other words, you don't pay for idle time.
Another thing I forgot to mention is that if you want to use an external domain (clojuresombrero.com instead of closuresombrero.appspot.com), and you want users in China to be able to access it, then you need to run everything through a reverse proxy or they'll hit the Great Firewall block.
E.g. on slide 79 the sight of generating HTML through a DSL horrifies me. Littering the code with presentation details like that leads to maintenance hell.
Likewise in the comparison of slide 83 vs 85 I frankly don't see any difference between python and lisp in terms of verbosity.
So whatever point the author was trying to make - didn't work for me.
I also found the code presented in the slide especially scary because it was intermixed with Lisp brackets and such. I imagine it would be a major pain to rearrange something in there, don't even want to think about exploratory programming in that style...
That's not to say it can't be neat in little one-off scripts - but for production code I'd be extremely wary of that technique.
(defn viewc [params session]
(let [navs (if (= (:action params) "reverse") (reverse navs) navs)
[nav1 nav2] navs]
(base {:title "View C"
:main (three-col {:left nav1
:right nav2})})))
The "can extract fragments from pure HTML" part certainly sounds interesting. But still I have to wonder how well that scales to complex templates. I mean, mixing logic into templates is ugly, but the alternative - completely separating the interpretation from the template - doesn't seem so rosy to me either. During a bigger re-arrangement I imagine it could become quite nasty to re-sync the new template version with what the code expects?
I assume the above "template interpretation code" was for quite a trivial thing. What would it look like for complex stuff? (70 chars of closing parentheses? ;-) )
{%for x in foo%}
<div id="cool">{{x.bar}} {{x.baz|pluralize}}</div>
{%endfor%}
Quite frankly; yes.
Not pretty in any way but I guess 15 years of familiarity play their part and I have never had a big problem with that particular concept (it just works well for me in practice).
However, to each their own. Looking forward to see how compojure adoption will play out, perhaps at some point I'll just "get it" and wonder how I ever worked without it. ;-)
Also, most Clojure functions tend to be only a few lines, so you'd rarely find yourself with more than, say, 8 closing brackets.
83 and 85 are the least interesting slides. How could instance instantiation be made much more succinct than that?
Having developed web apps in Python (CherryPy, Django) a lot of boilerplate could be eliminated just by having access to macros.
I prefer generating HTML content through s-expressions. It's more flexible and concise than a templating library, and it forces you to bear in mind the separation of content and presentation. In turn, this makes it easier to unit-test the views, and to write automated integration tests.
For instance, if I were a designer writing a template, I have control over both the CSS and the HTML. This might tempt me to write the HTML around a particular design:
<div class="post">
<div class="small">
<%= post.points %> points by <%= author.name %>
</div>
</div>
[:div.post {:id (str "post-" (:id post))}
[:div.header
[:span.points (:points post)]
" points by "
[:span.author (:name author)]]
(is (= (css-select "#post-1 .author" (:body response))
"Test User"))I would like to spend more time with both Clojure and AppEngine and the slides were some motivation. I am still a little skeptical however that Clojure base web apps will ever have the traction of Rails (I had a 5 hour sprint today to add two major features to a customer's rails web app: would have taken a long time to do with server side Java; I would guess that Clojure would split the difference).
I've bought 3 Clojure books, and I would by a 4th if the author of these slides would write a web app specific Clojure book.