Re: Mini-rant on Java REST (JAX-RS), JSON, XML, JAXB etc...

My next big Java-space web app development effort is going to be
shifting away from JSF. I've been using the framework for 8 or 9 years,
and I'm unhappy with it.

My current JSF routine is - once I know what the page flow is, the model
and viewmodels are thought through, wireframes or the equivalent are
worked up etc - commences by using my Scala DSL to generate appropriate
XHTML page and Java managed bean skeletons, which removes over 75% of
the boilerplate effort. I use a Mojarra JSF (latest version) and
Primefaces (latest version) combination to implement.

I still find it very tedious. In comparison to JPA, where 2.x really is
a major capability step up from 1.x, I found that JSF 2.x gave me a
small number of minor new handy capabilities, but largely formalized all
the workarounds and custom code that I'd had available since as early as
2007 or so for JSF 1.1, and later for JSF 1.2. For example, from 2008
through 2011 I did a lot of JSF 1.x projects using an
enhanced/customized JSF library (since the ability to extend JSF has
always been there) that foresaw the majority of 2.x features. I didn't
even switch over to 2.0 on real jobs until maybe a year after it came
out, except for experimenting with it, mainly because there was no real
need. This custom version, that I also enhanced myself, even did proper
paginated AJAX'd datatables.

I use 2.1 now, like I say Mojarra + PrimeFaces (I've tried ICEFaces,
RichFaces etc etc, but now prefer PrimeFaces), but when all is said and
done it takes as much time to develop - page for page, removing the
effect of me using my DSL - for 2.1 as it did for 1.1. Nothing I can
think of really takes less time and less effort with JSF 2.x than it did
with 1.x. Inline row editing is an example: anyone who wanted to do this
with 1.x worked out a solution early on, and had it in their toolbox.
That the capability is now provided out of the box by many frameworks
like Primefaces doesn't remove the fact that I could set up inline row
editing in 1.x just as quickly.

Sure, all of this is great for new JSF developers - but it's not
compelling progress for me.

I'm actually not even happy anymore with frameworks that separate the
whole business out into pages + code (e.g. JSF XHTML + managed bean
Java, or ASP.NET MVC aspx + C# codebehind, say). I've never worked in -
or heard of, or encountered - an environment where one team worked on
pages and another on backing code. It's usually the same developers that
do both. It's more productive that way. So why 2 different artifacts -
essentially a page template + the controller/presentation model code -
to accomplish one thing: a generated page?

While I'm not arguing for the return of classic ASP or classic JSP or a
general migration over to PHP for everyone (I seriously dislike PHP),
I'm not dogmatically opposed to a single artifact per generated page. As
far as I am concerned, by abstracting away as much as we have from a
servlet producing HTML directly, or CGI scripts or executables doing the
same thing, we've abstracted away too far. Look at all the problems on
StackOverflow etc that people are still wrestling with to do basic stuff
with JSF 2.x. I suppose if you just started with web frameworks last
year then you don't know any better, but I am not convinced we're better
off in 2013 than we were in 2003 or close to 20 years ago, actually, not
when discussing server-side technology.

Part of my thinking is inspired by the Scala DSL I wrote to not
continually waste my time with JSF boilerplate. It's not a big
conceptual step from that to a complete DSL that when executed *is* your
web app. It's not hard to do; a number of languages already support XML
in code, so your generators use that capability.

Not since Day One have my basic requirements in web pages changed. CRUD
and datatable capability is 90+ percent of it, always has been, always
will be. I'd be hard-pressed to think of a single page out of hundreds
I've written that isn't basically CRUD. 100 percent of the time when I
work with a JSF XHTML page or an ASP.NET MVC page, all that HTML is
standardized adornment - it could *always* be generated. Basically, why
don't I declare (in code) what my pages should do, and do it just once?
And a Page object knowing how to present itself - isn't that core OO?

I can do all of my tweaking with CSS and JavaScript, as required.
Usually just CSS, because most of the JS in my vision would be generated
too.

We call this codebehind/backing bean coding + XHTML page writing a
"separation of concerns". Well, no, it's not. Not when we routinely
embed JSF XHTML or ASP.NET MVC ASPX pages with code to the extent that
we may as well be doing scriptlets. The code we embed may simply be
viewmodel references and action references, but it's still embedded
code. To me all of this is simply extra effort for no real gain.

As you might guess I am pretty interested in HTML5 also. :-) Ideally
that would be the generated product. My gut feeling is that JSF
evolution will not be able to keep up with the real impact of HTML5
anyway, another reason to move away.