Struts, Spring, Tapestry, oh my!

Erich Pletsch erich at uvnet.net
Thu Aug 11 13:14:57 MDT 2005


   Jonathan:
   I hope that you can forgive my bizzarly de-paragraphed text in the
   last email.  Thunderbird seems to have mangled the email formatting on
   that last one.
   I guess the real issue at hand centers around which programming
   language and framework is the best for creating a webapp.  And the
   truth of the matter is that it depends on the application that you are
   creating.  Just about every programming language is really good at
   something and others are good at other things.
   You wouldn't use a swiss army knife to open a can of beans if you had
   an electric can opener handy would you?
   Nor would you write a script of shell commands in Java - you'd use
   your favorite shell or Perl for that.
   But the point that I would like to make is that Java is more of a
   viable web programming language now that it ever has been before.
   Lots of good people are working hard to make the Java and its many
   frameworks simpler and easier to use while also adding functionality
   to them.
   I happen to like the JSF frame work a lot.  At my company, we have
   several applications that perform very different functions for us and
   for our customers and the best way to tie everything together happily
   is with Java.  We've used several languages and several frameworks in
   the past.  I have a few developers working for me and I've seen a HUGE
   productivity increases from them since we switched from Struts to
   JSF.  However, I would not use JSF or Struts to write a very simple
   webapp.  I'd probably use PHP, Python, or Ruby on Rails for that.
   Jonathan Ellis wrote:

On Thu, 11 Aug 2005 09:51:27 -0600, "Erich Pletsch" [1]<erich at uvnet.net>
said:


   What's your idea of simple?


This is about all I could make out in your bizzarly de-paragraphed
text.  But I think it's your main point, so I'll run with it.

"My idea of simple" boils down to the unix philosophy of "small is
beautiful."

Some elaboration:

* Don't repeat yourself
  - if you can't introspect my database at runtime you
    are wasting my time; this is 2005
  - almost anything involving XML in the J2EE world fails this, not just
  ORM


   Database introspection is great and you're right J2EE doesn't address
   that very well.  You have to do JDBC calls to do that type of
   introspection.  But, non introspected database access is faster in
   Java than introspected access.  And, for most large applications you
   don't really need to introspect the database.  Hibernate has great
   tools for database introspection when you're programming.

* Code that does one thing shouldn't be spread across multiple files
  - e.g., JSP custom tags -- minimum 2 files to add a tag IIANM


   That depends.  Your example of custom tags is a good case and point.
   If you want a standard way of describing and validating tag libraries
   (which is what the tld does) then in does make sense to split them
   into 2 files.

* "My IDE handles it" is not a substitute for good design
  - because eventually you WILL run into a bug that requires
    understanding what is going on under the covers
  - the ide itself is a learning curve


   You are absolutely right.  And, as I mentioned before, anyone who
   embarks on JSF should understand the back end.
   However, the point of an IDE is to make life easier on the
   programmer.  So, if it creates the monotonous code for you (i.e.
   getters and setters in java beans, and backing beans for JSF apps)
   then all it's doing is speeding up the process of development for
   you.  You still have to understand what a backing bean is and what it
   does for any of that to be of any value, but you don't have to write
   the same code over and over again.

* the easy case should be easy
  - related: common cases should be easy
  - does avoiding the word "simple" help here?
  - easy: one line of code.  two tops.

To illustrate this last, consider calling a method on an object
by reflection.  Assume that "instance" is your object reference,
and "method" is a variable containing the method name.

Python--
    instance.getattr(method)(5, 'six')

Java--
import java.lang.reflect.*;
// ...
    // Object instance, String method
    Class c = instance.getClass();
    Method m = c.getMethod(method, new Class[] {Integer, String});
    m.invoke(instance, new Object[] {new Integer(5), "six"});


   I'll grant you that reflection in Java is not as simple as reflection
   in Python.  That's one thing that Python is great at.  However, I
   wouldn't use Python just because it's simpler to code reflection in.

Back to the flames:



 So far you've bashed Java and the J2EE
   architecture as overly complex, but I haven't seen you suggest a
   viable, enterprise class alternative.


I've already suggested Spyce, but I think that was in response to
the original poster back when this was actually on topic so you may
have missed it.


   I did.  Sorry about that.

If we avoid the trap of equating "enterprise class" with J2EE, then
yes, Spyce is enterprise-class.  I'm sure I could design a site to
serve a million db-backed pages per day from a single server (http +
db) in Spyce, because I've already built one in another interpreted
language (TCL) that is somewhat more feeble (and marginally slower)
than Python.  Is that enterprise-class enough?

(For comparison purposes, slashdot serves about 3M/day, but they have
multiple servers IIANVM.  My site was also very update-intensive,
unusually so for web applications; it's quite possible I could serve 3M
or more from the existing server if the database load were more
typical.)

Rails would also qualify as "simple" in my book.  I just happen to like
Python more than Ruby.

-Jonathan


   I guess my definition of enterprise class is that it has a robust
   feature set and can scale very well.  Want more detail - I go along
   with Bryan Sant's definition.
   Honestly, I don't know how Spyce compares here.  I don't have anything
   positive or negative to say about Spyce because I'm completely
   ignorant of its strengths and weaknesses.  However, I know my
   developers like Python, so it's probably great for a lot of things.

.-----------------------------------.
| This has been a P.L.U.G. mailing. |
|      Don't Fear the Penguin.      |
|  IRC: #utah at irc.freenode.net   |
`-----------------------------------'

References

   1. mailto:erich at uvnet.net



More information about the PLUG mailing list