Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Going beyond JSP with Ruby and Seaside

timothy posted about 8 years ago | from the whenever-I-stroll-along-with-you dept.

66

An anonymous reader writes "The Java community has used JavaServer Pages (JSP) technology through most of the last decade, but signs of rust are starting to show. Longstanding conventions inhibit Java programmers from using Java code within Web pages now. Other languages handle Web development much better than Java. This article discuss how code generation works in Ruby, and it delve into a more radical component-based approach in Seaside."

cancel ×

66 comments

Another template option (3, Informative)

tcopeland (32225) | about 8 years ago | (#15668048)

...that seems to be up and coming in the Ruby world is RJS [codyfauser.com] templates. We're using them for the new indi [getindi.com] site and they seem pretty handy. The Javascript to Ruby translation is not perfect, of course, but they make some AJAX-ish things nicer: page.visual_effect :highlight, 'sidebar_heading', :duration =>3.

If you're in the northern Virginia area you might be interested in the next NovaRUG [novarug.org] meeting; there'll be a presentation on RJS there. Good times...

Flame on! (4, Insightful)

Mark_Uplanguage (444809) | about 8 years ago | (#15668080)

Come on! How many times must we endure these kinds of debates? Just use the right tool for the job. You could say there are signs of nothing but rust on COBOL yet it's still very heavily used in financial applications (back end). There is nothing gained by making inflamatory statements, just state the benefits of Seaside and Ruby and leave other languages out of it.

Re:Flame on! (1)

neonprimetime (528653) | about 8 years ago | (#15668096)

There is nothing gained by making inflamatory statements

Yeah, I mean seriously, you could lose your cat [foxnews.com] !

Joke on! (0)

Anonymous Coward | about 8 years ago | (#15668150)

"There is nothing gained by making inflamatory statements, just state the benefits of Seaside and Ruby and leave other languages out of it."

You must be new here. :)

BTW Seaside is a nice tool.

Re:Flame on! (3, Insightful)

telbij (465356) | about 8 years ago | (#15668306)

There is nothing gained by making inflamatory statements, just state the benefits of Seaside and Ruby and leave other languages out of it.

Wrong. Ruby on Rails came to prominence because of DHH's brilliant marketing--poking Java guys with a stick.

Re:Flame on! (2, Informative)

I Like Pudding (323363) | about 8 years ago | (#15669271)

I was with you right up until you implied that COBOL was good at anything.

Re:Flame on! (2, Interesting)

plopez (54068) | about 8 years ago | (#15669324)

You could say there are signs of nothing but rust on COBOL yet it's still very heavily used in financial applications (back end).

Wrong! It's no just for the 'backend' these days! And you thought the old farts weren't 'with it'.

http://www.cobolscript.com/ [cobolscript.com]

Re:Flame on! (1)

Mark_Uplanguage (444809) | about 8 years ago | (#15670141)

I am one of the old farts, but I never would have guessed there was cobolscript. Thanks for the link!

Re:Flame on! (1)

00lmz (733976) | about 8 years ago | (#15672207)

And don't forget COBOL for .NET [netcobol.com] ! Among its features:

  • GUI design. (WinForms)
  • COBOL support for ASP.NET (LANGUAGE="COBOL")
  • Full Integration with Visual Studio.NET 2003 Project Manager.

Here are some [netcobol.com] screenshots [netcobol.com] .

confusing syntax, anyone? (0, Troll)

192939495969798999 (58312) | about 8 years ago | (#15668097)

I'm sorry, but to me this is just yet another confusing syntax for the same old tricks.

Wheee! 2 different kinds of strings... yet another invitation for novices to create spaghetti code that I will have to clean up later, thanks!

confusing syntax, anyone?-Engrish. (0)

Anonymous Coward | about 8 years ago | (#15668246)

"I'm sorry, but to me this is just yet another confusing syntax for the same old tricks."

The same thing could be said for the English language. Down with english! Bring back Latin.

Re:confusing syntax, anyone? (2, Insightful)

telbij (465356) | about 8 years ago | (#15668372)

I'm sorry, but to me this is just yet another confusing syntax for the same old tricks.

You really oughtta learn LISP. Instead of spending half an hour looking at some code and concluding that it's more confusing than the language you've been working with for the last 5 years, work with it long enough to 'get it' and then make a proper comparison.

Wheee! 2 different kinds of strings... yet another invitation for novices to create spaghetti code that I will have to clean up later, thanks!

Explain to me how string syntax has anything to do with spaghetti code. Honestly.

Re:confusing syntax, anyone? (2, Insightful)

jaydonnell (648194) | about 8 years ago | (#15668380)

are you talking about symbols? If so your spaghetti code conclusion makes no sense to me.

has_many :comments
vs
has_many 'comments'

I see no source of spaghetti code from this!

Yay, it's better than JSP. (4, Insightful)

cbiffle (211614) | about 8 years ago | (#15668176)

I know I'm going to have a hard time convincing the PHP audience of this, but the conventions preventing people from using code in JSP are a good thing. You're going to have a hard time selling me a solution that makes it easier to mix my business logic and presentation, even if it's written in a language I like (like Ruby or Smalltalk).

It's better than JSP? Yay. So is everything else developed in the last ten years (and some systems developed before). The Java community has moved on to alternative presentation technologies -- WebWork, JSF, GWT, and the myriad XSLT frameworks come to mind.

Now, if it's more productive than GWT or JSF...well, then we'll talk. But don't attack the strawman of JSP. That's like saying "Ruby is better than Perl 4!"

Re:Yay, it's better than JSP. (0)

jaydonnell (648194) | about 8 years ago | (#15668427)

personally i think ruby, and therefore rails, is better because I think dynamic languages are generally better than static ones.

Re:Yay, it's better than JSP. (2, Insightful)

telbij (465356) | about 8 years ago | (#15668454)

You're going to have a hard time selling me a solution that makes it easier to mix my business logic and presentation

Attacking JSP is a strawman, but so is this. Presentation requires logic. Ruby makes an excellent templating language. If we try to replace it with a secondary crippled syntax just to avoid people putting business logic in their templates, then we run the risk of forcing people who know what they're doing to mix presentation logic in with their business logic. Designing languages to prevent people from doing stupid things is a good thing for shitty programmers, but it's a terrible thing for good programmers.

Re:Yay, it's better than JSP. (2, Informative)

Anonymous Coward | about 8 years ago | (#15668733)

Ruby makes an excellent templating language.
Do you really mean the actual Ruby language or the Ruby templating language. Because even Ruby has a templating language (rhtml).

I think there's a bit of confusion on your part about the purpose of templating languages. You seem to believe that they exist to allow crippled logic to prevent programmers from doing things they should know not to do anyways. But this is only a side-effect of their true purpose. Templating languages evolved from people writing web pages in real programming languages. Code like:
print "<html>\n";
print "<head>\n";
print "<title>My Webpage</title>\n";
...
print "</html>";


Stuff like the above snippet gets ugly and un-maintainable in a hurry, no matter what language you use (Ruby included). Templating languages were the solution to this problem. Instead of defaulting to being Java/Perl/Whatever code, they made you use an escape sequence to wrap code in that language and the default behavior was to pass their content straight through to the output stream. The crippled logic you speak of only came about because code like:
<% if (mycondition) { %>
condition is true
<% } else { %>
condition is false
<% } %>
is awkward and ugly. However most templating languages still allow you to do logic in this manner.

Yes, presentation requires logic. No, presentation does not require business logic. Yes, fully-fledged languages like Ruby, Java, Perl, etc are better environments to write complex logic. However those environments are rarely the easiest to maintain large amounts of presentation code. Good templating languages will give you a way to write the complex logic in a real language and invoke that from the templating language. Not that JSP is a good templating language (no one in their right mind would say that...), but it does give you the ability to write custom tags in Java and call them from the JSP. And it also give you the &;lt;%...%> syntax to hack your way to what you want.

Re:Yay, it's better than JSP. (1)

Cyberax (705495) | about 8 years ago | (#15704568)

Presentation does not require much of logic. Most of it can be expressed with simple custom tags (supported by JSP 2.0):
<c:if cond="mycondition">
blah-blah
<c:else>
blah
</c:if>
Besides, you can get smart autocomplete and error checking in your favorite editor for custom tags. Yes, sometimes you'll need to use Java scriptlets. But if you have to do it only once for 10-20 pages then this is not a big problem.

Re:Yay, it's better than JSP. (0)

Anonymous Coward | about 8 years ago | (#15670282)

And most programmers are shitty programmers, hence the brilliance of Java.

Re:Yay, it's better than JSP. (1)

NutscrapeSucks (446616) | about 8 years ago | (#15670362)

Ruby makes an excellent templating language.

Is Ruby better than Java for templating? Depends.

Is RHTML any better (or even that different) than plain ol' JSP. No. There, I said it.

Re:Yay, it's better than JSP. (1)

Enonu (129798) | about 8 years ago | (#15671658)

JSPs aren't in the same class as WebWork or JSF. JSPs are a presentation technology while WebWork and JSF are web frameworks. Web frameworks are for organizing your web application while presentation technologies are for dumping out HTML (or whatever) to the client.

Starting to show??? (1, Insightful)

curunir (98273) | about 8 years ago | (#15668196)

The signs of rust have been showing since it started to get any kind of serious use. JSP is basically an abomination. It makes the simple stuff hard and the hard stuff require using scriptlets. And it makes it far too easy to put far too much application logic in JSP code. JSP 2.0 has helped a bit, but it's a bit like putting a prom dress on 600 lb hooker...she looks better, but only slightly.

But thankfully for Java programmers, there's a ton of other better alternatives that can be used. Freemarker, Velocity, Tapestry and Cocoon are all vastly superior options to JSP. Tapestry was a component-based view-layer framework long before Seaside or any other Smalltalk server-side framework. So comparing it to JSP is a bit like comparing apples to Ford Pintos.

Picking on JSP is like kicking a starving puppy...try picking on one of Java's guard dogs (listed above) and they'll put up a stronger fight.

Fuck you! (0)

Anonymous Coward | about 8 years ago | (#15668367)

"but it's a bit like putting a prom dress on 600 lb hooker...she looks better, but only slightly."

I think your mom looked really nice in that dress, and we had a great time together. Don't be such a dick about this relationship, I am not trying to replace your dad.

Re:Starting to show??? (1)

Billly Gates (198444) | about 8 years ago | (#15668781)

Which is why I am a fan of opensourcing java because its stagnating.

You listed alternatives but many bussinesses dont trust free software or consider such projects proprietary if they dont come from Sun. Sco did alot of damage to the mindset of phb's on one of my former employers. I know sun came up witht he JCP community process which have made nice tools llike the beanshell part of the next java.

JSp is what most bussinesses still use and where the jobs are out. No wonder MIS grads are looking at ASP.NET with c# for quicker development time.

I looked at the GWT and it seems to be geared towards presentation logic and I would like something more geared toward application logic that is free.

JSP needs to either improve and java needs to come with better tools or .NET will start to take over soon. I looked at the pet shop demo from Microsoft and its 1/4th the code and 2x as fast as the java equilivant that doesn't use JSP.

Re:Starting to show??? (1)

curunir (98273) | about 8 years ago | (#15670745)

Only Sun's Java offerings are really stagnating. The real improvements are happening outside of Sun. If Sun were to give up control of Java by open-sourcing it, it would do wonders for Java, but it is by no means necessary.

You'd be surprised at how well accepted projects like Spring [springframework.org] are among PHBs. Spring is quickly getting a reputation for allowing projects to deliver on time and budget (if not under). I was privileged enough to attend the Spring Experience conference last December and there were a number of really large companies (some of the biggest names from the financial, tech and retail sectors) that sent quite a few people there. Most of those I talked to said that those companies had basically dumped EJB and were using a Spring-style approach to new projects. Developing apps with Spring's IoC and AOP capabilities really does give you the faith that your application is rock-solid. And that kind of stability is something that, in my experience, management absolutely loves.

That's what's really missing from pieces like the linked article...any middlework framework for handling all layers of your application. Sure, that Smalltalk view framework might make creating intelligent components dead simple (doubtful, but possible). But how do you test them in isolation? How do you test the business layer below them in isolation? (and, of course, how do you test the data layer below that in isolation?). Spring offers a dead-simple way to do all of this. I've yet to see anything outside of the Java world come close.

To be expected (4, Insightful)

hexghost (444585) | about 8 years ago | (#15668230)

One look at the author being Bruce Tate, and you wonder why they didn't just link to his book at the top of the article instead of the bottom. Way to go Brucey!

Re:To be expected (1)

LarsWestergren (9033) | about 8 years ago | (#15673891)

Yes, I think this actually the tenth or so "Ruby -yay! Java -boo!" article by Bruce Tate that Slashdot posts. I think he writes about two a week for IBM devworks.

I think the quality of his writing has declined, starting with "Better, Faster, Lighter Java". He never talks about possible tradeoffs of choosing a design or technology, it is always "And see, this is the magic silver bullet that solves everything, three lines of code, bam, next project".

eh... (2, Insightful)

aleksiel (678251) | about 8 years ago | (#15668483)

not "better", "differently".

if i only learned one thing in my later classes in college, it was that a language is a tool. some languages make some tasks easy. some languages are better used given specific circumstances. there are differences between jsp and ruby. sure, maybe ruby does somethings better, but there are also definite advantages on the jsp side, as well.

Re:eh... (0, Insightful)

Anonymous Coward | about 8 years ago | (#15668914)

Everything you said is just a propagation of the Big Lie that permeates all of society these days. Just like in many other fields (in science as well as politics for example) there are not always advantages to - or even a necessity to hear out the arguments of - each side. Sometimes, one is simply better than the other, no need to be politically correct about it.

I'd be very surprised to find even one non-constructed, realistic task in which jsp has any advantages over Seaside. Newer Java-based frameworks may very well have some, but jsp? It's an abomination.

Re:eh... (1)

aleksiel (678251) | about 8 years ago | (#15669725)

big lie? hardly.

yes, there are some languages that are obsolete/dead. there are some that are still alive just because they're too entrenched to replace. but there's no one god-language that is better than all others. pretty much every language has SOME facet that is unique/different.

i'm not a seaside expert. i'm not a jsp expert. but i'm sure i could do some research, find differences, and come up with scenarios where jsp would be a better choice. maybe seaside is a better choice in most cases, but there almost definitely ARE cases where jsp is a better choice.

i could turn a screwdriver over and use it to pound in a nail, but a hammer is such a better choice. and yes, i've personally used both to nail in nails.

Re:eh... (0)

Anonymous Coward | about 8 years ago | (#15681424)

so, tell us, what is wrong with the JSP way?

easy incremental development, gets compiled into java on first execution (or when your server starts if you precompile them)

is it because it's java, and that's the only reason it's an abomination?

if I want somebody who knows JSP well, I can usually find a good quality person quickly. good luck finding a good seaside programmer on short notice.

ruby will remain a toy, java will pay the bills for lots of your fellow programmers.

Once again, wishful thiking (2, Insightful)

Anonymous Coward | about 8 years ago | (#15669424)

Not a single article from Bruce Tate manages to convince me of "killer funcionalities" in their Ruby solutions (only a web framework cannot match the whole Java for making it worth migrating), it seems more like a mediocre developer in love with his new toy trying to get the attention he needs. His sensationalitic approach makes him look like a fraud, an untalented programmer that proclaims himself as the spokesperson of something. Maybe a "fraud with a big mouth" is what he is after all.

All non-Java developers keep in mind that all this loser says has nothing to do with the general perception inside the Java community. The only general perception there's is that he's an idiot.

Once again he shows a pathetic template system, which could be easily done in Java but no one is crazy to do it because it's crap, and a framework like many others.

BTW, he needs to study Java web development, that goes beyond JSP. Not to mention the many options we have, including templating, but also a tool support unseen in the Ruby world, that makes web development as easy as drag'n drop.

Ruby is not a match for Java, give up. Why 10 out of 10 articles written about "dynamic languages" must have sensationalistic and impossible claims involving Java?

And opensource is not trustworthy. I see many people complaining about Java's commitment to compatibility between versions (including Bruce Tate) and then they recommend Opensource as a solution! That's CRAZY. Would you like to know that you need to rewrite that big application of yours because of a new version that has just came out??

How do they expect to be taken seriously?

Re:Once again, wishful thiking (1)

arevos (659374) | about 8 years ago | (#15670968)

Ruby is not a match for Java, give up.

How is this unfounded statement any better than what's written in the article?

Re:Once again, wishful thiking (0)

Anonymous Coward | about 8 years ago | (#15671431)

How is this unfounded statement any better than what's written in the article?
Since the claim that "it's better than Java" was made by him, the obligation of proving it belongs to him. Otherwise my assumption holds true since the use of Java is widespread and no company would use it if it were bad.

Re:Once again, wishful thiking (0)

Anonymous Coward | about 8 years ago | (#15672121)

no company would use it if it were bad

Unlike, say, Microsoft Windows.

Re:Once again, wishful thiking (1)

arevos (659374) | about 8 years ago | (#15673840)

Since the claim that "it's better than Java" was made by him, the obligation of proving it belongs to him. Otherwise my assumption holds true since the use of Java is widespread and no company would use it if it were bad.

That's not quite what I asked. As a presumably experienced programmer, you will doubtless know that some languages are more suitable for some tasks than others. One would not construct a web application in assembly, for instance.

The claim that "Ruby is not a match for Java" reeks of generalities. Ruby is clearly a rather different language to Java, and has disadvantages and advantages to use. The most obvious disadvantage of Ruby is that it's slow. An advantage is that Ruby is a syntaxically more flexible and concise language than Java. The list goes on. To claim that Java exceeds Ruby under all circumstances, which is what your original quote appears to suggest, seems patently false.

Java has its uses, as does Ruby.

Re:Once again, wishful thiking (0)

Anonymous Coward | about 8 years ago | (#15677992)

The claim that "Ruby is not a match for Java" reeks of generalities. Ruby is clearly a rather different language to Java, and has disadvantages and advantages to use. The most obvious disadvantage of Ruby is that it's slow. An advantage is that Ruby is a syntaxically more flexible and concise language than Java. The list goes on. To claim that Java exceeds Ruby under all circumstances, which is what your original quote appears to suggest, seems patently false.
 
Java has its uses, as does Ruby.
That's because you are ignoring what most people choose to ignore in such comparisons. For developing software you way more than just the language! You need tools, libraries, opensource software, etc and Java has them in a much more quantity (and quality) than Ruby.

Only the standard class library from Java is enough to dwarf Ruby.

BTW, Ruby is older than Java, isn't it curious how Java developed itself and Ruby didn't?

Re:Once again, wishful thiking (1)

arevos (659374) | about 8 years ago | (#15679381)

That's because you are ignoring what most people choose to ignore in such comparisons. For developing software you way more than just the language! You need tools, libraries, opensource software, etc and Java has them in a much more quantity (and quality) than Ruby.

Obviously. I program in Java for a living. I'm quite aware of amount and quality of libraries available for Java.

However, in terms of general web development, Ruby's featureset is fairly complete. There isn't much it lacks. I mean, sure, if you want a complete business solution that involves messaging, job scheduling, customisable rulesets, clustering and goodness knows what else, then Java's probably the better choice. But if you just want a web framework with ORM, templating system, unit testing, AJAX integration and search engine, then Ruby has it covered.

And once you start to develop custom code, Ruby's featureset is its advantage. You can often do more in a shorter space of time, and in a smaller amount of code, in Ruby than in Java. Indeed, some programming techniques are so cumbersome in Java, that it's rarely advantageous to go near them; JIT class construction, for instance. In Ruby, many of these techniques are standard ammunition in the programmer's arsenal.

BTW, Ruby is older than Java, isn't it curious how Java developed itself and Ruby didn't?

Not really. Java had a multibillion dollar corporation pushing it. That often helps.

There are other reasons. To get the most out of Ruby, you need to understand the more exotic concepts available in it. This requires a certain level of skill that may not be available to every programmer. In which case, many of the advantages to using Ruby over Java are lost.

Virtual machine dfficiency, familiarity and product visibility all also play a part in Java's success.

Re:Once again, wishful thiking (0)

Anonymous Coward | about 8 years ago | (#15679685)

However, in terms of general web development, Ruby's featureset is fairly complete. There isn't much it lacks. I mean, sure, if you want a complete business solution that involves messaging, job scheduling, customisable rulesets, clustering and goodness knows what else, then Java's probably the better choice. But if you just want a web framework with ORM, templating system, unit testing, AJAX integration and search engine, then Ruby has it covered.
You forgot to mention Unicode support, internationalization and decent documentation that are expected even in the smallest projects.

I still think Java dwarfs Ruby, and most of the testimonials I hear are like Bruce Tate's, i.e., full of passion and with a complete lack of tradeoffs as if it were a miracle. Nothing is like that. Don't you think there's something wrong in all of this?

It's not difficult to see idiotic over-generalizations around like "RoR is better than the whole Java", or "Java is dead". Sorry, but Ruby isn't better than Java, not today.
And once you start to develop custom code, Ruby's featureset is its advantage. You can often do more in a shorter space of time, and in a smaller amount of code, in Ruby than in Java.
I have some experience with scripting languages and would like to protest against the notion that "less lines of code = better". So did the Perl developers always get it right? Taking every possible shortcut in order to make the code smaller?

I don't think so. Usually the people that are anti-design, i.e., promote the idea of "simpleness through less lines of code" are untalented programmers that like to spit out code quickly. For quick'n dirty things that is ok, but not for big things.

I will tell you, even a small application, passing from hand to hand over the years and being treated by "keystroke economists" can become a pain to maintain.

I'm not going to put myself as better than everyone else, like many Ruby developers love to do, but I really think:

- explicitness lead to better code;
- Java makes it easy for developers to write well organized code;

The most absurd things I have heard lately from such people is "deprecate final" or "everything should be open because the developer knows what he is doing" or some other security stupidity. Not only this goes against OO and encapsulation but it's risky. People in order to mess with your code must know the implications of the change!!! Advocating that "everyone should be free to change it" it's crazy, because the person would need to know YOUR WHOLE APPLICATION.

Is this feasible in real world? I don't think so.
Indeed, some programming techniques are so cumbersome in Java, that it's rarely advantageous to go near them; JIT class construction, for instance. In Ruby, many of these techniques are standard ammunition in the programmer's arsenal.
Ruby developers always miss the big picture, that's the problem. You want to compare "features" from different languages? Well, good luck. You'll have some work.

We don't need only a "featureset", we need to the complete package (language, tools, IDE, libraries, technologies), and Java does it. Java is not good because "it's the best language with the best features" but because it provides a good balance of good stuff in ALL THOSE AREAS.

Maybe when Ruby folks learn that Ruby will stand a chance, because "less keystrokes" is not enough to business to adopt it.

Re:Once again, wishful thiking (1)

arevos (659374) | about 8 years ago | (#15682419)

You forgot to mention Unicode support, internationalization and decent documentation that are expected even in the smallest projects.

That's why I prefer Python, myself ;)

It's not difficult to see idiotic over-generalizations around like "RoR is better than the whole Java", or "Java is dead". Sorry, but Ruby isn't better than Java, not today.

Gah! You decry over-generalisations, then make one of your own!

I have some experience with scripting languages and would like to protest against the notion that "less lines of code = better". So did the Perl developers always get it right? Taking every possible shortcut in order to make the code smaller?

To an extent, you're correct. A one line hack in Perl is often not maintainable in the future.

But you're only addressing part of what I wrote. I said, "You can often do more in a shorter space of time, and in a smaller amount of code". Both parts of the sentence are important. Code in Ruby is not concise in the same way a one liner of Perl is concise. For instance:

class Folder < ActiveRecord::Base
    acts_as_tree
    has_many :files
end

The above code is concise, yet understandable. You can see that this is an ActiveRecord called Folder, which acts as a tree, and that each Folder has many files.

Incidentally, this concise readbility is made possible only through Ruby's support of mutable classes. The two functions, acts_as_tree and has_many, alter the class that they exist in. Incidentally, because Java cannot easily alter class behaviour, so this technique is beyond Java's capabilities. This means that often, Ruby can be more readable than the equivalent Java code.

The most absurd things I have heard lately from such people is "deprecate final" or "everything should be open because the developer knows what he is doing" or some other security stupidity.

This is largely unrelated to Ruby, as Ruby supports class permissions. However, I disagree with you about this. If a developer wishes to shoot his foot off, let him. So long as you make it clear in your documentation that overloading this particular function is not something that should be done, there's no need to go any further. A stupid developer will always find ways to break things; there's no point in nannying the programmer.

We don't need only a "featureset", we need to the complete package (language, tools, IDE, libraries, technologies), and Java does it. Java is not good because "it's the best language with the best features" but because it provides a good balance of good stuff in ALL THOSE AREAS.

A good balance? I don't understand your argument. Okay, sure, if you had a choice of one language, and one language only, to use for every project from now 'till doomsday, then Java might be your man. But individually, some programming projects are rather specific. You don't need a "good balance" of features and libraries; you need the features and libraries that are best for that particular job. Sometimes Java will fulfil that need best, and sometimes other languages will.

You said it yourself: 'Java is not good because "it's the best language with the best features"'. Follow that chain of logic forward and you'll come to the conclusion that Java is not the best language for every possible problem. Nor, for that matter, is Ruby, or Python, or Scheme, or Haskell, or whatever else you might happen to come across. Your choice of language should be dictated by the problem you face.

Also, if you're so stuck on libraries, then a JVM-based language such as Nice [sourceforge.net] might be just up your street.

Re:Once again, wishful thiking (0)

Anonymous Coward | about 8 years ago | (#15684207)

Gah! You decry over-generalisations, then make one of your own!
Am I? Take a look at any article produced by Mr. Bruce Tate.
This is largely unrelated to Ruby, as Ruby supports class permissions. However, I disagree with you about this. If a developer wishes to shoot his foot off, let him. So long as you make it clear in your documentation that overloading this particular function is not something that should be done, there's no need to go any further. A stupid developer will always find ways to break things; there's no point in nannying the programmer.
Yes, there's a need beyond documentation. You can't guarantee who will work with your software and ANYTHING may happen, ignoring that is like saying "Ok, let's not use encryption, transmit it in plain text because a bad person would always find ways of cracking it" or "Ok, let's not lock the house door because a thief would always find a way in" or "Firewall? What for? A hacker would always find a way of breaking into your system".

This is pure nonsense. How many developers read the WHOLE documentation before start coding? How many people read the WHOLE manual before installing a DVD player or a new stereo?

This assumption is a dangerous to make and may lead to security flaws. The sanest way is not to trust the
"documentation will be enough", either because people might not read it or it could be not updated, and always protect the code from undesired usage.

The "break the application" is the mininum damage scenario for unprotected code. Imagine the client's data silently corrupted due to a small bug introduced by "something that shouldn't be overriden". You could lose serious money.
You said it yourself: 'Java is not good because "it's the best language with the best features"'. Follow that chain of logic forward and you'll come to the conclusion that Java is not the best language for every possible problem. Nor, for that matter, is Ruby, or Python, or Scheme, or Haskell, or whatever else you might happen to come across. Your choice of language should be dictated by the problem you face.
Once again, you miss the point entirely. I will say it once more:

- We need way more than just the language.

You may argue that one is "better" than the other in a given task, but that alone is not enough to use it. A more flexible environment can compensate one shortcoming with another thing, for example compensate the missing features from the language with the IDE, or libraries.

It's good to keep to a minimum the number of languages inside of a company, but why? Because they are all "lame developers"? NO, BECAUSE IT'S EASIER TO REPLACE DEVELOPERS THEN.

What if your developer found a new opportunity somewhere else and you need to replace him? Would it be better if he used 8 different languages depending on the case or if he used only one? This kind of thinking of yours only proves that Ruby developers, and opensource developers in general, always miss the BIG PICTURE.

Java doesn't need to be the best, it needs to be good enough for the majority.

Re:Once again, wishful thiking (1)

arevos (659374) | about 8 years ago | (#15684719)

Yes, there's a need beyond documentation. You can't guarantee who will work with your software and ANYTHING may happen

Sure, and why should that be a problem? Once my library is in the hands of a developer, what he does with it is completely up to him. If he attempts to extend an undocumented internal function, what happens is not my problem. Warrenty void if opened.

ignoring that is like saying "Ok, let's not use encryption, transmit it in plain text because a bad person would always find ways of cracking it" or "Ok, let's not lock the house door because a thief would always find a way in" or "Firewall? What for? A hacker would always find a way of breaking into your system".

Of course it isn't. The examples you give deal with protecting data and hardware from other users. Class permissions are designed to protect the developer from themselves. I'm of the opinion that programmers should be given more than enough rope to hang themselves with; you never know when those extra feet of rope could come in handy.

You may argue that one is "better" than the other in a given task, but that alone is not enough to use it.

You've lost me. If a language is clearly more suited to a particular task than another, surely that's reason enough to use it?

It's good to keep to a minimum the number of languages inside of a company, but why? Because they are all "lame developers"? NO, BECAUSE IT'S EASIER TO REPLACE DEVELOPERS THEN.

A significant proportion, perhaps even the majority, of software companies specialise either on a single product, or on an set of similar products. In such cases, there isn't so much of an advantage to using a "Jack of all trades" language such as Java.

Besides, any new developer will likely as not have to get to grips with the company's software and internal libraries anyway. For an experienced programmer (and would you want to hire any other kind?), learning a new programming language is trivial in comparison. There's much more overlap between programming languages than there is between libraries and frameworks; it's just a case of mapping familiar constructs to a new syntax.

What if your developer found a new opportunity somewhere else and you need to replace him? Would it be better if he used 8 different languages depending on the case or if he used only one? This kind of thinking of yours only proves that Ruby developers, and opensource developers in general, always miss the BIG PICTURE.

So long as the languages are chosen wisely, I fail to see the problem. As I pointed out earlier, learning a new language is trivial compared to trying to understand the source code and architecture of a complex application you yourself have not worked on before, even with extensive documentation.

Realistically though, I can't see a business needing eight different languages. I've never found myself using much more than three regularly.

Re:Once again, wishful thiking (0)

Anonymous Coward | about 8 years ago | (#15684796)

Sure, and why should that be a problem? Once my library is in the hands of a developer, what he does with it is completely up to him. If he attempts to extend an undocumented internal function, what happens is not my problem. Warrenty void if opened.
Because you might work in the same company as this other person works, or even worse, in the same team, and if he screws up you get screwed too?

Security is never enough. Ruby developers with this "developers know what they are doing" talk resembles C++ developers with "we need no stinkin' memory management, the developer know what he is doing". We all know how this story ends.
Of course it isn't. The examples you give deal with protecting data and hardware from other users. Class permissions are designed to protect the developer from themselves. I'm of the opinion that programmers should be given more than enough rope to hang themselves with; you never know when those extra feet of rope could come in handy.
Have you realized that we are also users? We use other people's code everyday, in tools, in libraries, in frameworks. We need protection in the code too, from other users.
A significant proportion, perhaps even the majority, of software companies specialise either on a single product, or on an set of similar products. In such cases, there isn't so much of an advantage to using a "Jack of all trades" language such as Java.
Yes, there is. Easy replacement of employees if needed is one example. Tools, libraries, support, evolution are others.
For an experienced programmer (and would you want to hire any other kind?), learning a new programming language is trivial in comparison. There's much more overlap between programming languages than there is between libraries and frameworks; it's just a case of mapping familiar constructs to a new syntax.
That may be, at your home as a hobby, but it's not always feasible in real world, especially when some pressing bug occurs and it must be fixed yesterday. Would you like to hunt it in an environment you know or in a complete alien one?

Besides, ALL developers are supposed to know it, at least in the same team, in case of vacation, days off, sick days, etc. It's not so simple.

Re:Once again, wishful thiking (1)

arevos (659374) | about 8 years ago | (#15685036)

Because you might work in the same company as this other person works, or even worse, in the same team, and if he screws up you get screwed too?

Someone with that level of incompetance would find a way to screw things up even with strict class permissions. I'd also be leery about working for a company who would employ people without a technical interview to determine if they knew what they were doing.

Security is never enough.

Sure, for untrusted users. But if you consider the programmers in your team to be incompetant enough to screw up that badly, then I'd contend your problems are too widespread to be solved by class permissions.

Have you realized that we are also users? We use other people's code everyday, in tools, in libraries, in frameworks. We need protection in the code too, from other users.

Again, if you have an imbecile hiding somewhere in the chain of development, class permissions aren't going to solve much. If you're using a piece of third-party software, be it a library, framework or whatever, you place a degree of trust in the developers not to have completely FUBARed the code. If you don't trust them, or have reason to suspect that the software was developed by people with a room temperature IQ, then why on earth are you using the software in the first place?

Class permissions are not adequate protection from incompetant developers. To believe otherwise is to give yourself a false sense of security.

Yes, there is. Easy replacement of employees if needed is one example. Tools, libraries, support, evolution are others.

Easy replacement of employees? As I said before, any skilled developer will be able to pick up a language in a far shorter time than they could get to grips with any reasonably complex software product. Also, those developers who are familiar with less popular languages, tend also to be some of the most competant. You don't learn Ruby to improve your prospects of employment; you do it because you enjoy programming for the sake of programming.

As for tools and libraries, if the language you use has all the necessary tools for the product you're developing, then Java has no inherent advantage. Indeed, once one moves away from Java, it's limitations rapidly become apparent. Contrast Java's Hibernate with Python's SQLObject. If you need to handle large volumes of database queries, then Hibernate's clustering and efficienty ORM mappings become rather essential. But if you aren't dealing with that level of traffic, then the less CPU efficient, but far more concise SQLObject starts to look terribly tempting.

This isn't just a problem with a specific library. Java can't emulate SQLObject in any meaningful way, as it lacks the syntax capabilities to do so. Thus, in some respects, other languages can offer better libraries than Java, as they're not subject to the same restrictions.

That may be, at your home as a hobby, but it's not always feasible in real world, especially when some pressing bug occurs and it must be fixed yesterday. Would you like to hunt it in an environment you know or in a complete alien one?

Besides, ALL developers are supposed to know it, at least in the same team, in case of vacation, days off, sick days, etc. It's not so simple.

You have that problem whatever language is used. If only one programmer is working on a large, critical piece of software, then you're clearly going to have problems if they bugger off. That's why you ensure beforehand that other developers have the necessary knowledge about the system to fix any problems, or to continue work after the main developer leaves.

Re:Once again, wishful thiking (0)

Anonymous Coward | about 8 years ago | (#15685213)

Someone with that level of incompetance would find a way to screw things up even with strict class permissions. I'd also be leery about working for a company who would employ people without a technical interview to determine if they knew what they were doing.
Ok, I believe you so far only explicited a fatal flaw in Ruby fanatics logic. Follow with me:

- Humans commit mistakes;
- Developers are humans;
- Therefore developers commit mistakes;

Unless you are implying that Ruby developers are superhumans that never commit mistakes, I think you should review your opinions.

By your logic: does Microsoft only hire morons? Would you be "leery" about working at Microsoft by their "level of incompetence"?

PEOPLE WILL COMMIT MISTAKES! BUGS WILL HAPPEN EVEN IF YOU ARE THE BEST DEVELOPER IN HUMAN HISTORY SIMPLY BECAUSE YOU ARE HUMAN. Do you disagree with that? Don't you think "preventing the worse" is worth doing?

Documentation alone is not enough. I, as a responsible professional, must make the code secure enough to prevent undesired usage. In a small class it may look like an exaggeration, but in a bigger project, especially after some years with several maintainers, that's obvious.
Sure, for untrusted users. But if you consider the programmers in your team to be incompetant enough to screw up that badly, then I'd contend your problems are too widespread to be solved by class permissions.
Accidents happen. Thank God you don't work in civil construction:

"What? Using these security equipments, what for? If you think your workers are so dumb to fall off the window of the 3rd floor or let a brick fall on their heads then your problems are so widespread a simple rope and a helmet won't help".
Easy replacement of employees? As I said before, any skilled developer will be able to pick up a language in a far shorter time than they could get to grips with any reasonably complex software product. Also, those developers who are familiar with less popular languages, tend also to be some of the most competant. You don't learn Ruby to improve your prospects of employment; you do it because you enjoy programming for the sake of programming.
What we are talking about after all? I am kind of lost. So it all nails down to your personal preferences? I think we have a problem, because if you work in a big enough company, i.e., more than 1 employee, it may happen that different people have different ideas of what is "cool". If you are implying that anyone that disagrees with you is stupid, then I think you probably have a big difficulty in working in teams.

People want to hire individuals that KNOW THE TECHNOLOGY they are supposed to use, not to learn as they use. In what planet do you live? That's why there are requirements for jobs, that doesn't mean someone else wouldn't be "smart enough to do it" but simply because companies don't have the time to wait for the person to learn.

BTW, you are considering only the language. Using a platform for development is not only that! It's about learning the platform, the libraries, the paradigms, and it takes time in order for a person to produce good code in that, i.e., code without duplication from the libraries, code using paradigms correctly, code taking advantage of the features.

As I told you, and will repeat once more:

- We need way more than just the language;

The language is one of the tools we use, but not the only one.

Re:Once again, wishful thiking (1)

arevos (659374) | about 8 years ago | (#15685485)

Ok, I believe you so far only explicited a fatal flaw in Ruby fanatics logic. Follow with me:

- Humans commit mistakes; - Developers are humans; - Therefore developers commit mistakes;

Unless you are implying that Ruby developers are superhumans that never commit mistakes, I think you should review your opinions.

Firstly, Ruby has class permissions the same as Java. This isn't anything to do with Ruby.

Secondly, there are mistakes, and there are mistakes. If I decided to stick a electrical cable in my mouth without checking if it's live or not, then I suspect people wouldn't go around saying, "Well, he's only human". Instead, I rather suspect they'd say, "What a moron!", and rightly so. Likewise, if a programmer ignores a big fat warning and attempts to overload an undocumented, internal method of some hidden class, then they shouldn't be surprised if they screw something up.

Screwing around with undocumented internal functions is not something any experienced programmer would do lightly. Nor is it really something you can do by accident. You have to deliberately set out to screw with the internals, and if you don't know the problems that could result in, then quite frankly you deserve what's coming to you.

Accidents happen. Thank God you don't work in civil construction:

"What? Using these security equipments, what for? If you think your workers are so dumb to fall off the window of the 3rd floor or let a brick fall on their heads then your problems are so widespread a simple rope and a helmet won't help".

That's not a very accurate analogy. A better one would be, "Should we plaster this support pillar with warning signs saying 'Do not destroy', and trust our workers not to take a jackhammer to it, or should we construct an elaborate cage around it to prevent any mishaps?". In construction, warning signs are used more often than physical barriers, since the construction firms expect their employees to have some idea about workplace safety. I see no reason why software development should be any different.

People want to hire individuals that KNOW THE TECHNOLOGY they are supposed to use, not to learn as they use. In what planet do you live?

Not all firms take this approach. I once had a job offer from a company who worked mainly with C#, a language which I had no prior experience in. The difficulty was not learning C#, but learning the architecture and internal APIs of the large software package they sold. They presumably knew this, otherwise they wouldn't have offered me the job.

BTW, you are considering only the language. Using a platform for development is not only that! It's about learning the platform, the libraries, the paradigms, and it takes time in order for a person to produce good code in that, i.e., code without duplication from the libraries, code using paradigms correctly, code taking advantage of the features.

Paradigms and patterns are often cross-language. Syntax usually has a lot of overlap with existing languages.

You are right, however, with your mention of libraries. But if you stop and think about it, programmers don't need to know that much about the standard libraries of a programming language to code effectively. For instance, I've worked with Python for a long time. But if you asked me to name all the modules in the standard library, I could only manage about six, and I'd be able to tell you even less about the functions in those libraries. I have a similar experience with Java; I can recall only a dozen standard classes off the top of my head.

But the thing is, I don't need to know the specifics. All I need to know is general capabilities. If I know that Java, or Python, has a regular expression library, then the documentation is a two second Google away. I don't need to know the details of the library; I just need to know what to search for. This reduces the task considerably, not only because the problem is now abstracted, but also because there's a lot of overlap between standard libraries, much as there is with syntax. Most languages nowadays, for instance, include regular expressions as standard.

Re:Once again, wishful thiking (0)

Anonymous Coward | about 8 years ago | (#15680757)

> Ruby's featureset is fairly complete. There isn't much it lacks

Unicode. Holy crap, how on earth does anyone do sane I18N without it? Of course RoR doesn't support that either.

Re:Once again, wishful thiking (1)

Cyberax (705495) | about 8 years ago | (#15704590)

Just use UTF-8. It's a 8-bit Unicode encoding and it works quite OK with Ruby.

JSP != Java (4, Insightful)

iangreen (793707) | about 8 years ago | (#15670819)

The main article here says 'there are better languages for web than java', or something to that effect. How irrelevant. This article is about JSP, not Java. One could in theory write a ruby language bytecode compiler/interpreter for Java and use it there.

JSP has issues, yes, but some of us dont even use it for our web VIEWS, which are independent of the java backend, (if you're an architect worth hiring, anyway) -- for which Java is unparalled in doing the job. Try to scale like Java does with Ruby at the backend. Good luck.

Re:JSP != Java (2, Informative)

funfail (970288) | about 8 years ago | (#15671834)

One could in theory write a ruby language bytecode compiler/interpreter for Java and use it there.
In practice, actually: http://jruby.sourceforge.net/ [sourceforge.net]

ASP? (0)

Anonymous Coward | about 8 years ago | (#15671890)

The author must be living in 1995. Ever heard of ASP.NET? he jumps from JSP/ASP to the 'revolution' of LAMP and Seaside. Really convincing arguments there with side-by-side comparisons of the latest technologies. Lame.

unicode (4, Informative)

theolein (316044) | about 8 years ago | (#15671930)

I live and work in Switzerland and our sites have to handle 4 or more languages. When Ruby has unicode support built in, I'll take another look at it. Until then, it's Java, python and php for me.

Ruby supports UTF-8 (0)

Anonymous Coward | about 8 years ago | (#15699616)

use -K for source encoding

Don't know if that helps you, though.

Seaside (3, Informative)

cgreuter (82182) | about 8 years ago | (#15672419)

I've never used either JSP or Ruby on Rails, so I can't make any kind of informed comparision. I have, however, done some stuff with Seaside and the article focusses on the HTML generation aspect of it and completely misses what makes Seaside great.

Seaside's HTML generator is (IMHO) kind of clunky, actually. Something like PHP, where you embed the code in an HTML file, is cleaner and simpler. But, if you need Seaside, the HTML generation is going to be a small part of your application.

What makes Seaside so utterly cool is that the back button works.

Let me explain:

In Seaside, you generate your page programmatically and you specify what happens when a link is clicked or a button pressed via a callback.

For example:

html anchorWithAction: [self increase] text: '++'.

creates a link. The stuff between the square brackets gets executed when the user clicks the link. In the above example, the current page just gets refreshed. If you want to go to another page, you'd use the "call:" method:

html anchorWithAction: [self call: OtherPage new] text: 'Some other page'.

Called components can also return values, so you can call out to another page, get a result and use it in your action:

html anchorWithAction: [self setBackgroundColor: (self call: ColorPicker new)] text: 'Change background color'.

So hopefully from this, you can see that Seaside works sort of like a boring GUI toolkit. You design the screens and add callbacks to the controls. When the user clicks on a link or presses a button, the associated callback gets invoked.

This would be pretty simple for all concerned were it not for that pesky back button. In the final example, the callback first takes the user to another page (a ColorPicker component) and then, when the user selects "Okay" in that, returns the result and passes it to "setBackgroundColor:".

But what if the user hits the back key while in the ColorPicker? This happens right in the middle of the callback. Can Seaside unwind the entire callback?

Yes, it can. Backing out Just Works.

But, I hear you say, what if there's information I don't want unwound? Say, a shopping cart?

Simple. You can tell Seaside which objects don't change after a backout.

Aside from the back button, you also get access to your entire programming system in the framework so you can do some pretty powerful things in between those square brackets.

Also, the web server is part of the system so you can bypass the framework and do lower-level stuff. For example, I once wrote an image generator. It analyzed its URL, generated the appropriate GIF and returned it.

Plus, of course, it's written in Smalltalk which is the greatest programming language ever ;-).

Re:Seaside (1)

RevAaron (125240) | about 8 years ago | (#15673455)

If I had me mod points, I'd mod the above post even higher...

Right on, man!

I do Smalltalk when I can- I'm with you, it *is* the best language we have right now. I just started a job doing Java servlets and ... well, I miss Squeak and Seaside. I miss beign able to run the image on my local machine rather than the server, and sprinkle in inspectors, etc etc to trouble shoot problems. I feel like I'm working with a line editor like sed and assembler with Java, productivity-wise. Oh well! Maybe I'll convince them that the best thing to do is a rewrite in Smalltalk. :D

Re:Seaside (0)

Anonymous Coward | about 8 years ago | (#15680837)

Last I looked at Seaside, it was generating some uuuuuuugly urls. I mean, they looked like ASP.NET viewstates or something. And all I could see in Seaside docs was advocacy and disdain for the whole idea of "pretty urls", like we're just dainty little princesses that can't handle something that isn't pretty.

Well, my app does a lot of funny logic on url names, from caching to balancing (thank god security doesn't rely on it anymore), and /profile/bill/5381/amendment/3 is a whole damn lot more meaningful to third party code than ?x=Kjhkjh235iOY98kjhn24kj5hkljHiuy4398529ukjhkjh34 dfg. If I can't use something like routes for Seaside, it's useless to me.

Straw Man (3, Informative)

cyranoVR (518628) | about 8 years ago | (#15672616)

Geez - the "Trouble with JSP" article TFA references is over 6 years old(!). Java web development has come a long way since then! Just for starters, thinkg JSP with JSTL or Velocity templates plus your favorite MVC framework. Or how about Struts + Tiles? Saying that JSP is bad because of scriptlets is like saying...ASP.NET is bad because of VBScript.

Why continuations are useful for web programming. (2, Informative)

sdfad1 (880883) | about 8 years ago | (#15672941)

I don't pretend to grok continuations (that's what Seaside does I hear), but an article [cincomsmalltalk.com] I have found to be really illuminating explains this in quasi-Basic. The Basic-ish code in that example by the way, is written in what we call continuation passing scheme (CPS). That's basically the extra function tacked onto the argument list passed to functions [instead of f(arg1,arg2), we call f(arg1,arg2, c) where c is the continuation. f does not return as such, but calls c when it is ready to return. Instead of "return some_value;", we call "c(some_value)"].

Of course, continuations are not the solution to everything, but there's a lesson to learn from their usage.

CPS is often what functional programming languages compile into - no one writes code like that manually. You take a program, transform it into CPS, keep doing that, resubstituting variables names, expanding macros, and simplifying functions as necessary, until you are left with a couple of variables (-> registers), and a whole lot of assembler instructions - it has been compiled into assembly language. Now that's a nice compiler!

Actually... (0)

Anonymous Coward | about 8 years ago | (#15673804)

Continuations are the solution to everything. IIRC, all other control structures that have yet been invented can be implemented with continuations: Exceptions, coroutines, nondeterminism, you name it.

(Oh, and it's Continuation Passing Style. Not that it matters all that much.)

Re:Actually... (1)

sdfad1 (880883) | about 8 years ago | (#15675395)

Continuations can be used to build everything (don't know, maybe everything), but from what I've managed to gather, there are problems with continuations as they are used in Scheme at the moment (don't know about any other language).

I've been trying to read through and understand this [nhplace.com] , but haven't got far yet. Basic idea is I guess "how does a continuation escape from an unescapable unwind-protect?". Unwind-protect is like "finally" in Java, it has to run *always* - but continuations never return, so it's like when an immovable object meets an irresistable force.

Additionally, there's added issues with general error handling and other stuff - how can we do this efficiently and without getting in the way of the programmer - many of these issues are subjective, so what I meant was not the same thing you were thinking I guess.

Re:Actually... (1)

sdfad1 (880883) | about 8 years ago | (#15675517)

Err maybe not. I think my ignorance is beginning to show. The problem might be rather - continuations allow you to escape many times, but unwind-protect should only run once. So if you wrap some code with unwind-protect, it is a postlude to that code, and should run when you exit (either a normal exit, or by non-local ones like throwing exceptions) the wrapped code. Continuations inside that wrapped block of code can "continue" many times, so we have no way of knowing when we are done, so there's no straight answer to when we can run the postlude code. Whatever - if anyone's really interested, don't listen to me - do your own reading.

I prefer using Java for web apps, thank you. (2, Interesting)

master_p (608214) | about 8 years ago | (#15673745)

I prefer to use one environment for my apps. After all, the browser is a glorified 'window system' no different than X-Windows in concept...and the best toolkit for this job right now is Echo2.

Re:I prefer using Java for web apps, thank you. (1)

donniejones18 (749882) | about 8 years ago | (#15691048)

Thanks for the info on Echo2, I just looked at their demo apps and tutorial and...
Wow, I am impressed with Echo2. I'm not usually a fan of Java web-frameworks simply because my experience has been that they require the you to program in Java and then do the HTML and Javascript too, but Echo2 doesn't, very cool.

And, as for Web 2.0 and giving the web a true application feel, very few frameworks or sites actually accomplish that without tons of Javascript, however Echo2 really does without the developer doing all the Javascript... very, very nice.
Granted, it may take me longer to develop than say a site with Ruby on Rails, but if I really want the application feel, Echo2 does it quite well.

Thanks for the laugh (3, Interesting)

LizardKing (5245) | about 8 years ago | (#15674118)

Longstanding conventions inhibit Java programmers from using Java code within Web pages now.

That's because you don't want to mix business logic with presentation logic. Any "programmatic" logic you need for presentation can be accomplished with the JSTL, hence most people disable scriptlet support. Only novices would advocate placing code into templates. I shouldn't complain though, as I can rely on these novices fucking things up so much that I can always find work replacing their abominations with something scalable and maintainable.

seaside rehash of Weblogic htmlKona (1)

usidoesit (956958) | about 8 years ago | (#15681231)

generating HTML from within programming language was a bad idea. Even worse in an unreadable language like smalltalk. When are they going to let that horrible syntax die? I never bought that smalltalk was intuitive enough to be a "teaching language". IBM owns smalltalk now. ST useless.

I Welcome It! (1)

SethEaston (920552) | about 8 years ago | (#15693899)

I for one welcome this wholeheartedly, especially after my long-standing battle with JSF, with which I have found it very difficult to make even very simple things work, and that with a team of developers! It's enough to make me want to go back to Perl/CGI. It has been a thorn in my side for a year now and I am ready for something new. I realize that Java-related technologies have a steep learning curve, but this is ridiculous! Even if it takes me 6 more months to learn Ruby and Seaside, I'm up for the challenge, so at least I can use more than one damn form on a page.

I don't mean to vent about JSF, but this simply emphasizes the need to for new, easy-to-use, and reliable technologies; It also illustrates a failure in the industry - and I firmly believe that it is JSF.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...