Slashdot Mirror
Tapestry Making Web Development a Breeze?
An anonymous reader writes "IBM DeveloperWorks has an interesting article on how to simplify your Web-based development with Tapestry, an open-source, Java-based framework that makes developing a breeze. The article shows you around Tapestry, from installation to file structure. See for yourself how Tapestry facilitates servlet-based Web application development using HTML and template tags."
Is it just me, or does anyone else feel that all the "rapid development" frameworks that are all the rage lately may be harmful to the current crop of new developers? There should always be a balance between development speed and flexibility, and I fear that crutches like rapid web development frameworks trade ease of use for the ability to do something novel. Of course, one can say "if you don't like it, don't use it", but the fact is that people new to the field will use it regardless, simply because it's the path of least resistance. True, some clever ones will extend the range of what was thought possible, but most will end up with the same cookie-cutter projects for which these frameworks are always tailored (look to scaffolding in Ruby on Rails for an example of the omnipresent "database browser").
I suppose this is just the next step in the constant progression toward appeasing laziness; no matter how easy an interface becomes, there will always be demand for something or someone to fill the gap of applying actual effort to learn it.
>The solution is definately more involved than the problem.
I'd love to say "amen to that". I hate frameworks.
But the thing is, there are often classes of problems to which these things apply. It's just that you and I dont have them. A framework is a tool; use it when it suits.
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
Hm. Tapestry is an open source project; from the FAQ:
So I'm not sure that this really qualifies as an ad. More of a "free, informative article", especially since the author (Brett McLaughlin) is quite a Java guru.
Looks like Tapestry uses annotations a lot; I've found them to be pretty handy things as well...
The Army reading list
IMHO, this article is really poorly written. When reading an article on this kind of topic, I want the first couple of paragraphs to tell me what is new/unique about this tool. Instead the author wastes endless column space describing how to install the software, then more space describing the sample applications that you could look at yourself once you downloaded it anyway. I want to be given a reason to try it out: What makes this tool powerful; how can it save me time/help me to produce cleaner code? Maybe he got to this by the end of the article, but I had given up by then.
As the original author of Tapestry (but not the article on DeveloperWorks, which caught me by surprise) I can say that IBM doesn't have any secret agenda on this. In fact, given that IBM is selling a commercial product that competes head-to-head with Tapestry (their JavaServer Faces, built on top of their WebSphere proprietary Eclipse IDE) it is enlightened of them to cover Tapestry.
Of course, what's going on there is two fold. First, IBM is big enough that different areas of the organization will have different and occasionally competing goals. Primarily, all on-line magazines are constantly hunting for new material to keep the eyeballs looking (and the click rates clicking). IBM doesn't solicit authors to write on particular subjects, they accept existing authors efforts, with the authors pursuing their own interests. Here, Brett happened to be into Tapestry and did a great job providing additional documentation in the form of this article.
I make my living off of Tapestry, so I'm happy to see this kind of coverage, but the framework itself is open source and free, with a very, very liberal license (ASL 2.0). I make money by providing Tapestry support and training. There's your ad.
In even newer news, Tapestry 4.0 final release is now available.
Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind
pfft, web based tapestry making has been around for ages.
No! :(
The post looks like an ad.
I have used Tapestry several times since its firsts versions (pre-Apache). It sucks.
Yeah is much better than Struts and others, but is really complicated... a lot of XML
Why other frameworks like Seaside http://www.seaside.st/ doesn't receive the attention of Slashdot?
Seaside is technically superior, it uses continuations to mantain state and this make it really transparent...
Maybe because Seaside runs in Squeak http://www.squeak.org/, is open source and...
Wait is not sponsored by any big name (like IBM, or Sun)... mmm both IBM and Sun publishes its ads in slashdot...
Ahhh now I see why
Rails has a lot going for it, and the entire Ruby concept of focusing on code has influenced many frameworks, including Tapestry. Tapestry uses abstract properties combined with annotations (or auxillary XML files) to do the kind of meta programming that is done using class methods in Ruby, but nonetheless.
In terms of dependencies, being an Apache project causes some distribution problems w.r.t depenencies, especially when you use non-Apache projects like OGNL and Javassist. The next major release of Tapestry will build using Maven, which will make nearly all of part 1 of this article irrelevant (or at least, standard). I'm looking forward to part 2 myself, which should identify why Tapestry is so special.
Finally, within the Java community, Tapestry is fairly well known, though a regrettably small percentage have used it. The majority of the targetted readers of this article would have objected to wasting too much space describing Tapestry and its goals, just as others in this thread have objected to the lack of that introductory material. You can't please everyone (exception on Slashdot, where you can't please anyone).
Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind
Please don't take offense with this, but Tapestry seems to be an open source version of NeXT's - then Apple's WebObjects web application development system. Even the Tapestry documentation acknowledges this.
WebObjects performed poorly in the marketplace due to Apple's stunning inability to market it's strengths - the exact same strengths the article is describing. Many people, including Apple employees - (myself in the past) - lobbied for WO to be made open source. We failed. Good to see that the ideas live on.
To be fair, when I hear a reference to the "Original Author of Tapestry" I do think its only fair to refer to the staff at NeXT, then Apple who developed this wonderful system. Tapestry is impressive in its own right, but seems more an extension of WO design principals rathen than a unique work. Such is the history of software design, so all's fair in the end.
And yes, I own your book, and think it's very well done. Tapestry is a great system, and can be recommended - but let's not forget the original inspiration.
/* Dang, I can't type that well. */
I realized long ago that frameworks were a waste of time, I'd already authored several by then. The last framework I wrote generated static html and now we just edit these pages by hand or write simple shell scripts. The solution is definately more involved than the problem.
Not necessarily. The right framework can produce the HTML for you, and can save you a lot of time because you can use components that generate things like fully-tested portable JavaScript. Some frameworks allow a lot of re-use. JavaServer Faces (JSF) will allow the possibility of rendering HTML, XML, WML or a range of other client presentation technologies from the same tags.
The solution may only be more involved that the problem is simple, and it is hard to tell when a problem will grow to be complex. Using a framework can not only save time but can be a form of insurance against future growth in complexity of the website.
This is no longer our father's web so why should our tools be our fathers?
Because they work.
KFG
I have heard authors who swear that handwriting is much better than typewriting. Some people swear that they can tell if a story was written on a word processor. I have heard many complaints that Power Point tends to force presentations into a kind of mindless cookie-cutter kind of sameness. All these things are actually true.
What separates a good web page from a crummy one is not so much the tools that get used but the talent and knowledge of its author. The sad truth is that there are many hacks out there who won't produce good web pages no matter what tools they use. Easy-to-use tools do make it easier for talented designers to get up to speed quickly.
My experience is with the sign industry. In the good old days, a sign painter would work for years to perfect a 'font' which he could produce effortlessly with his brush. By the time he learned his craft he was probably a pretty good designer too. Then we got sign cutters (cutting vinyl letters with a plotter). Now everyone had the same set of fonts. Joe's Rapid Cheap Sign Place was competing with businesses that had been established for many years. Guess what? The good designers still command good prices. The hacks race to the bottom of the market; undercutting each other on price. As far as I can tell, web design is quite similar. Any high school kid can churn out a web page. Some of them are nicer than those done by 'professionals'. There's still a market for good work. The hacks can't do good work and people can tell the difference.
I think in real life it doesn't metter which technology you use for implementation to give results fast too much. Ofcourse with some technologies the results are faster than wiht another for instance PHP vs Java Servlet. But if you count time which you spend on implementation of user requirements and time which you spend by reimplementing functionality which user specified incorrectly, you can end-up with result that reparing taken most of the time in other words budget. In our company we solved this issue by creating prototypes with this tool PETRA (http://www.cleverlance.com/petra). Business analyst draws gui prototype by speed 20 pages per day. When he is finished he gives prototype to customer/user who clicks trough and expresses his changes. After making several rounds customer and customer is satisfied with prototype, programers finaly start coding. We expirienced that with this approach customer knows what will be delivered on the begining of the project. He saves money on change requests and we deliver real application twice faster. It isn't just rapid development what does delivering faster, but clear customers requrements rafined by prototype. Check out that tool, it realy helps.
For personal development i've set myself a directory of perl scripts that don't interact directly with live html (they aren't CGI's), but rather perform small web related tasks on a bunch of files. I still edit my markup in a text editor. Here is a taste of what I mean.
/> tag to before the 4th paragraph of a chunk of text and float it to right (by applying the 'right' class attribute to it).
... yuck!).
paragraph.pl: Replaces "\r\n\r\n" with "</p%gt;\r\n\r\n<p%gt;" to properly paragraph text.
image.pl: Let's me issue a command like "add madness.png 4 right" to add an <img
thumbnails.pl: Give it a directory, it simply creates a subdirectory called 'thumbnails' and creates a dump load of thumbnails of a specific size therein.
I have a few dozen like this organised into folders, some taking a filename parameter but most just slurp stuff in via stdin and spitting out via stdout.
For the most part, this suits my style of personal web development. I find it difficult and discouraging to finish a project and polish it off only to have it 'out of fashion' or hate it myself in a few months time. This method let's me idley write small scripts, almost out of boredom, and put them to use. Recycling code is made very easy as well.
Of course personal pages these days have to have a bit of flashy interactivity. For that I get away with as much as I can on the client side. For example, manipulating lists using javascript for fast navigation (no not using xmlhttprequest, just manipulating the DOM), this saves on dynamic server side navigation code (Think of how many URL's out there you've seen ending in something like 'index.php?page=login'
For real interactivity, commenting underneath photos for example, comments are written using a live (cgi) perl script to a flat text file and a cronjob at my webhost crawls the directory tree every so often, does some filtering and validation, regenerates the comments html, and deletes the source files. The comments HTML in included into the photo page then using a server side include.
Simplistic but.... sufficient for a geeks personal webpage?
Don't be put off by the comments. If you already know about it, how to install it etc, this is not for you. But if you don't, its clear and informative and interesting. Looking forward to the next part.
I just finished reading an interesting comparison of Java, PHP and Python over on Bob Ippolito's weblog. It talks about the implementation of a simple web service in the three languages. To summarise:
That's to implement the same web service.
Bogtha Bogtha Bogtha
I am aware of the dangers associated with poorly designed rich clients, but rich clients work well, as long as you use some discipline in the system architecture. I know some rich client architectures exist, such as Curl, but in general, it appears there is very little activity in this arena. I wish this industry would focus a little more on interesting GUIs, instead of beating the same horse over and over again.
Although I freely being influenced as a user of WebObjects back in the day (circa 1998 and 1999), that's about as far as the lineage goes. I certainly built Tapestry with a different set of expectations and compromises than WebObjects, and that has evolved further of the years.
However, I will stand by declaring myself "the original author of Tapestry". That clearly describes Tapestry design and implementation; the flavor might inlcude a little WebObjects spice, but the meat is pure Java + Servlets + Howard Lewis Ship's insights and contributions (and mistakes).
Now look what you made me do ... refer to myself in the third person!
Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind
* 117 lines of very liberally spaced Python code, or
* 138 lines of insecure PHP code, or
* 3004 lines of Java code in 45 files, 29 lines of SQL, and 246 lines of XML configuration in five files.
Which is complete nonsense, as with Java you can use JSP tag libraries, which will are secure (compiled, so no code injection at run-time) and can be used in exactly the same way as PHP, so will require about the same size of code.
I've worked with Tapestry. Is it a decent framework? Yes. Did we end up choosing it over JSF for our project? Yes, we did. Did it make development "a breeze"? No.
In my experience, Tapestry simplifies some complex tasks and helps you write reasonably clean, well-structured code. This is, I think, all anyone should realistically hope for from any framework. However, it isn't a magic bullet and we did find that things became a little gnarly as soon as we tried to do stuff that the Tapestry developers hadn't really anticipated or designed for (and the things we were trying to do weren't really very exotic).
Of the frameworks I've seen lately, Ruby on Rails is the one that bends the curve the furthest in the trade-off between 'what you can do' and 'how easy it is to do it'. Tapestry is a way behind that, but it's nevertheless a solid addition to anyone's toolkit, so long as you don't have unrealistic expectations of what it can do for you.
I agree with the sentiment of this comment -- but Escherial, I think you saw the word "rapid" and made a bunch of bad presumptions about Tapestry. Tapestry is not a crutch; it is an excellent framework, one you're obviously ignorant of.
What Tapestry is emphatically not is a whizzy-ooey drag-and-drop autogenerated no-coding-necessary whiz-bang shill. Those are, by and large, a bunch of crap: they usually just make the easiest 90% even easier, and the "last 90%" even harder.
What Tapestry is is a very nice web framework, which has a lot of the same MVC capabilities as Struts and the code reuse possibilities of JSF, with far less configuration and unnecessary complexity than either of those options. The Tapestry team, much like the excellent Rails folks, have looked for ways to reduce redundancy, boilerplate code, and messy configuration -- especially in this 4.0 release. Roughly speaking, Tapestry is about 80-90% of the streamlined simplicity of Rails, but with a much richer framework underneath and all the existing libraries and machinery of Java at your disposal. It has the best mechanism for HTML fragment reuse I know of.
What the Tapestry team has not done is try to make an app that thinks for you. You've still got to code. It's just a lot less tedious than with most other frameworks.
My two latest webapps have been all Tapestry 4, and it's great how little code/config I have to write that isn't conveying useful information. I'm really quite impressed with the framework.
So yeah, I agree with your rant, but it's not appropriate to Tapestry.
...will people stop pretending that "Java" is one giant monolithic thing that only works one way.
Look, these flagships specs like J2EE and EJB are designed to solve problems of writing massively distributed apps that need to have transactions spanning multiple servers running different OSes -- horrendous problems that you never, ever, ever want to have to solve. And if you do have to solve them, Java is the best way -- but if you take all that machinery and try to write a "hello world" webapp, of course it's going to take 30 bazillion lines of code.
Somebody writing the webapp he describes in 3000 lines of Java is either (1) utterly ignorant of how to use the Java frameworks (like Tapestry) that are appropriate for the task, or (2) deliberately spreading FUD on behalf of Python.
That is not to slight Python or the framework he's using. Python is very cool. I'm just sick of people complaining about "Java" when what they're really complaining about is "Java abuse."
Lets just, for the sake of clarity and shameless Python-fanboyism, ignore the fact that the PHP code was properly commented (about a third of the 'code') and the Python code had a whopping 1 (one) line of commenting. Not to mention the PHP code had extra newlines adding to the readability of the code, and about half the code was a (very neatly indentend) array for some external library. Wake me up when you have a proper comparison.
Don't get me wrong: I love Python. But it doesn't need flawed statistics. Heck, I'd think a maintenance programmer would love the PHP code easily over that Python mess. (K)LOC don't count people, your use of commenting and clear code does!
This sig is intentionally left blank
Everything that isn't spaghetti code has an underlying architecture. Frameworks are just standardized, generalized, pluggable versions of that architecture. Practically any off-the-shelf web framework you decide to use is going to be better than what you hand roll, assuming your site is bigger than 10 pages. If it is smaller than 10 pages, stay the hell away from Java and get a decent Perl, Ruby, or PHP framework.
A framework is less a tool than it is an entire toolbox and a methodology for using said tools. These things are almost always useful.
Comment removed based on user account deletion
There will always be a need for developers. The lack of creative flexability that these types of systems offer will be their ultimate downfall.
This just in! 3 out of 4 people make up 75% of the population.
Must be slashdot:
- Uninformed comment near the top? check
- Pointless flamebait modded to Score 5? check
- Disingenuous and patently ridiculous to boot? check
- Complete ignorance to the turing equivalency to all languages? of course
Wow. I'm making a study. Apparently in french:
"Voulez-Vous Couchez Avec Moi?"
In English
It has come to the attention of my biological subsystems that I find you sexually fit and attractive, and thus would like to engage in procreative attempts in order to further the expansion of my genetic sequences in the Hobbesian environment we live in. Do you find such a query to be to your liking and predilection?
Hey, I'm just your average shit and piss factory.
Sun's java studio creator is now free. I'm not sure which "framework" if any it uses but it seems a quick and
e ator/index.jspe ator/reference/quicktour/2/flash/index.html
well though out way to created database backed web pages. I wonder if tapestry works with this or eclipse.
Sun is definetly feeling some heat from eclipse and starting to make it development tools significantly better.
If I wasn't using php I would definetely look into thses.
http://developers.sun.com/prodtech/javatools/jscr
http://developers.sun.com/prodtech/javatools/jscr
I evaluated both JSF and Tapestry for my latest project, with a slight prejudice in favor of JSF, and ended up choosing Tapestry ... by a mile, actually, and for some of the same reasons you mentioned: too hard to "break the mold" in JSF.
That's not to say that I haven't had some wrangling with Tapestry, but it was for genuinely unusual stuff. And it's a heck of lot more concise than JSF.
The Tapestry docs are rather mediocre; they're still a holdover from v3 in many parts, and make some things sound harder than they need to be. I wonder if you used Tap 4 on Java 1.5 to their full potential?
On the plus side, they can possibly (and sometimes live up to the promise of) saving you the trouble of writing boilerplate code (e.g. db access, ....). They're far better than what would be hand-coded at shops where competence is, shall we say, less than common. My relevant horror story here was a job I walked into that had no definitive version of the source, no source code control, and developers just out of school given open-ended assignments to make this or that work with no supervision or code review. Lots of random SQL in jsps, a real mess. In a situation like that any framework is a godsend (any kind of architecture is better than none).
Another positive is that you can learn a fair amount about architecture and patterns from using them - one of the things that made a fair impression on me when reading about patterns was the statement that other professions, like architecture, train people by having them emulate and study the works of professionals, and the complaint that there were no software masterpieces to study. A budding architect studies Frank Lloyd Wright's FallingWater. What does a budding software developer study? Maybe frameworks are the beginning of an answer to this question, as you can absorb a fair amount of architectural principles through working with them.
On the minus side, I'm starting to see these things done as a sort of orthodoxy, and often they just add unnecassary layers to the code because "that's the way you're supposed to do it". You can often spend more time twiddling with the framework to get it to do what you want than it'd take you to write your own. My relevant story here is the day and a half I spent last week trying to figure out why my hibernate setup wasn't working properly, until I finally came upon a little note somewhere in the docs that it had problems with SQL Server and wasn't recommended. This is, BTW, for read-only access to the database, hardly worth the bother. (Of course, It's entirely possible that I was configuring it incorrectly in some way, didn't have the time to research it further, which is part of the point of the bother of it, there's a fair gap between learning it enough to get by and knowing it thorugh and through, and one rarely has time for the latter).
Generally my problem with them is that they tend to black-box the solutions they provide (which I suppose is sort of the point) which is great if it works exactly the way it's supposed to and leaves you wasting enourmous amounts of time if it doesn't.
A related issue is that they can make debugging and code tracing much harder. A Spring app, for example, links code through config files. Even if you understand the config files, you add a layer of indirection to code tracing. If you don't it can be almost impossible to figure out how this piece of data gets onto that page.
They're neccessary, I suppose, and good for something, but should be swallowed with a bit more salt than they generally are in the industry.
Yeah, I agree.
I can understand why people choose Java and do J2EE. I've studied J2EE and liked it.
But as I do work in LAMP enviroment, can't fathom why I should move to Java application servers in the web.
They're far too complex, many are still buggy and costs are high for then. Jsp doesn't offer much more than does PHP, infact I think to effectively use it, one needs to do lot more.
It's not that Java is hard or difficult, using it just create lot more work than using PHP. Unless you have some uber organization that needs lot of scalability and thread safety, then the sacrifice for java is not justified.
Nobody knows the trouble I've seen, nobody knows has the trouble seen me, even I sometimes wonder why I write these line
My own current solution on my personal Web site involves doing a more limited version of that using PHP. I'm debating whether I want to try to move it to a Real Web Framework or not.
If you like Perl, you might be interested in Jifty, a new open-source Perl-based Web framework. It's only a "developer release" right now (ie. don't use it to run your banking site), but it's pretty useable all the same. It's got a lot of the shiny AJAX stuff people have come to expect, and it makes setting basic things up ridiculously easy, but it's also got a solid core foundation for database stuff. It's a pretty spiffy framework.
(Disclaimer: I work for Best Practical Solutions, the company that started Jifty.)
Your code has a buffer overflow error at byte 12.
This gets modded Informative? What crack are the mods on and please cant I not have any of it?
In this day and age, real men write HTML by integrating several streams from databases, RSS feeds, and all manner of other things, and passing the resultant XML through an XSL transform on the fly.
Fair enough, you probably write your XSL in a text editor.
I'm old enough to remember when discussions on Slashdot were well informed.
However, more I have done programming and web pages, more I think simplicity is best. More there are layers and neat tricks, more there is confusion and something that you have to debug.
Not really. There can be nothing as confusing as dozens of JSP/PHP pages with lots of repeated code and no central map of how the navigation is done.
Often structure gives clarity.
This gets modded Informative? Oh, the irony... it hurts.
Mods, just bogart that joint! My post (above) wasn't Informative . At best it was (dubiously) Funny . Arguably it was either Flamebait or Troll ; and it is now certainly Overrated .
See, these funny little words in the moderation menu, they all have semantic content, you know? Like, they actually mean something... Oh, never mind. As you were.
I'm old enough to remember when discussions on Slashdot were well informed.
Argh, you spoiled the joke. Every developer who doesn't use frameworks could see that obvious programming mistake.
---- MISSING MISCELLANEOUS DATA SEGMENT --- [sigdash] trolololol
1. Complicated. Uneasy to learn.
Just different. People trying to find Struts++ get confused because Tapestry is a completely different beast.
2. Does not support unit testing.
Wrong. This was doeable in 3.0 with an add-on; an improved version of the add-on is part of Tapestry 4.0.
3. The "Model" component of MVC is closely tight to "View"; you cannot have many views of the same page (for instance: web page, web page for printing, WAP page).
Ultimately, your model is really DTO, not your page or component class. Tapestry components don't care where data comes from, thanks to OGNL. So, there's no reason you can't have multiple pages for different formats. However, Tapestry does not address the myth of one page / multiple views. A desktop HTML application and a WAP application are completely different beasts and should be treated as such. You should not be coding applications inside a big case statement.
4. Adding your own JavaScripts suxx. You have to map component names etc.
Because HTML output is componentized, JavaScript generation for that HTML must be componentized. This is an annoyance for simple cases, but means that complex cases just work. You can have as many DatePickers or Palettes or validating fields and forms per page as you like and it all just works with everything wired together properly, and all client-side elements (JavaScript variables and function names) generated free of naming collisions. Tapestry was born to do Ajax.
5. If you want to validate form field, you have to use special components (ValidField). Some components do not have their validated counterparts. Client-side validation is very basic (e.g. cannot check if entered date is in the future).
You haven't looked at Tapestry 4.0. Paul Ferarro did a complete rewrite of the validation subsystem to make it more powerful and more flexible; all the form control components now support input validation, ValidField has been deprecated.
6. Changing one line of code/template requires you to redeploy whole application; that is, pack it into .war archive, send to web server, perform refresh. When used with Apache Tomcat, leads to memory leaks.
So you're blaming Tapestry for your bad development model? I deploy into Tomcat, but do all my development inside my IDE using Jetty. No redeploy, and I can bounce the Jetty instance in a few seconds.
7. The page pool model is said to scale well, but can be very error-prone. For instance: if you forget to reset some variable, it can be displayed by some other user when he happens to pull it from the page pool.
This I find an amazing observation; Even Tapestry 3.0 supports transient and persistent properties for you ... meaning you write an abstract class and let Tapestry provide the code to implement the property along with the compliance code to work well with the page pool. Management of transient and persistent page state is an application concern that you should be delegating to Tapestry. Just define abstract getters and/or setters, rather than instance variables (and getters and setters). Tapestry writes the code for you (at runtime).
Howard M. Lewis Ship -- Independent J2EE / Open-Source Java Consultant -- Creator, Apache Tapestry and HiveMind
Generating XML and transforming it via XSLT on the server is plain stupid. I have never seen a project which required this extra flexibility and justified the huge overhead of using the ugly XSLT. Piping the XML to the client and doing the XSLT transformations there might be ok in cases where bandwith is of importance.
Here is an example, so you can say that you have 'seen' such a project. Sometimes it is useful to generate XML because it can be selectively transformed by XSLT to a variety of report formats as the user requires: XML+XSLT can output RTF, or it can output XSL:FO which can be rendered as postscript or PDF, which can be returned to the user. The same XML output can be transformed into these different formats simply by supplying a different XSL stylesheet. This is simple to use.
XSLT processing can be very efficient, and to say XSLT is 'ugly' is simply a personal aesthetic judgment, and not of any value in judging how useful or fast it is.
All these frameworks limit testing capabilities and move things away from the compiler to the runtime. EL expressions, JSP taglibs, Beans using Reflection, huge XML configuration, XSLT and so on are all evaluated at runtime and none of this can be checked by a compiler.
This is simply not true. A good IDE (like Eclipse) has plugins that can check the validity of most of these before runtime.