> It makes you much more credible if you understand what you are talking
> about. You should read Tapestry's documentation before posting such a
> blog.
> First of all, if you would spend 5 minutes learning Tapestry you would
> come
> across the "static structure, dynamic behavior" principle. Tapestry is not
> "rescanning templates and building DOM of the page before each rendering".
I have spent at least 5 weeks learning Tapestry, not 5 minutes.
Unfortunately I come to a suspicion that I know Tapestry site better
than even you do,. Here is what I read on the Tapestry site:
"At runtime, Tapestry parses the documents and only checks for
wellformedness".
So either Tapestry parses the documents at run-time or the Tapestry
site is awfully wrong.
> All the page instances are singletons, which are smart enough to care for
> multithreading aspects. So, your expectation on efficiency is naive.
But the Tapestry site tells:
"Components render out a Document Object Model (DOM). This is a
tree of nodes representing elements,
attributes and text within a document. Once all rendering is
complete, the DOM tree is streamed to the client."
Usually rendering means rendering at run-time. What this text describes
literary is that at run-time:
1) components render out DOM (tree of nodes)
2) DOM is visited recursively with streaming HTML to the client
(client is waiting for HTML, not for DOM).
If something different from described was meant by Tapestry site text
that is a problem of that site, not mine.
> If you want to speak about performance, create two similar apps with both
> technologies and measure the results. Show me the results, but please
> don't
> come up with something like "All in all it’s hard to expect Tapestry to be
> fast in production.".
I often insist on measuring of results in such a situation.
Unfortunately I have same much reasons to ask you to do the same. But
in general I agree. I even have a small set of very small tests on
HybridJava site that I suggest everybody to implement. I am afraid
that implementing them with Tapestry may be a waist of time, but if
you agree to try to implement some of my tests (for instance
"Components") using Tapestry than I may promise to implement a test of
your choice in HybridJava provided it will be not much more complex than my
test.
> Also your statements on Tapestry's IoC, mixins, template inheritance and
> annotation-based approach are sweet and naive as you don't provide any
> arguments. These features are why Tapestry users love the framework.
User's love may be an argument for commercial success, but not for
scientific discussion.
There are many users for instance that admire heroin.
By the way - one of the features mentioned above is if fact "not
recommended" by Tapestry site ...
> Nice try, but not professional.
Did not get what is nice. "not professional" does not sound convincing.
Especially if what you do not like is in fact a mess in your own
documentation.
I wrote above about comparing in numbers and that would be way more
professional
than blatantly claiming each other "unprofessional".
I suggest you may also pay attention to similarities in our frameworks
and possible collaboration of
our teams in the future
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Re-HybridJava-vs-Tapestry-tp3555989p3656756.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
