Perhaps, for now. Where I work (at a very, very large company) it seems like every big application release notification (enterprise wide apps), corporate communication, etc, etc comes with a flash movie embedded in it. Trust me, what was once a novelty quickly becomes an annoyance.
It's like they say, all emphasis is no emphasis. When every eMail is a dolled-up HTML doohickie, nobody will care anymore.
Agreed. Where I work, the big thing is (and has been forever) to send Flash(!) in eMail. I mean, come on! It's exactly what you said -- "push web". Pointy haired bosses love it. They sure won't like this new no HTML thing, so guess what? We'll just see more Flash.
Unbelievably, they still do. Of course, they scramble them and add zeros. But still...shocking that they still use SSNs for that. She said that they use SSN to log into the registers and ring out sales and salespeople routinely provide SSNs to co-workers so that they can ring out sales for the right person. Dillards offers to allow them to use a fictitious SSN, but amazingly nobody (including my wife, I found out) opted to use it because "who wants to have to remember another number?" Man, am I glad she's leaving that mess.
yeah, agreed. The last PC I bought was a Dell. It's a good PC, but I had to deal with the damn circus freaks they call employees. First, the World's Dumbest Man placed my order. Then the Girl Without A Native Language talked to my wife when the computer was two weeks late. Then, after my flat panel monitor was discovered to be DOA, I had to talk to the Sultan of Stupidia, who spoke quite a curious dialect, then the Worlds Most Inarticulate Woman, and finally Sri Bhagwon Rangoon and his Amazing Hold Button in order to get them to send me a replacement monitor. Like I said, a bunch of circus freaks.
After weeks of living in a surreal world of especially bad customer service, I got my new flat panel monitor as well as a free set of surround speakers (granted to me by the Ringmaster Suresh for my excessive troubles). In the end I got more than what I paid for and a new PC that is still working as well as when it was new. I just had to deal with Dell's merry band of lunatics to get it. I guess it could have been worse. And now I have funny stories to tell!
Please don't take this as flamebait, but how are we defining crapplets? Software that I don't want that is preinstalled for me? Well, in that case wouldn't XP or Vista, at least in some circumstances, fit this definition? Just because I *have* to pay for it doesn't mean I *want* it. Yet Microsoft strongarms PC vendors into preinstalling Windows and then passing the cost on the consumer. If I want an ubuntu box, for example, then to me Windows is an unwanted "OEM Crapplet".
Now that I got that off my chest, I do have to agree. The amount of garbage that is Preinstalled is atrocious. What's worse is that it's all trial software that bugs you until you buy it or uninstall it. Gimme a break! Trial programs are nothing more than ads. That's like buying a new TV and having to watch an hour of ads before you can watch any shows. It really is insulting and really not helpful at all. Not that it will *break* Vista, it sure as heck will continue to ruin the user experience.
Dillards is at the top of their list...this hits home for me. My wife just quit her job there. I have to say, that in the month she worked there I know enough to say that Dillards is the worst place to work for. Hear this:
1) if you don't meet sales targets, at your semi-annual review you get a pay cut. No, you don't get commission. You don't get a huge raise if you exceed your sales targets. You just get a pay cut if you miss.
2) Servant mentality. Employees are forbidden from using the store's elevators, escalators, etc. They must exit in the back of the mall, and even when it's dark out there is no security to ensure than employees get to their cars, and they must park in Antartica.
3) Judging from the previous item, you'd think there is no security. No, there is security -- to watch the employees. My wife had to ge a clear purse (really a bag) because she cannot carry in opaque bags. There is security watching them at their counters. They are watched in the stores. They are watched as they exit and enter. And the mall that she works in is in a good part of town.
4) Poor morale. In addition to mistreating employees, Dillards fosters a very competitive spirit among employees. So nobody likes one another.
5) Bad scheduling. My wife took this job because she has limited availability, since I work and we have two children. This leaves just a few evenings that she can work, and as such she was unable to get a job more like she is accustomed to. Well, of course, they scheduled her overnight to do inventory, which was flat out unnacceptable.
6) After about a month, my wife (being the honest, professional person she is) wrote a resignation letter. When she tried to hand it to the manager, he told her he could not accept it and instead she needed to fill out a form. Management proceeded to avoid her for the rest of the day. Needless to say, she never got a form. She made them take her letter. This is how they treat people who try to do the right thing and give notice. She should have just did a no show on a Saturday or something. That would have served them right.
So, while this site is obviously a not-so-reputable one, they are dead right. Dillards is a horrid place to work, and they deserve to go out of business. Hope you enjoyed reading this. It should make you feel *really* good about your job as you sit at your desk sipping a coffee. I know I do.
doing a single SQL select for a month range you want ~31 seperate DB calls, HTTP requests (incl. authentication and logging etc.)? And all for what, so you don't have to create the "table" server side?
Zoiks! * falls out of chair *
No, no, no. One DB call, one XMLHTTPRequest, which returns a JSON object.
I did not provide all the details here just because I didn't feel like typing them. Let me just say this isn't a 31 day calendar, but more of a scheduling application for workgroups (I just used calendar for simplicity of discussion). This is an application that admittedly was not the best candidate for a web app, but I had to make it work (this is for work, mind you, so there are business constraints). Building the page server side, there were scalability issues, for example with a large workgroup (250 users) the page size was something like 4M for a monthly schedule (imagine a table 31 wide by 250 high, each cell having onclick, title, style attributes...*shudder*). This same workgroup, after making the schedule get all the data via JSON arrays and build *some* HTML client side (but not the entire page, just the schedule grid), the page size is <40K and the total data transfer is <200K, not to mention it loads much faster now, usually less than 4 seconds. If you want to know more for the sake of knowledge, I will give you more details. If you just wanna argue, then I won't waste my time (though your post doesn't sound argumentative).
As for javascript compatibility/accessibility, I agree, not everything is a good candidate for this type of design. In fact, I'd say that you shouldn't use AJAX gratuitously. I am making a point to argue for AJAX as I am doing here because I feel like it is a valid and powerful tool. So is a jackhammer. That doesn't mean you use it to work on your car. In this case, it was either continue to kill the server or come up with a better way. I wasn't trying to go for "kewl" and bleeding edge. I simply needed a way to make an existing application work better.
This is on an intranet, so I do have the benefit of knowing that most users are using something sane like IE7, Firefox, Opera, or less sane, IE6. There is nobody using IE3 or something else crazy, and if they are, well, frankly my dear, I don't give a damn. On the internet, I would probably take the same approach, that is unless I really had to appeal to *everybody* for some reason (like Amazon.com or a.gov site would). As for the uber paranoid javascript disablers, I put a noscript attribute so that these user can at least know they are missing the content. Have I had any complaints? Not a one, and users are required to access this site so that they can get their work schedules. This is in a corporate intranet environment, and people around here just *love* to complain.
I recently needed to rewrite a web site so it works on firefox too... and the surprising element was that when testing the new and the old site on IE7 I found out that many things does not function as expected and "not function as expected" isn't the right word for it, it was more a question of working at all.
Funny, I have several very large intranet sites that use web standards, have a few hacks to make IE6 behave, and even a few places where I use <input type="image"/> for form submits. They all worked flawlessly in IE7.
It was probably something else in the author's code that was causing things not to work. For example, leaving the ; off the end of a javascript statement can have different effects in different browsers. But just claiming that <input type="image"/> caused the problem? I dunno, sounds fishy to me. This is how myths get started. How many people will read this article, then tell their co-workers to stop using <input type="image"/>? (not saying we should use images for submit buttons, but stop using them for the right reasons and not because someone thinks they don't work!) I don't particularly like IE, but it does seem that IE7 is at least a step in the right direction.
If anything, what could cause problems in IE7 is if all if the "IE only" hacks that were used to make IE6 behave itself still work and with odd results (since IE7 did fix much bad behaviour). That said, I personally haven't encountered that problem. It seems like it would happen, theoretically.
you clearly don't get the fact that not everything needs to be bookmarked. You also don't see how you can use AJAX to make the client take some load off the server and network.
As another reply to your message already stated, there is no sense arguing with you about this. If you don't like a particular technique, then don't use it. Just don't pontificate about the evils of a technology you obviously have no grasp on. I am done with you now. Bye.
Man, am I glad I am not the only one who feels like the whole "use OOP (java) everywhere for everything!" mantra is a bit cargo-cultish. Thank you. I thought there was something wrong with me for a minute.
When it comes to sites using AJAX, such bookmarks are often not possible.
My. Goodness.
Look. It depends on HOW AND WHERE you use AJAX. Jeez!!! Can we please put this to bed? Yes, if you design a whole flippin site that is one page with a zillion AJAX calls, well, gee whiz! Bad idea! But, if you use your brain and use it only where it ADDS VALUE then maybe, just maybe, it's a good thing? You think? Just because beer is a good thing doesn't mean you pour it in your gas tank, use it to make Kool-Aid, or bathe in it. I am SICK (can you tell?) of people misusing technologies and then blaming the technologies! Stop it!!!
AJAX applications just aren't solid or stable, for the most part. We tried to integrate a number of them into our network here, and frankly each attempt went terribly.
Do I have to do this? Do I have to tear up your bad anecdotal evidence that AJAX is teh suxx0r?
C++ applications just aren't solid or stable, for the most part. We tried to integrate a number of them into our network here, and frankly each attempt went terribly.
.NET applications just aren't solid or stable, for the most part. We tried to integrate a number of them into our network here, and frankly each attempt went terribly.
Java applications just aren't solid or stable, for the most part. We tried to integrate a number of them into our network here, and frankly each attempt went terribly.
In all cases, I'd kindly suggest the problem is not with the technology, but with the person doing the work.
Not being able to bookmark or use the back button? Those are gigantic problems.
Agreed, but like I said...it depends on what you use AJAX for. Plus, AJAX uses HTTP to get and retrieve data, which can be use to make HTML. It doesn't bend them.
For example, let's say you have a page where a user has some sort of an inbox from which the user can delete things, like system notifications. Next to each item, you have a delete link. Clicking on the link deletes the item, meaning javascript deletes the node from the DOM, and an AJAX call gets the thing deleted from the DB. Good use of AJAX. In fact, in an AJAX-less solution, ths user 1) has to wait for the whole page to reload, and 2) if the user presses the back button, depending on browser settings, the deleted events will seem to reappear. That could be confusing. This is one very simple example of where AJAX is great.
Consider another example. A shared calendar web application, that builds a table server side, gets all the data, runs security checks on each event to see what the current user can do to each event, and then presents the data. Building the table server-side, then pumping out tons and tons of HTML code will not only tax your web server, but also generate unnecessary network traffic. You could pretty easily refactor this application to build the table client side, and then send the data to the client via a JSON object. Now, the server page that builds the JSON object is built to check the user's cookie or whatever you use for authentication and it only sends the data that the user can see. The client takes this data and build the content client side. This is the network equivalent of purchasing a disassembled computer desk and taking it home to assemble it rather than purchasing the floor model and trying to cram it into your Mazda Miata.
I give these two examples because they are real life solutions I developed at work. Both are absolutely secure, and both save the user wait time. Also, these reduce the network and server load. What's not to like?
Of course, if you design a website whose navigation controls use AJAX, or some other weird use of AJAX you will get interesting results, and by interesting I mean bad. No offense, but I think you are saying that AJAX is a bad technology perhaps because you just don't know enough about it.
Both solutions are on an intranet, else I would gladly provide links. On the internet, would I use AJAX? Absolutely! I would, of course, use just a bit more caution...no, not because of security (I know how to make secure AJAX code) but because of browser compatibility. On the intranet, I use web standards and therefore all modern browser will work great. The nice thing is, though, you aren't going to have some weirdo using Netscape 3 or something like that. On the web, would I pander, er, I mean cater to this type of user? Depends on how much I needed them as a client.
If you want to learn more about AJAX and effective javascript constructs like JSON, check out these links: http://www.sergiopereira.com/articles/advjs.html and http://www.sergiopereira.com/articles/prototype.js .html for starters. One of these is the documentation for the prototype library, which I would recommend. I don't usually like using other people's code libraries in languages like javascript, but this one is quite good.
You could (and many do) make the argument that HTML is in the same boat. Yes it *works*. Does it provide a perfect environment for creating the complex, interactive web apps that we use it for? Heck no! Does anyone with any real power actually enforce standards? W3 who? And yet, in spite of its ugliness it works. It's a bit like wikipedia, in theory it sucks but in practice it works great.
If anything, I think it's a testament to the web development community that something so huge and robust can be hacked together with totally inadequate tools. It's like someone building a car with nothing more than a ball-peen hammer and a dull hacksaw.
Yes, and just because bad development techniques can cause security holes, we blame the technology. This is a bit like PHP being called insecure. Any language/platform/technique is insecure if the programmers leave gaping holes.
AJAX is a great technology. Yes, if you overuse it or use it in the wrong places then it is harmful. Saying AJAX is unstable, unusable, brittle, impractical is simply an untrue generalization. Like anything else, if you do it right it enhances usability and is quite reliable.
holy crap! You need to put that on Foldoc with some kind of name like <>'s Theorem. That's actually true! Especially about the part about most people not caring about how it works. Reminds me of something I read a long time ago: most users "satisfice", meaning they will search your application for a button/link that seems to be the closest thing to what they want and click/push it without really knowing what it is that they are doing.
Users muddle through most applications and somehow manage to get them to do what they need. This is also why sometimes things stay broken for a long time without the programmer ever knowing...because users will find another way to hack (loosely used here) at an application to get it to work anyway.
Heck, I'd bet that when you use a website you don't carefully read every option, you just pick the first thing that jumnps out at you and go from there. It's all trial and error, if one thing doesn't work something else will. And that's why you cannot get good requirements from users. That's also why programmers have to learn to think like users. Applications can be simple, it's just that programmers too often assume people will take the time to understand. Bzzzt! False!
In terms of software design, applications can be simple if programmers are smart enough to present the "right" complexity. It's all about choosing the right options. Yes, some users ask for configuration on top of configuration. Trouble is, that these get piled into the application for everyone to see. If people want advanced settings, they should have to ask for them. It's the good old Pareto Principle, aka the 80/20 rule. Do what 80% of your users need, and hide the complexity for the remaining 20% of people who want it.
You bring up the example of Linux, and I will go with you on that. Let's look at two common desktop environments: KDE vs Gnome. In my opinion, KDE is a miserable desktop environment because it assualts you with 50 bazillion options everywhere. Gnome seems to choose the right options and makes you go digging for more. If I had to choose a Linux distro for the masses, or at least, for my computer illiterate grandmother, it'd be one with a Gnome DE (ubuntu, to be precise). No way would I recommend KDE for people who are easily confused.
Complexity doesn't have to be in-your-face, and simplicity doesn't have to mean dumb.
Software should just work. Of course, that is oversimplified.
Too many times a project goes like this: Customer places request. Project Mgr talks to client. Requirement Analyst turns request from PM into low level requirements. Programmer reads requirements document, writes program. User gets program and guess what? It's not what he wanted! So, he places another request, and we are back to square one. Sound familiar?
Users request crazy things. Sometimes, they ask for things to work around other problems. The person writing the software should know, not what the Requirements person thinks the user wants, but what the user is actually trying to accomplish and why they are trying to do this. What is the user trying to do? Then, the programmer should make a proposal and necessary parties should either agree or disagree. This means that some requirements people are out of work, this means that the programmer has to be smart and communicate well, and that he has to spend time talking to users. And therein lies the problem.
We have IT departments that are so fragmented and people in them are so specialized. Programmers often suck at talking to people (and this is a reason why Offshoring is so unproductive). Requirements analysts often have no concept of (programming) reality. Project Managers are MBAs who should be working in marketing. And don't even get me started on what unrealistic timelines to do software. Like the old adage goes, you can pick only two of the following: Good, Fast, Cheap.
The solution? Teach programmers to communicate! Requirements people should also be programmers. Maybe that's where you put the "programmers" who don't quite make the cut. Too many suits in IT, where there should only be geeks. Geeks who know how to communicate. Keep the suits in HR, Financial, Marketing, etc.
More software would "just work" if this approach were followed. One last thing: the user has to commit to a process. You cannot design an application if there are no business processes to code to. If there's a process clearly defined, there more communication, and no death march mandates, software won't suck.
I think I agree with you. I recently converted a large website to Oracle/Linux/Apache/ColdFusion from SQL Server/IIS/ASP/ColdFusion becuase of changing company standards where I work. When we presented our results to some executives, we were met with a whole lot of "so what?". Nobody cares about which platform something is on as long as it doesn't cause too many headaches, in other words, cost too much to maintain.
The other problem with conversion is all of the feature creep that comes with it. Everyone wants to "Just slip in one more thing".
If you must convert, then hire good programmers and let them release it When It's Done. That's the only way to get things done. Of course, large enterprises cannot understand this concept. No, they'd rather pay 1000 Indians for two years to do something badly but with a very formal timeline. Somehow this is "better" than hiring 50 competent programmers, paying them well, leaving them alone, and then letting them get it right. It would seem the latter approach is a money pit, but in reality I'd be willing to bet you'd get it better, cheaper, and faster.
Slashdot Mirror
It's like they say, all emphasis is no emphasis. When every eMail is a dolled-up HTML doohickie, nobody will care anymore.
Agreed. Where I work, the big thing is (and has been forever) to send Flash(!) in eMail. I mean, come on! It's exactly what you said -- "push web". Pointy haired bosses love it. They sure won't like this new no HTML thing, so guess what? We'll just see more Flash.
Unbelievably, they still do. Of course, they scramble them and add zeros. But still...shocking that they still use SSNs for that. She said that they use SSN to log into the registers and ring out sales and salespeople routinely provide SSNs to co-workers so that they can ring out sales for the right person. Dillards offers to allow them to use a fictitious SSN, but amazingly nobody (including my wife, I found out) opted to use it because "who wants to have to remember another number?" Man, am I glad she's leaving that mess.
yeah, agreed. The last PC I bought was a Dell. It's a good PC, but I had to deal with the damn circus freaks they call employees. First, the World's Dumbest Man placed my order. Then the Girl Without A Native Language talked to my wife when the computer was two weeks late. Then, after my flat panel monitor was discovered to be DOA, I had to talk to the Sultan of Stupidia, who spoke quite a curious dialect, then the Worlds Most Inarticulate Woman, and finally Sri Bhagwon Rangoon and his Amazing Hold Button in order to get them to send me a replacement monitor. Like I said, a bunch of circus freaks.
After weeks of living in a surreal world of especially bad customer service, I got my new flat panel monitor as well as a free set of surround speakers (granted to me by the Ringmaster Suresh for my excessive troubles). In the end I got more than what I paid for and a new PC that is still working as well as when it was new. I just had to deal with Dell's merry band of lunatics to get it. I guess it could have been worse. And now I have funny stories to tell!
Please don't take this as flamebait, but how are we defining crapplets? Software that I don't want that is preinstalled for me? Well, in that case wouldn't XP or Vista, at least in some circumstances, fit this definition? Just because I *have* to pay for it doesn't mean I *want* it. Yet Microsoft strongarms PC vendors into preinstalling Windows and then passing the cost on the consumer. If I want an ubuntu box, for example, then to me Windows is an unwanted "OEM Crapplet".
Now that I got that off my chest, I do have to agree. The amount of garbage that is Preinstalled is atrocious. What's worse is that it's all trial software that bugs you until you buy it or uninstall it. Gimme a break! Trial programs are nothing more than ads. That's like buying a new TV and having to watch an hour of ads before you can watch any shows. It really is insulting and really not helpful at all. Not that it will *break* Vista, it sure as heck will continue to ruin the user experience.
not that I know of, what did they at one time? I wouldn't doubt it.
Dillards is at the top of their list...this hits home for me. My wife just quit her job there. I have to say, that in the month she worked there I know enough to say that Dillards is the worst place to work for. Hear this:
1) if you don't meet sales targets, at your semi-annual review you get a pay cut. No, you don't get commission. You don't get a huge raise if you exceed your sales targets. You just get a pay cut if you miss.
2) Servant mentality. Employees are forbidden from using the store's elevators, escalators, etc. They must exit in the back of the mall, and even when it's dark out there is no security to ensure than employees get to their cars, and they must park in Antartica.
3) Judging from the previous item, you'd think there is no security. No, there is security -- to watch the employees. My wife had to ge a clear purse (really a bag) because she cannot carry in opaque bags. There is security watching them at their counters. They are watched in the stores. They are watched as they exit and enter. And the mall that she works in is in a good part of town.
4) Poor morale. In addition to mistreating employees, Dillards fosters a very competitive spirit among employees. So nobody likes one another.
5) Bad scheduling. My wife took this job because she has limited availability, since I work and we have two children. This leaves just a few evenings that she can work, and as such she was unable to get a job more like she is accustomed to. Well, of course, they scheduled her overnight to do inventory, which was flat out unnacceptable.
6) After about a month, my wife (being the honest, professional person she is) wrote a resignation letter. When she tried to hand it to the manager, he told her he could not accept it and instead she needed to fill out a form. Management proceeded to avoid her for the rest of the day. Needless to say, she never got a form. She made them take her letter. This is how they treat people who try to do the right thing and give notice. She should have just did a no show on a Saturday or something. That would have served them right.
So, while this site is obviously a not-so-reputable one, they are dead right. Dillards is a horrid place to work, and they deserve to go out of business. Hope you enjoyed reading this. It should make you feel *really* good about your job as you sit at your desk sipping a coffee. I know I do.
No, no, no. One DB call, one XMLHTTPRequest, which returns a JSON object.
I did not provide all the details here just because I didn't feel like typing them. Let me just say this isn't a 31 day calendar, but more of a scheduling application for workgroups (I just used calendar for simplicity of discussion). This is an application that admittedly was not the best candidate for a web app, but I had to make it work (this is for work, mind you, so there are business constraints). Building the page server side, there were scalability issues, for example with a large workgroup (250 users) the page size was something like 4M for a monthly schedule (imagine a table 31 wide by 250 high, each cell having onclick, title, style attributes...*shudder*). This same workgroup, after making the schedule get all the data via JSON arrays and build *some* HTML client side (but not the entire page, just the schedule grid), the page size is <40K and the total data transfer is <200K, not to mention it loads much faster now, usually less than 4 seconds. If you want to know more for the sake of knowledge, I will give you more details. If you just wanna argue, then I won't waste my time (though your post doesn't sound argumentative).
As for javascript compatibility/accessibility, I agree, not everything is a good candidate for this type of design. In fact, I'd say that you shouldn't use AJAX gratuitously. I am making a point to argue for AJAX as I am doing here because I feel like it is a valid and powerful tool. So is a jackhammer. That doesn't mean you use it to work on your car. In this case, it was either continue to kill the server or come up with a better way. I wasn't trying to go for "kewl" and bleeding edge. I simply needed a way to make an existing application work better.
This is on an intranet, so I do have the benefit of knowing that most users are using something sane like IE7, Firefox, Opera, or less sane, IE6. There is nobody using IE3 or something else crazy, and if they are, well, frankly my dear, I don't give a damn. On the internet, I would probably take the same approach, that is unless I really had to appeal to *everybody* for some reason (like Amazon.com or a
It was probably something else in the author's code that was causing things not to work. For example, leaving the ; off the end of a javascript statement can have different effects in different browsers. But just claiming that <input type="image"
If anything, what could cause problems in IE7 is if all if the "IE only" hacks that were used to make IE6 behave itself still work and with odd results (since IE7 did fix much bad behaviour). That said, I personally haven't encountered that problem. It seems like it would happen, theoretically.
*sigh*
you clearly don't get the fact that not everything needs to be bookmarked. You also don't see how you can use AJAX to make the client take some load off the server and network.
As another reply to your message already stated, there is no sense arguing with you about this. If you don't like a particular technique, then don't use it. Just don't pontificate about the evils of a technology you obviously have no grasp on. I am done with you now. Bye.
You don't read too well, do you?
oh, you didn't see the author's name?
wait for it...
Elmer Fudd? There... FUD, written by FUDD, and written in FUD. Ok, I'm gonna get some food.
Man, am I glad I am not the only one who feels like the whole "use OOP (java) everywhere for everything!" mantra is a bit cargo-cultish. Thank you. I thought there was something wrong with me for a minute.
Look. It depends on HOW AND WHERE you use AJAX. Jeez!!! Can we please put this to bed? Yes, if you design a whole flippin site that is one page with a zillion AJAX calls, well, gee whiz! Bad idea! But, if you use your brain and use it only where it ADDS VALUE then maybe, just maybe, it's a good thing? You think? Just because beer is a good thing doesn't mean you pour it in your gas tank, use it to make Kool-Aid, or bathe in it. I am SICK (can you tell?) of people misusing technologies and then blaming the technologies! Stop it!!!
C++ applications just aren't solid or stable, for the most part. We tried to integrate a number of them into our network here, and frankly each attempt went terribly.
Java applications just aren't solid or stable, for the most part. We tried to integrate a number of them into our network here, and frankly each attempt went terribly.
In all cases, I'd kindly suggest the problem is not with the technology, but with the person doing the work.
For example, let's say you have a page where a user has some sort of an inbox from which the user can delete things, like system notifications. Next to each item, you have a delete link. Clicking on the link deletes the item, meaning javascript deletes the node from the DOM, and an AJAX call gets the thing deleted from the DB. Good use of AJAX. In fact, in an AJAX-less solution, ths user 1) has to wait for the whole page to reload, and 2) if the user presses the back button, depending on browser settings, the deleted events will seem to reappear. That could be confusing. This is one very simple example of where AJAX is great.
Consider another example. A shared calendar web application, that builds a table server side, gets all the data, runs security checks on each event to see what the current user can do to each event, and then presents the data. Building the table server-side, then pumping out tons and tons of HTML code will not only tax your web server, but also generate unnecessary network traffic. You could pretty easily refactor this application to build the table client side, and then send the data to the client via a JSON object. Now, the server page that builds the JSON object is built to check the user's cookie or whatever you use for authentication and it only sends the data that the user can see. The client takes this data and build the content client side. This is the network equivalent of purchasing a disassembled computer desk and taking it home to assemble it rather than purchasing the floor model and trying to cram it into your Mazda Miata.
I give these two examples because they are real life solutions I developed at work. Both are absolutely secure, and both save the user wait time. Also, these reduce the network and server load. What's not to like?
Of course, if you design a website whose navigation controls use AJAX, or some other weird use of AJAX you will get interesting results, and by interesting I mean bad. No offense, but I think you are saying that AJAX is a bad technology perhaps because you just don't know enough about it.
Both solutions are on an intranet, else I would gladly provide links. On the internet, would I use AJAX? Absolutely! I would, of course, use just a bit more caution...no, not because of security (I know how to make secure AJAX code) but because of browser compatibility. On the intranet, I use web standards and therefore all modern browser will work great. The nice thing is, though, you aren't going to have some weirdo using Netscape 3 or something like that. On the web, would I pander, er, I mean cater to this type of user? Depends on how much I needed them as a client.
If you want to learn more about AJAX and effective javascript constructs like JSON, check out these links: http://www.sergiopereira.com/articles/advjs.html and http://www.sergiopereira.com/articles/prototype.j
Why do you hate 'Merica?
--
I'm not an actor, but I play one on TV
You could (and many do) make the argument that HTML is in the same boat. Yes it *works*. Does it provide a perfect environment for creating the complex, interactive web apps that we use it for? Heck no! Does anyone with any real power actually enforce standards? W3 who? And yet, in spite of its ugliness it works. It's a bit like wikipedia, in theory it sucks but in practice it works great.
If anything, I think it's a testament to the web development community that something so huge and robust can be hacked together with totally inadequate tools. It's like someone building a car with nothing more than a ball-peen hammer and a dull hacksaw.
Yes, and just because bad development techniques can cause security holes, we blame the technology. This is a bit like PHP being called insecure. Any language/platform/technique is insecure if the programmers leave gaping holes.
AJAX is a great technology. Yes, if you overuse it or use it in the wrong places then it is harmful. Saying AJAX is unstable, unusable, brittle, impractical is simply an untrue generalization. Like anything else, if you do it right it enhances usability and is quite reliable.
holy crap! You need to put that on Foldoc with some kind of name like <>'s Theorem. That's actually true! Especially about the part about most people not caring about how it works. Reminds me of something I read a long time ago: most users "satisfice", meaning they will search your application for a button/link that seems to be the closest thing to what they want and click/push it without really knowing what it is that they are doing.
Users muddle through most applications and somehow manage to get them to do what they need. This is also why sometimes things stay broken for a long time without the programmer ever knowing...because users will find another way to hack (loosely used here) at an application to get it to work anyway.
Heck, I'd bet that when you use a website you don't carefully read every option, you just pick the first thing that jumnps out at you and go from there. It's all trial and error, if one thing doesn't work something else will. And that's why you cannot get good requirements from users. That's also why programmers have to learn to think like users. Applications can be simple, it's just that programmers too often assume people will take the time to understand. Bzzzt! False!
In terms of software design, applications can be simple if programmers are smart enough to present the "right" complexity. It's all about choosing the right options. Yes, some users ask for configuration on top of configuration. Trouble is, that these get piled into the application for everyone to see. If people want advanced settings, they should have to ask for them. It's the good old Pareto Principle, aka the 80/20 rule. Do what 80% of your users need, and hide the complexity for the remaining 20% of people who want it.
You bring up the example of Linux, and I will go with you on that. Let's look at two common desktop environments: KDE vs Gnome. In my opinion, KDE is a miserable desktop environment because it assualts you with 50 bazillion options everywhere. Gnome seems to choose the right options and makes you go digging for more. If I had to choose a Linux distro for the masses, or at least, for my computer illiterate grandmother, it'd be one with a Gnome DE (ubuntu, to be precise). No way would I recommend KDE for people who are easily confused.
Complexity doesn't have to be in-your-face, and simplicity doesn't have to mean dumb.
Software should just work. Of course, that is oversimplified.
Too many times a project goes like this: Customer places request. Project Mgr talks to client. Requirement Analyst turns request from PM into low level requirements. Programmer reads requirements document, writes program. User gets program and guess what? It's not what he wanted! So, he places another request, and we are back to square one. Sound familiar?
Users request crazy things. Sometimes, they ask for things to work around other problems. The person writing the software should know, not what the Requirements person thinks the user wants, but what the user is actually trying to accomplish and why they are trying to do this. What is the user trying to do? Then, the programmer should make a proposal and necessary parties should either agree or disagree. This means that some requirements people are out of work, this means that the programmer has to be smart and communicate well, and that he has to spend time talking to users. And therein lies the problem.
We have IT departments that are so fragmented and people in them are so specialized. Programmers often suck at talking to people (and this is a reason why Offshoring is so unproductive). Requirements analysts often have no concept of (programming) reality. Project Managers are MBAs who should be working in marketing. And don't even get me started on what unrealistic timelines to do software. Like the old adage goes, you can pick only two of the following: Good, Fast, Cheap.
The solution? Teach programmers to communicate! Requirements people should also be programmers. Maybe that's where you put the "programmers" who don't quite make the cut. Too many suits in IT, where there should only be geeks. Geeks who know how to communicate. Keep the suits in HR, Financial, Marketing, etc.
More software would "just work" if this approach were followed. One last thing: the user has to commit to a process. You cannot design an application if there are no business processes to code to. If there's a process clearly defined, there more communication, and no death march mandates, software won't suck.
I think I agree with you. I recently converted a large website to Oracle/Linux/Apache/ColdFusion from SQL Server/IIS/ASP/ColdFusion becuase of changing company standards where I work. When we presented our results to some executives, we were met with a whole lot of "so what?". Nobody cares about which platform something is on as long as it doesn't cause too many headaches, in other words, cost too much to maintain.
The other problem with conversion is all of the feature creep that comes with it. Everyone wants to "Just slip in one more thing".
If you must convert, then hire good programmers and let them release it When It's Done. That's the only way to get things done. Of course, large enterprises cannot understand this concept. No, they'd rather pay 1000 Indians for two years to do something badly but with a very formal timeline. Somehow this is "better" than hiring 50 competent programmers, paying them well, leaving them alone, and then letting them get it right. It would seem the latter approach is a money pit, but in reality I'd be willing to bet you'd get it better, cheaper, and faster.