Slashdot Mirror

← Back to Stories (view on slashdot.org)

Ruby on Rails 0.13 Out Today with AJAX Superpowers

Posted by timothy on from the buzzword-diesel dept.

Robert J. Berger writes "The Ruby on Rails team announced that "After the longest gap between releases since Rails was made public and after more than 225 fixes and new features, the final major release before the 1.0 milestone has arrived." This is a major update to what is to many developers consider the new tool for developing sophisticated interactive database driven web applications. It integrates backend Model/View/Controller object-oriented model with AJAX based clients so that the developer can focus on the app and not on the details of basic mechanisms. You really can do much more with much less coding. The new release adds a completely rewritten visual effects engine, drag-and-drop capability including sortable lists, and autocompleting text fields to Rails. All building on top of an upgraded version of Prototype, the javascript foundation for Ajax in Rails ... Check out the very cool demos at script.aculo.us."

79 comments

  1. This is actually really damned good by byolinux · · Score: 2, Interesting

    Those demos have really got me interested in seeing what I can do with this.

    Imagine a web enabled version of Delicious Library with this. Fuck, that's cool.

    --
    Join the Free Software Foundation
    1. Re:This is actually really damned good by eyeye · · Score: 1

      It is good but is there a (js) library that offers these functions so people can use it with their favourite language. I dont find much of use searching cpan for ajax.

      --
      Bush and Blair ate my sig!
    2. Re:This is actually really damned good by drakaan · · Score: 2, Informative
      AJAX isn't a language, it's a concept. Search for XMLHTTP on Google, instead of AJAX on CPAN.

      I've been XMLHTTP-ing a bunch of old ASP code (and made a cool cross-browser chat page), and thinking about moving a bunch of stuff to PHP. Now I might chuck it all and see if I can use Ruby instead. Scary simple.

      --
      "Murphy was an optimist" - O'Toole's commentary on Murphy's Law
    3. Re:This is actually really damned good by rheimbuch · · Score: 3, Informative

      Since all these effects are built on top of the Prototype javascript library, you can use them standalone or with any server side language. Just download the effects and the Prototype library (be sure to get the pre-release version) and you should be good to go. Nothing Ruby or Rails specific, but Rails does have some predefined helper functions to make it easier to use the AJAX effects.

      --
      -- I take full responsibility for the failure of the project do to my tendency to underestimate your incompetence.
    4. Re:This is actually really damned good by bsadler · · Score: 1

      There is actually a perl module called HTML::Prototype, and several modules Template::Plugin::Prototype? that exist to make RoR-like easyness available to certain templating engines. I am sure that many languages have similar modules/classes/libraries in the works.

      --
      Stupid sig of the week: Perl Hackers DIIMTOW
    5. Re:This is actually really damned good by eyeye · · Score: 1

      luckily some other respondents actually understood my post :-)

      --
      Bush and Blair ate my sig!
    6. Re:This is actually really damned good by drakaan · · Score: 1
      I guess you confused me because the article was about Ruby on Rails. I figured that given that, it must have been the non-Ruby part of the solution you were asking about using with [Perl].

      Sorry for the mix-up.

      --
      "Murphy was an optimist" - O'Toole's commentary on Murphy's Law
  2. Re:ad by GnuVince · · Score: 0

    10$ says somebody asks what Ruby on Rails.

  3. Re:ad by chris_mahan · · Score: 0, Troll

    In Soviet Ru... What's Ruby on Rails?

    Oh, in Japan!!!

    hehe

    --

    "Piter, too, is dead."

  4. This is fantastic stuff! by Per+Wigren · · Score: 4, Interesting

    I've been playing with Rails since september and I've run edge rails (subversion trunk) for about a month while developing my soon-to-be-released rewrite of my site that uses a lot of this Ajax stuff in a user friendly way.

    Users can sort the pictures in their galleries by dragging them to the position they want and doubleclick them to hide them (it then becomes 50% transparent). The user always get immediate feedback without reloading the page thanks to Ajax. For translators the site is inline editable. Just doubleclick on a textfield or alt+click on a string to edit it inline. Click "save" and it's changed. Admin stuff is always available but hidden by default in drawers that you can slide in when you need them so you can be logged in as an admin an change any setting, delete posts etc without needing to go to a separate admin page or have a cluttered interface. You don't even have to reload the page in most cases...

    All this stuff is damn easy to implement thanks to the wonders of Ruby on Rails and the Prototype framework.

    --
    My other account has a 3-digit UID.
    1. Re:This is fantastic stuff! by drakaan · · Score: 1
      For translators the site is inline editable. Just doubleclick on a textfield or alt+click on a string to edit it inline.

      I can't believe I didn't think of that before you just mentioned it...did you roll your own, or find a decent example? I did that once before for some old pages that had a lot of updates, but without the benefit of AJAX-type technology.

      Care to share some code with the rest of us?

      --
      "Murphy was an optimist" - O'Toole's commentary on Murphy's Law
    2. Re:This is fantastic stuff! by Anonymous Coward · · Score: 0

      Is your project open source? What are the good open source rails image galleries? I'd love to be a beta tester! I only speak English, unfortunately.

    3. Re:This is fantastic stuff! by Per+Wigren · · Score: 3, Interesting

      I'm in the middle of rewriting that part but here is the logic:

      Make sure textfields are inside a <div class="editable" id="text_id"> and wrap strings in <span class="editable" id="string_id"> where text_id/string_id is the id of the text/string in the database.

      Create a Javascript behaviour that finds all nodes that has class "editable". Prototype comes with the function getElementsByClassName().
      On each div, add a ondblclick event that:
      * creates a textarea node and put it inside the div.
      * hide the old content
      * set value of the textarea to the text content
      * add a submit button that has onclick = "new Ajax(foo);" where foo is the parameters for your ajax call and set it to update the current editable div (so the textarea will be overwritten)
      * the action for the Ajax call should return the output of the saved text.

      do the same for strings but use a input type="text" instead.

      --
      My other account has a 3-digit UID.
    4. Re:This is fantastic stuff! by JimDabell · · Score: 1

      That's not degradable.

      A better solution would be to start with a page that has an "edit" button that works without Javascript. Then have your Javascript check to make sure the AJAX stuff is available, and makes the visibility of the edit button hidden (while keeping a rule that unhides it on :focus for keyboard users).

      Finding all the .editable elements in your onload handler or at the bottom of the page is bad practice as well. On a slow connection or when you have slow-loading ads, the user could be double-clicking like mad with nothing happening. Use actual ondblclick attributes on each element. It's more code, but doesn't break when the timing isn't perfect.

      Doing AJAX badly is easy. Doing AJAX well requires a bit more thought if you want it to work reliably.

  5. solaris/firefox 1.04 by Endymion · · Score: 4, Insightful

    wow... I really want to try this... I love the idea of ruby on rails, but all of this client side code is nuts.

    Of all the samples, only the shoping cart works at all on Firefox1.04 on solaris. Everything else just does nothing and renders horribly. Even the shoping cart demo fails to render things properly, even when it works.

    sigh...

    I really really really want to like this... but how is relying on the client to run code properly sane, with all the different clients out there?

    --
    Ce n'est pas une signature automatique.
    1. Re:solaris/firefox 1.04 by heinousjay · · Score: 0, Troll

      I guess both of you running solaris will have to suffer.

      --
      Slashdot - where whining about luck is the new way to make the world you want.
    2. Re:solaris/firefox 1.04 by Endymion · · Score: 1

      what, like my entire lab?

      and the point isn't just solaris. Using heavyweight client side code like this is great for eyecandy-type features, but it's extreemly inconsistent in it's implementation.

      have they validated that this works on Opera, Safari, other strange platforms, etc etc? I don't mean it has to support all of the cool new features - it should degrade nicely, not "click, do nothing besides render badly".

      --
      Ce n'est pas une signature automatique.
    3. Re:solaris/firefox 1.04 by Anonymous Coward · · Score: 0

      Jesus, people get so touchy over things like this. It was a wiseass joke.

    4. Re:solaris/firefox 1.04 by interiot · · Score: 1
      I really really really want to like this... but how is relying on the client to run code properly sane, with all the different clients out there?
      1. Google is doing it (eg. gmail, maps), and that's good enough for me!
      2. Browsers are following the javascript/DOM specs much more these days (except for MSIE, of course)
      As far as Firefox-on-Solaris goes... there's no reason it shouldn't work there, is there? I don't know Ruby-on-Rails specifically, but Firefox/Solaris shouldn't be any different from Firefox/Windows as far as AJAX goes, right?
    5. Re:solaris/firefox 1.04 by drakaan · · Score: 1

      Works well in Firefox and IE on Windows and in Firefox on Linux. Dunno about Safari, but it should work as well there as on Linux. Seems pretty widely usable to me. Maybe complain to Firefox about brokenness on Solaris?

      --
      "Murphy was an optimist" - O'Toole's commentary on Murphy's Law
    6. Re:solaris/firefox 1.04 by jimrthy · · Score: 1
      I really really really want to like this... but how is relying on the client to run code properly sane, with all the different clients out there?

      I'm pretty much with you here. gmail doesn't rely on the client handling anything properly. They have a straight html version (which I keep meaning to check out through lynx. There just aren't enough hours in the day. Anyone played with that?)

      Anyway, this sort of thing's really exciting. In a lot of ways, I've never much liked writing GUI stuff. Developing for the web takes away most of that worry.

      I've been avoiding ruby up to now, but I guess I'm going to have to look into it. *Sigh.* It's time to start my annual "learn a new language" anyway.

    7. Re:solaris/firefox 1.04 by Endymion · · Score: 1

      The thing is, maps.google.com works great here, and the ruby-on-rails stuff didn't. badly.

      maybe google is only using a "safe subset" of features?

      Yah, firefox should be the same everywhere, I'd think, but it's not apparently.

      When I drag item in the shoping cart, I don't get a picture of the drag, just the basic mouse pointer. When I try the auto-complete, nothing happens at all.

      I'll have to try it on Firefox/Linux when I get home...

      --
      Ce n'est pas une signature automatique.
    8. Re:solaris/firefox 1.04 by Endymion · · Score: 1

      yah, maybe. if I can narrow it down more to what the problem is, I may file a bug report.

      I still don't trust heavyweight client stuff, though.

      At least with java-applets (shudder) it should work on any browser with a JVM.

      --
      Ce n'est pas une signature automatique.
    9. Re:solaris/firefox 1.04 by Anonymous Coward · · Score: 0

      Google is doing it (eg. gmail, maps), and that's good enough for me!

      Do you have Google's resources to fix any problems that might crop up? Do you have Google's legal department to deal with lawsuits from its inaccessibility? People have been successfully sued for this stuff for years. Do you have Google's market share to demand compatibility from browser developers?

      Google can get away with a lot of stuff simply because they are massive. Unless you have similar resources to Google, "good enough for Google" is a moronic approach to take.

    10. Re:solaris/firefox 1.04 by thomas.galvin · · Score: 3, Insightful

      Of all the samples, only the shoping cart works at all on Firefox1.04 on solaris. Everything else just does nothing and renders horribly. Even the shoping cart demo fails to render things properly, even when it works.

      I'm running Firefox 1.0 on Solaris, and they all worked fine, albeit a bit slowly. I'm not sure what you're seeing. Perhaps one of your extensions is borking something? If your filtering .js files via adblock, for example, things would go very wrong, very quickly.

      --
      Thomas Galvin
    11. Re:solaris/firefox 1.04 by Endymion · · Score: 1

      hmm... that's a good idea. I'm not filtering js, though. images and iframes from quite a few well known hosts, yes...

      I'm more and more confused about this the more I look at it. Perhaps it is something borked up with my solaris install? This would not exactly be a revalation.

      that just lends evidence to my theory that using heavyweight client side code is too fragile. if it breaks that easily, why trust it?

      --
      Ce n'est pas une signature automatique.
    12. Re:solaris/firefox 1.04 by Paradox · · Score: 1

      Just another person saying that it seems to work okay on Solaris. Methinks it's your install.

      And Mac OS X Safari/Firefox, Windows IE6 (although the transparency is glitchy, of course), and Linux Firefox & Mozilla.

      --
      Slashdot. It's Not For Common Sense
  6. Nah. by abulafia · · Score: 1

    Someone's going to rail on Ruby. Hey, it was me last time.

    --
    I forget what 8 was for.
  7. Here's why... by Saeed+al-Sahaf · · Score: 2, Insightful

    Because Ruby on Rails is the "bleeding edge" half baked trendy geek masturbation language / platform de jour. Sort of like tapas and sushi, except sushi is now passé (unless you eat it off the belly of a super midel).

    --
    "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
    1. Re:Here's why... by GnuVince · · Score: 1, Offtopic

      Is the new cool trend to use a bunch of french words in an english sentence to look smarter?

    2. Re:Here's why... by mbrewthx · · Score: 1

      Les phrases fraincaises paret plus intelligentes avec les mots englaises.

      --
      __________ Leave me alone I'm compiling a RPG II program on my S/36...Thanks to metamucil I'm a Regular Meta Moderator
    3. Re:Here's why... by Anonymous Coward · · Score: 0
      Is the new cool trend to use a bunch of french words in an english sentence to look smarter?

      Nothing new about it. Pretty common actually. Now go fuck off.

    4. Re:Here's why... by Anonymous Coward · · Score: 0

      Vachier calice de gros cave

    5. Re:Here's why... by Paradox · · Score: 2, Insightful
      half baked trendy geek masturbation language
      Ruby? Half-baked? Ruby hasn't been around as long as Python, but it's not exactly the flavor of the month. And have you seen the people backing Ruby? The authors of those books are not amateurs.

      And since when is a language wich such an excellent spread of features a "masturbation language"? Closures, a powerful standard library, continuations, open classes, everything-is-an-object... I could go on. These aren't "bleeding edge" features. These are features found in languages like Lisp, Scheme and Smalltalk that big players like Java ignored because it was "too complex" for the "average coder."

      In other words, languages like Ruby and Python are state of the art. It's Java and PHP that are behind.

      --
      Slashdot. It's Not For Common Sense
    6. Re:Here's why... by Saeed+al-Sahaf · · Score: 1
      everything-is-an-object...

      Don't you think that with the exception of GUI design, OOP is a little OVERRATED?

      --
      "Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
    7. Re:Here's why... by Paradox · · Score: 1
      Don't you think that with the exception of GUI design, OOP is a little OVERRATED?
      Not for data types. The fact that I can ask my integers what precision they are, or define new string routines, or conveniently redefine how my IO sockets is a good idea.

      Besides, who says OO excludes functional paradigms? Not OCaml or Common Lisp, that's for sure.

      Besides, Ruby isn't about pure object modeling. Because of all its very functional features (Did you know Ruby has no "statements", only expressions? Everything returns a value!) it gets the best of both worlds frequently. In this, it resembles the very functional Common Lisp, which was very OO.

      The fact you can even make such a statement about Ruby shows how little you know about the language. Do you really think you're qualified, even on /., to talk about it like you know what the hell you're going on about? Have you actually tried using it? Tried using Rails? Face it, we're past the flavor-of-the-month hype stage here. It's now a real deal and it's not going anywhere except towards "better."

      --
      Slashdot. It's Not For Common Sense
    8. Re:Here's why... by uedauhes · · Score: 1

      OO Overrated lol ... Pure ruby/rails beauty: 3.weeks.from_now or how about: 5.times do |time| puts "I love OO #{time} times" end

  8. future of the web? by file+cabinet · · Score: 1

    my personal opinion is that the future of the web is ruby on rails + JS + postgresql.

    why? RoR is a framework (unlike php, for example). postgres has more features then the more common mysql. JS improves usability.

    1. Re:future of the web? by int19h · · Score: 0

      I respect your opinion, but your reasons are totally disconnected from your statement.

      Neither "it's a framework", "has more features" or "improves usability" are reasons for why it should be the future of the web.

      When that's all said and done, here's what I know about the issue:
      - There are several alternative frameworks out there (Zope, Plone and Tomcat/Struts are three examples)
      - More features are seldom the answer to anything
      - JS might improve usability in a few cases, but more often, I've seen it ruin whatever usability was left of a webpage

      I'm sure RoR will be part of the future of the web (it already is, to some limited extent), but I can't imagine it playing a vital role.

      That's my personal opinion. :-)

    2. Re:future of the web? by germ!nation · · Score: 1

      anything involving lots of javascript will only be the future of the user Internet.

      The corporate Internet will wonder whether instant feedback when people have been used to non-instant feedback for years on the net already will be worth having to develop and test 2x the funcationality (with + without javascript) to avoid being the test case in 508/DDA discrimination lawsuits.

  9. Crappy Autocompletion by Anonymous Coward · · Score: 0

    Is it just me or do those autocompletion demos kinda suck.
    When I type in "An" to get to the name Andrew, it doesn't show up on the list of entries, let alone the top entry where it should be. There is only one name that starts with "An".....

    1. Re:Crappy Autocompletion by jericho4.0 · · Score: 1

      It's still not quite my idea of autocompletion, and the code uses "text_field_with_auto_complete", seemingly a primitive.

      --
      "A language that doesn't affect the way you think about programming, is not worth knowing" - Alan Perlis
    2. Re:Crappy Autocompletion by Anonymous Coward · · Score: 0

      err.. it's a composite.
      i have no idea what you could have meant by calling it a primitive. it's syntax sugar.
      and if you look closer at the example, it renders to just an input tag, with an associated div and script tag. you can control a ton of the input/div/script params by passing them in a hash or a block.
      so uhh.. pray tell, what *is* your idea of autocompletion?
      it can *quite* easily be changed to be inline completion as well, and update on every keypress.. it just doesn't seem to be as usable. /shrug

  10. The AJAX doesn't run in Opera... by davegaramond · · Score: 1

    Damn, and just when I thought I'd switch to Opera due to its built-in Bittorrent client...

    1. Re:The AJAX doesn't run in Opera... by ZosX · · Score: 1

      I don't know if this was supposed to be a joke, but why on earth would anyone use a bittorrent client embedded in their browser when their is Azureus?

      --
      zosxavius photography
    2. Re:The AJAX doesn't run in Opera... by G-Licious! · · Score: 1

      Some people wonder why anyone would use Azureus.

      Either way, one of the goals of bittorrent was to make downloading as natural as possible to the user. You click a .torrent link, bittorrent reads the .torrent metafile and connects to the tracker and peers to start downloading. But to the user, it looks almost like a regular download dialog.

      Opera goes one step further by integrating a bittorrent into the browser, eliminating the need for a client, and simply bringing bittorrent one step closer to being a regular download method. Or something like that.

    3. Re:The AJAX doesn't run in Opera... by Anonymous Coward · · Score: 0

      "their is Azureus"

      there is Azureus... THERE!

  11. Retraction: Crappy Autocompletion by Anonymous Coward · · Score: 0

    Oops, it is doing a full text search, not a prefix search... my bad

  12. Demos by mattwarden · · Score: 3, Insightful

    Great. AJAX shopping carts. Will no one learn from the usability problems people found using Flash for such things?

    AJAX is great... for applications where the state is not particularly important (i.e., enough to be bookmarked). A product catalog and shopping cart is not one of this type.

    1. Re:Demos by Anonymous Coward · · Score: 0

      look, i understand, REST is awesome. seriously, it is.
      but c'mon now, step back for a second.. i know i'm mixing metaphors, and we can do new k-rad things in this Brave New World.. but when was the last time someone put a bunch of crap in a shopping cart in Wal-Mart, went home and forgot about it for a week, and then came back and *expected* their crap to still be there?
      yeah.. bookmarking shopping carts is super important.
      start with the set of all carts.
      remove those which don't require you to be logged in in the first place, (for which you can store carts ad infinitum on the server)
      now remove those carts that are going to change their contents *significantly* over a 2nd journey.
      now, to the set of all remaining carts, add a 'Bookmark this cart' button that hey, serializes their cart contents and runs it through the ruby tinyurl lib.. presto!
      the problem is not dhtml/flash/java carts, the problem is a) people who complain for no real reason and b) developers who use dhtml and friends without understanding REST.

    2. Re:Demos by mykdavies · · Score: 1

      Nicely put; I just wish I had mod points.

      --
      The world has changed and we all have become metal men.
    3. Re:Demos by JimDabell · · Score: 1

      AJAX is great... for applications where the state is not particularly important (i.e., enough to be bookmarked). A product catalog and shopping cart is not one of this type.

      What are you talking about? You can use AJAX for a product catalogue and shopping cart easily without breaking things.

      What matters is that important entry points should be addressable by URI. When somebody adds something to their shopping cart, it doesn't matter that immediately following the action, the resulting view isn't addressable, because the shopping cart state is part of the session, not simply the page that is being addressed.

      Look at any halfway decent shopping cart system - when you have something in your shopping cart, that's indicated on every page on the website. You don't need to be able to address the shopping cart directly, because the last page the user was on will include this information no matter where they were in the site. And, because it's part of the session and not any particular page, that information will always be up to date - you don't need to keep giving them a new URI every time you update the cart.

    4. Re:Demos by mattwarden · · Score: 1

      I'm talking about being able to bookmark parts of the product catalog. I am not talking about saving one's shopping cart.

    5. Re:Demos by mattwarden · · Score: 1
      What are you talking about? You can use AJAX for a product catalogue and shopping cart easily without breaking things.

      Show me an implementation of an AJAX product catalog that doesn't suffer from severe usability problems. Backbase is a perfect example of why this is not a good idea: http://projects.backbase.com/RUI/shop.html

    6. Re:Demos by ceejayoz · · Score: 1

      Depends on how many products you have.

      This shopping cart, for example, works just fine without being able to bookmark individual product pages.

      Sure, if I were Amazon.com with millions of products there'd be problems with a single page catalog, but most small e-businesses don't need a huge shopping cart.

    7. Re:Demos by JimDabell · · Score: 1

      Show me an implementation of an AJAX product catalog that doesn't suffer from severe usability problems.

      Well AJAX is only recently gaining mindshare amongst developers, so there's not many examples of it out in the wild.

      In any case, I can't think of a single product catalogue, with or without AJAX, that doesn't have usability problems.

      Backbase is a perfect example of why this is not a good idea

      No, that's a perfect example of a terrible use of AJAX. It's also a perfect example of a terrible use of Javascript. Does that mean all Javascript is bad? It's also a perfect example of a terrible website. Does that mean all websites are bad?

      Really, there is nothing intrinsically bad about AJAX that means you can't use it for stateful applications. In fact, there are many opportunities to increase usability by using AJAX. Pointing out an example of somebody misusing AJAX doesn't change this fact.

      As I said before, the important thing is to retain addressability. When somebody adds something to their shopping cart, there is no need to change the URI.

    8. Re:Demos by Anonymous Coward · · Score: 0
      This shopping cart, for example, works just fine

      Uh, no it doesn't.... I tried adding a large number of shirts, and clearing them all; and nowevery shirt I add is invisible.

      With non-ajax HTML at least I get what I want.

  13. Well... by SirJorgelOfBorgel · · Score: 1

    I've been in software development for years. Until very recently, I only did desktop applications and didn't have to bother with web stuff, apart from fooling around a little with Delphi's [AToZed's] IntraWeb and writing the HTTP compression code for it. Now I'm back working for a company that does all sorts of webrelated stuff. I haven't been doing this since HTML 2.0! Ofcourse: we start with PHP and MySQL, sometimes replacing MySQL with MSSQL and very rarely writing CGI/ISAPI/DSO in my language of choice if a dedicated server is warranted. Since then, I've been looking for ways to improve. ActiveX's never even been alive, Flash is pure evil. XMLHTTP seemed like a revelation to me. But getting all your stuff to work together properly, is a real bitch (excuse me). By now I've written a decent framework using PHP, Smarty, XMLHTTP and JavaScript (doing things they're not meant to all the way) which is really very MVC . But it just isn't nearly desktop programming. So my question is, to you, the experienced (or well, it is fairly new) RoR/AJAX users: Is this what I'm waiting for? Will this drastically improve development time? Or is it just FuD like all the other 'promising' stuff we've seen? Because IMHO, investing lots of time in stuff like JavaScript validation (etc), simply wont beat the costs for just buying a big server with a fat pipe that'll give users fast responsiveness in a more brute way. I'm not interested in shopping carts and drag and drop. Our customers have specific needs usually not for the 'home user'. They don't really care about eye-candy or technology. The people using it know what they're doing. They want it to work, work properly and work fast.

    1. Re:Well... by Anonymous Coward · · Score: 0

      seriously, AJAX is about the lamest part of RoR.
      and it still rocks.
      but regardless, sometimes, even given "They want it to work, work properly and work fast", the quickest more proper way, is to allow the user to visually drag and drop crap.
      but the real benefit is the significantly quicker design/test/deploy cycle, which will let you add whatever else these serious ;) people need faster than most other frameworks.

      (i do take slight offense at the seeming opposition you've set up between liking eye-candy and knowing what you're doing... the visual/tactile metaphor can be super efficient in certain contexts, and *everyone* to *some* degree at least, would rather use a pretty, engaging interface than your standard html schlocky buttons and same 3 fonts they see everywhere else.
      Engaging people's attention, and catering to their mood ups productivity, period.

    2. Re:Well... by white1827 · · Score: 1

      In my opinion, AJAX has some compelling uses, but for most web application work, it adds a lot of extra complexity and points of failure with little end user return. Ruby on Rails on other hand, will probably be the next PHP. It greatly speeds prototype development on and into live production. It also has built in unit testing and lots of other compelling features. Run through the first Ruby Tutorial here. It will change your thinking on creating web apps forever.

    3. Re:Well... by SirJorgelOfBorgel · · Score: 1

      Ofcourse, you are correct in what you're saying. It just doesn't apply to our situation :)

      The quicker design/test/deploy cycle, if true, would be a GoodThing(tm) and I can clearly see it's benefits.

      Drag and drop is often just not very practical at all. I could state numerous examples why it isn't useful for (internally used) webapps but I'm not writing an essay here. Furthermore, you have misunderstood me if you think I mean that eye-candy is for people who do not know what they're doing. If people know what they're doing in the whole process (not in the webapp itself), they'll usually know identification codes for everything and don't need big pretty lists or drag-and-drop functionality. Ofcourse I'm beating up on drag-and-drop here, but the same thing stands for several candy items

      Now if you're talking external webapps (unleashed on the internet or another large network with people who don't know exactly what they want, with which records ID) THEN things become entirely different ofcourse.

  14. Impressive, but... by RAMMS+EIN · · Score: 0, Troll

    Wow, these demos are really impressive indeed. Not that they are doing anything that couldn't have been done with Internet Explorer 4, but how little Ruby code is required to make it all work.

    That said, this technology is full of problems by its nature. Browser support is no longer the issue it once was (especially if the framework takes care of the remaining differences for you), but many browsers do DHTML very slowly, and more often than not it just doesn't have the right feel to it (as in, it still looks like a static page with moving parts, rather than a truely interactive application). And, one of my pet peeves, communicating with the server after the page has been loaded is clumsy and inefficient at best.

    What I feel the world needs for the next phase of web development is a standard (especially portable) way to define real native applications. I once quickly whipped up something that parsed a UI in XML format, then used GTK to render it. GTK could easily be replaced by Cocoa or Win32 here. Pair this with some kind of scripting language (I think Ruby would be a good choice), and you can write native applications in a light-weight and portable way. Native UI, filesystem interaction, networking, it's all there.

    From there, only some integration with the web is called for (at least, I think that would be a Good Thing). Something along the lines of allowing these applications to be embedded in XHTML, and sandbox them (limit filesystem access to a single, dedicated directory, limit disk space usage, etc.)

    The only real problem I can see is that this adds Yet Another Standard That Isn't. It will only fly if it is widely supported, and that won't happen until it gains enough momentum. Seeing what happened to Java applets, Flash, early DHTML attempts, and the popularity of XUL, I am tempted to conclude that people just don't want all that. Just the text, please. Well, I can sympathize with that, too.

    --
    Please correct me if I got my facts wrong.
    1. Re:Impressive, but... by ltmon · · Score: 1

      > And, one of my pet peeves, communicating with the server after the page has been loaded is clumsy and inefficient at best. I think this is what's being addressed. It really is pretty easy with Rails.

    2. Re:Impressive, but... by RAMMS+EIN · · Score: 2, Insightful

      I'm pretty sure Rails can't address the issue of client-server communication. It just can't be done with current browser technology. The only way browsers communicate with servers is through HTTP requests. This means that, even if you only want to send a single word, you need a full HTTP request, and you will get a response, which the browser will try to display or otherwise process.

      Sending data from the server to the client is completely impossible, unless you somehow keep your request from completing, which most browsers don't like.

      Something as simple as an IRC client is impossible to write for web browsers, because of these limitations. Probably the closest you can get is a form for submitting new messages, and a reloading page that displays the last few messages. This means a new connection, HTTP request, and response (which will give you the same form you just submitted) for every message you send. For the refreshes, you have a trade-off between update speed and wasted resources. Everything about it is hopelessly inefficient.

      Rails is not going to be able to fix these issues. It's just inherent in the way browsers work. All it can do is make the generation of content on the server sied easier. At that, it does a very good job. My only concern is performance; Ruby is pretty slow at the moment, and I'm not sure if I would develop a dynamic site with a great number of visitors with it. I'm guessing it wouldn't be a problem, but I'd measure it first.

      --
      Please correct me if I got my facts wrong.
    3. Re:Impressive, but... by ltmon · · Score: 1

      Oh, I thought the original issue was that asynch XMLHttpRequest was hard. Yes the pull-only issue of http sucks for programming apps. But this kind of thing with timed javascript events can help alot until something better comes along.

    4. Re:Impressive, but... by goynang · · Score: 1

      You are aware of XMLHTTPRequest yeah?

      Whist it's not perfect and support does vary it solves the problem you mention. Javascript makes the request and handles the response so there is no need to do a full page refresh just to get one word back to stick in the middle of the page (or whatever).

      You probably could write an IRC client using this technique (not saying you should, just could). It would need to poll the server every n seconds or something to check for updates and then grab the lastest comments if there are some and append them to the current list. It could do that behind the scenes without a full page refresh each time. Not ideal but not impossible either.

    5. Re:Impressive, but... by Fweeky · · Score: 3, Interesting

      "Ruby is pretty slow at the moment"

      Actually, Ruby's quite speedy. It's not the fastest of dynamic languages, but it's certainly on par with PHP/Python in most areas that count. Where it's not, well, that's where the incredibly easy C extension stuff comes in.

    6. Re:Impressive, but... by IpalindromeI · · Score: 1

      You're not understanding him. In fact, you're offering up as solutions the very problems he's pointing out. You may think that XMLHTTPRequest is some magical tech that can communicate with the server telepathically, but it's not.

      Javascript makes the request and handles the response so there is no need to do a full page refresh just to get one word back to stick in the middle of the page (or whatever).

      That's the problem. The Javascript is making full HTTP requests to fetch one word. Why do you think it's called XMLHTTPRequest.

      --

      --
      Promoting critical thinking since 1994.
    7. Re:Impressive, but... by goynang · · Score: 1

      Fair enough, I (vastly) overstated it when I said that XMLHTTPRequest 'solved' it and I do understand the point he made.

      I guess I was trying to point out that whilst stuff like XMLHTTPRequest isn't perfect it can be used to good effect in certain situations. All is not completely lost.

    8. Re:Impressive, but... by sonamchauhan · · Score: 1

      > You're not understanding him.

      Are you sure? 'RAMMS+EIN' didn't mention anything to do with AJAX (as far as I can see) but said:
      "Probably the closest you can get is a form for submitting new messages, and a reloading page that displays the last few messages"

      Looks like 'goynang' is right to update 'RAMMS+EIN' about AJAX.

  15. My Kinda Software by DavidLeeRoth · · Score: 0, Redundant

    I wouldnt use this because I only use software with super cow powers. ...."Have you mooed today?"...

  16. Semi-OT: Catalyst is the Perl equivalent by egghat · · Score: 1, Interesting

    Check it out, it's based on Maypole, but now forked off and is under heavy and fast development.

    There's a short introductory article on perl.com. I quote one paragraph from this article, that gives a good overview on Catalyst:

    Catalyst is a new MVC framework for Perl. It is currently under rapid development, but the core API is now stable, and a growing number of projects use it. Catalyst borrows from other frameworks, such as Ruby on Rails and Apache Struts, but its main goal is to be a flexible, powerful, and fast framework for developing any type of web project in Perl. [...]

    It's semi-OT cause it supports AJAX and uses Prototype as its Javascript library.

    Bye egghat.

    --
    -- "As a human being I claim the right to be widely inconsistent", John Peel
  17. Shopping Cart UI suggestion by tom75646437 · · Score: 1

    After you've drag and dropped into the cart, the image should disappear and reappear rather than sliding. The current sliding back animation makes it look like the computer has refused your instruction.

  18. Right For Some by bassburner · · Score: 1

    Ruby On Rails is to Web Development as Modular Homes are to Home Construction. Personally, I'd rather not live in a trailer park no matter how fast I can move in.

  19. Java Web Start or wxWidgets by sorbits · · Score: 1

    Sounds like you want either Java Web Start or wxWidgets.

    As for your statement: "GTK could easily be replaced by Cocoa or Win32 here". It makes me think you have never used more than one GUI framework, or tried a Java, Qt, Python (using e.g. wxWidgets) application etc. on OS X.

    Native look'n'feel is only achieved by writing the application for the actual platform (often using platform frameworks, or replicating 99% of their functionality), since there are so many differences, and you can't address it by designing a cross-platform framework, it has been tried again and again.

    The browser (HTML/DOM/CSS) actually is the best cross-platform framework.

    1. Re:Java Web Start or wxWidgets by RAMMS+EIN · · Score: 1

      I don't completely agree with you there. Native look and feel, IMO, is the combination of using the right (native) widgets, and following the conventions of the system (with respect to positioning and such).

      Using the native widgets is easy enough for a cross-platform framework like the one I proposed. Of course, you do have to write an implementation for each widget toolkit, but you can start by making a portable non-native one (a la wxUniversal) as a proof of concept first.

      Getting the positioning and naming and such right only matters in cases where there are conventions for it. This is mostly a matter of using the same common dialogs that other applications use. Beyond the common dialogs, every program will do its own thing anyway, and more likely than not will break guidelines here and there. As long as you make your framework high-level enough (ideally, don't require users to specify what goes where), you can get pretty satisfactory results.

      Of course, it will never fit in with the desktop as well as an application designed by platform experts using native tools. However, it will be a whole lot better than your average web page, or even Java program. Plus, my point wasn't so much that applications developed using the framework will be indistinguishable from native ones in look and feel, but more in terms of performance and flexibility.

      The Web still presents a very limited interface, and limited options for what programs can do. That's what I really want to address. Java applets go a long way in solving that, but they have other problems which I won't discuss in this post, because I get modded down every time I do.

      --
      Please correct me if I got my facts wrong.
  20. FUD = Fear, Uncertainty, & Doubt by sorbits · · Score: 1

    Will this drastically improve development time? Or is it just FuD like all the other 'promising' stuff we've seen?

    FUD is spreading fear, uncertainty, and doubt about your competitors product.

    Maybe RoR spreads FUD about J2EE, but a product itself cannot be FUD...

  21. Prototype library copyright/license by mgkimsal2 · · Score: 1

    I don't see that the prototype javascript library has been released under any specific license - there's only a copyright to Sam Stephenson in there. Is it licensed differently based on if you use it in RoR apps or using standalone? While it seems that this library could provide a great cross-language platform to build javascript UI libraries with, without licensing info it's rather dead in the water, no?

    --
    creation science book