Pylons vs Tomcat+GWT

[Tycon]

I heard that many "enterprise" web applications use tomcat (and Google
Web Toolkit to create the client side javascript code).
What are the advantages of using a framework like Pylons (or Django,
Rails, etc) compared to using Java framworks ?
Why can't the Java framwork be used for non-enterpise web site apps ?

Java has a performance advantage over Python (and Ruby), but I guess
the down side is that it's not as "agile" for rapid development ?

[MilesTogoe]

definitely not as agile as Rails or even Django. likewise some of us
prefer to program in Python or Ruby than in java or javascript. I think
it's easier to deploy Rails, Django, Pylons with simple Apache and wsgi
or passenger than have to delve into tomcat. and JQuery handles the
javascript stuff well. my $.02

[Jonathan Vanasco]

Java can take 10-20x longer to develop and manage than php / perl /
python / etc. When you factor in rapid/agile frameworks like Pylons,
Rails, Django, Catyalyst, Cake, etc the differences are even larger.

You /can/ do whatever you want in Java; fun projects, startups, small
businesses typically don't use it, because its too damn human-
resources intensive.

[Tycon]

Is there a Rails-like framework for Java ?

[chris mollis]

'grails'?

[Jan Gurda]

In my opinion Grails is new technology and isn't checked well. Of course I can be wrong. I am programming with Java. I use Hibernate, Spring and Facelets and to put it to work it takes a lot of time and a lot of xml written.

2009/1/30 chris mollis <chris....@gmail.com>

[Philip Jenvey]

On Jan 30, 2009, at 11:21 AM, Tycon wrote:

>
> Is there a Rails-like framework for Java ?
>

The Java Wicket framework is intended to provide rapid web development
ala Rails, that might be the closest thing.

If you just want to run on the JVM and are willing to take a
performance hit from regular Java, you could use Rails via JRuby, or
Grails via Groovy or even Django or Pylons via Jython (Pylons 0.9.7
has initial support for Jython 2.5). JRuby is slower than regular
Java, but at this point is probably better for most things
(particularly long running server side apps) than normal Ruby 1.8 (MRI).

There's also Scala's Lift web framework. Scala should perform close to
normal Java.

Granted I'm talking about the performance of these language runtimes
compared to Java -- the performance of the frameworks themselves may
matter as well.

--
Philip Jenvey

[Michael Bayer]

I worked briefly with a project that used GWT (we of course ultimately
rewrote the whole thing in pylons) for some portions of a web based
administration tool. The components were incredibly simple table
controls displaying database data. There were two dozen GWT-derived
source files used to generate about four different data views that all
looked nearly alike, multiple compilers and two separate build.xml
files existed to compile the full application (gwt has its own
compiler separate from javac), and there were skeletons, stubs and all
kinds of translation/glue code all over the place. On the view side
there was nothing about these components that you wouldn't have seen
from a perl CGI script 10 years ago - they were just flat tables of
data, no interactivity beyond "previous page/next page". The usage
of GWT was obviously selected out of a vague sense of "doing things
the 'right' way" without the benefit of actual experience in doing
things at all.

These small table controls took more than a full second to render just
20 or 30 rows of data, and I assumed that the underlying SQL and
database was the reason.

Not so at all. Removing the usage of GWT and replacing with a simple
ajax call to a struts action which rendered inline HTML directly from
a jsp page, with all other factors remaining in place including the
same database code and database (remember we're still in java), the
components rendered about 50 times faster. The size of the code base
shrunk by about 24 source files, one less build.xml file, and several
hundred class files (their build process was multiplying the full set
of GWT classes in multiple locations for some reason, which I suspect
was not a GWT-specific issue).

To see why a straight ajax call to a JSP page to a struts action to
some hibernate code might be 50x faster than a GWT interface to a GWT-
enabled servlet to the same hibernate code, the next time you build a
small GWT application, use firebug to look at the XMLHttpRequest calls
being sent over the wire. The messages are more bloated than
Google's stock price two years ago and more inscrutable than Peter
Norvig's PHD dissertation.

Remember, the "enterprise" way of thinking is what's brought us the
economic disaster, vast ponzi schemes where everyone looks the other
way, etc. I.e. "seems to work for now so fuck it".

[chris mollis]

;).. pretty good... . not atypical, I'm afraid.  Nothing wrong with Java, per se.. but Sun tried to make it an 'industry' (and I suppose in some sense it is), but when you're trying to build an 'industry', you have to let a lot of people in who maybe shouldn't be there (like IBM, and Oracle).. and their job is to make things really complicated so people will continue to pay them for ever more useless shit, year after year.  

[Mario Ruggier]

Thanks. I have probably been lucky to not have had the opportunity of
having GWT inflicted on any of my projects, but your appreciation of
GWT resonates very true -- and with many projects java... the problem
probably is that google was constrained to hire too quickly, so after
having creamed the python pool they had to succumb to hiring too many
java developers ;-!! Anyway, I've always been very wary of any
platform where its proponents tend to describe things via tool-based
procedures e.g. select menu x in eclipse, then click y (hence my
reference to over in another thread to keep those eclipsed guys out of
pylons if you want pylons to retain its design integrity).

But GWT is RIA territory, and so not specifically pylons territory. It
should be compared to what best RIA options would be for use with
pylons? Or, maybe even more specifically, how would other "client code
generator" types of toolkits compare -- two that come to mind are
pyjamas (from python) and cappuccino (from objective-c) ?

[jerry]

"""
the "enterprise" way of thinking is what's brought us the economic
disaster, vast ponzi schemes where everyone looks the other way,
etc. I.e. "seems to work for now so fuck it".
"""

Bravo, Bravo, and BRAVO!

This is so brilliant that it got to go in the "Zen of Pylons".

Jerry

[Dalius Dobravolskas]

Michael Bayer wrote:
> (we of course ultimately rewrote the whole thing in pylons)

This.

> same database code and database (remember we're still in java), the
> components rendered about 50 times faster.

And this. What have you gained from Pylons? Development speed or
performance as well?

Regards,
Dalius

[Tycon]

I'm planning on using GWT only for client side code and doing all
server calls
using JSON, and not using GWT's RPC mechanism. So I guess that would
avoid the problem you are talking about ?

Correct me if I'm wrong, but neither Perl/CGI not Pylons/Rails etc
CANNOT
be used to create a gmail-like application, unless you resort to hand
writing
the entire UI (which runs wholly on the client) in javascript (good
luck with
that !).

GWT is a proven technology used by many sites and application (while
pyjamas
is a poorly supported lacking small time project). Basically most of
google apps
were written using GWT-like technology, and IMO google apps are the
best example
of smart efficient next generation web apps.

[MilesTogoe]

Tycon wrote:
> I'm planning on using GWT only for client side code and doing all
> server calls
> using JSON, and not using GWT's RPC mechanism. So I guess that would
> avoid the problem you are talking about ?
>
> Correct me if I'm wrong, but neither Perl/CGI not Pylons/Rails etc
> CANNOT
> be used to create a gmail-like application, unless you resort to hand
> writing
> the entire UI (which runs wholly on the client) in javascript (good
> luck with
> that !).
>

you are way off here - it is quite doable to create a nice GUI with
Rails (or Pylons or Werkzeug or ...) and use Prototype or add in some
jQuery (or your js framework of choice) for fast client side actions.
Just look at some of the 37 Signals apps - but if you want to use GWT
that's fine, your choice.

[Tycon]

The point of GWT is that you can use java for the client side code,
with most
of its core libraries, and you get better optimized javascript, and
much better
development environment and tools (IDE, debugger).
This is superior compared to using any javascript framework, none of
which offers
the comprehensive high level libraries that java provides.

[Noah Gift]

On Sun, Feb 1, 2009 at 8:55 AM, jerry <jerry...@gmail.com> wrote:
>
> """
> the "enterprise" way of thinking is what's brought us the economic
> disaster, vast ponzi schemes where everyone looks the other way,
> etc. I.e. "seems to work for now so fuck it".
> """
>
> Bravo, Bravo, and BRAVO!
>
> This is so brilliant that it got to go in the "Zen of Pylons".

I agree. Fraud isn't just endemic in Wall Street, it also exists in
Software Engineering, and especially in "buzz" technologies. One of
the dead give aways, is when someone says, "Trust me, I am smarter
than you, and you just don't understand..", that is a huge red flag
for any new technology.

--
Cheers,

Noah

[Alberto Valverde]

Tycon wrote:
> The point of GWT is that you can use java for the client side code,
> with most
> of its core libraries, and you get better optimized javascript, and
> much better
> development environment and tools (IDE, debugger).
> This is superior compared to using any javascript framework, none of
> which offers
> the comprehensive high level libraries that java provides.

Why write Javascript in Java when you can do it in Ruby? Make sure you
check out HotRuby: http://hotruby.yukoba.jp/

Alberto

[Tycon]

because it's not ready so it's just a toy at this point, just like
pyjamas, while GWT is used by real production websites (ever heard of
gmail)

[Jorge Vargas]

On Sat, Jan 31, 2009 at 11:00 PM, Tycon <adi...@gmail.com> wrote:
>
> because it's not ready so it's just a toy at this point, just like
> pyjamas, while GWT is used by real production websites (ever heard of
> gmail)

Actually all I have heard is the opposite. In fact one of GWT's
biggest "but" is that none of serious google products use it. In fact
I'm almost certain gmail doesn't simply because gmail is older than
the gwt project.

[Michael Bayer]

On Jan 31, 2009, at 4:28 PM, Tycon wrote:

>
> I'm planning on using GWT only for client side code and doing all
> server calls
> using JSON, and not using GWT's RPC mechanism. So I guess that would
> avoid the problem you are talking about ?

or you could just use jquery...ive no idea how you'd use only the
"client side" portion of GWT. from what I could tell it seemed like
the entire server-to-client is spit out from a single monolithic
compilation and there was certainly no easy way to just use "the
client".

> Correct me if I'm wrong, but neither Perl/CGI not Pylons/Rails etc
> CANNOT
> be used to create a gmail-like application, unless you resort to hand
> writing
> the entire UI (which runs wholly on the client) in javascript (good
> luck with
> that !).

i think there are alternatives which would result in easier to read
code. jquery can go a very long way.

> were written using GWT-like technology, and IMO google apps are the
> best example
> of smart efficient next generation web apps.

theyre tremendously complex and reliant upon special build tools.
facebook AFAIK is just php and is a more compelling client side
experience than anything I've seen google do.

[Michael Bayer]

On Jan 31, 2009, at 6:21 PM, Tycon wrote:

>
> The point of GWT is that you can use java for the client side code,

why is that important ? are you one of these "oh the JVM ! we NEED
the JVM ! " types ?

>
> with most
> of its core libraries, and you get better optimized javascript, and

how come I was able to replace a simple table control that took 2
seconds to render with GWT with a simple one that took about .1 ?

>
> much better
> development environment and tools (IDE, debugger).

every development platform has IDEs and debuggers.

>
> This is superior compared to using any javascript framework, none of
> which offers
> the comprehensive high level libraries that java provides.

wow...good luck. sounds like you've never used java before.

[Colin Flanagan]

I don't follow this logic. If the "enterprise" model, software development or otherwise (and does GWT really fit into that?), brought on the current economic disaster, what safeguards would the alternative (I guess in this instance, Pylons) have provided?

The notion of "enterprise" java is an increasingly difficult word to define, almost as hard as the term "art." Nevertheless, the very specific practices of financial institutions and their relation to regulatory bodies seems like a difficult simile to stylistic approaches to software development.

[Colin Flanagan]

If you are serious about perusing this path, please consider Seam/RichFaces before doing so.

----- Original Message ----
From: Tycon <adi...@gmail.com>
To: pylons-discuss <pylons-...@googlegroups.com>
Sent: Saturday, January 31, 2009 6:21:28 PM
Subject: Re: Pylons vs Tomcat+GWT

[Tycon]

I'm not talking about facebook/youtube type sites, I'm talking about a
real web application
where users access information, enter information, search and analyze
information, and visualize information.
I'm not creating web sites for popularity contests, but using the web
as a platform for real
software applications that provide an actual (business) service. For
that it's much better to use
more client side (e.g. javascript) code to make it seem like a real
desktop app.
If you just want to create some flicker slideshow derivative, then yes
you can use php or whatever other
server side "application" code.

[Mark Hildreth]

My vote has to go to ThunderCats: Jaga on the backend with Cheetara
for templating.

[Wyatt Baldwin]

On Jan 31, 9:19 pm, Tycon <adie...@gmail.com> wrote:
> I'm not talking about facebook/youtube type sites, I'm talking about a
> real web application
> where users access information,  enter information, search and analyze
> information, and visualize information.

MySpace does all this stuff. Why don't you use their platform?

[Alberto Valverde]

Tycon wrote:
> because it's not ready so it's just a toy at this point, just like
> pyjamas, while GWT is used by real production websites (ever heard of
> gmail)
>

Oh, sorry, I forgot you were looking for something serious. The you
should definitely consider this:

http://brainfuck.progopedia.org/

I've heard from very credible sources that it is what is powering the
next generation of Coogl products about to hit the market.

Alberto

[Ben Bangert]

On Jan 31, 2009, at 9:19 PM, Tycon wrote:

> I'm not talking about facebook/youtube type sites, I'm talking about a
> real web application
> where users access information, enter information, search and analyze
> information, and visualize information.
> I'm not creating web sites for popularity contests, but using the web
> as a platform for real
> software applications that provide an actual (business) service. For
> that it's much better to use
> more client side (e.g. javascript) code to make it seem like a real
> desktop app.
> If you just want to create some flicker slideshow derivative, then yes
> you can use php or whatever other
> server side "application" code.

Is gmail a real web application? As others have mentioned, Google
isn't using GWT for gmail, in fact, according to this article Google
is NOT using GWT for *any* of its online AJAX applications:
http://ajax.phpmagazine.net/2007/03/why_can_google_not_eat_its_dog.html

The article is a bit old, so maybe they've started using it now, who
knows, the fact is that they clearly were able to build a real web
application with ZERO GWT. If you're trying to make website for real
software apps, maybe you should consider why Google isn't using GWT
itself?

Cheers,
Ben

[Michael Bayer]

On Jan 31, 2009, at 11:34 PM, Colin Flanagan wrote:

>
> I don't follow this logic. If the "enterprise" model, software
> development or otherwise (and does GWT really fit into that?),
> brought on the current economic disaster, what safeguards would the
> alternative (I guess in this instance, Pylons) have provided?
>
> The notion of "enterprise" java is an increasingly difficult word
> to define, almost as hard as the term "art." Nevertheless, the very
> specific practices of financial institutions and their relation to
> regulatory bodies seems like a difficult simile to stylistic
> approaches to software development.

yeah I don't make a great analogy pre-coffee. I was mostly
thinking of indifference to wrongness cemented by institutions. It
was widely suspected that Madoff was running a ponzi scheme. But
everyone looked the other way, since people were making money - it
would go against the institution to say something. Similarly, GWT
produces really bloated and complex applications which all look really
boring. But the framework was produced by the highest echcelons of
"the institution", and that alone is the only answer needed to the
question of what to use. GWT is not even a great example, better
examples would be Interwoven Teamsite, VBScript and Cold Fusion,
selected due to their corporate roots - the notion that corporate-
driven products are the better selection strictly due to their
corporate roots.

[Michael Bayer]

On Feb 1, 2009, at 12:19 AM, Tycon wrote:

>
> I'm not talking about facebook/youtube type sites, I'm talking about a
> real web application
> where users access information, enter information, search and analyze
> information, and visualize information.

which one of those is not supplied by facebook ?

[Tycon]

sure but without client side code, it will have to reload a new page
in response for each user interaction
Rich Internet Applications rely on client side code to be as powerful
as desktop app, and GWT facilitates
that in a more comprehensive way than the simple javascript code
snippets, or javascript libraries

[Raoul Snyman]

On Mon, Feb 2, 2009 at 2:28 PM, Tycon <adi...@gmail.com> wrote:
> sure but without client side code, it will have to reload a new page
> in response for each user interaction

Says who?

--
Raoul Snyman
B.Tech Information Technology (Software Engineering)
E-Mail: raoul....@gmail.com
Web: http://www.saturnlaboratories.co.za/
Blog: http://blog.saturnlaboratories.co.za/
Mobile: 082 550 3754
Registered Linux User #333298 (http://counter.li.org)

[Jose Galvez]

Tycon wrote:

sure but without client side code, it will have to reload a new page
in response for each user interaction
Rich Internet Applications rely on client side code to be as powerful
as desktop app, and GWT facilitates
that in a more comprehensive way than the simple javascript code
snippets, or javascript libraries
  

Did I miss something, but doesn't the GWT simply end up writing the appropriate html pages for you with the embeded javascript?  If thats correct, which I think it is (although I may be over simplifying things) how is this more comprehensive then any of the other javascript libraries out there?  Isn't the GWT just a different way of putting the code together?

[Wyatt Baldwin]

On Feb 2, 9:51 am, Jose Galvez <jj.gal...@gmail.com> wrote:
> Tycon wrote:
> > sure but without client side code, it will have to reload a new page
> > in response for each user interaction
> > Rich Internet Applications rely on client side code to be as powerful
> > as desktop app, and GWT facilitates
> > that in a more comprehensive way than the simple javascript code
> > snippets, or javascript libraries
>
> Did I miss something, but doesn't the GWT simply end up writing the
> appropriate html pages for you with the embeded javascript?  If thats
> correct, which I think it is (although I may be over simplifying things)

It's that and another layer to wade through while debugging.
Especially fun if you're not sure if the bug is in your code or the
generated code.

[Jose Galvez]

On Mon, Feb 2, 2009 at 11:01 AM, Wyatt Baldwin <wyatt.le...@gmail.com> wrote:

On Feb 2, 9:51 am, Jose Galvez <jj.gal...@gmail.com> wrote:
> Tycon wrote:
> > sure but without client side code, it will have to reload a new page
> > in response for each user interaction
> > Rich Internet Applications rely on client side code to be as powerful
> > as desktop app, and GWT facilitates
> > that in a more comprehensive way than the simple javascript code
> > snippets, or javascript libraries
>
> Did I miss something, but doesn't the GWT simply end up writing the
> appropriate html pages for you with the embeded javascript?  If thats
> correct, which I think it is (although I may be over simplifying things)

It's that and another layer to wade through while debugging.
Especially fun if you're not sure if the bug is in your code or the
generated code.

Wow, sounds too complicated, I think I'll stick with hacking JS for the moment

[Mark T.]

You do seem pretty intent on using GWT, no matter what advice is
offered in this thread. It sounds as if you were looking more for
confirmation of a decision already made.

However, if you are still open to alternatives, I would suggest that
you give a strong look at Yahoo's UI library (http://
developer.yahoo.com/yui/), which includes a lot of rich components,
not just JavaScript language shortcuts or smaller building blocks
(which it also includes). I have personally used YUI a lot and I feel
that it is a mature, well designed library.

Here's an example of a "real software application," not just a picture
slideshow:

http://developer.yahoo.com/yui/examples/layout/adv_layout_source.html

You will need to code your server-side logic separately, but if
anything goes wrong, performance is bad, or you need to extend the
functionality, you will be dealing with code that you have written,
not a mess of auto-generated, opaque gibberish.

On Jan 31, 9:19 pm, Tycon <adie...@gmail.com> wrote:

[Colin Flanagan]

Hopefully we can end this discussion soon, but it may be worth noting that GWT was first concieved in an era where javascript libraries hadn't yet evolved to what they are today (especially with regard to jquery) and backend developers, especially Java ones, were extremely gun-shy at delving into the world of client-side scripting languages.

A few months back, a similar discussion came up on this list about Pyamas and someone posted a link to John Resig's thoughts on javascript code generation. I can't find it off-hand , but his perspective definately resonated with me.

Does anyone have that link?

[Colin Flanagan]

[Dalius Dobravolskas]

On Tue, Feb 3, 2009 at 3:12 AM, Colin Flanagan <quadv...@yahoo.com> wrote:

Does anyone have that link?

Looks like this one: http://ejohn.org/blog/javascript-language-abstractions/

I must note that it is worth to read almost everything what is written by John Resig.

--
Dalius
http://blog.sandbox.lt

[Tycon]

AnonymousGuy wrote:
"......You do seem pretty intent on using GWT, no matter what advice
is
offered in this thread......."

I listen to advice from many different sources, and the advice in this
thread ranks pretty low
in its usefulness compared to the whole range of opinions that exist.

Javascript libraries suck because the developer still needs to use the
retarded "java-crypt" language
which would be excutiating to develop any real application logic with.
Productivity, development tools,
debugging, componentization, reusability, rich libraries, high level
algorithms and data structures, type
safety, compile time optimizations are all huge advantages of Java
compared to "java-scrap-it" ;-)

http://www.ryandoherty.net/2007/04/29/why-google-web-toolkit-rots-your-brain/


On Feb 2, 11:50 pm, Dalius Dobravolskas
<dalius.dobravols...@gmail.com> wrote:

[Dalius Dobravolskas]

On Tue, Feb 3, 2009 at 11:06 AM, Tycon <adi...@gmail.com> wrote:

Javascript libraries suck because the developer still needs to use the
retarded "java-crypt" language
which would be excutiating to develop any real application logic with.
Productivity, development tools,
debugging, componentization, reusability, rich libraries, high level
algorithms and data structures, type
safety, compile time optimizations are all huge advantages of Java
compared to "java-scrap-it"  ;-)

 

You are expecting from java-script something what it was not intended for. It is moving to that direction now (FireBug, jQuery with big selection of plug-ins, MochiKit or other libraries, java-script unit-testing libraries). Compile Time Optimizations - haven't you heard anything about V8 or TraceMonkey? That's not exactly CTO but that's what you want... componetization - haven't you seen XUL and are you not using FireFox add-ons? It looks like either your knowledge should be refreshed a little bit or you are ignorant.

BTW. You can use java applets. That's *exactly* what you need.

--
Dalius
http://blog.sandbox.lt

[lasizoillo]

2009/2/3 Tycon <adi...@gmail.com>:

>
> AnonymousGuy wrote:
> "......You do seem pretty intent on using GWT, no matter what advice
> is
> offered in this thread......."
>
> I listen to advice from many different sources, and the advice in this
> thread ranks pretty low
> in its usefulness compared to the whole range of opinions that exist.
>
> Javascript libraries suck because the developer still needs to use the
> retarded "java-crypt" language
> which would be excutiating to develop any real application logic with.
> Productivity, development tools,

http://www.aptana.com/

> debugging,

http://getfirebug.com/

> componentization, reusability, rich libraries,

http://ajaxpatterns.org/Javascript_Multipurpose_Frameworks
jQuery, EXTJs, Dojo, YUI, ... are made for these issues.

> high level algorithms and data structures,

Even relational databases (don't use in your home)
http://code.google.com/p/trimpath/wiki/TrimQuery

> type safety,

like python?

> compile time optimizations are all huge advantages of Java

like dojo does?
http://wicketstuff.org/confluence/display/STUFFWIKI/Build+a+custom+dojo+to+fit+to+your+application
(yes, use a javascript engine made with java like some minimizers)

> compared to "java-scrap-it" ;-)

Maybe javascript its hard to learn, but you can do a lot of advanced
things (like unit tests).

I like javascript more than Java. More of the upper links are unusable
for me, but are javascript posibilities.

Excuse my poor english. I only mean that javascript isn't too bad ;-)

regards,
Javi

[Wyatt Baldwin]

On Feb 3, 2:48 am, Dalius Dobravolskas <dalius.dobravols...@gmail.com>
wrote:

> On Tue, Feb 3, 2009 at 11:06 AM, Tycon <adie...@gmail.com> wrote:
> > Javascript libraries suck because the developer still needs to use the
> > retarded "java-crypt" language
> > which would be excutiating to develop any real application logic with.
> > Productivity, development tools,
> > debugging, componentization, reusability, rich libraries, high level
> > algorithms and data structures, type
> > safety, compile time optimizations are all huge advantages of Java
> > compared to "java-scrap-it"  ;-)
>
> You are expecting from java-script something what it was not intended for.
> It is moving to that direction now (FireBug, jQuery with big selection of
> plug-ins, MochiKit or other libraries, java-script unit-testing libraries).
> Compile Time Optimizations - haven't you heard anything about V8 or
> TraceMonkey? That's not exactly CTO but that's what you want...
> componetization - haven't you seen XUL and are you not using FireFox
> add-ons? It looks like either your knowledge should be refreshed a little

> bit or you are ignorant...

...or a troll.