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 <kalle.o.korho...@gmail.com>
wrote:

> On Fri, Dec 25, 2015 at 1:22 PM, Alex Kotchnev <akoch...@gmail.com> 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
> >
>

Reply via email to