First off, I've used every single one of these frameworks and all of the technology therein to build applications much less trivial than what he displays.

These are stream of consciousness comments typed in as I watch.

1) He's not a very good Emacs user if he's not using dired to rename directories...

2) Boilerplate is for ze cut and ze paste when you start a new app. Negative points for dinging stuff on it.

3) Hello World is a stupid test. The actual benefits/detriments of a particular platform aren't going to show up until you have a real application.

4) Gee, Zope sure looks whiz bang, dunnit? The reality is that programming applications via a web interface well and truly sucks. More Hello World Is A Stupid Test there.

5) Zero configuration doesn't mean zero configuration. Again, the nifty Rails/TurboGears/Django management scripts are nice, but you don't see what goes on after the fact when you want more pages and so on.

6) Regex URLs do not suck. They kick much ass in a real application.

7) No one uses servlets any more. Use Spring or something. Lame.

8) You can use annotations instead of Hibernate XML.

9) A real J2EE dev environment (ie. not Maven) doesn't require server restarts (or compiling if you're just changing a JSP, for that matter).

10) He doesn't understand I18N in J2EE if he doesn't see how to make it internationalized in an easy fashion.

11) SQL frameworks are great... until you come up against a legacy db that doesn't follow the required naming conventions. Something like hibernate errs on the side of allowing flexibility in mapping that at the expense of lots of config, while something like Rails errs on the side of making new applications easy and legacy integration a PITA.

12) Plone looks great, but repository development can really, really suck (Hi Todd!). You pay for that easy Zopeness in maintenance costs.

13) The Zope object database is great for insular projects, sucks for real databases (like Postgres). Once again, it demos great, but fails in the real world.

14) Autogenerated pages are great for whiz bang tables, but for anything more complex than simple CRUD (which is admittedly a lot) they fail. Or, if you want to do anything slightly non-conformist with your CRUD, they fail as well (to varying degrees).

15) By his standards, none of the templating languages have good integration. Anything that lets you do an if/then statement will look odd. You can't get around this if you're templating. Having said that, the Django and TG templates are much more editor friendly than JSP.

16) I disagree with his documentation comment on Django. Django has practical documentation that actually helps you write apps, as opposed to J2EE or TG.

17) Django has built-in I18N along the same lines as J2EE (and much better when it comes to translations in code, actually). He failed both of these. It's no harder than creating a file with your translated strings and using a slightly different syntax in your code or template.

18) He really should have done a Spring application with a decent build system.

Some final thoughts:

J2EE isn't as bad as he says it is, if you're smart about what you're doing. Use Hibernate and Spring. When would I recommend this? You're in an all Java shop with conservative managers, and/or you have 30-40 people of varying skill levels all working on the same application. Note that Hibernate doesn't work well with Oracle Object Types, however. That's s discussion for some other time.

What you really want is something that does the easy stuff easily, but really buckles down and helps when things get hairy and unconventional.

Ruby on Rails: easy stuff is kinda easy as long as you are working on a new app, the language itself is kind of weird but usable, but it's somewhat unfinished and naive in places.

Turbo Gears: ditto, minus the comment about the language. Python is a joy. YMMV.

Zope: avoid unless you have the most cookie cutter of apps to build. Once you have to start digging into internals and changing things, you lose a lot of time and encounter a lot of headaches.

Django: Easy for easy stuff, and really pretty easy for hard stuff. The regex URLs let you solve a lot of problems you can't with the other frameworks, the templating is refreshingly practical, and there are a number of tools built-in that help you with more complex problems (like the wonderful template tag system -- beats taglibs hands down). The admin interface is sufficiently customizable that you can actually program to it if you want. Not a big deal. He didn't cover generic views or forms; good stuff there too. Django suffers a little from the same legacy DB problem that RoR has, excepting that you can change your models to do Hibernate-stylee remapping via the definitions.

Of all of these, Django is in my mind the best for this kind of development. Ease + flexibility + practicality.

Final final thought: the older I get, the more I come to appreciate explicit coding. I look on magic mapping and hidden functionality with a jaundiced eye, as these things 1) make maintenance (especially other peoples stuff) a pain in the ass, and 2) they make stepping outside the bounds of the magic unnecessarily difficult. XML configs are the worst of both worlds: encoding explicit magic. Yuck.

Agree on the productivity/bugs/boilerplate observations.

Disagree on templates. I *hate* document generation. I need to be able to see the structure of the document in an editor. Generation obfuscates that, and it's one step removed from string catenation. I've used such systems before and they're ugly. Although having said that, I don't know what you mean by "builder pattern".

On repositories: note that I said they can really, really suck. YMMV. However, I have to say that with Squeak at least the editor is ass. Sorry. Probably personal preference, but it's not Emacs.

On files being a distraction: you and I will disagree on this to the end of time, I'm sure. :-) Don't confuse Java's many nasty files with something like Python, though. Dired is sufficient to manage source files.

Looks like every other one I've seen, other than the Smalltalky bits. I really dislike systems that conflate HTML with code. I find them difficult to debug (where is this HTML coming from?) and difficult to rearrange when I want the page to look like something else.

I don't want it to look "something" like the HTML... I want to look at it and immediately understand what I'm getting. Difficult stuff can be put in a tag and called from the template.

Django's template system has a thing called [link|http://www.djangoproject.com/documentation/templates/#template-inheritance|blocks] as well:

In a parent template:
{% block foo %}This is the default.{% endblock %}

Then inherit that parent, and replace the 'foo' block if you want to specialize:
{% block foo %}This is not the default.{% endblock %}

Very useful. Django templates have the added bonus of being output-neutral: use them for emails, CSV, whatever.

I just don't agree with you that it's as useful as you seem to think it is, and I dislike the paradigm itself. Don't confuse disagreement with ignorance.

I prefer my HTML widgets to be written in HTML and markup, thank you very much. Not some unrelated language.

And if I forget and endblock, I produce a trace showing me that I forgot an endblock... not broken HTML.