The part about how so much of web application development is just translating data from one format into another, and how objects just get in the way of that process, really struck home with me. With Google's key value store mapping directly to Clojure structs, which are then handed off to the HTML generation code or converted into JSON, it's clear that including a step to map to objects somewhere in there is totally superfluous. Which is exactly what I find in developing web applications in Java on a daily basis.
It would be awesome if they posted this in a real text format rather than lots of slides with (sometimes) very small text. I highly recommend the read, very interesting.
Can someone with recent GAE experience comment on how well it works these days? Any glaring problems, particularly with the JVM implementation? I plan to launch a Clojure web app in the next few months, and I'd love to avoid maintaining servers.
I'm on the Python end, and it's gotten a lot more stable and faster since it launched. A lot more features, too. A lot of the workarounds that we did early on to fix headaches and failure cases just aren't needed any more, so it's much closer to the abstraction we signed up for.
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.
> 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.
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.
That is a plus. You can go very far within the free quota limits.
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.
It may not be the best choice for an infrequently used Web page or App because your "slice" sleeps if not used for a while and the JVM takes a while to start up.
This is true, but should be a minor concern--you can easily ping it every once in a while to keep it hot without using very many resources. You might even be able to use App Engine's built in cron jobs to do it from the instance itself (might need more often than once a minute though).
I'm regularly curiously peeking at the functional languages but I must say those slides did not convince me much - perhaps just bad choice of examples.
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.
HTML isn't meant to handle presentation. Ideally, it's a way of marking up content to allow an arbitrary presentation layer to be laid on top.
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:
But if I am a programmer, without necessarily much knowledge of the presentation, I might be more careful to write more semantic HTML that's presentation-neutral.
Python templating solutions are also broken. They mix markup and logic. You could do everything described in the slides and use something like Enlive instead which cleanly separates markup and presentation logic. Most of the fancy features in popular templating solutions is just function composition in Enlive. Being a competent Lisp, macros can take things to a whole other level.
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.
Having done the DSL templatng route in Perl, it's not really that bad. Really there isn't much difference between having the templates in a template language or a first class programming language. I can see it getting bad if you're not disciplined and mix you app logic with you display logic. But it's not really all that bad. I did it so I could use closures and what-not in my templates. Worked out well. Makes the higher level templates more readable.
Well, I commonly use template inheritance (in jinja) to great effect and can think of dozens little reasons why having the HTML in separate files makes a lot of sense (i18n, re-use, designers editing them, testing outside the app etc.).
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.
This is what a "template" looks like in Enlive. Enlive actually can extract HTML fragments out of a pure HTML file and manipulate them. This means designers can work in pure HTML and the coder can manipulate those HTML files at will w/o putting any code into the markup.
Well, thanks for providing a peek, although I'm still not sure I could bear that syntax. I just find it very hard to parse ("})})))", seriously?), but perhaps that gets better with age/familiarity.
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%}
It's just different flavors of line noise. At least with Emacs you have paredit to manage code structure for you, no need manually track parens/braces at all.
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. ;-)
Well forget the HTML-in-Clojure bit. Most people don't like that. Enlive is the current standard for complete separation of presentation and logic in Clojure right now. And hey, at least it's not HAML :)
Great set of slides - I wish I could have heard the talk live. I did add his company's blog to my RSS/Atom feed.
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.
I have to say that languages that favor immutable data structures and functional style are great for web dev. From what I've done in Clojure/Compojure compared to my experience in Rails, it's great not having a billion implicit magical parameters to each function (aka instance methods and magic instance/class methods that may not exist or be documented). You can really fit a lot of a functional web app in your head. Rails just spills all over the place and you slip on it and end up with stitches.
Thanks, that sounds right. That said, I have 3+ years invested in Rails, so it is difficult to make a commitment to another stack. I am doing a small (non web app) project with Clojure right now, which is fun and educational.
Nice remark on how the need for a "powerful" IDE is a code smell. The need for the IDE reveals that some abstraction the language should provide but isn't has to be handled by something else. No such problem with macros.
