So read this blog post as my (as an Interface Developer) reaction to working with Tapestry. Reactions like these can be avoided in two ways:

1) Document why Tapestry have chosen a different path than most other frameworks (for instance concerning white-space-collapsing). I found almost no reasoning when googling about the issues I encountered.
2) Change the defaults to more closely match when someone like me expect. From the comments I read that Tapestry developers don’t like to change any defaults, since they are used to things how they are. That’s fine. Do step 1 instead.

Yes, I have worked with Tapestry quite extensively and yes, I have quite different opinions of how to use html and css, but I ‘personally’ think that gives my bias a much stronger foundation than yours. Unfortunately, only somebody who has actually worked with Tapestry is capable of figuring out the holes in your arguments, so anybody who actually believes your _opinion_ might turn to something that is far worse but didn’t get flamed by a developer who didn’t get enough time put into learning it properly.

So, yes, I am biased, but no, I’m not close-minded. Among other things that’s how I am able to realise that Tapestry works extremely well for me while I accept that this may not count for everybody. Why I believe that you ARE closeminded, and I quote: “No. Tapestry was clearly not built with an interface developer in mind.” Which means that everybody does interface development the way you do, right?

My experience with T5 is limited, and I’ve not claimed otherwise, but I think a framework should handle that, either by being easy to learn (and by that I mean modify to ones liking, not simply using), or by being properly documented. My experience is that T5 is neither.

Feel free to say *which* of my statements are wrong, and I will address your concerns.

I’ve used several frameworks that let me choose the js frameworks myself, and that’s a good thing.

I think some of your complaints are just inexperience with T5, and frankly with web frameworks in general, because some of your statements are just wrong.

Also, you’re complaining about including JavaScript. I have to say, managing which JS libraries get loaded when can be a big pain in any of the application frameworks I’ve used. The fact that T5 has stuff to deal with that is a good thing.

It depends the way you develop your application.

Tapestry is designed to be extremely scalable in several dimensions:

* Tapestry applications may contain large numbers of pages and many custom components.
* Tapestry applications may contain very complex functionality.
* Tapestry applications may be created by large, diverse teams.
* Tapestry applications can service large numbers of concurrent users.

Please read first … before you give commentsssss…

Concerning XHTML. I usually don’t use it, but I don’t see why a framework should disallow people to use it. If Tapestry developers wants to disallow XHTML, they of course can. But it would be easy to make it possible to use.

You also seem to agree with my main point: Tapestry 5′s defaults are not as good as they could be. So, now we need two things: Change the defaults, and meanwhile, documentation of how to change the defaults to our liking.

There are many frameworks which are worse than Tapestry, no doubt, but that doesn’t mean Tapestry is perfect.

And where the xml element expansion is concerned: why would you want to deliver XHTML to browsers who don’t speak XML in the first place? Why not use old-fashioned HTML instead?

.Net makes for some seriously screwed up html, I agree, out of the box it is most likely one of the most horrible frameworks out there. I can probably find you 50 others, strewn around php, java, python, etc… So let’s get that out of the way, by default a framework is far from perfect, that’s because interface-developer think differently from backend developers and what’s even worse, they disagree between themselves!

Same goes for Tapestry, out of the box, it ain’t perfect! Surprisingly enough, out of the box it gets most of the stuff pretty close to perfect, from my personal perspective.
- It forces id’s on elements that need it, of course only if the developer didn’t actually set one correctly in the first place!
- It removes white-space from the page, and I like that, what’s even better, should I really need white-space somewhere on the page, I can tell it to preserve that, only there!!!
- All the default javascript and css can be disabled or overwritten, damn, that’s so cool, it only takes a single configuration property for each! With other frameworks I was unable to even so much as think about such things.
- The last point, about hidden elements you make? Really, get a live! Hidden elements rarely, if ever, screw up design, it’s a lousy point to make when the result of those hidden elements have many benefits that have, indeed, nothing to do with your little narrow field of specialization.
- Oh, did I mention that T5 can return only page-partials for Ajax-request, or JSON, or plain text, whatever you need? Guess you didn’t know that, I also guess the developer you worked with had as little experience with T5 as you did, since returning a seperate page for an Ajax-request is not quite the logical way to do things. The developer you work with should have been able to tell you how to work it out with T5, actually, he probably should have done the work. If you didn’t work with one, either you should not do the job, or you should get more serious about learning the framework you work in.

One last feature, plain html templating, the only non-html information you ‘have’ to add being t:id=”…” to elements that require an actual T5 component to render in their place.

All of this just being the tip of the ice-berg. Suffice to say, I’ve seen plenty of frameworks come and go, I’ve never (from an html/js/css point of view) been more enthusiastic about the capabilities of a framework before. Should you really not like the fact that you may need to re-configure parts of [insert name of a framework here] to get it closer to your private perspective of perfection, build your own, or start using plain old .jsp or .php pages and hope your backend developers won’t kill you :)

I think that article’s like this one are usefull not just for the community but also for the framework creator who can consider and repair all those HTML fights. It’s like a large feedback.

I don’t think that Emil is looking for perfection, i think that the word which can be used here is called “improvement”

Regarding those who read and not try i think that they should reconsider.