COWS Ajax - Ajax Evolved

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."

Comments

Not a developer

[Lispy]

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

[Directrix1]

- 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.

Re:Not a developer

[Anthony Boyd]

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.)

drawback

[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...

Re:drawback

[Anonymous Coward]

This is kinda like breaking the back button, and then breaking it a little more so it works.

Fatal Flaw?

[WebHostingGuy]

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?

[gregmac]

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...

[bunions]

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.

Oh come on

[zaajats]

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

[Anonymous Coward]

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.

Re:DO NOT USE THIS

[Anthony Boyd]

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.

Re:Yay! One more buzzword!!! (nt)

[ShieldW0lf]

Wow... a web service based on a cross-site scripting vulnerability.

That's brilliant.

Now third party websites can offer to check my spelling and eavesdrop on my conversations with only one line of code!

I know I'm excited.

A different way of making web apps

[alejsama]

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/browser shows the HTML, make the DOM modifications and sends function execution request to the server with user input. Just some ideas

Really bad idea!

[mrsbrisby]

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...

Re:Really bad idea!

[magerquark.de]

Hey, but we already did look stupid when Google Analytics was down the last time and all of our websites were slow to access and we couldn't fix it, didn't we?

Not really...

[ErGalvao]

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

Re:Slow?

[Shados]

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 (unless a structural change is made, obviously), and so on.

Its just...the tried, tested and true way of doing thing, ajax or not :)

Dejavascript Vu

[mwvdlee]

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?