Beta
×

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!

The Future of AJAX and the Rich Web

kdawson posted more than 6 years ago | from the question-is-worth-1000-answers dept.

Programming 303

jg21 writes "This AJAXWorld Magazine article indicates how far AJAX has come since devs complained here two years ago that it sucked all the time. Eight experts were asked what questions we should now all be asking about where AJAX is headed next. The suggested questions are refreshingly hard-headed, including: 'How are we to fix the web?'; 'When will AJAX development finally be easy?'; and 'Do we really need JavaScript 2.0? Won't it be somewhat irrelevant by the time it becomes commonplace and thus usable?' One of the most interesting questions came from Kevin Hakman, co-founder of TIBCO's General Interface: 'On what timeline will AJAX skills become commoditized like HTML skills became?'"

Sorry! There are no comments related to the filter you selected.

SLASHDOT SUX0RZ (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21661551)

_0_
\''\
'=o='
.|!|
.| |
goatse 2.0 [goatse.ch]

Your comment has too few characters per line (currently 3.4). Your comment has too few characters per line (currently 3.4). Your comment has too few characters per line (currently 3.4).

I, for one, welcome (0, Redundant)

Finallyjoined!!! (1158431) | more than 6 years ago | (#21661565)

Our Ajax overlords :^D Couldn't resist...

Do you also welcome AJAX hosts holding your data? (3, Insightful)

compumike (454538) | more than 6 years ago | (#21662531)

Lots of people seem to welcome AJAX, and it does provide a huge step in the interactivity of web interfaces without sacrificing platform compatibility or development time.

However, one thing that continues to surprise me is how willing most people are to having a third party store all of their data. All AJAX apps essentially require that you do not hold your own data -- it's held by the application provider. A big reason is because Javascript can't touch your local filesystem, but another is that Javascript isn't powerful enough to really be useful for all of the processing, so back to the server-side scripting it goes.

In fact, one of the things that scared me today was how excited a friend was to discover that Google's chat application logged all of their Jabber conversations -- even if they had been made with a 3rd party GUI client (Pidgin). This, to me, would just be scary.

--
Educational microcontroller kits for the digital generation. [nerdkits.com]

Re:Do you also welcome AJAX hosts holding your dat (3, Informative)

AKAImBatman (238306) | more than 6 years ago | (#21662751)

However, one thing that continues to surprise me is how willing most people are to having a third party store all of their data. All AJAX apps essentially require that you do not hold your own data -- it's held by the application provider.

How does that differ from regular web applications holding your data? There's been well over a decade of time for users to become comfortable or uncomfortable with the idea of entrusting a third party with their data. So far, users have been leaning toward "comfortable".

Re:Do you also welcome AJAX hosts holding your dat (2, Interesting)

Bogtha (906264) | more than 6 years ago | (#21663025)

All AJAX apps essentially require that you do not hold your own data -- it's held by the application provider.

You're referring to software as a service, not Ajax. An application ran as a service by an outside vendor can hold your data hostage, whether or not it uses Ajax, and an application running within your organisation doesn't, whether or not it uses Ajax. The key is who runs the application, not whether it uses Ajax.

Re:Do you also welcome AJAX hosts holding your dat (1)

osu-neko (2604) | more than 6 years ago | (#21663397)

However, one thing that continues to surprise me is how willing most people are to having a third party store all of their data.

A lot of people don't backup their data regularly, and know that their data is probably safer on some ASP's servers than on their own hard drive.

Of course, from your comments about Goggle logging conversations being scary (this is one feature I make sure to turn on in every chat app -- it's SO damn useful to be able to bring up the text of old conversations, especially given that my memory is not what it used to be), I'm guessing what surprises you is the privacy concerns.

I suspect most people have come to grips with the fact that they aren't James Bond. I'm well aware that someone at any of the companies storing my data could read it, that the NSA has probably already scanned it, etc. If there's someone at the NSA reading everything I write, my gods, dude, I'm sorry I've got such a boring life. I feel for ya, man...

But seriously, who really cares? And why?

When did AJAX stop sucking? (1)

ameyer17 (935373) | more than 6 years ago | (#21661569)

It's slow and an accessability nightmare. I say it still sucks.

Let's see (3, Insightful)

smitty_one_each (243267) | more than 6 years ago | (#21661871)

In the beginning, there was client server.
Then, there was n-tier with the thin client.
Now, the client seems past the bout of anorexia, we've gone back to client/server, and AJAX has fattened it right up.
Next (mis)step? N-tier, repackaged as "federated", with an emphasis on thin, mobile clients. But you knew that. The real question is, what will AJAX for the hand-held be called? I say: BORAXO [boraxo.com] .
I will confess some guilt that this has not been reduced to a Burma Shave troll, but I'm still slightly under the weather.

Re:Let's see (2, Funny)

morgan_greywolf (835522) | more than 6 years ago | (#21662619)

Next (mis)step? N-tier, repackaged as "federated", with an emphasis on thin, mobile clients. But you knew that. The real question is, what will AJAX for the hand-held be called? I say: BORAXO.
How about JAXOFF?

Re:Let's see (1)

klubar (591384) | more than 6 years ago | (#21663355)

I think you missed a couple of steps... In the beginning there was the mainframe; all information was centralized Then there was time sharing (dumb terminals); information was centralized, but you could get at remotely Then there was mini-computer (see, PDP-1, PDP-8, PDP-11, etc); processing was put in the hands of the elite Then there was PC; information was put in the hands of nearly everyone Then there was centralized administration of the PC and centralized servers (see time sharing) Then there was the web... see time sharing Then there was Web 2.0 ... see time sharing with fancy terminals

Re:When did AJAX stop sucking? (2, Insightful)

secPM_MS (1081961) | more than 6 years ago | (#21662087)

The rich web is all well and good for those with nice screens and good vision. It does not do so well for those with highly constrained devices and/or bad vision. I would love it if companies pushing commerce web sites started having acessibility requirements.

If a user has bad vision, they can feed text into a text to speech converter. GUI into a speech converter doesn't work so well. There are an increasing number of older folks using the web, and expecting a large screen real state is not appropriate - they may have large screens, but they may have increased the font size for readability.

As for me, I am paranoid. I don't believe in running script unless I have a good reason to trust the site in question. Thus by default, I have Java, Javascript, Flash, ActiveX, et al off. Thus, no rich web for me. Too bad.

Re:When did AJAX stop sucking? (1)

amRadioHed (463061) | more than 6 years ago | (#21662185)

How about you run a browser in a VM and live a little?

Re:When did AJAX stop sucking? (1)

secPM_MS (1081961) | more than 6 years ago | (#21662343)

A very good suggestion. A few years ago I believed that doing so would be enough of a security guarantee. It will typically work well against naieve threats, but as VM usage gets more widespread, attackers will start supplementing their attacks with VM penetrators to nail the host. The standard VM products do not make strong guarantees about confining hostile code in VM's.

Re:When did AJAX stop sucking? (1)

devjj (956776) | more than 6 years ago | (#21663007)

You can't have it all. Simple as that. You simply cannot expect people to always design and develop for the lowest common denominator. We'd have no innovation if we took every single accessibility issue into account from the get-go. AJAX is young, even today. We're still figuring out the best ways to apply it, where it's appropriate to apply it, etc. Browser vendors are going to have to adapt to it; not the other way around. The entire reason it's difficult right now is because what we're effectively doing is using tools that were always there to do things they hadn't done before.

So far as screen real estate goes you make a point, but resolution independence is on its way, and I can't see myself building sites in 640x480 simply because someone might want to up the font size five times. A well-designed site can cope with this regardless.

So far as scripts go, I think you're a little too paranoid. Yes, they can be misused, and yes, it's possible that in leaving scripts on that you'll expose yourself to a security risk, but shutting them off entirely is a knee-jerk reaction at best. The overwhelming majority of these problems can be avoided by simply using a little common sense and staying away from questionable sites in the first place. I've never turned off scripts in my browser, and I've never run a virus scanner. Across three different platforms (Windows, Mac OS X, and Linux), I've yet to get hit by a single virus, piece of malware, etc. It's all about common sense.

Re:When did AJAX stop sucking? (0)

Anonymous Coward | more than 6 years ago | (#21663311)

You simply cannot expect people to always design and develop for the lowest common denominator.
I'm not sure I would call the blind the "lowest common denominator," and neither would big corporations, which is why they will fear AJAX if it implies any sort of discrimination whatsoever, be that discriminating against their users with an inaccessible website or discriminating against people they could or could not hire due to an inaccessible internal web app. Dangerous territory, I'm afraid.

Re:When did AJAX stop sucking? (0)

Anonymous Coward | more than 6 years ago | (#21663323)

I've never turned off scripts in my browser, and I've never run a virus scanner. Across three different platforms (Windows, Mac OS X, and Linux), I've yet to get hit by a single virus, piece of malware, etc.

Kinda begs the question, how would you know?

You're like the asshat at the bar, hittin' every piece you can, boys and girls, shooting smack for fun, and loudly proclaiming "I never use a rubber, always share needles, have never taken an AIDS test, and I still don't have AIDS".

Re:When did AJAX stop sucking? (3, Insightful)

hobo sapiens (893427) | more than 6 years ago | (#21663315)

Well too bad for you.

Developing for the web is about knowing your audience. If I were designing a site like ebay or amazon, in other words, trying to have the widest possible user base, or if I were working for some entity that had to abide by ADA requirements, then maybe avoiding AJAX would be advisable. For a site that is not a necessity, like, for example, youtube, slashdot, digg, flickr, etc AJAX is great. When done properly, AJAX makes more efficient applications that enhance the user experience.

Also, if you really want to, you can develop sites that use AJAX but also degrade nicely. Everyone here (at least, anyone who calls himself a serious web developer) is using web standards and writing good semantic markup, right? Well, that will make your site at least accessible. If you just use the noscript tag to handle non javascript user agents (where necessary, obviously not where there isn't ROI anyway) then your site should work pretty well.

As someone else who replied to you mentioned, we cannot develop web sites around people who for some crazy reason refuse to use new technologies (if you call javascript new, as if!). That, along with MSIE, are holding the web back.

I think people who hate AJAX just hate it because of all the bad AJAX sites. But that's like hating the web because there are bad non-ajax sites. AJAX, like other technologies, makes things better when used properly.

will AJAX development finally be easy? (3, Interesting)

doroshjt (1044472) | more than 6 years ago | (#21661649)

It already is. What is so hard about it?

Re:will AJAX development finally be easy? (2, Informative)

brunascle (994197) | more than 6 years ago | (#21661707)

i was thinking the same thing. there's all of about 5-10 methods/properties to learn, and then you just need to know basic DOM functions for the response. it's not hard at all.

Re:will AJAX development finally be easy? (2, Interesting)

misleb (129952) | more than 6 years ago | (#21661961)

Doing simple AJAX stuff is easy. Drag/drop a few lists. Insert a new div into the page... Anyone who's used Ruby on Rails knows that. The hard(ish) part is making an app that is completely AJAX. As in, loads from a single page and never refreshes after that. Though I haven't tried toolkits like GWT. Maybe using one of those is just as easy as developing a desktop application.

Re:will AJAX development finally be easy? (2, Insightful)

Dragonslicer (991472) | more than 6 years ago | (#21662765)

Doing simple AJAX stuff is easy. Drag/drop a few lists. Insert a new div into the page...
Repeat after me: DHTML/DOM manipulation has NOTHING to do with XMLHttpRequest.

Re:will AJAX development finally be easy? (2, Insightful)

misleb (129952) | more than 6 years ago | (#21663217)

True, but there's little point in doing XHR if you're not manipulating the DOM. They go hand in hand. Together they make up "AJAX" as is commonly implemented. While doing XHR and manipulating the DOM are, in and of themselves, not particularly difficult, making a a truely rich desktop-like application using them can be tricky. Especially considering the relative sparseness of HTML with regards to application control.

Re:will AJAX development finally be easy? (2, Interesting)

SnapShot (171582) | more than 6 years ago | (#21662799)

Unable to focus on it to the exclusion of other Java development, I found GWT very hard to get used too. My fingers and brain want to write Java, but when in GWT you're really only writing a sub-set of Java 1.4. The lack of generics (which have become second-nature; I can't write "Set" without instinctively putting a "" after it) and of Java 5 support in general was very difficult to get over. For me it was harder than working in another language where I expect things to be different.

Maybe, if GWT was re-released for OCaml (or some other language that I'd learn in conjunction with GWT) I might have an easier time working with it.

That being said, GWT is a very powerful and very cool system and you can do a "single page" AJAX app that's fairly cross-browser compatible and never have to leave your Java environment. A little work with the existing maven plugins and you can deploy your complete app just like you'd build a Swing application (almost ;-)

(P.S. My experience with GWT was last spring which is probably about 10 versions old so things may have changed...)

Re:will AJAX development finally be easy? (4, Insightful)

Larry Lightbulb (781175) | more than 6 years ago | (#21661963)

Ok, point me to a place where I can pick up all the knowledge I need to use it, I've got a free afternoon. And I mean that seriously.

Re:will AJAX development finally be easy? (1)

truthsearch (249536) | more than 6 years ago | (#21662081)

Sure, no problem [fuckinggoogleit.com] .

Re:will AJAX development finally be easy? (1)

mrami (664567) | more than 6 years ago | (#21662275)

So you don't know, then.

Re:will AJAX development finally be easy? (1)

truthsearch (249536) | more than 6 years ago | (#21662397)

Is this [google.com] really hard? Or this [google.com] ? Or this [google.com] ?

That's how must of us learned it.

Re:will AJAX development finally be easy? (1)

mrami (664567) | more than 6 years ago | (#21662641)

Maybe I have too much poitics in my life, but it was an evasive answer. I'm just sayin'.

And even the links you give above don't answer the original question. They're just places you assume will answer the question. Unless you' know of a specific page in those results that try to teach AJAX in an afternoon.

In which case, you could enlighten us, if you so choose...

Re:will AJAX development finally be easy? (4, Informative)

truthsearch (249536) | more than 6 years ago | (#21662951)

Fair enough. I was awfully obnoxious, so I should make up for it with some actual information.

For a quick, but useful and accurate, starting point I like Mozilla's introduction [mozilla.org] .

Then I recommend downloading and trying prototype [prototypejs.org] . It saves the mundane tasks, makes code a little easier to read, and is used by other popular frameworks.

Those cover the base scenarios. I haven't seen any good intermediate documentation. After the intros I suggest reading more reference documentation and just trying things out.

Re:will AJAX development finally be easy? (1)

mrami (664567) | more than 6 years ago | (#21663251)

Cool!

Re:will AJAX development finally be easy? (1)

Conception (212279) | more than 6 years ago | (#21662205)

Just download a framework and be done with it. http://www.prototypejs.org/ [prototypejs.org]

It'll take about an afternoon to figure out the ins and outs and make it do what you want.

Re:will AJAX development finally be easy? (0)

Anonymous Coward | more than 6 years ago | (#21662669)

prototype sucks. use mootools.

Re:will AJAX development finally be easy? (2, Informative)

brunascle (994197) | more than 6 years ago | (#21663079)

here's a good intro [w3schools.com] . this assumes you have a file time.asp on your site that just outputs the time.

if, instead, time.asp outputs an XML file, in the code change .responseText to .responseXML, and from that you can use DOM functions (e.g. xmlHttp.responseXML.getElementsByTagName("time")[0].childNodes[0].nodeValue.

Re:will AJAX development finally be easy? (1)

YourMotherCalled (888364) | more than 6 years ago | (#21663121)

Try the jQuery [jquery.com] framework.

Re:will AJAX development finally be easy? (4, Insightful)

jma05 (897351) | more than 6 years ago | (#21662045)

The challenge is not technical. Devs need to change their mindsets while about thinking about web applications. I am not talking about putting an occasional AJAX widget. The change is from synchronous to asynchronous web applications. That's about as big a change as writing distributed applications for someone who mostly wrote 1-tier applications. Design is different as is debugging.

Re:will AJAX development finally be easy? (2, Funny)

The Clockwork Troll (655321) | more than 6 years ago | (#21661855)

What is so hard about it?

Not using it.

Re:will AJAX development finally be easy? (0)

Anonymous Coward | more than 6 years ago | (#21662141)

It already is. What is so hard about it?

Making it accessible? Also, to know when to use and to use it which is something a lot of devs seem confused about.

Re:will AJAX development finally be easy? (1)

rhizome (115711) | more than 6 years ago | (#21662767)

It already is. What is so hard about it?

I don't know, but as long as (surprise!) AJAX Magazine says "AJAX is awesome," I'm on the kool-aid bus whether it's easy or not!

Re:will AJAX development finally be easy? (5, Insightful)

SharpFang (651121) | more than 6 years ago | (#21662927)

It is not quite as easy.

Assuming you start from zero...

The beginnings are easy. Learn basics of HTML and CSS. A week and you're intermediate. You still don't know all the hacks and caveats but you know quite enough.

Learn basics of Javascript. Say, 3 days. Simple JS is easy. If you think all JS is easy, read some scripts by Douglas Crockford and see how wrong you were. But for a starter, you need simple JS.

Then learn using DOM. This isn't all that hard. There are some caveats like some browsers inserting whitespace text nodes between tags and such, but that's all doable. One evening to master it.

Learn some backend language. PHP probably. With some database too. Quite easy but the amount of knowledge you need to absorb is at least 2 weeks of learning.

Next you learn basics of using xmlHttpRequest. This is one evening and you know how it works and you know there's no sense using it as-is.

You spend the next afternoon picking an AJAX framework/library/toolbox and another day learning it.

They you spend another year writing AJAX and learning how to properly react to unreliable connections and handle all kinds of errors, corrupted data, browser incompatibilities, how to protect your apps from script injection attacks or exploiting your application server by someone "from outside", deal with load ballancing on the server side, sharing scripts between domains, making the code non-conflicting with other JS and self (2 instances of the same AJAX-based tool on one page? It's broken more often than you think!), creating javascript files dynamically using PHP to allow better flexiblity of your app, parsing, traversing, modifying and extracting data from style sheets, interacting with Flash, Java and APIs of a dozen external services, writing XUL based apps, optimizing data for transfer, porting large parts of business logic to JS to offload your application servers, then finally using the advanced javascript where modifying system methods and objects is not a taboo anymore.

Then you know AJAX.

Re:will AJAX development finally be easy? (1)

FranklinDelanoBluth (1041504) | more than 6 years ago | (#21663367)

That's still not any harder than programming with any other language/platform combo. Each different area of programming has its own unique caveats and gotchas. For example, you'll also see problems of asynchronous programming and data corruption when doing low level driver development. This doesn't make AJAX (and web dev overall) any harder than general programming. (Though if you want to compare to just normal HTML, yes, I'll concede that it is harder.)

cleaning with bleach products will be all the rage (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21661655)

it's a dirty world now. better days coming. see you there?

corepirate nazi execrable costs outweigh benefits
(Score:-)mynuts won, the king is a fink)
by ourselves on everyday 24/7

as there are no benefits, just more&more death/debt & disruption.

fortunately there's an 'army' of light bringers, coming yOUR way

do not be afraid/dismayed, it is the way it was meant to be.

the little ones/innocents must/will be protected.

after the big flash, ALL of yOUR imaginary 'borders' may blur a bit?

for each of the creators' innocents harmed, there is a debt that must/will be repaid by you/us, as the perpetrators/minions of unprecedented evile, will not be available after the big flash occurs.

beware the illusionary smoke&mirrors.con

all is not lost/forgotten/forgiven.

no need to fret (unless you're associated/joined at the hype with, unprecedented evile), it's all just a part of the creators' wwwildly popular, newclear powered, planet/population rescue initiative/mandate.

or, is it (literally) ground hog (as in dead meat) day, again? many of US are obviously not interested in/aware of how we appear (which is whoreabull) from the other side of the 'lens', or even from across the oceans.

vote with (what's left in) yOUR wallet. help bring an end to unprecedented evile's manifestation through yOUR owned felonious corepirate nazi glowbull warmongering execrable.

some of US should consider ourselves very fortunate to be among those scheduled to survive after the big flash/implementation of the creators' wwwildly popular planet/population rescue initiative/mandate.

it's right in the manual, 'world without end', etc....

as we all ?know?, change is inevitable, & denying/ignoring gravity, logic, morality, etc..., is only possible, on a temporary basis.

concern about the course of events that will occur should the life0cidal execrable fail to be intervened upon is in order.

'do not be dismayed' (also from the manual). however, it's ok/recommended, to not attempt to live under/accept, fauxking nazi felon greed/fear/ego based pr ?firm? scriptdead mindphuking hypenosys.

consult with/trust in yOUR creators. providing more than enough of everything for everyone (without any distracting/spiritdead personal gain motives), whilst badtolling unprecedented evile, using an unlimited supply of newclear power, since/until forever. see you there?

"If my people, which are called by my name, shall humble themselves, and pray, and seek my face, and turn from their wicked ways; then will I hear from heaven, and will forgive their sin, and will heal their land."

Web is bloated. (-1, Redundant)

gowakuwa (1199733) | more than 6 years ago | (#21661671)


  Everything you need to write a web page. Now if you want an interactive metaporn flash wmv portal get this AJAX thing.

Re:Web is bloated. (0, Offtopic)

gowakuwa (1199733) | more than 6 years ago | (#21661757)

Now why does slashdot eat my tags when I post as Plain Old Text?

Re:Web is bloated. (1)

whmac33 (524094) | more than 6 years ago | (#21662067)

Post extrans (html tags to text)
<b> <i> <p> <br> <a> <ol> <ul> <li> <dl> <dt> <dd> <em> <strong> <tt> <blockquote> <div> <ecode> <quote>

and perveiw.

Ajax will be obsolete before it becomes mainstream (0)

Anonymous Coward | more than 6 years ago | (#21661721)

As anything but a way to make webpages slightly interactive, Ajax will never become mainstream. Ajax as an application platform has no chance against Silverlight and Flash/Flex. The complexity of Ajax is inherent to the display control: HTML is simply too convoluted for application development.

Re:Ajax will be obsolete before it becomes mainstr (4, Informative)

e4g4 (533831) | more than 6 years ago | (#21661873)

Ajax *is* mainstream - Google, Yahoo, Microsoft, Apple - all using ajax in one form or another in their web applications. Now - as to your other claim, that Ajax doesn't stand up to Silverlight or Flash; I say Flash!?! Have you every built an application in flash? It's a nightmare to maintain. I can't speak to Silverlight, as I've not yet played around with it. But the design theory of ajax combined with a good JS api (like prototype [prototypejs.org] ) Makes it a much more maintainable and IMHO a nice way to build interactive web apps.

Re:Ajax will be obsolete before it becomes mainstr (1)

Mr. Underbridge (666784) | more than 6 years ago | (#21662037)

Flash!?! Have you every built an application in flash? It's a nightmare to maintain.

Screw that, flash is a disaster to *use*. Flash causes a reflex in me that causes me to mash the 'back' button ASAP.

Re:Ajax will be obsolete before it becomes mainstr (1)

WWE-TicK (593858) | more than 6 years ago | (#21662337)

Developing applications in Flash is old school. These days, you're supposed to use Flex.

Re:Ajax will be obsolete before it becomes mainstr (1)

asaivan (1025940) | more than 6 years ago | (#21662597)

>Have you every built an application in flash? It's a nightmare to maintain.

Yes, I do it all the time. My apps are easy to maintain, because I make them that way. What about yours?

It's not the code, it's the coder. It's not the language, but the skillful use of that language.

Re:Ajax will be obsolete before it becomes mainstr (1)

e4g4 (533831) | more than 6 years ago | (#21662789)

What kind of applications do you develop in flash? And who maintains them once you've released them, you or someone else?

Re:Ajax will be obsolete before it becomes mainstr (2, Interesting)

asaivan (1025940) | more than 6 years ago | (#21662973)

I've made dozens of web video streaming applications and interactive web pages and right now am working on a multi-user video conferencing app. I maintain them myself, which I know is always easier than maintaining someone else's, however, I always try to write code (any code-HTML/CSS, Actionscript, PHP) very cleanly and clearly. Anyhow, I know Flash isn't the answer to the world's problems, but I do appreciate the advances in Actionscript 3 they've made, by turning it into a full-on OO language which resembles Java in many ways. In fact, I like the clean structure of AS3 so much that I wont program in AS2 or (defintely not) AS1 anymore. Peace.

Re:Ajax will be obsolete before it becomes mainstr (1)

anomalous cohort (704239) | more than 6 years ago | (#21662663)

Google, Yahoo, Microsoft, Apple - all using ajax in one form or another in their web applications

Three of those four vendors have published their own AJAX libraries for outside consumption. This accelerates adoption which is important from the standpoint of going mainstream.

...can't speak to Silverlight...design theory of ajax combined with a good JS api...makes it a much more maintainable and IMHO a nice way to build interactive web apps.

I have not used silverlight either. Those whom I have spoken with about it are jazzed about it because you don't have to use java script as the programming language. IMHO, there are serious problems with java script. Not that there's really a problem with the language itself. Rather, the problems show up in how the code engines are implemented. I have gone into more detail about this here [transitionchoices.com] . Good programmers can live with these shortcomings either by rendering most of the GUI via HTML and using java script only lightly (i.e. validating event handlers) or by using good libraries and debuggers.

Reduce the Quirks and Exceptions to HTML/CSS (3, Insightful)

JoeCommodore (567479) | more than 6 years ago | (#21661793)

Probably the biggest thing I see is that we live with a 'quirky' web where you write an HTML/CSS document and have to adjust for problems with one browser or another (or not support some because of such things), while the use of standard libraries and tools have provided automatic solutions for much of the quirks they still limit the possibilities.

HTML skills are a commodity? (3, Insightful)

Bogtha (906264) | more than 6 years ago | (#21661827)

On what timeline will AJAX skills become commoditized like HTML skills became?

It seems to me that developers that can write decent HTML are still an extreme minority. I still see href="javascript:", "<div> s are better than tables for layout", a chronic amount of invalid code, and all kinds of other idiocy all the time. Sure, if you want monkeys to throw tag soup all over the place it's not hard to find them, but that doesn't mean they know what they are doing or that it's easy to find people who actually understand HTML.

Re:HTML skills are a commodity? (1)

Yetihehe (971185) | more than 6 years ago | (#21662279)

<div>'s are better than tables for layout
If only tables still supported height attribute... I'm just php/js programmer, but I still often have to do complete reworking of templates (often to tables) if I need to make dynamic template from some designer's work.

Re:HTML skills are a commodity? (1)

blincoln (592401) | more than 6 years ago | (#21662401)

I still see href="javascript:",

How else would you like people to make clickable text that executes a JavaScript method, and how would it be better than that approach?

"
s are better than tables for layout"

Uh, DIVs are better than tables for layout. They let the designer create more elaborate layouts more efficiently than tables, but they also make even simple layouts much more consistent and easy to implement.

Re:HTML skills are a commodity? (2, Informative)

brunascle (994197) | more than 6 years ago | (#21662613)

How else would you like people to make clickable text that executes a JavaScript method, and how would it be better than that approach?
use the onclick attribute, with return false at the end to cancel the href. that way, you can use the href for a URL to degrade gracefully. for example, if it's opening a popup window, have the href be the URL of the page that loads in the popup.

Re:HTML skills are a commodity? (4, Insightful)

Bogtha (906264) | more than 6 years ago | (#21662691)

How else would you like people to make clickable text that executes a JavaScript method, and how would it be better than that approach?

Add an event handler to a normal <a> element with a proper href attribute. It works when JavaScript is switched off, it works when your event handler has an error, it works when you try to open something in a new tab or window, it works when the browser doesn't support whatever it is you are trying to do in your event handler, it just plain works.

DIVs are better than tables for layout.

No, they aren't. They are absolutely useless for layout.

They let the designer create more elaborate layouts more efficiently than tables, but they also make even simple layouts much more consistent and easy to implement.

You have confused the <div> element type with CSS. They are totally different things.

This is not pedantry. If you are thinking that layout is somehow achieved with <div> elements, then you are looking at things completely upside-down. You use the most appropriate element type for the information at hand, whether that's a table, a list, a paragraph, or whatever. You then arrange those elements with CSS. The particular element types you've used are not relevant to the layout. If you think <div> elements are in any way interesting for layout purposes, then you don't understand how the whole picture fits together.

Re:HTML skills are a commodity? (5, Informative)

Osty (16825) | more than 6 years ago | (#21662945)

This is not pedantry. If you are thinking that layout is somehow achieved with <div> elements, then you are looking at things completely upside-down. You use the most appropriate element type for the information at hand, whether that's a table, a list, a paragraph, or whatever. You then arrange those elements with CSS. The particular element types you've used are not relevant to the layout. If you think <div> elements are in any way interesting for layout purposes, then you don't understand how the whole picture fits together.

A div is just a non-semantic block (just like a span is a non-semantic inline bit, though of course either of those could be changed by CSS). A table is very specific. Semantically, only tabular data should go into a table, and thus tables are completely wrong for layout. Divs, on the other hand, do make sense. For example, you're building a page with two columns, perhaps for a nav sidebar and a main content area. You have two separate components to your page, but they don't have any semantic meaning other than being blocks to put stuff (that is, they're not tabular data, list data, paragraphs, headings, etc). In that case, a div (short for "division", as in "page division" or something logically separate from other bits on the page) is absolutely correct to use. So now you have two divs on your page, one for the sidebar and one for the content. Using CSS, you can make these look however you like. Put the sidebar on the left or right, it doesn't matter (can't do that with a table without editing content). Put the "sidebar" along the top or bottom of the content area (can't do that with a table without editing content, either). Obviously that's CSS's doing, but you need something to work with in order to style appropriately. Within the sidebar, you have semantic data, as nav data can be considered a list. Within the content division, you have semantic data consisting of paragraphs, headings, etc. If you modelled your page as a table with a single row, with the sidebar being one cell and the content being another cell, your page is not semantic. Modelling it with divs, it is.

Divs can definitely be over-used. There are a lot of specific layouts that require wrappers and such, which usually means using divs. While you can avoid much of that, there's still some tag soup required if you want specific layouts with today's browsers, and you just have to deal with the fact that reality is intruding on your perfect little world. For my part, I would much rather have two divs wrapped in a third in order to do a two-column page layout than have a single table with columns as cells in the table.

Re:HTML skills are a commodity? (1)

Bogtha (906264) | more than 6 years ago | (#21663201)

tables are completely wrong for layout.

I have not said otherwise. Please pay attention to what I say rather than attempting to read between the lines.

For example, you're building a page with two columns, perhaps for a nav sidebar and a main content area. You have two separate components to your page, but they don't have any semantic meaning other than being blocks to put stuff (that is, they're not tabular data, list data, paragraphs, headings, etc). In that case, a div (short for "division", as in "page division" or something logically separate from other bits on the page) is absolutely correct to use.

Yes, and what was the motivation for using <div> elements? If it was because you have two separate components without a more appropriate element type to describe them, then that's a structural issue, not a layout issue. If it was because you are building a page with two columns, then you are screwing up and don't understand HTML. Either way, saying that "divs are better for layout" is not a sensible thing to say.

Re:HTML skills are a commodity? (1)

jddj (1085169) | more than 6 years ago | (#21663241)

Not sure, but I think parent's point was that the <div>s aren't actually doing the layout - in fact, they're containing (and thus identifying) certain desired blocks of content. You're applying layout with CSS, not with divs, and with CSS, you're applying layout to <div>s, <p>s, <h1>s and the rest...

Re:HTML skills are a commodity? (1)

Palinchron (924876) | more than 6 years ago | (#21663297)

So how do I create a tabular layout for non-tabular data without using a table? Say, two columns - nav sidebar and main content area - having equal, but liquid height (let's say I'd like the column borders to line up)?

Re:HTML skills are a commodity? (2)

LordLucless (582312) | more than 6 years ago | (#21663361)

Wake me up when the semantics of a tag changes the way it renders in the browser. Alternatively, give me a call when something other than a table-cell supports the vertical-height attribute, or there's an easy, cross-browser, standard-compliant way to make a div only use the minimum amount of vertical space required for it's content the way a table does by default.

I would prefer to write semantic code, but there's just too many bizarre design decisions made in the development of CSS and the float model, and far too many browser incompatibilities.

Re:HTML skills are a commodity? (1)

Lord Ender (156273) | more than 6 years ago | (#21663317)

For an AJAX project, the ability to work with javascript disabled is a moot point--thus invalidating your event handler argument.

To the CSS, div, and table contention: You seem to be completely unaware of the fact that clients pay for the way the page/app LOOKS, not for strict adherence to HTML/CSS philosophy. In the real world, aesthetic-only divs are sometimes necessary to produce the look the client wants--to win the contract. Being a CSS purist is of little value when you are unemployed.

Re:HTML skills are a commodity? (2, Insightful)

Bogtha (906264) | more than 6 years ago | (#21663453)

For an AJAX project, the ability to work with javascript disabled is a moot point--thus invalidating your event handler argument.

Did you read past the first few words? I gave examples of opening links in a new tab or window. This is a problem for javascript: links regardless of whether Javascript is switched on or off.

In any case, why is the ability to work with JavaScript disabled a moot point just because Ajax is used? Just because you use Ajax, it doesn't mean that you need to give up on situations where JavaScript is disabled.

You seem to be completely unaware of the fact that clients pay for the way the page/app LOOKS

We're talking about how well a developer understands HTML, your tangent about what clients pay for is irrelevant to that.

Re:HTML skills are a commodity? (1)

cbart387 (1192883) | more than 6 years ago | (#21662759)

Uh, DIVs are better than tables for layout.
Maybe if you're designing for a single browser. If you have a wide audience, and have to code for multiple browsers/versions divs don't always work. Sometimes you have to do ugly hacks to get it looking consistent. I'm normally about my code looking nice, but I'd rather that the user can see the website how I want it to look then for it to look 'perfect' in a 'View Source'.

Re:HTML skills are a commodity? (0)

Anonymous Coward | more than 6 years ago | (#21662563)

Repeat after me: tables are not intended, nor suited, for layout.

Re:HTML skills are a commodity? (4, Insightful)

Frosty Piss (770223) | more than 6 years ago | (#21662611)

Repeat after me: tables are not intended, nor suited, for layout.
What a particular tag was meant for when it was first implemented is entirely irrelevant as to if it can be effectively used to do something.

Re:HTML skills are a commodity? (1)

Bogtha (906264) | more than 6 years ago | (#21662747)

I never said they were.

Re:HTML skills are a commodity? (1)

thomthom (832970) | more than 6 years ago | (#21662649)

I strongly disagree that divs over tables for layout is idiocy. Making a layout neutral HTML is essential in order to get your site working with browsers, screenreaders, print, not to forget the rapidly increasing number of handheld devices accessing the web now. And with mashup services popping up and more and more tool utilizing microformats, proper semanic is more important than ever.

Re:HTML skills are a commodity? (1, Insightful)

Bogtha (906264) | more than 6 years ago | (#21662833)

I strongly disagree that divs over tables for layout is idiocy.

It is idiocy because it shows a complete lack of understanding of the separation of content and presentation. <div> elements are content, not presentation.

Saying that <div> elements are for layout is exactly the same mistake as saying that tables are for layout. The consequences are less severe because the <div> element type has almost no associated semantics to pervert, but it's still the same mistake.

marchitecture alert (4, Insightful)

anomalous cohort (704239) | more than 6 years ago | (#21661891)

I claim first serious post.

Most of these questions appear to me to be either leading questions, whose intent is to foment desire in the questioners product(s) and/or service(s), or marketing questions.

Some of the questions are legit, however. For example, those questions concerning security, performance, unit testing, and analytics.

With regards to the question about which framework to choose, I have posted my favorites here [transitionchoices.com] .

the suck/non-suck divide (4, Informative)

abes (82351) | more than 6 years ago | (#21661919)

I think a large part of the people's opinion on AJAX depends on what they're doing. It's difficulty depends in part on the framework/libraries you use. For example, script.aculo.us and RoR hide many of the details for you. On the other hand, if you do outside of what they do well, the difficulty level quickly rises.

I think one sign of this difficulty is that just about all AJAX libraries do the exact same thing. The same basic special effects, field additions, etc. The fact that none of the libraries go beyond these, points to what's hard to do.

Javascript isn't a great language. It's not robust, and it's difficult to really do good architecture with libraries using it. HTML is a pretty decent method to mark up text, but wasn't meant originally to ever be interactive.

Tying together a hacked together language with HTML doesn't make for the greatest programming experience. Especially compared to any real GUI framework.

Maybe most people don't want/need a real GUI framework, and AJAX covers all the bases for them -- in which you're probably going to say you like AJAX.

However, I suspect if AJAX and HTML were really so great/powerful/easy, many people would have stopped using flash already. I have no love for flash, but it can do things much more easily/faster than AJAX can for many tasks (disliking both technologies I'm pretty non-biased here).

What I would love to see is a standard *real* GUI for the web that is non-language dependent (i.e. whatever scripting language you prefer you can use). I'd even use something like Jython with newer/better GUI libraries. But we really need something written from the ground up with GUI in mind.

Re:the suck/non-suck divide (1)

TedCHoward (920331) | more than 6 years ago | (#21662153)

Tying together a hacked together language with HTML doesn't make for the greatest programming experience. Especially compared to any real GUI framework.
...
What I would love to see is a standard *real* GUI for the web that is non-language dependent (i.e. whatever scripting language you prefer you can use). I'd even use something like Jython with newer/better GUI libraries. But we really need something written from the ground up with GUI in mind.
You should take a look at ThinWire [thinwire.com] , which is a *real* GUI framework for the web. It allows the developer to create a web application using the same paradigm as desktop application development. It is written in Java, and therefore you can code in any scripting language that runs on the JVM.

Re:the suck/non-suck divide (0)

Anonymous Coward | more than 6 years ago | (#21662201)

What I would love to see is a standard *real* GUI for the web that is non-language dependent (i.e. whatever scripting language you prefer you can use). I'd even use something like Jython with newer/better GUI libraries. But we really need something written from the ground up with GUI in mind.
like XUL [faser.net] ?

Re:the suck/non-suck divide (5, Interesting)

Osty (16825) | more than 6 years ago | (#21662301)

Javascript isn't a great language. It's not robust, and it's difficult to really do good architecture with libraries using it. HTML is a pretty decent method to mark up text, but wasn't meant originally to ever be interactive.

Once you understand it, Javascript is an awesome language. It's C/C++/Java-like syntax hides its fundamentally functional underpinnings. The core datastructure in Javascript is a method. Everything can be represented in terms of methods, even to the point of not using any variables. With that in mind, it's a very powerful language that is often maligned precisely because of what it is -- many people just don't "get" functional languages (why C/C++/Java/etc are so popular and Lisp/ML/Haskell/etc are not), though you can certainly write procedural or even OO code in Javascript. It's also very easy to shoot yourself in the foot with Javascript, depending on implementations (using anonymous methods is a good way to leak memory in IE if you're not careful, for example).

As a scripting language, Javascript has a lot too offer. Too bad it's been forever tied to HTML and web stuff.

However, I suspect if AJAX and HTML were really so great/powerful/easy, many people would have stopped using flash already. I have no love for flash, but it can do things much more easily/faster than AJAX can for many tasks (disliking both technologies I'm pretty non-biased here).

People like Flash because it gives you lots of pretty, shiney bits for very little work. It's also vector-based, so you can build a pixel-perfect layout like so many bad web designers want ("Our web site must look exactly like our magazine"). Too many people associate "AJAX" with flashy Web 2.0-y visual effects (fading highlights, rounded corners, wet reflections, large fonts, etc), when AJAX is really about communication. If all you care about is glitz, go ahead and use Flash. If you want to build something that actually works well, I'd go with javascript+HTML.

However, I suspect if AJAX and HTML were really so great/powerful/easy, many people would have stopped using flash already. I have no love for flash, but it can do things much more easily/faster than AJAX can for many tasks (disliking both technologies I'm pretty non-biased here).

You may not want to hear it, but Microsoft has much of that with ASP.Net AJAX [asp.net] , as have others like Script# [nikhilk.net] . In each case, you're writing most (or all, in the case of Script#) of your code in a .NET langauge and the compiler handles generating the javascript appropriate for your target browser(s). These work with at least Firefox and IE, and should also work with Safari, Opera, and others with minor tweaking.

Re:the suck/non-suck divide (1)

abes (82351) | more than 6 years ago | (#21662625)

I'm actually a big fan of both OOP and functional programming (e.g. I like both C++ and Scheme). I should also point out that C++ is and never has been a purely OOP language .. Bjarne Stroustrup has gone to great lengths to ensure this. While template hacking has its own issues, Boost actually provides a good deal of functional-programming functionality through use of templates.

I know there are some proponents of Javascript. Yes, it's nice that it provides things like closures. But I'm not a huge fan of the syntax of the language, nor have I ever felt it was feature complete (at least the libraries provided for the web). Flash makes much better use of javascript, but I think very few people would claim it's a great solution. People use it because there aren't many alternatives.

I'm a big Python advocate myself. Yes, the whitespace issue is really annoying, but once you get past that, it does a lot that other scripting languages don't. Oh, and here's the obligatory XKCD comic to prove my point:

http://www.xkcd.com/353/ [xkcd.com]

I would be willing to try out ASP.Net, though I'm going to guess I can't actually develop for it since I own a Mac.

Also, more importantly, I don't actually want a solution that spits out more HTML. I don't want my GUI in a web browser. I want a real actual GUI on its own. Kinda like what Java can, only with a lot less Java (oh, and a much better designed GUI).

Re:the suck/non-suck divide (1)

Osty (16825) | more than 6 years ago | (#21663111)

I'm a big Python advocate myself. Yes, the whitespace issue is really annoying, but once you get past that, it does a lot that other scripting languages don't. Oh, and here's the obligatory XKCD comic to prove my point:

Python is great, but when dealing with the web you either have to stick to web-standard languages (ECMAScript) or try to get another language standardized (which probably wouldn't be Python). Obviously if you take the web out of it, things open up considerably.

I would be willing to try out ASP.Net, though I'm going to guess I can't actually develop for it since I own a Mac.

You could run Parallels (which would require a Windows license, of course), or you could play with Mono [mono-project.com] . I'm not sure how much of ASP.Net 2.0 they support, nor whether ASP.Net AJAX runs on Mono, but it might be interesting to find out.

so, more importantly, I don't actually want a solution that spits out more HTML. I don't want my GUI in a web browser. I want a real actual GUI on its own. Kinda like what Java can, only with a lot less Java (oh, and a much better designed GUI).

Then you're not talking about AJAX or web development. You're talking about traditional "rich client" development, which many languages can do. Speaking of Javascript, JScrpt.NET [wikipedia.org] is a full .NET language based on Javascript/JScript/ECMAScript, and as such has full access to .NET libraries like Winforms or any of the gui toolkit bindings like Qt# or GTK# (for use with Mono, mostly).

Re:the suck/non-suck divide (0)

Anonymous Coward | more than 6 years ago | (#21662433)

"something written from the ground up with GUI in mind."

Like, ummm, Flash?

Re:the suck/non-suck divide (1)

abes (82351) | more than 6 years ago | (#21662681)

I think I used the modifier good too. If not, I apologize. I'd like it to be good.

As far as I can tell, Flash was never intended to do complex GUI things. It's only with the last release of Flash that it allowed a completely code-based GUI to be created (and not all of that crazy timeline editing). And even still, adding the controls, creating their handlers, etc. is horrible.

If the future is making Flash GUIs, I do not welcome the future.

Make a new protocol already! (1, Insightful)

Anonymous Coward | more than 6 years ago | (#21662055)

Toss out JS, and put python on both client and server.

Toss out HTML and make an XML based form layout language, with a *proper* rich widget set, and GTK-style splitter based layout mechanics.

Toss out the request-response paradigm and go with a proper connection.

In other words, make it a browser based application framework, because that's what people actually seem to want.

All this AJAX malarkey is just a *huge* kludge.

when will AJAX skills become commoditized? (5, Insightful)

Ralph Spoilsport (673134) | more than 6 years ago | (#21662085)

'On what timeline will AJAX skills become commoditized like HTML skills became?'"

Easy: when a WYSIWYG editor, a la Dreamweaver, can accomplish all basic AJAX functionality without having to mess with much, if any, code.

Yeah - sure - Dreamweaver is suboptimal, but for 95% of what you need in a site (and if your site is fairly simple, 100%) it does the job, just fine, and you don't need to mess with that messy HTML and javascripty goopety glop. you just treat it like InDesign or Quark, and design your page - no muss, no fuss, nothing too fancy.

When Dreamweaver (or some similar app yet-to-be-developed) can do Exactly That - let me do AJAX without touching code, then you know AJAX coding skills will commoditise and disappear. How many hear can read PostScript, raise your hands! Not too many. I figured as much... FreeHand, Fontographer, and Illustrator removed the need to know how to program a page description in PostScript. Dreamweaver ate HTML and trivial Javascript. AJAX is next... I'd say, give it 2 years. Tops. I'm sure the programmers at Adobe are hard at work mulling over how to do just that.

RS

Re:when will AJAX skills become commoditized? (1)

fireboy1919 (257783) | more than 6 years ago | (#21663171)

but for 95% of what you need in a site (and if your site is fairly simple, 100%)

My experience is more like "25% of what you need in a site (and if your site is fairly simple, 5%)"

Fairly simple means that you need to spend more time to make the look & feel work right, because people will notice it more, and you can't use a WYSIWYG for that kind of thing unless you don't care at all about page flow.
By default Dreamweaver treats pages like they're not going to have to work at multiple resolutions/fonts - fixing the size of every single element in the pages. It's telling that you mention two programs that do exactly the same thing. HTML flows. You aren't supposed to treat it like print.

It also doesn't work too well with non-html markup (such as PHP, ASP.net, jsps, etc). This is fundamental to the nature of HTML. It can't be done properly with a WYSIWYG. It needs a WYSIWYM to work.

Re:when will AJAX skills become commoditized? (1)

TheMCP (121589) | more than 6 years ago | (#21663343)

>>'On what timeline will AJAX skills become commoditized like HTML skills became?'"
>Easy: when a WYSIWYG editor, a la Dreamweaver, can accomplish all basic AJAX functionality without having to mess with much,
>if any, code.

Why does it have to be that difficult?

Here's a complete AJAX app in Water (waterlanguage.org), with an object that represents a boat, and you can use AJAX to change the name of the boat:
<class biz.boat name=req=string>
    <method change_name new_name=req=string> .<set name=new_name/> .<refresh/>
    </>
    <method htm_inst>
        <span>
            <h1 .name/>
            <do .change_name.<htm_inst _subject/> />
        </>
    </>
</>

Do you see the AJAX? No? But it's there. The language takes care of it for you. So why does it have to be difficult?

how far HAVE we come? (5, Insightful)

vsync64 (155958) | more than 6 years ago | (#21662109)

It does suck.

As for the "refreshing[] hard-headed" questions, all I see are questions about performance and silly flitting about with their own buzzwords and pipe dreams about getting rid of real applications in favor of their toys.

Here are some questions:

  • Whatever happened to degrading gracefully? If you look at the apps produced by Google, the poster child for "AJAX", you'll see that they took the time to make most or all of the functionality work without JavaScript, without images, without CSS, or with a deranged hodgepodge of those. I don't see others making the same efforts.
  • How about semantics, and security? We're getting back into the mess of data intermingled with code. I'm seeing more and more sites out there have a blank page that loads, and then JavaScript that loads the content. Now you have to have scripting enabled for every site you visit. MS Office macros all over again. And forget trying to spider the content without having some sort of bizarre Turing machine debugger to try to get at the real content.
  • Yeah, how about mobile devices? If you were doing it right (see above) you wouldn't have to worry about the iPhone or about a special mobile AJAX. It would work fine within the constraints of any device. Google does.
  • How do you plan to interact with the local filesystem? Java has an effective sandbox, signed codebases, and granular user permissions (although the latter are kind of sucky). Are users not allowed to retain control over their own data?
  • How are users supposed to have any confidence about what you're doing to them? The previous model was good. Users knew when they were sending anything to the server, and if the UA vendors would do their jobs they would also know when they were affecting data [w3.org] . What are users supposed to do now, have wireshark running all the time? Not acceptable.

I'm implementing Web-based applications as of this writing, and I plan to have some dynamic features to simplify some of the UI (such as cascading follow-up questions during user signup). But these will be an optional extra.

These jokers forget that the World Wide Web is a repository for mutual citation of academic-style documents. New stuff is good, just don't break the old stuff.

Every improvement on the Internet has been in the direction of better user controls, decentralization, caching, peer-to-peer, transport tunnels, etc. The AJAX people are swimming against the tide and they need to realize it and shape up.

Re:how far HAVE we come? (1)

MightyMartian (840721) | more than 6 years ago | (#21662721)

I'm with you. I've used a bit of AJAX coding, very basic stuff, to make a set of client management pages work a little better (ie, checkbox settings that update the underlying database field without reloading the page). I think, unless you really know what you're doing and are really willing to put the time into it, that pure-AJAX apps are a danger zone.

While I agree with some other posters that browsers are a horrible application platform, when has that ever stopped an application platform from being useful? I think once some of the more serious concerns can be addressed, then I see no reason why it couldn't be used as a development and distribution platform for some kinds of apps.

Re:how far HAVE we come? (1)

Garberage (1191783) | more than 6 years ago | (#21663165)

So many of your complaints about the abundance of poorly designed AJAX sites are compared to Google. I know that in the companies I've worked for, we strive to support as many browsers and devices as possible. After all, the more places your site works, the more you can sell. However, we are all not Google. Nor do most companies have the financial resources that Google does. For each additional device you want to support, you need further development. Using your example of Google, it can really work great on mobile devices. Do you think this was an accident? No. There is probably a team of 50 or so people dedicated to the task of designing, implementing, and maintaining the portion of the application that works on phones. So while it would be great for all AJAX applications to work everywhere, most of us are just trying to satisfy the 80-20 rule, as that is all the time/money we have available to us.

Re:how far HAVE we come? (0)

Anonymous Coward | more than 6 years ago | (#21663247)

I wish this could be modded 6. "How are users supposed to have any confidence about what you're doing to them?"

I don't trust AJAX, and JavaScript to start with is a huge attack vector. How is JavaScript 2.0 better?

From the start... (1)

ThePromenader (878501) | more than 6 years ago | (#21662175)

...Ajax is a project in hype -- strip all the cruft away and it comes down to one frigging javascript command. That aside, it has its uses. That is, if it is used wisely.

The only thing I disparage in Ajax is its lack of a back button. All the rest is positive in my books -- time/bandwidth-saving partial page reloads, perhaps the elimination of the "disorientation factor" that can occur with total page reloads (That "Wha? What's taking so long to load? Where the hell am I now?" feeling that grows proportionally the shorter the short-term memory/attention span). I like the feeling of control it gives a user (he's selecting the information he wants without being bandied all over the place). I've built a website using a mix of php/mysql/ajax and it's working fine for our customers -- not one complaint -- au contraire in fact. Have a look here [matphot.com] if you like. What I like the most (in that site) is the fact that our customers can always keep their "shopping cart" (rather "rental cart") always on hand, and add/eliminate things to/from it no matter where they are in the site. I'm not sure of the numbers yet, but this has been a big boost to our client base.

Another Ajax drawback could be its un-friendliness to search engines -- but there is a workaround for that (a liberal use of hard-coded links with added "onClick" functions), but this means that you have to build your website in two different-functioning levels. This takes a bit of thought beforehand, but it can be done.

As for Ajax's future: of course. But forget the buzzword and the technology behind it; it's what the technology does that will be sticking around in one form or another. For example, it is possible to build a full-Flash website that behaves exactly as Ajax - with even more search-engine limitations and added "plugin" requirements -- so I think more than a few see the merits of partial page reloading.

Re:From the start... (1)

NiK0laI (1012851) | more than 6 years ago | (#21662507)

Cool site, however it pegs my CPU as soon as I click on any of the menus, and they come down really slow. I'm using latest Firefox under Windoze XP on a 2.8 p4.

Re:From the start... (1)

ThePromenader (878501) | more than 6 years ago | (#21663369)

Thanks. Yep, I know what you mean about those unfolding menus... I wish there was a faster/less CPU-taxing way to go about it, but hey. Firefox seems to be deathly slow in all things javascript (especially loops), but I suppose I should be taking that into account as well; I may just add a "bypass animation" button for that. I just added the search engine yesterday, so here's hoping that many will make liberal use of that - I think many will, as, no matter how lovely some animations may be, who likes to comb through menus to find something?

silverlight (5, Interesting)

wwmedia (950346) | more than 6 years ago | (#21662211)

i know alot of people here hate microsoft (duh!)

but i believe silverlight will be a large part of the rich web

now this is my personal opinion and heres why:
*it was designed with web applications in mind (XAML) unlike the current html/css/javascript mess
*its more or less crossplatform
*it brings C# to the clients browser (see javascript mess above)
*has vector and hd video supprt of the box
*is designed to be easily updated

Re:silverlight (1)

WWE-TicK (593858) | more than 6 years ago | (#21662443)

I prefer Flex for now because 1) I already know it, 2) Flash has larger market penetration. Presumably, you can use any .NET language for Silverlight development, so that's a major plus for Silverlight IMHO. With Flex, you're stuck with ActionScript 3 and MXML. ActionScript 3 and MXML aren't really all the bad, but it's nice to have options. Also, the Silverlight runtime will probably come standard with all Windows versions from here on out, so it can potentially kill off Flash if Adobe doesn't do something about it.

Interoperability (1)

gsnedders (928327) | more than 6 years ago | (#21662345)

What we still need is to continue moving towards full interoperability. Hopefully having a proper spec [w3.org] will help with that.

Behaviour such as handling of getResponseHeader(header) when no header exists still varies: IE returns null, Fx/Opera return an empty string. If you want to check if a header exists, claiming it is an empty string isn't helpful.

AJAX vs. Flash is the real question (-1, Troll)

Anonymous Coward | more than 6 years ago | (#21662373)

How long before people abandon AJAX and just use flash for everything? Much more reliable.

Re:AJAX vs. Flash is the real question (0, Redundant)

ThePromenader (878501) | more than 6 years ago | (#21662659)

Well, as soon as search engines learn how to "read into" flash, for starters. Otherwise the web (for Google) will turn into one giant, blank page.

Re:AJAX vs. Flash is the real question (2, Insightful)

LWATCDR (28044) | more than 6 years ago | (#21662817)

Why?
Yes people that use flash for layout and menus are just as stupid as people that used Java buttons.
But Google doesn't need to read applications.

Re:AJAX vs. Flash is the real question (1)

Ralph Spoilsport (673134) | more than 6 years ago | (#21662897)

How long before people abandon AJAX and just use flash for everything? Much more reliable.

when flash stops sucking? Flash is NOT a solution. Flash is a proprietary disaster in slow motion. AJAX is not a happy thing, either, but between AJAX and Flash, I'd choose AJAX every time.

RS

AJAX is already dead (0, Offtopic)

richieb (3277) | more than 6 years ago | (#21662859)

Move on to FLEX....

Checkout labs.digg.com for some cool FLEX/Flash apps. Try doing that in AJAX...

Personal experience with AJAX (1)

heroine (1220) | more than 6 years ago | (#21662943)

The main thing I know about AJAX is the traffic nightmare it's boom has created on 680.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?