Static vs Dynamically Typed Web Frameworks



  • I'm hoping this doesnt open up a can of worms, but my question exists from the development of Groovy and Grails.  For those who do not know about it, it is java's response to Ruby on Rails.  Its a dynamically typed framework that compiles on the JVM.  Well I am currently working with java Struts and am maintaining a rather rich system right now.  My deployment of java web apps are relatively quick so the fast and easy deployment of Groovy or even say Ruby on Rails isnt very important.  Lastly about Groovy, all java files are said to be able to be written as .groovy files and it would compile exaclty the same.  As you can imagine there are many more important points of groovy I havent mentioned but the underlying idea is there.

    That being said, I am really looking for those who have both experience in static and dynamically typed web frame works and my question is, is there any really good reason to implement Groovy and Grails on top of my pre existing struts frame work.  If there are up sides for groovy integrated in struts, that would be worth understanding.  I guess, since working with java for so long, I havent really grasped the concept for dynamic web frameworks very much (other then say javascript).



  •  I'm no expert on Grails, but if you're already running well on Struts, why bother adding another framework?  Don't be fooled by the name; so-called "dynamic languages" are just another way to do things.  They aren't inherently better or worse than strongly-typed languages.  Each has its own advantages and disadvantages.



  • I've no personal experience of it, and my own line of work is completely different anyway, but I've heard so many good things about Ruby on Rails that it definitely merits serious investigation at the very least.  I'm not so sure about mixing it with Java though, the phrase "steak milkshake" springs fairly quickly to mind.



  • @mfah said:

    I've no personal experience of it, and my own line of work is completely different anyway, but I've heard so many good things about Ruby on Rails that it definitely merits serious investigation at the very least.  I'm not so sure about mixing it with Java though, the phrase "steak milkshake" springs fairly quickly to mind.

    RoR is impressive in some ways.  It's great for rapid prototyping and it has excellent Ajax support.  And Haml's pretty nice for markup.  But it's not without its flaws.  For example, even with Mongrel, it's still slow for big sites, for the simple reason that Ruby is still slow. Supposedly Ruby 2 will fix this, but I haven't even played with 1.9 yet, so I don't know how they're doing with that.

    Still, whether or not RoR is good shouldn't cause one to change directions.  If you have a functional Struts site, stick with Struts.  You're already three steps ahead of where you'd be if you switched.

    And as for Groovy on Grails, I've never used it and can't speak to its quality.  I know a lot of smart people were dismissing Groovy for some time, but I haven't seen anything either way lately.  My uninformed position is that it smacks of a stupid attempt to catch the Python/Ruby wave.



  • @bstorer said:

    RoR is impressive in some ways.  It's great for rapid prototyping and it has excellent Ajax support.  And Haml's pretty nice for markup.  But it's not without its flaws.  For example, even with Mongrel, it's still slow for big sites, for the simple reason that Ruby is still slow. Supposedly Ruby 2 will fix this, but I haven't even played with 1.9 yet, so I don't know how they're doing with that.

     

    As a rule of thumb, if you want to build something that is roughly a web interface to a database, and you want to do it in an afternoon, you should probably go with RoR. If you want to do a large, high-traffic site, or something that does not approximate a database, you should probably use something else. It's good at what it does and poor at everything else. 



  • @asuffield said:

    you should probably use something else

    One option that people seem to ignore is Ruby sans Rails.  Pretty much every major web framework assumes a database back-end.  If you don't need a database on the back end then you are basically free to build it in whatever language will get the job done, Ruby being one of them (in most cases).



  • @djork said:

    @asuffield said:

    you should probably use something else

    One option that people seem to ignore is Ruby sans Rails.  Pretty much every major web framework assumes a database back-end.  If you don't need a database on the back end then you are basically free to build it in whatever language will get the job done, Ruby being one of them (in most cases).

     

    Blech.  Straight-up Ruby?  Why don't we just go back to the Perl CGI days?  A better option, says a friend of mine who has used it, is Nitro.  At least then you get the benefits on the front end without being as tied to a database on the back end.



  • @djork said:

    One option that people seem to ignore is Ruby sans Rails.  Pretty much every major web framework assumes a database back-end.  If you don't need a database on the back end then you are basically free to build it in whatever language will get the job done, Ruby being one of them (in most cas

    Yes, but in that case, ruby has no particular advantage over any of the other options (java, perl, etc), so it doesn't seem worth mentioning specifically.



  • @bstorer said:

    Why don't we just go back to the Perl CGI days?

    I don't remember ever leaving them. Perl CGI is still an excellent solution to many problems. It's not a great way to do the sort of things that RoR is good at, but it's usually the quickest and neatest solution to problems of the form "upload a file from the user and stuff it into the local application for processing", where you're basically just slapping a web interface onto some existing tool so that people can use it remotely. 



  • @asuffield said:

    @bstorer said:

    Why don't we just go back to the Perl CGI days?

    I don't remember ever leaving them. Perl CGI is still an excellent solution to many problems. It's not a great way to do the sort of things that RoR is good at, but it's usually the quickest and neatest solution to problems of the form "upload a file from the user and stuff it into the local application for processing", where you're basically just slapping a web interface onto some existing tool so that people can use it remotely.

     

    Well that hardly sounds like a MVC architecture! 



  • @asuffield said:

    Perl CGI is still an excellent solution to many problems ...  usually the quickest and neatest solution to problems of the form "upload a file from the user...
     

    I must say that file uploads is one my greatest "good god, people actually think this is a good thing" problems with PHP. Uploaded files in PHP are cached in *memory*, instead of streamed directly to disk. If you want to upload a 16meg file, you have to make sure that PHP's memory limit is large enough to handle the script PLUS the uploaded data.

    Of all the moronic design decisions... 



  •  @MarcB said:

    I must say that file uploads is one my greatest "good god, people actually think this is a good thing" problems with PHP. Uploaded files in PHP are cached in *memory*, instead of streamed directly to disk. If you want to upload a 16meg file, you have to make sure that PHP's memory limit is large enough to handle the script PLUS the uploaded data.

    Let me guess; when the connection somehow fails, PHP leaks memory like a sieve — nay, drain pipe?



  • @bstorer said:

    @djork said:

    @asuffield said:

    you should probably use something else

    One option that people seem to ignore is Ruby sans Rails.  Pretty much every major web framework assumes a database back-end.  If you don't need a database on the back end then you are basically free to build it in whatever language will get the job done, Ruby being one of them (in most cases).

     

    Blech.  Straight-up Ruby?  Why don't we just go back to the Perl CGI days?  A better option, says a friend of mine who has used it, is Nitro.  At least then you get the benefits on the front end without being as tied to a database on the back end.

    That would qualify as [i]sans Rails[/i] to me, but Nitro still comes packaged with an ORM and a bunch of MVC stuff. Nitro is definitely lighter than Rails, that's for sure, but Rails can be used without ActiveRecord just as easily. Overall Nitro looks like it has about 4/5 as many classes involved compared to Rails.



  • @asuffield said:

    @djork said:

    One option that people seem to ignore is Ruby sans Rails.  Pretty much every major web framework assumes a database back-end.  If you don't need a database on the back end then you are basically free to build it in whatever language will get the job done, Ruby being one of them (in most cas

    Yes, but in that case, ruby has no particular advantage over any of the other options (java, perl, etc), so it doesn't seem worth mentioning specifically.

    Sure it does, for some people. If you 1) know Ruby well, and 2) are more productive in Ruby than other languages, then it has those two benefits over them. I'd be 99% confident that I would choose Ruby/FastCGI over Perl or Java wherever practical.

    The real point is that some people don't realize that Ruby exists apart from Rails. But, I guess those people aren't really going to be the type to pick up Ruby anyway ;) ...


Log in to reply