Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Programming The Internet IT Technology

The Future of AJAX and the Rich Web 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?'"
This discussion has been archived. No new comments can be posted.

The Future of AJAX and the Rich Web

Comments Filter:
  • by doroshjt ( 1044472 ) on Tuesday December 11, 2007 @04:30PM (#21661649)
    It already is. What is so hard about it?
    • Re: (Score:3, Informative)

      by brunascle ( 994197 )
      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: (Score:3, Interesting)

        by misleb ( 129952 )
        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: (Score:3, Insightful)

          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: (Score:3, Insightful)

            by misleb ( 129952 )
            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: (Score:2, Interesting)

          by SnapShot ( 171582 )
          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
        • The hard(ish) part is making an app that is completely AJAX.

          Forgive my ignorance if this is obvious, but why would you want to do that? Surely using AJAX should be a complement to traditional web pages, not a replacement. I like seeing the URL change as I browse different resources on the web, and as a user am repelled by apps which break my back button, don't let me save state, and basically break the web. This really annoys me about gmail - though I understand there that they're dealing with info you're n

          • by misleb ( 129952 )

            Forgive my ignorance if this is obvious, but why would you want to do that?

            For applications that are richer and more responsive than traditional, page refreshing apps. Webmail and calendaring, for example. Also, administrative interfaces for various hardware such as routers, network copiers, etc. These things don't work very well with document oriented interfaces, IMO.

            Surely using AJAX should be a complement to traditional web pages, not a replacement. I like seeing the URL change as I browse different re

        • The hard(ish) part is making an app that is completely AJAX. As in, loads from a single page and never refreshes after that.


          Why would this even be a goal? What would be the point? What are you trying to accomplish? What's wrong with the browser loading pages? Isn't that the whole purpose of a browser? Otherwise build your own downloadable GUI and use whatever client/server protocol you like.

      • by Larry Lightbulb ( 781175 ) on Tuesday December 11, 2007 @04:49PM (#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.
        • Sure, no problem [fuckinggoogleit.com].
        • 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: (Score:2, Informative)

          by brunascle ( 994197 )
          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.
        • by hobo sapiens ( 893427 ) on Tuesday December 11, 2007 @06:22PM (#21663567) Journal
          How well do you know javascript?

          As someone else pointed out, XMLHTTPRequest is what makes AJAX tick. But without knowing Javascript, what are you gonna do with it?

          Assuming you are very good with javascript, here are two resources for you. 1 will help you see what the XMLHTTPRequest object does. 2 will help you tame it a bit and abstract things.
          [1]: http://w3schools.com/ajax/default.asp [w3schools.com]
          [2]: http://www.prototypejs.org/learn [prototypejs.org]

          The thing is, the AJAX bit is a very small part of the total AJAX package. Then you'll need to learn JSON (a good data interexchange format) and how to use Javascript to create elements.

          There, now that I have provided what you asked for and not just some smart alek remark about how you need to google it, this has to be said...If you seriously expect to master a useful skill in an afternoon, then you have some expectation issues. If there's one thing life has taught me, it's that something worth having doesn't come in a day, and if it does come in a day, it's probably not worth much. Did you learn to program in one day? No? Then why would you expect to learn a complex object and a totally new technique for making web applications on one day? But if you really want to learn then you'll thank me for those links later when your web development reaches the next level. If you are just bashing AJAX with a cudgel of ignorance, then you'll ignore those links and keep griping about AJAX being too hard. I guess time will tell.
          • No, I don't expect to learn everything in an afternoon (& it turned out I've been busy, so couldn't have), my comment was a response to the idea that AJAX is easy.

            Some people may find it easy to write an AJAX solution for something, but as your posting and others point out, there's a lot of learning to do before you can get to that stage. Anyone can be a concert violinist if they're willing to spend eight hours a day practicing.

            And to me, that stops it being easy.
      • by jma05 ( 897351 ) on Tuesday December 11, 2007 @04:53PM (#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.
    • What is so hard about it?

      Not using it.

    • by rhizome ( 115711 )
      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!
    • by SharpFang ( 651121 ) on Tuesday December 11, 2007 @05:41PM (#21662927) Homepage Journal
      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: (Score:3, Insightful)

        by Just Some Guy ( 3352 )

        porting large parts of business logic to JS to offload your application servers,

        Whoa, hey, full stop. I was with you until then, but... You're really trusting your business logic to the least controlled (both in the "security" and "standardized" sense) part of the stack? Ouch. Good luck, man.

      • Re: (Score:3, Informative)

        by iamacat ( 583406 )
        I am sorry for the abuse you went through. I dabbled a bit with JavaScript and gave up when I found out that <img src="foo.gif" style="width: 50%;height:50%;"> does not work in IE, even the latest version of IE7. So I installed http://code.google.com/webtoolkit/ [slashdot.org]>gwt and gwt-ext [google.com] and had the first page of my application running in a couple of days using nothing but the plain Java code. I create a tree of serializable Java objects on the server and get the same tree on the client and then use it to up
        • I don't think you'll find any web developers who like IE. That said, what did you expect <img src="foo.gif" style="width: 50%;height:50%;"> to do? In other words, you wanted the width and height to be 50% of what? The image or the thing that contains it? I think maybe the browsers didn't do what you wanted it to and instead of finding out why you just gave up. The web is a great platform, but since browsers can be really sketchy, you need to understand why some things go wrong. This is essential
          • by iamacat ( 583406 )
            The image tag is in a div with dimensions set in points. CSS standard is quite clear on the meaning of the styles in this context and I tried various combinations of position:absolute and position:relative on div and the image to no avail. IE's actual behavior is to either not scale the image or sometimes to not display it at all. The result depends on container hierarchy and other styles of the image. I think in cases where browser's behavior is so flaky and not easily documentable or worked around, it's b
            • Re: (Score:3, Informative)

              Please do not take offense, but the fact that you tried using the position property shows that you don't really understand CSS that well. That's not meant as an insult, just a statement of (apparent) fact. I just wrote a very simple page (just a div and image tag, no doctype or anything) that had this content:

              <div style="width:40pt;height:40px;border:solid;">
              <img src="foo.png" style="width:50%;height:50%;" />
              </div>


              That displayed the image correctly in Firefox and IE6, the
      • Re: (Score:2, Insightful)

        by CandideEC ( 953336 )
        You can skip of a lot of that crap if you just learn Java and use GWT. I mean *really*...is there any other option?
      • by sackeri ( 704269 ) on Tuesday December 11, 2007 @06:50PM (#21663989)
        You just can't say it any better than that.

        From a lot of the comments I get the impression that most people really don't get it. AJAX is incredibly useful, but it's mostly a really clever hack. The need for dynamically updating elements on the web page is definitely there, and AJAX manages to fill that need somewhat. But Javascript/DOM + XML/HTML is a terrible set of tools to build GUI widgets with.

        AJAX works by sweeping the nitty-gritty details under the rug, but scratch the surface, and you realize how filthy the whole thing is. The first time you try to use a cool feature of your favorite GUI widget, and expect it to work the way your favorite desktop widget does, the cool-factor quickly degrades into frustration. Even with some of the best libraries out there, they still don't seem to have the problem licked.

        It's amazing how far we have gotten with the tools available, but there really is a threshold forming due to these weaknesses. I'm not smart enough to envision how to get there, but there really needs to be a fundamental change that better integrates these technologies. Otherwise we're gonna be in spaghetti-code hell for a quite some time to come.
  • 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.
  • by Bogtha ( 906264 ) on Tuesday December 11, 2007 @04:41PM (#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.

    • <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.
    • 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: (Score:2, Informative)

        by brunascle ( 994197 )

        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.
      • by Bogtha ( 906264 ) on Tuesday December 11, 2007 @05:28PM (#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.

        • by Osty ( 16825 ) on Tuesday December 11, 2007 @05:42PM (#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.

          • by Bogtha ( 906264 )

            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

            • Re: (Score:2, Insightful)

              by Osty ( 16825 )

              Yes, and what was the motivation for using

              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.

              Now you're just being pedantic. Obviously it's the CSS that positions things in your layout, but w

              • Re: (Score:3, Insightful)

                by Bogtha ( 906264 )

                Now you're just being pedantic.

                No, it's not pedantry. This isn't merely a case of wrong terminology, it's a sign that a developer is looking at something in a completely upside-down way.

                most people will call the latter "div layouts" just because it's easier to understand

                "Div layouts" is not easier to understand than "CSS layouts".

                "I laid out all of my stuff using table cells. What should I use if I can't use those?" "Divs styled by CSS"

                If you tell people to replace layout tables with

                • Sorry, I vote for pedantic. Also, kind of condescending. You know what he meant, stop being a jerk to prove how much smarter you are and start being nice.
                  • by Bogtha ( 906264 )

                    I'm not being a jerk to prove how smart I am, I'm not being nasty, I'm trying to explain a fundamental flaw in the way many people understand HTML.

                    If you disagree with anything I am saying, then by all means explain why. But don't just call me names while ignoring the technical matters. That is being a jerk.

          • by jddj ( 1085169 )
            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...
          • 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, a
        • 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: (Score:3, Insightful)

            by Bogtha ( 906264 )

            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 situ

  • by anomalous cohort ( 704239 ) on Tuesday December 11, 2007 @04:45PM (#21661891) Homepage Journal

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

  • by abes ( 82351 ) on Tuesday December 11, 2007 @04:46PM (#21661919) Homepage
    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.
    • by Osty ( 16825 ) on Tuesday December 11, 2007 @05:06PM (#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.

      • by abes ( 82351 )
        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
  • by Ralph Spoilsport ( 673134 ) on Tuesday December 11, 2007 @04:55PM (#21662085) Journal
    '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

    • 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 - f
    • by TheMCP ( 121589 )
      >>'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=str
    • by raddan ( 519638 )
      If what you're predicting comes true, then we haven't even seen the tip of the iceberg for web-application attacks. For your typical designer to be able to do this stuff, we need some other kind of technology, because input validation done in Javascript ain't gonna cut it.
  • by vsync64 ( 155958 ) <vsync@quadium.net> on Tuesday December 11, 2007 @04:56PM (#21662109) Homepage

    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.

    • 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 use
    • AJAX isn't about making static content more interactive. It is about replacing thick-client applications with thin-client webapps. [OK, I admit there is some of both].

      You may think AJAX "breaks" the ability to link and index content, but please tell me how you were liking and indexing thick-client apps before? You weren't. Nothing breaks. It's progress.
  • silverlight (Score:5, Interesting)

    by wwmedia ( 950346 ) on Tuesday December 11, 2007 @05:01PM (#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

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

      Or you could try Mozilla's XULRunner:

      • It was designed with web applications in mind (XUL), unlike the current mess
      • It is crossplatform
      • It brings JavaScript to everyone
      • Has support for all kinds of stuff (see Miro for an example)
      • Is designed to be easily updated
      • Already exists in production
      • Isn't some Microsoft hack
    • Re: (Score:3, Informative)

      by moreati ( 119629 )
      You are wrong, the web is a sloppy combination of repurposed standards and half-implementations that has evolved. It isn't clean, it isn't pretty but it works for the widest range of people: those with a web browser.

      Silverlight is like flash, only worse:
      * It ignores all the work on document layout and styling, instead it chooses to reinvent the wheel. XAML is untested beyond a few Windows developers and power users on Windows with a PC. HTML has been deployed, tested & debugged on about every platform i
  • The main thing I know about AJAX is the traffic nightmare it's boom has created on 680.

  • AJAX directions (Score:4, Interesting)

    by Stan Vassilev ( 939229 ) on Tuesday December 11, 2007 @06:37PM (#21663787)
    I see few recurring themes in the questions asked, so I'll try to cover them briefly:

    Q1: How do you deploy an AJAX application offline?
    A1: You can use integrated HTML/CSS/JS/Flash/PDF runtime, like Adobe AIR [adobe.com].

    Q2: How do I deliver bulky complex AJAX applications over the net, if it's a lot of code?
    A2: You don't. It's not a suitable deployment model, at least until we have a simple delivery vehicle for bundling multiple app elements into a single file, such as a browser downloading and directly reading a ZIP file with collection of resources/JS files (as with Java's JAR). Until then, and for complex UI-s in general, look into established compiled solutions like Flash.

    Q3: Do we need JS2.0?
    A3: No, we don't (right now), since JS2 delivers benefits for larger projects only (refer to Q2 why large online JS projects are not viable). If this is resolved, then JS2 will be highly desirable.

    Q4: Hand-made AJAX or AJAX framework?
    Q4: Framework. Cuts development time, provides consistent code, avoid wheel reinvention (Exception: very large projects may need custom code. Are you Google? Yahoo? If not, use a framework).

    Q5: Is AJAX wide-spread / easy / hard / common?
    Q5: It's easy, wide-spread, and accepted. Fallback is usually present, unless the AJAX is a component of a complex online app that can't have no-JS fallback (example: rich text editor).

    Q6: Do I pick AJAX or Web 1.0 / iPhone SDK ?
    A6: Apply common sense. In general, when a new technology comes around, people abuse it and try to shoehorn it into replacing everything before it [morfik.com]. Then comes the backlash ("AJAX sucks"). Only then, people settle to use said tech in moderation, co-existing versus replacing, evolution versus revolution, and solving unique problems not solved before.
  • How are we to fix the web?

    If I had a dollar for every time I've seen that question bandied about, I'd have at least enough money to see a matinee. Maybe even the 9pm show. Ever since the commercialization of the Web started in the late 1990s, there has been talk of "fixing" the Web. Java was going to fix it. XML was going to fix it. But nothing will "fix" the Web. It's an inherently messy environment, because of its openness. The bazaar is never as pretty as the cathedral. It's more dynamic, and it adap

  • AJAX still sucks (Score:3, Insightful)

    by Animats ( 122034 ) on Tuesday December 11, 2007 @09:18PM (#21665607) Homepage
    Reasons AJAX still sucks:
    • The concurrency model is lame and buggy. Open Google Maps in Firefox 2. Roll the mouse wheel rapidly to zoom in and out. Watch the maps break up as the browser gets out of sync with the server and doesn't properly repair the window damage. It's like a window system from 1990 or so.
    • Firewalls and AJAX still don't play well together. Rewriting JavaScript source in the firewall is not the answer.
    • The conflicts between cross-site scripting, mashups, and security illustrate that Javascript's security model is inadequate.
    • The JSON concept opens security holes. JavaScript has the wrong primitives. In LISP, there's the reader, which takes in a string and turns it into an S-expression, and there's "eval", which executes an S-expression. In JavaScript, there's only "eval", which takes a string and runs it. Oops. Not the right tool for marshalling.
    JavaScript itself isn't that bad a language, though. It's the integration with browsers that's not good enough.

The means-and-ends moralists, or non-doers, always end up on their ends without any means. -- Saul Alinsky

Working...