Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

COWS Ajax - Ajax Evolved

Posted by kdawson on Mon Sep 04, 2006 03:35 PM
from the cows-2.0 dept.
Programming IT Technology
nuttzy writes, "COWS Ajax takes over where Ajax leaves off. The web has gone through a great period of experimentation and there is now a dizzying array of frameworks, add-ons, howtos, and books. The common drawback these Ajax aids all fail to overcome is that, even with aids, apps take a long time to create and debug. Many times someone has already created a great tool and you'd really just rather use theirs instead of reinventing it (especially if it's a Google, Yahoo, or other trusted player). Wouldn't it be great to drop in a single line of code to gain a huge amount of functionality that frees you for something else? You can't do that with Ajax, but you can with COWS (Changeable Origin Web Services) Ajax. Now highly interactive third party services like SpellingCow are possible."
+ -
story
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

COWS Ajax - Ajax Evolved 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.
  • Now the web will really mooooove forwards!

  • COWS Ajax (Score:5, Funny)

    by eclectro (227083) on Monday September 04 2006, @03:41PM (#16039642)

    Sounds good. Developers should milk it for all its worth.
    • I think I'll moove my site over to this before I get "sent to the pasture" by my boss.

    • A new technology which allows developers to just pull together complete applications from pre-fabricated blocks. Where have I heard this before a million times? Can't remember, because all those others stopped being relevant years ago. Why would this be any different?

  • Not a developer (Score:5, Insightful)

    by Lispy (136512) on Monday September 04 2006, @03:42PM (#16039645) Homepage
    But if a dev in my team would ask this to implement I would ask a few questions:
    - Does it work if the embedded page is offline?
    - Does it slow down if the embedded page is under heavy load from somebody else?
    - Does it break if some standard/lib/implementation/EULA changes?
    - Can we customize it to our GUI?
    - In the example given, how does it play with browserspellcheckers like the one coming in FF2.0?
    - Why are we paying you if all you do is reuse thirdparty code wich doesnt belong to the company?

    You get the idea. Not saying its a bad idea but I have my concerns and so would a lot of managers/devs. At least the ones I have the pleasure to work with.

    • Re:Not a developer (Score:5, Insightful)

      by Directrix1 (157787) on Monday September 04 2006, @03:49PM (#16039677)
      - Why are we paying you if all you do is reuse thirdparty code wich doesnt belong to the company?

      You ever heard of libraries? Sheesh, you should pay the man more if he found a way to increase productivity for next to nothing.
      • I understand the concept. But companies are kinda greedy when it gets to owning their proprietary stuff. Well, at least thats what its like in the company I work for.
      • Indeed, I loooove having a 200K javascript .js file download when I am browsing some site on a slow connection, especially when 199K of that file is just library code that the parent website does not even use, but they wanted one strange obscure function and didnt bother hacking apart the full library.
        • What are these "slow connections" of which you speak?

          • Re: (Score:2, Funny)

            by Anonymous Coward
            What are these "slow connections" of which you speak?

            The ones in Alaska. They're still stuck on old tube technology, while the rest of us have dump trucks.

    • Re:Not a developer (Score:4, Insightful)

      by Anthony Boyd (242971) on Tuesday September 05 2006, @12:43AM (#16042296) Homepage

      Wow. That last question of yours would make some developers -- the best ones -- walk away from the job.

      Does it work if the embedded page is offline?

      It's more like a remotely-hosted library. And no, the page would likely NOT work if that other server was down. A good developer could probably add some code to check the remote site and disable certain features on-the-fly if needed. I've done that for a lot of Salesforce stuff I do. Not too awful.


      Does it slow down if the embedded page is under heavy load from somebody else?

      Seems like it would.


      Does it break if some standard/lib/implementation/EULA changes?

      Not sure, because I don't know what you're referring to. Do you mean, what happens if you change a library on your own server? Probably shouldn't hurt -- it's all client-side JavaScript. If you mean, what happens if the site that hosts the JavaScript code changes a license or how a library works, then yes, that could likely screw you up.


      Can we customize it to our GUI?

      Looks like a qualified yes.


      In the example given, how does it play with browserspellcheckers like the one coming in FF2.0?

      It's not aware of the spellchecker in Firefox 2.0. But neither are any of the other spelling tools. This spelling tool works live on the text, and if you had Firefox 2.0 spellchecking it also, you'd simply have 2 tools running spellchecks. That could make for some interesting interface weirdness, but I doubt it would hurt anything.


      Why are we paying you if all you do is reuse thirdparty code wich doesnt belong to the company?

      That question is so completely insulting to a developer -- it so trivializes their attempt to do something smart and useful for you -- that if you asked that question, developer morale would immediately plummet. If you have ever asked such a question in the past, you need to know that your company has lost productivity because of it. Even if it never resulted in a missed deadline. Once you insult your developers, they're not going to want to work hard for you. They're going to stop caring. Do something smart and get insulted? OK, stop trying to be smart. If you've ever had to limit your scope or drop features or push out a deadline or worse, and such a thing happened after you asked such a question, now you know why. If you've ever released something that was buggier than people expected, or more difficult to refactor than the developers expected, you can probably bet that a member of your team was insulted and stopped caring.

      Any question that is basically a "sounds like you're useless" kind of question is self-destructive to ask. Anyone with self-esteem will not accept it. You know how useful your developers are by their output. Do they hit deadlines? Do they build the things that are needed? Is the uptime good? Is the bug count low? Are the customers happy? Think about it. How are you going to feel if the developer replies to you by saying, "all you seem to do is push pencils around, so why are we paying you again?"

      (And if you're inclined to respond by saying, "Unfair question, because I don't just push pencils, I provide real value!" ...then you understand the argumentative feeling you've instilled in your developers.)

  • This will be easier to assess when we know more: would the team behind this care to write an article for Dion Hinchcliffe's AJAXWorld Magazine [ajaxworldmagazine.com]? He can be easily reached, just Google him.

  • drawback (Score:2, Insightful)

    by Anonymous Coward
    The common drawback these Ajax aides all fail to overcome is that, even with aides, apps take a long time to create and debug.

    And there I was, thinking that the common drawback was the lack of accessibility for disabled people and those of us who like to use links or the back button...

  • Fatal Flaw? (Score:3, Insightful)

    by WebHostingGuy (825421) * on Monday September 04 2006, @03:45PM (#16039664) Homepage Journal
    Great concept, but unless the server hosting the script has enough bandwidth and CPU to handle the requests or the the embedded script will never run. This will always be the fatal flaw in concepts like this.

      • Re:Fatal Flaw? (Score:4, Insightful)

        by gregmac (629064) on Monday September 04 2006, @05:27PM (#16040142) Homepage
        I was actually thinking that one of the 'benefits' of this technique is that you could release a tool for people to use WITHOUT releasing the source (or backend database, or any other tools/data used). This is more of a benefit to the Googles and Yahoos, or the guy that wants to eventually make money off this tool, not the end-developer integrating it.

        Overall, it seems to me like a solution to a problem that just doesn't exist. There are already ways to access web services from the server-side (SOAP, XML-RPC, REST, and so on). To make use of these sources with AJAX, you just need to code some AJAX glue to tie it together. Using the toolkits that most languages have now, this can literally be 5 or 10 lines of code.

        You also get to control the code that gets returned - set your own timeout (server-side) for fetching data from the web service; not have to worry about the hosting site going down and possibly breaking your app; not worrying about the remote end getting comprimised (since it would be a bright shiny target, and you don't know anything about their security); not worry about them shutting down operations, switching to a pay-per-use model (see above), changing the API in a non-BC way, etc.

  • if Craig Nuttal is reading this... (Score:5, Insightful)

    by bunions (970377) on Monday September 04 2006, @03:47PM (#16039673)
    Next time you release an API, don't tell us "Instead of sorting through the techno-babble, let's just say [whatever]." This phrase immediately engages my bullshit sensors. You've apparently got a nice wrapper around the cross-site problems, just say that. Anyone who understands will be interested, anyone who doesn't won't care either way.
  • The Widget mechanism in TurboGears is intended to address the issue of reuse of 3rd-party AJAX code. How does this differ?

  • Cows (Score:5, Funny)

    by David_Bloom (578245) <slashdot@3lesson.org> on Monday September 04 2006, @03:59PM (#16039717) Homepage
    You have two cows. They eat AJAX and die.

  • Oh come on (Score:4, Insightful)

    by zaajats (904507) on Monday September 04 2006, @03:59PM (#16039720) Homepage

    From the spell checker:

    "You won't be able to reenable it without reloading the page"

    That's so very AJAX.

  • DO NOT USE THIS (Score:5, Insightful)

    by Anonymous Coward on Monday September 04 2006, @04:02PM (#16039738)
    Jacquesm posting as AC because I'm travelling, please do NOT USE THIRD PARTY JAVASCRIPTS.


    It really is asking for trouble, once you have third party javascript on your site you are
    basically at the mercy of whoever wrote that javascript.


    They can do nice stuff, and not so nice stuff with your end users (popups, form content
    hijacking and so on).


    And possibly lots of stuff that I have not even thought of. Also, they're pretty much
    in control of the timing on your site, some browsers do not display the page until all
    java script has loaded and if you are loading it from a remote server then you are
    basically as slow as that server.


    • same goes for third party web apps, but are you telling everyone who uses slashcode to drop it and roll their own?

      • Re: (Score:3, Insightful)

        by Anthony Boyd (242971)
        Slashcode is code that you copy onto your own server and use under your own control. He is talking about remotely hosted code. In other words, this cow code stays on a 3rd party's server. You do not get to control it or custom-rebuild it. It is very different from the Slashcode model. Thus, your questions and concerns are inapplicable.
        • argh. duh. I apparently ate a brain tumor for breakfast, please disregard my previous post.
          • No. The original poster just did not explain himself clearly. I had the same interpretation at first too. Then I realized that even an AC couldn't be that stupid and he meant to say something else.
  • If we become used to loading random pieces of code from 3rd parties and injecting it into legitimate web pages, how long will it be before someone skeaks in a nice password sniffer or some such? I can already envision it: "This favelet makes logging into your bank so much easier" yeah right *for them*.
    Besides, this stuff does not support Opera well.

    • Re: (Score:2, Interesting)

      by nuttzy (877548) *

      With anything on the net, you should only be running code from a trusted source. All sorts of nasty things can happen just by visiting a scammers website (XSS+phishing combo attacks and such). Obviously COWS Ajax introduces another layer of concern, but it can be mitigated by running tools/apps from trusted sources only (as I state in the opening blurb). If someone has a vested interest in offering a tool, then that should reduce the odds of a scam. There's a wealth to be gained from 3rd parties... just

      • Obviously COWS Ajax introduces another layer of concern, but it can be mitigated by running tools/apps from trusted sources only (as I state in the opening blurb).

        To a point. The sites that are serving up this code will quickly become a target of crackers, as the only thing better than exploting one web server and putting your phishing code into their site is exploting one server and putting code into their site that's served up on hundreds or thousands of other websites.

  • Long to develop? What? (Score:3, Interesting)

    by mortonda (5175) on Monday September 04 2006, @04:12PM (#16039776)
    The common drawback these Ajax aids all fail to overcome is that, even with aids, apps take a long time to create and debug.


    What in the world is that supposed to mean? I implemented a autocomplete search text box in only a few minutes using RoR. It really is that simple. It has a rich interface to create all sorts of ajax effects, useful ones that reduce traffic to/from the server.

    Also, debugging is a breeze with the Firebug plugin for firefox; you can see exactly what is getting sent to the server and what is returned.

    Moooove along, nothing to see here. (Sorry, couldn't resist)
  • This looks like a neat concept, but sort of seems like a hack around the existing security model. Frankly, I'm of two minds. On one hand, I like the idea of being able to tie together multiple hosted javascripts from other parties without having to install and configure them on my server. (plug - I mentioned this idea in an AJAX discussion on http://webdevradio.com/ [webdevradio.com] a couple months ago). On the other hand, 'same-origin' policy exists for a reason (not that I agree with it) and it seems like relying on a
  • From the website:
    Uses no resources

    Excellent. So you've finally perfected producing something from nothing? Brilliant, my man! Although with such a discovery you'd think you could do better than a spell check.

  • one word: Echo2 (Score:4, Informative)

    by master_p (608214) on Monday September 04 2006, @04:30PM (#16039851)
    the echo2 library is an Ajax library which makes web application development as easy as desktop application development; it is an all-Java framework with no need to write even one line of XML/HTML/JSP/other. You can find it here:

    http://www.nextapp.com/platform/echo2/echo/ [nextapp.com]

  • Having recently re-written from scratch a very large project with two or more PHP developers and myself as the only front-end designer, I've found Ajax to be the fastest way to develop web apps for in-house use. If you write a spec for data I/O, then follow it exactly, the front end can be developed without the back end using sample data. The back end can be developed without the front end, since simulated posts/gets can be done to verify that the XML (or JSON or text or whatever) is valid. That means th

    • Re: (Score:3, Insightful)

      by Shados (741919)
      The way you're developing apps has little to do with Ajax, and more with using the correct design... Any half decent application (not just web apps...ANY APPS, aside for very specialized stuff, and even then) should be like that... separating everything so that the front end and the back end (and the data access layer, and the security, and the validation, and...and...and...) are separated, so that you know exactly where any problems are, how to fix them, that fixing them usualy won't break anything else (u

  • Sounds like just a toolkit to me. One implementation among many. A simple Ajax implementation isn't even 20 lines of code client side, and then whatever server side code is needed to perform the necessary functions.

    I find it ironic that their first example of COWS Ajax is a spell checker, which my Firefox already has built-in, client side, for ANY form field on ANY website.

  • Old trick, new buzzword (Score:4, Informative)

    by kap1 (164828) on Monday September 04 2006, @04:46PM (#16039930) Homepage
    Ouch. Adding a script tag dynamically is old hat in Ajax. See the DOM Based On-Demand Javascript [ajaxpatterns.org] pattern.

    In fact, there are a number of project under way that use dynamic script injection to emulate cross-domain XHR. See http://ajaxian.com/archives/jsonp-json-with-paddin g [ajaxian.com]

    But worse yet, the argument that developing web applications with Ajax is hard is a straw man. Imagine you had to design a desktop GUI by twiddling with the screen bits directly or, worse yet, implementing application logic in the graphics controller. Blech!

    That's the situation with Ajax and webapps right now [pathf.com]: writing code in the wrong places and at the wrong level of abstraction.

    If you want to simplify how you write webapps using Ajax, try a server side framework like Echo2 or ZK. These allow you to write webapps much like a desktop GUI while working in only one language context -- Java on the Server side.
  • It would not be better to use the browser to show only HTML, extend HTML document oriented tags with application oriented tags, SVG and use a protocol designed for applications not one for download documents? A protocol like X11 but with HTML, DOM nodes and DOM modifications. A stateful protocol without cookies, binary, designed for minimizing the amount of data traffic needed between server and client. The server sends HTML pages and DOM modifications to the client/browser at any moment and the cliente/bro

  • Really bad idea! (Score:4, Insightful)

    by mrsbrisby (60242) on Monday September 04 2006, @04:50PM (#16039958) Homepage
    We're looking at the worst kind of "copy and paste coding" here: the kind that can change at any time in the future. If you can't write a spellchecker, and you can't copy one from someplace else, you're going to look mighty stupid when the cow-speller site goes down, and you can't fix it.

    Seriously, by doing this, I'm not only trusting this bovine-fixated individual to not only (a) never change his API, (b) always be up, (c) never do evil things with my data, but also (d) actively prevent evil things from being done with my data.

    Consider for a moment that you write an email client that "leverages" this technology. In this situation, not only are you handing your logs, you're also potentially passing your customer's email and passwords to this cow-speller.

    Bad fucking idea...

  • Not really... (Score:3, Insightful)

    by ErGalvao (843384) on Monday September 04 2006, @05:00PM (#16040010) Homepage Journal
    Wouldn't it be great to drop in a single line of code to gain a huge amount of functionality that frees you for something else?
    Actually my answer is "nope! not really!". Coders - as the term implies - like to code, not to drop a single line and watch it gain functionality without knowing what's happening behind the scenes. Coders ARE behind the scenes, so this cow can be good for companies who aren't involved in web developing or programming of any kind, but not for us, programmers. We code. There isn't such a thing as "something else" for us, but hey, thanks for your concern =P
  • To be able to spell check through AJAX, wouldn't you need to send every word back to their servers as they return and tell you which one's to highlight and which words to use?

    Given that, it's rather scary where I'd want to use this spellchecker on. I would never use spellchecker if my document was being sent from Word back to the Office group's spell checking server. Some things like these a crucial to be on the client side.
  • ROFL, Safari is not that uncomplient that it should not work, IMHO.

    angel'o'sphere
    • And when you use Firefox, and hit the checkbox for disabeling spell chekcing, it says you need to reload the page to reenable it .... how AJAX like is that, lol.

      angel'o'sphere
  • The SpellingCow demo doesn't seem to work in Safari. Too bad. I wonder if that's because Apple's built in spell check interferes with it? I tried turning Apple's off, but it still doesn't seem to work. Bummer.

  • Light fingers... (Score:3, Interesting)

    by kap1 (164828) on Monday September 04 2006, @08:20PM (#16041012) Homepage
    Looks like SpellingCow was lifted from another project without attribution (http://me.eae.net/archive/2006/09/04/spellingcow/ ). This whole post/project smells fishy.

    • Re: (Score:2, Funny)

      by Anonymous Coward
      Opps indeed! This comment was spell checked by Firefox 2.0...looks like it works a bit better than SpellingCow!

    • Re: (Score:3, Interesting)

      by naoursla (99850)
      ATLAS [asp.net] also automates AJAX development.

      The last part of this video [microsoft.com] shows an asp.net web page being AJAX enables (although ATLAS is not asp.net specific).

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.