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 >
