Re: Where does Tapestry fit today
Interesting discussion. :) As much as you can move logic from server- to client-side, there's still stuff that doesn't fit well in the client, specially security-sensitive stuff (including privacy issues and sensitive data that shouldn't leave the servers). So you want this stuff done server-side, and Tapestry and Tapestry-IoC (from which a large fraction of Tapestry-the-web-framework awesomeness comes from) are a very good choice, maybe even the better ones. One example in which single-page applications wouldn't work: websitPubFactory (http://www.pubfactory.com/), which is built on Tapestry. Disclaimer: I'm part of the PubFactory team: https://www.safaribooksonline.com/blog/2015/11/23/my-life-with-open-source-or-how-helping-strangers-boosted-my-career/. From PubFactory's website: "PubFactory is built from the ground up to support books, reference works and journals in a variety of XML formats, with full support for PDF, images and other rich media. It offers a full array of features for users, management tools for librarians and administrators, and a complete suite of back-end controls for publishers to control their content and manage relationships with their customers." We could never pass the raw document data for it to be transformed and rendered client-side. It would be both a security issue (raw data in the client) and probably a performance issue (too much time and processing power needed to do the complex transformations if done in the client, specially in mobile devices). SEO is also a very important factor for PubFactory and its clients and it's not covered well by single-page applications yet. On Tue, 29 Dec 2015 12:07:57 -0200, Barry Books wrote: I've written several "Enterprise Apps" with Tapestry and I would say as of 5.4 it's pretty much perfect for that class of web applications. The best feature of Tapestry is it's easy to build components and piece them together is various ways to build applications. The obvious place to start is with the tml/java UI components but with Tapestry pretty much everything is a building block that that can be combined in various ways. For example BeanEditor/Grid/Hibernate can handle CRUD with only a few lines of code and produce a working prototype in a few minutes. By leveraging datatypes, validators, mixing, components and services the prototype can be turned into the final product. All the parts can easily be refactored into a library and the next application is even easier. The addition of Bootstrap makes everything pretty without much work. While Java is perhaps the new Cobol that's a feature in the Enterprise world. Tapestry hides some of the worst parts like server restarts and if you do things right it's faster to build prototypes with Tapestry than almost anything else and they will work in production and be maintainable. With annotations most of the high level code can be declarative and it's possible to make sweeping changes without changing the tml/Java files. It's possible to plug into the rendering pipeline in various ways so complexity can be isolated and finally if you use Maven the structure is defined and builds are easy (really). As far as performance I run 5 applications on one virtual machine with 4 instances of Tomcat. I load balance the apps across 2 so I can deploy without downtime. I run Hudson in 1 to schedule jobs and the last instance runs all the batch jobs. The machine gets about 10 page hits a second and runs about 10% cpu. I'm sure all of them could be run on the smallest AWS EC2 instance. The whole stack (except perhaps the database) is free and Enterprise friendly. I'm not sure what else you could want. As far as one page apps go I have built some GWT apps that run on top of the Tapestry stack but I've been moving them back to Tapestry one by one. While there have been complaints about Tapestry backward compatibility some of my applications started with version 3 and are now 5.4 While it's taken some work the fundamental ideas have remained pretty constant. Currently this does not seem to be the case with Javascript frameworks and long term maintenance is a problem. While single page apps are the new hotness I think they fill a perhaps small niche. They are not currently SEO or Enterprise friendly. That said Google maps would be painful as an old school web app. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Where does Tapestry fit today
I've written several "Enterprise Apps" with Tapestry and I would say as of 5.4 it's pretty much perfect for that class of web applications. The best feature of Tapestry is it's easy to build components and piece them together is various ways to build applications. The obvious place to start is with the tml/java UI components but with Tapestry pretty much everything is a building block that that can be combined in various ways. For example BeanEditor/Grid/Hibernate can handle CRUD with only a few lines of code and produce a working prototype in a few minutes. By leveraging datatypes, validators, mixing, components and services the prototype can be turned into the final product. All the parts can easily be refactored into a library and the next application is even easier. The addition of Bootstrap makes everything pretty without much work. While Java is perhaps the new Cobol that's a feature in the Enterprise world. Tapestry hides some of the worst parts like server restarts and if you do things right it's faster to build prototypes with Tapestry than almost anything else and they will work in production and be maintainable. With annotations most of the high level code can be declarative and it's possible to make sweeping changes without changing the tml/Java files. It's possible to plug into the rendering pipeline in various ways so complexity can be isolated and finally if you use Maven the structure is defined and builds are easy (really). As far as performance I run 5 applications on one virtual machine with 4 instances of Tomcat. I load balance the apps across 2 so I can deploy without downtime. I run Hudson in 1 to schedule jobs and the last instance runs all the batch jobs. The machine gets about 10 page hits a second and runs about 10% cpu. I'm sure all of them could be run on the smallest AWS EC2 instance. The whole stack (except perhaps the database) is free and Enterprise friendly. I'm not sure what else you could want. As far as one page apps go I have built some GWT apps that run on top of the Tapestry stack but I've been moving them back to Tapestry one by one. While there have been complaints about Tapestry backward compatibility some of my applications started with version 3 and are now 5.4 While it's taken some work the fundamental ideas have remained pretty constant. Currently this does not seem to be the case with Javascript frameworks and long term maintenance is a problem. While single page apps are the new hotness I think they fill a perhaps small niche. They are not currently SEO or Enterprise friendly. That said Google maps would be painful as an old school web app.
Re: Where does Tapestry fit today
Kalle - I'm not necessarily interested in single page apps only. I gave that as an example of a pattern that seems to be popular these days, that doesn't fit very well w/ the most valuable parts of Tapestry (as discussed by Vangel , those apps have their own set of problems). In general, I'm interested in learning what types of applications current users find Tapestry most applicable in. JAX-RS is indeed a bit cumbersome (for providing those restful services), and these days I'm not entirely convinced that JPA/JDO as as necessary an evil as they looked to be in the last few years. I've also seen first hand the mess that apps built using dynamic languages have a tendency to turn into (my personal experience was w/ Groovy/Grails). Along the same lines, looking at how Java EE app servers were created (to host multiple wars/applications, somehow isolated from each other), they seem a bit less relevant today (as everyone seems to be deploying an "app per process" to get proper resource isolation) and they bring SO MUCH baggage with them. Many of the issues with "Java the language" are pretty well addressed with Scala (which incidentally, works pretty well in Tapestry). In any case, lately I've been trying to really understand how much of the existing complexity of Java web apps is really needed, and how much of it is just a result of "I've been doing this for so long that it doesn't bother me". In terms of "other frameworks", in the last few years I've looked at a couple of the Scala-originated ones (e.g. Play, Lift), and although they do offer a fresh perspective on how web apps should/could be built (e.g. no servlet containers, asyncrhonicity, a bunch of other niceties), they certainly lack a lot of the things that I've gotten used to (e.g. being able to package markup + client javascript and server-side behavior in one component), and seem to have taken steps backward towards "action based" approaches (although Lift has some good/interesting ideas similar to Tapestry in terms of how content is assembled, it has a bunch of statefulness/weirdness that didn't quite fit with me) Vangel, I appreciate the thoughts on how "modern" JS-focused apps tend to offload their work onto the client. I've also seen a bunch of other issues (in addition to the mess of processing that js-focused apps tend to offload to the client) w/ that approach first hand (e.g. where there is a "bubble of state" on the client side in the browser that likes to get out of sync w/ the "real" state on the server). My question is still open though - what are the kinds of apps that Tapestry, being what it is (sophisticated, component based framework) that it uniquely serves. 1. Performance : the example by Kalle is valid to an extent (e.g. performance vs non-jvm based apps), but I get the sense that the same advantage can be claimed by a Spring MVC or by a Play-based app. 2. Templating : this was another valid point by Kalle - although other frameworks do have templating capabilities, they are a bit less advanced from what Tapestry provides. This might be a valid distinction, although it's still not entirely clear that this is a reason to choose Tapestry (e.g. not if you were seasoned in it, but if you were starting from scratch) 3. Not offloading computation to the client where it's not needed (Vangel's example) - this is a fair point, but again, it can be claimed by ANY server side framework, not just Tapestry. 4. Application structure : the point of the steaming mess that dynamic languages tend to make out of a medium-sized non-trivial applications. This , to an extent is also a fair point (as Tapestry does offer a bunch of additional structure that's not present in other apps), but this can also be claimed largely by any framework that's written in Java/Scala (being statically typed languages) that offer some guidance/rules on the structure of the app ( most frameworks that I've dealt with do this already) So, what is the sweet spot for Tapestry-based web apps ? What keeps the users on this list still building their apps in Tapestry (beyond, well, it was already built that way), and what brings new users to build their apps with Tapestry (when they're starting from scratch) ? Cheers - Alex K On Sat, Dec 26, 2015 at 7:30 PM, Kalle Korhonen wrote: > On Fri, Dec 25, 2015 at 1:22 PM, Alex Kotchnev wrote: > > > These days, HTML5 + javascript single page apps are all the rage. The > whole > > approach of having a rich javascript-based client (e.g. something based > on > > Angular) that uses REST-ful services, although not incompatible w/ > > Tapestry, certainly doesn't quite fit very well . > > > > Is it Tapestry or Java that doesn't quite fit well? Having been using > JAX-RS (via tapestry-resteasy of course) paired with an Ember frontend now > for some months, JAX-RS always feels a bit cumbersome and never quite > fitting. Some of the fault is with Ember and it's modules though (but after > Ember's clear and predictable roadmap, ember
Re: Where does Tapestry fit today
On Fri, Dec 25, 2015 at 1:22 PM, Alex Kotchnev wrote: > These days, HTML5 + javascript single page apps are all the rage. The whole > approach of having a rich javascript-based client (e.g. something based on > Angular) that uses REST-ful services, although not incompatible w/ > Tapestry, certainly doesn't quite fit very well . > Is it Tapestry or Java that doesn't quite fit well? Having been using JAX-RS (via tapestry-resteasy of course) paired with an Ember frontend now for some months, JAX-RS always feels a bit cumbersome and never quite fitting. Some of the fault is with Ember and it's modules though (but after Ember's clear and predictable roadmap, ember-cli and friends, I'm not going back to Angular). But even still, I can see why node.js is a popular choice as the back-end for the single page apps. For me personally, I'd love to use a different framework for building web apps if it was better. The problem with most other contenders I've tried is that they are nowhere near as comprehensive as Tapestry. They may shine in some areas but often horribly lack in others. Sometimes it's the language itself. I've always hated Java's syntax (coming from Delphi, Smalltalk background) but I just don't get how people get by without actual threads. Certainly there are many infoapps that merely input/output data but as soon as you start doing some real number crunching, it better run on the background and in parallel. I've seen so many RoR and Python implementation that started out clean and small, then somewhere along the way required one other service for this and another service for that, deploying some C libraries, perhaps a few front-end servers for scalability etc. etc. and before you know it, the time of all of your engineers is spent on debugging some weird issues that nobody really fully understands. Even if it's not the complexity that causes dislike in me, it's the performance. Nowadays, you can always "just spin up another instance" but nobody ever thinks about the cost. In a fairly recent case (based on T5.3), we were serving 17,000 requests/minute at peak times from a single node for pennies on the dollar. I've seen a VC-backed startup serving 10,000 requests per day on a Heroku deployed RoR implementation and paying $400/month for it. Compared to personnel and other costs, of course it's peanuts but I just hate to imagine what something like that costs if it ever became truly popular. Anyhow, I guess you mainly wanted comments about the single page apps, not about infrastructure. I return to the issue with deployment complexity. Often the single page app still need supporting "static" pages, except these pages are never quite static. They need common templates, perhaps a little dynamic section here, up-to-date information there and so it goes... Of course, you are always free to a totally different tool for these pages but what I like in Tapestry is that you can do it all with it. I'd love to know if there's another web framework that has built-in support for common design patterns and makes it possible to easily implement aspects like tapestry-security-jpa ( http://www.tynamo.org/tapestry-security-jpa+guide/). A lot in Tapestry is just for dealing with Java's rigidity and certainly in languages like Ruby or Javascript, you can always hack stuff together but too often, it quickly becomes a huge, messy hairball when there's less structure. Kalle So, I would be curious to learn from everyone in the community where > Tapestry still fits in the modern world. Is there a particular niche where > a component-based server-side framework like Tapestry still fits very well > ? Or does it need to focus on other usages to maybe work better w/ "modern" > approaches for developing web apps ? Where do people in the community use > Tapestry (and it works well) ? > > Cheers - Alex K >
Re: Where does Tapestry fit today
On 25.12.2015 22:22, Alex Kotchnev wrote: So, I would be curious to learn from everyone in the community where Tapestry still fits in the modern world. Is there a particular niche where a component-based server-side framework like Tapestry still fits very well ? Or does it need to focus on other usages to maybe work better w/ "modern" approaches for developing web apps ? Where do people in the community use Tapestry (and it works well) ? I have witnessed deployment of a critical business application done as HTML5 + Javascript app in such a way that the app offloaded the most of the database to the browser, and then all operations were done fully in the browser. When I asked why, they explained it was very easy to do it thheat way. What about security? Privacy? Reusability? Nah, not important. As another example, imagine the hypothetical situation that I am searching for a laptop to buy, and am looking to compare offers on 30 different websites. Even worse, imagine doing that on an average smartphone. If I have 30 tabs open, I expect to have 30 open html documents, waiting to be read. But, nowadays, each of these 30 websites tries to save some power and offloads some of their processing by handing it to me, via javascript. So, instead I end up with 30 open documents AND 30 Javascript applications, with full or partial data sets, just to be able to read those documents. Do I really need to be running those Javascript apps? No. Running them incurs bigger power usage on client side, so while the provider saves on power, my battery will die faster. Even worse, on agregator websites, there are many animated ads that are served via Javascript (or Flash, whatever), which means that I am running few additional Javascript applications per tab. Because of this, as a client, I praise more those companies that do not force me to run obscure or even libre code on MY computer, so that I am able to see the info on THEIR products. If they have a mode of viewing the products that is highly interactive, let's say 3D interaction with the products, it would be fine, I would opt-in. Otherwise, serve me a regular clean html doc. The question whether to program that way is not just technical, but sometimes also organizational issues should be considered, even ethical and moral issues. As a professor, I am teaching the students to analyse carefully the situation, to give focus on understanding and planning for the real user needs (and not programmers' wishes) and to delay the decision on the very technology to use, as late as possible, after they had the time to have few interaction prototypes, understood the users' environment and finally could make an informed decision on the software architecture. I had this very same discussion two weeks ago. The real question is - does the user NEED to run those javascript applications, and if he doesn't - what will you do, what type of architecture will be beneficial for the whole system. smime.p7s Description: S/MIME Cryptographic Signature
