In our dept., we're putting together JSF 2.0 applications to run on
the company intranet. They're written in Java 1.6 and hosted on a
Tomcat 6 web server on a linux box and they access data in Oracle
databases. They work fine and are proving reliable but JSF and
managing beans does seem to be something of a dark art.
The database is a given and I'd be reluctant to change either the base
language or web server that we use (but might be persuaded).
Given those restrictions, what are the most mainstream alternatives
that we might consider?
For sheer speed of development, I'm getting some great mileage out of twitter's bootstrap[1] on the client-side and James Strachan's scalate/jade[2] on the server.
As much as possible, I'll use restful json data sources to provide any dynamic content that populates the templates, and also handle any submitted data as json (instead of the traditional http form post technique).
You may also want to consider the play framework[3], it's a bit good!
> In our dept., we're putting together JSF 2.0 applications to run on > the company intranet. They're written in Java 1.6 and hosted on a > Tomcat 6 web server on a linux box and they access data in Oracle > databases. They work fine and are proving reliable but JSF and > managing beans does seem to be something of a dark art.
> The database is a given and I'd be reluctant to change either the base > language or web server that we use (but might be persuaded).
> Given those restrictions, what are the most mainstream alternatives > that we might consider?
Most of the issues I see clients have with JSF boil down to a few fundamentals: - ignorance of the JSF lifecycle (leads to all sorts of trial + error with attributes; performance issues (e.g. repeating controls are in forms)) - not understanding state saving (leads to memory problems) - a lack of class design in managed beans (backing bean is a dumping ground for all sorts of cross-cutting concerns; inappropriate scoping of data)
Of course, you could probably generalize this problem. Anyone who struggles writing a correct Servlet application isn't going to fare any better when you stick JSF on top of that stack. People's eyes tend to glaze over when I suggest referring to the specifications.
Most of the work I've been doing is migrating projects off server-side frameworks to static HTML + REST. The old web tiers have used SOAP to consume services, so this approach is relatively low-impact. If you want to evaluate this approach, look at Apache Wink.
On Fri, Feb 10, 2012 at 11:56 AM, Vince O'Sullivan <vjosulli...@gmail.com>wrote:
> In our dept., we're putting together JSF 2.0 applications to run on > the company intranet. They're written in Java 1.6 and hosted on a > Tomcat 6 web server on a linux box and they access data in Oracle > databases. They work fine and are proving reliable but JSF and > managing beans does seem to be something of a dark art.
> The database is a given and I'd be reluctant to change either the base > language or web server that we use (but might be persuaded).
> Given those restrictions, what are the most mainstream alternatives > that we might consider?
> -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en.
definitely consider Grails. Its the next step up without it being completely different. The Groovy language is very nice but not too intimidating, with the proviso you can drop into plain Java if you need to.
The Grails framework essentially gives you a convention-over-configuration application framework (based on Spring/Hibernate) excellent for creating corporate CRUD apps quickly.
R
On 10 February 2012 11:56, Vince O'Sullivan <vjosulli...@gmail.com> wrote:
> In our dept., we're putting together JSF 2.0 applications to run on > the company intranet. They're written in Java 1.6 and hosted on a > Tomcat 6 web server on a linux box and they access data in Oracle > databases. They work fine and are proving reliable but JSF and > managing beans does seem to be something of a dark art.
> The database is a given and I'd be reluctant to change either the base > language or web server that we use (but might be persuaded).
> Given those restrictions, what are the most mainstream alternatives > that we might consider?
> -- > You received this message because you are subscribed to the Google Groups "The Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
<kev.lee.wri...@gmail.com> wrote: > For sheer speed of development, I'm getting some great mileage out of > twitter's bootstrap[1] on the client-side and James Strachan's > scalate/jade[2] on the server.
+1 for Twitter Bootstrap, that I'm using for all my new websites, which have dynamic parts. In this case I use a custom made CMS based on Spring MVC. For more dynamic websites I'd try Wicket, which works very well with HTML templates.
> For sheer speed of development, I'm getting some great mileage out of > twitter's bootstrap[1] on the client-side and James Strachan's > scalate/jade[2] on the server.
> As much as possible, I'll use restful json data sources to provide any > dynamic content that populates the templates, and also handle any submitted > data as json (instead of the traditional http form post technique).
> You may also want to consider the play framework[3], it's a bit good!
> On 10 February 2012 11:56, Vince O'Sullivan <vjosulli...@gmail.com> wrote:
>> In our dept., we're putting together JSF 2.0 applications to run on >> the company intranet. They're written in Java 1.6 and hosted on a >> Tomcat 6 web server on a linux box and they access data in Oracle >> databases. They work fine and are proving reliable but JSF and >> managing beans does seem to be something of a dark art.
>> The database is a given and I'd be reluctant to change either the base >> language or web server that we use (but might be persuaded).
>> Given those restrictions, what are the most mainstream alternatives >> that we might consider?
>> -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en.
> Agree with this, today, I would use Play, Bootstrap and jQuery in a > heartbeat.
> You'll get up to speed in no time and after that, you can iterate to make > your site more customized.
> -- > Cédric
> On Fri, Feb 10, 2012 at 5:01 AM, Kevin Wright <kev.lee.wri...@gmail.com>wrote:
>> For sheer speed of development, I'm getting some great mileage out of >> twitter's bootstrap[1] on the client-side and James Strachan's >> scalate/jade[2] on the server.
>> As much as possible, I'll use restful json data sources to provide any >> dynamic content that populates the templates, and also handle any submitted >> data as json (instead of the traditional http form post technique).
>> You may also want to consider the play framework[3], it's a bit good!
>> On 10 February 2012 11:56, Vince O'Sullivan <vjosulli...@gmail.com>wrote:
>>> In our dept., we're putting together JSF 2.0 applications to run on >>> the company intranet. They're written in Java 1.6 and hosted on a >>> Tomcat 6 web server on a linux box and they access data in Oracle >>> databases. They work fine and are proving reliable but JSF and >>> managing beans does seem to be something of a dark art.
>>> The database is a given and I'd be reluctant to change either the base >>> language or web server that we use (but might be persuaded).
>>> Given those restrictions, what are the most mainstream alternatives >>> that we might consider?
>>> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" group. >> To post to this group, send email to javaposse@googlegroups.com. >> To unsubscribe from this group, send email to >> javaposse+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en.
I have to say, I got a bit disillusioned with Grails. It's kind of messy, and pretty slow. I like what it can do, and the syntax is an upgrade from plain Java, but it's just not that great once you end up with a more complex system than a couple of dozen model classes.
I've heard good things about Play with Scala, I think I'm gonna check that out next.
> definitely consider Grails. Its the next step up without it being > completely different. The Groovy language is very nice but not too > intimidating, with the proviso you can drop into plain Java if you > need to.
> The Grails framework essentially gives you a > convention-over-configuration application framework (based on > Spring/Hibernate) excellent for creating corporate CRUD apps quickly.
> R
> On 10 February 2012 11:56, Vince O'Sullivan <vjosulli...@gmail.com> wrote: >> In our dept., we're putting together JSF 2.0 applications to run on >> the company intranet. They're written in Java 1.6 and hosted on a >> Tomcat 6 web server on a linux box and they access data in Oracle >> databases. They work fine and are proving reliable but JSF and >> managing beans does seem to be something of a dark art.
>> The database is a given and I'd be reluctant to change either the base >> language or web server that we use (but might be persuaded).
>> Given those restrictions, what are the most mainstream alternatives >> that we might consider?
>> -- >> You received this message because you are subscribed to the Google Groups "The Java Posse" group. >> To post to this group, send email to javaposse@googlegroups.com. >> To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "The Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
Alex, I'll acknowledge that Grails is slow, but can you elaborate
about what makes it messy? Would your complex system with dozens of
model classes be more organized in a different framework? I'm not
arguing, I'm just curious.
On Feb 11, 9:32 pm, Alex Turner <alexrmtur...@gmail.com> wrote:
> I have to say, I got a bit disillusioned with Grails. It's kind of messy, and pretty slow. I like what it can do, and the syntax is an upgrade from plain Java, but it's just not that great once you end up with a more complex system than a couple of dozen model classes.
> I've heard good things about Play with Scala, I think I'm gonna check that out next.
> Alex
> On Feb 10, 2012, at 5:22 AM, Rakesh wrote:
> > definitely consider Grails. Its the next step up without it being
> > completely different. The Groovy language is very nice but not too
> > intimidating, with the proviso you can drop into plain Java if you
> > need to.
> > The Grails framework essentially gives you a
> > convention-over-configuration application framework (based on
> > Spring/Hibernate) excellent for creating corporate CRUD apps quickly.
> > R
> > On 10 February 2012 11:56, Vince O'Sullivan <vjosulli...@gmail.com> wrote:
> >> In our dept., we're putting together JSF 2.0 applications to run on
> >> the company intranet. They're written in Java 1.6 and hosted on a
> >> Tomcat 6 web server on a linux box and they access data in Oracle
> >> databases. They work fine and are proving reliable but JSF and
> >> managing beans does seem to be something of a dark art.
> >> The database is a given and I'd be reluctant to change either the base
> >> language or web server that we use (but might be persuaded).
> >> Given those restrictions, what are the most mainstream alternatives
> >> that we might consider?
> >> --
> >> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> >> To post to this group, send email to javaposse@googlegroups.com.
> >> To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
> >> For more options, visit this group athttp://groups.google.com/group/javaposse?hl=en.
> > --
> > You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> > To post to this group, send email to javaposse@googlegroups.com.
> > To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/javaposse?hl=en.
I'm working on a Grails project with 162 domains so far (20ish of them
are mostly empty subclassed shells, but the rest aren't). As I work
through it, I find myself wondering how I'd build this if I started
from scratch, either in Grails or something else, to have things be
'less messy'. I'm not sure it's really possible, to the extent I want
it to be, while still being able to hit any reasonable deadlines for
delivering business goals.
Much of the 'messiness' I see in this project are the same sorts of
things I've encountered on other large projects in Grails, PHP and
even in one case Rails (smaller, but it still got messy imo): devs on
the team change; devs changed their mind about an approach and didn't
go back to refactor earlier code; few or no tests in place; lack of
up to date documentation for devs or end-users. None of these are
encouraged by Grails, or indeed any other language/platform.
So yes, I'd also like to hear about the 'messiness' and how something
like Play would make a project not messy. I'll grant that starting
over from scratch will give the feeling of non-messiness to start
with, but much of the feelings of 'messy' from projects have far more
to do with developer discipline and understanding of their own tools
vs anything inherent in a particular platform.
On Feb 12, 2:33 am, Joe Sondow <joeson...@gmail.com> wrote:
> Alex, I'll acknowledge that Grails is slow, but can you elaborate
> about what makes it messy? Would your complex system with dozens of
> model classes be more organized in a different framework? I'm not
> arguing, I'm just curious.
> On Feb 11, 9:32 pm, Alex Turner <alexrmtur...@gmail.com> wrote:
> > I have to say, I got a bit disillusioned with Grails. It's kind of messy, and pretty slow. I like what it can do, and the syntax is an upgrade from plain Java, but it's just not that great once you end up with a more complex system than a couple of dozen model classes.
> > I've heard good things about Play with Scala, I think I'm gonna check that out next.
> > Alex
> > On Feb 10, 2012, at 5:22 AM, Rakesh wrote:
> > > definitely consider Grails. Its the next step up without it being
> > > completely different. The Groovy language is very nice but not too
> > > intimidating, with the proviso you can drop into plain Java if you
> > > need to.
> > > The Grails framework essentially gives you a
> > > convention-over-configuration application framework (based on
> > > Spring/Hibernate) excellent for creating corporate CRUD apps quickly.
> > > R
> > > On 10 February 2012 11:56, Vince O'Sullivan <vjosulli...@gmail.com> wrote:
> > >> In our dept., we're putting together JSF 2.0 applications to run on
> > >> the company intranet. They're written in Java 1.6 and hosted on a
> > >> Tomcat 6 web server on a linux box and they access data in Oracle
> > >> databases. They work fine and are proving reliable but JSF and
> > >> managing beans does seem to be something of a dark art.
> > >> The database is a given and I'd be reluctant to change either the base
> > >> language or web server that we use (but might be persuaded).
> > >> Given those restrictions, what are the most mainstream alternatives
> > >> that we might consider?
> > >> --
> > >> You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> > >> To post to this group, send email to javaposse@googlegroups.com.
> > >> To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
> > >> For more options, visit this group athttp://groups.google.com/group/javaposse?hl=en.
> > > --
> > > You received this message because you are subscribed to the Google Groups "The Java Posse" group.
> > > To post to this group, send email to javaposse@googlegroups.com.
> > > To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://groups.google.com/group/javaposse?hl=en.
as impressed as I am with Grails, I should point out that it really makes a difference if you are building a typical web app - 3 tier architecture with DAOs, Service Layer and pretty much CRUD.
If you don't want that, then Grails is not for you.
As much as I see its value, I have to point out that there is a learning curve to learning Groovy and the way Grails does things.
My app has a requirements where the war file is created ONCE and then pushed through the environments and eventually ending up in prod (with various test phases along the way).
This is not the preferred Grails way however and I spent many days circumventing the build system to get it to do what I want (and I still feel its a hack).
I really, really like Groovy. However, it will take time to get used to and use it appropriately. I still forget the sort of magic you can do (because its so non-obvious). Like with maps (reference key as if attribute) and Expando and MockFor and StubFor, etc...
So I guess what I'm saying is do your due diligence for suitability, then plan some time to learn it and make mistakes - don't push for it on the first business critical project that comes along because you think you can develop it quickly (because thats what you heard on a forum somewhere).
Maybe it's just my poor knowledge of Grails, but I couldn't find a way to create domain objects in different packages. Once I started needing domain objects for deserialized things like facebook data, sometimes with names that overlapped, it became kind of a nightmare. I also find the mixture of Groovy syntax and Java syntax a bit off-putting. You're never quite sure which syntax you need for a method declaration. Whilst a higher level of familiarity with language details might fix that, I think one of the main arguments for Grails is the shallow learning curve, so I think I'm probably not the only person who gets going very quickly, only to find things like this further down the road that become stumbling blocks. It's hard once you become accustomed to things just falling together in a framework to suddenly be struggling with something that seems so basic.
On the flip-side is the amazing speed at which you can prototype. The simplicity of the structure makes things go very fast for a smaller system. I love the way service objects work, and gsp is pretty darn good.
Once the system gets bigger, the cycle time from changing a file to seeing it updated on the site can get pretty gnarly. Grails seems to have an increasing propensity to bomb-out when a file changes the larger the system gets, and I find myself having to restart the container pretty frequently, which is painfully slow. Any speed in the beginning is lost with interest further down the line it seems.
I did find Groovy to be a great gateway drug into Scala, and with SBT and FSC, many of the problems with cycle time go away. Same goes for syntax. Scala syntax is cleaner than grails. I just haven't looked at Play yet, so I have no idea if it has the same rapid development capabilities that Grails does.
> Alex, I'll acknowledge that Grails is slow, but can you elaborate > about what makes it messy? Would your complex system with dozens of > model classes be more organized in a different framework? I'm not > arguing, I'm just curious.
> On Feb 11, 9:32 pm, Alex Turner <alexrmtur...@gmail.com> wrote: >> I have to say, I got a bit disillusioned with Grails. It's kind of messy, and pretty slow. I like what it can do, and the syntax is an upgrade from plain Java, but it's just not that great once you end up with a more complex system than a couple of dozen model classes.
>> I've heard good things about Play with Scala, I think I'm gonna check that out next.
>> Alex
>> On Feb 10, 2012, at 5:22 AM, Rakesh wrote:
>>> definitely consider Grails. Its the next step up without it being >>> completely different. The Groovy language is very nice but not too >>> intimidating, with the proviso you can drop into plain Java if you >>> need to.
>>> The Grails framework essentially gives you a >>> convention-over-configuration application framework (based on >>> Spring/Hibernate) excellent for creating corporate CRUD apps quickly.
>>> R
>>> On 10 February 2012 11:56, Vince O'Sullivan <vjosulli...@gmail.com> wrote: >>>> In our dept., we're putting together JSF 2.0 applications to run on >>>> the company intranet. They're written in Java 1.6 and hosted on a >>>> Tomcat 6 web server on a linux box and they access data in Oracle >>>> databases. They work fine and are proving reliable but JSF and >>>> managing beans does seem to be something of a dark art.
>>>> The database is a given and I'd be reluctant to change either the base >>>> language or web server that we use (but might be persuaded).
>>>> Given those restrictions, what are the most mainstream alternatives >>>> that we might consider?
>>>> -- >>>> You received this message because you are subscribed to the Google Groups "The Java Posse" group. >>>> To post to this group, send email to javaposse@googlegroups.com. >>>> To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com. >>>> For more options, visit this group athttp://groups.google.com/group/javaposse?hl=en.
>>> -- >>> You received this message because you are subscribed to the Google Groups "The Java Posse" group. >>> To post to this group, send email to javaposse@googlegroups.com. >>> To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com. >>> For more options, visit this group athttp://groups.google.com/group/javaposse?hl=en.
> -- > You received this message because you are subscribed to the Google Groups "The Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
> My app has a requirements where the war file is created ONCE and then > pushed through the environments and eventually ending up in prod (with > various test phases along the way).
> This is not the preferred Grails way however and I spent many days > circumventing the build system to get it to do what I want (and I > still feel its a hack).
Feel like sharing how you did it? This is a best practice at many organizations due to change controls.
> Agree with this, today, I would use Play, Bootstrap and jQuery in a > heartbeat.
> You'll get up to speed in no time and after that, you can iterate to make > your site more customized.
> -- > Cédric
> On Fri, Feb 10, 2012 at 5:01 AM, Kevin Wright <kev.lee.wri...@gmail.com> > wrote:
>> For sheer speed of development, I'm getting some great mileage out of >> twitter's bootstrap[1] on the client-side and James Strachan's >> scalate/jade[2] on the server.
>> As much as possible, I'll use restful json data sources to provide any >> dynamic content that populates the templates, and also handle any submitted >> data as json (instead of the traditional http form post technique).
>> You may also want to consider the play framework[3], it's a bit good!
>> On 10 February 2012 11:56, Vince O'Sullivan <vjosulli...@gmail.com> wrote:
>>> In our dept., we're putting together JSF 2.0 applications to run on >>> the company intranet. They're written in Java 1.6 and hosted on a >>> Tomcat 6 web server on a linux box and they access data in Oracle >>> databases. They work fine and are proving reliable but JSF and >>> managing beans does seem to be something of a dark art.
>>> The database is a given and I'd be reluctant to change either the base >>> language or web server that we use (but might be persuaded).
>>> Given those restrictions, what are the most mainstream alternatives >>> that we might consider?
>> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" group. >> To post to this group, send email to javaposse@googlegroups.com. >> To unsubscribe from this group, send email to >> javaposse+unsubscribe@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en.
> -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en.
-1 for Wicket.
We did a web framework bake-off and wicket lost for 2 reasons:
designer friendliness (lack thereof) and violation of the DRY
principle.
(see http://groups.google.com/group/javaposse/browse_thread/thread/5a133dc... )
We are now using Tapestry with Glassfish with both Java and Groovy
page classes
and it is working wonders!
On Feb 10, 9:33 am, Casper Bang <casper.b...@gmail.com> wrote:
On Thu, Feb 16, 2012 at 12:49 AM, Lenny P <lpri...@hope.nyc.ny.us> wrote: > -1 for Wicket. > We did a web framework bake-off and wicket lost for 2 reasons: > designer friendliness (lack thereof) and violation of the DRY > principle. > (see http://groups.google.com/group/javaposse/browse_thread/thread/5a133dc... > ) > We are now using Tapestry with Glassfish with both Java and Groovy > page classes > and it is working wonders!
> On Feb 10, 9:33 am, Casper Bang <casper.b...@gmail.com> wrote: >> +1 for Wicket. While still statefull, infinitely better than ivory tower JSF. Easy to create and reuse components and integrate with templates.
> -- > You received this message because you are subscribed to the Google Groups "The Java Posse" group. > To post to this group, send email to javaposse@googlegroups.com. > To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
On Thu, Feb 16, 2012 at 10:37 AM, phil swenson <phil.swen...@gmail.com> wrote: > does wicket still have troubles with restful URLs?
> On Thu, Feb 16, 2012 at 12:49 AM, Lenny P <lpri...@hope.nyc.ny.us> wrote: >> -1 for Wicket. >> We did a web framework bake-off and wicket lost for 2 reasons: >> designer friendliness (lack thereof) and violation of the DRY >> principle. >> (see http://groups.google.com/group/javaposse/browse_thread/thread/5a133dc... >> ) >> We are now using Tapestry with Glassfish with both Java and Groovy >> page classes >> and it is working wonders!
>> On Feb 10, 9:33 am, Casper Bang <casper.b...@gmail.com> wrote: >>> +1 for Wicket. While still statefull, infinitely better than ivory tower JSF. Easy to create and reuse components and integrate with templates.
>> -- >> You received this message because you are subscribed to the Google Groups "The Java Posse" group. >> To post to this group, send email to javaposse@googlegroups.com. >> To unsubscribe from this group, send email to javaposse+unsubscribe@googlegroups.com. >> For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
> Interesting. Lift would be even worse than JSF, and Play not much better.
I'm curious what makes Lift so bad. Having templates that are 100% html is something that still looks highly enticing to me. The css based replacement mechanism looks very strong. (I have only done a few toy projects in lift, but to say there are more than a few features from it I always wish I had would be an understatement.)
Or are you just referring to how stateful it is? I'm still not convinced that is a poor choice. I was under the impression JSF was bad because of the odd lifecycle of everything.
All of these frameworks have to be measured on several criteria:
- availability of support - strength of community - designer-friendliness of templates - maturity - stagnation - flexibility - performance - scalability - robustness - statefulness - programming language support - internationalisation - separation of concerns - verbosity/tendency towards boilerplate - presence of built-in patterns that fit your domain - interaction with client-side frameworks/technology - interaction with other server-side frameworks in your stack - is it a complete self-contained solution? - etc.
Every single framework listed there is simultaneously both "best" and "worst". It all depends on context!
is it suited for REST? for a client-facing app?
On 17 February 2012 14:39, Fabrizio Giudici <Fabrizio.Giud...@tidalwave.it>wrote:
<kev.lee.wri...@gmail.com> wrote: > "worse" on what dimension?
Don't ask me, of course, ask the presentation author :-) I see a diagram where frameworks are ordered by a certain score, which if I understand well is created by summing intermediate values. It's not clear to me who gave those values.
