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?'"
will AJAX development finally be easy? (Score:3, Interesting)
Re:will AJAX development finally be easy? (Score:3, Informative)
Re:will AJAX development finally be easy? (Score:3, Interesting)
Re:will AJAX development finally be easy? (Score:3, Insightful)
Re:will AJAX development finally be easy? (Score:3, Insightful)
Re:will AJAX development finally be easy? (Score:2, Interesting)
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? (Score:2)
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 not generally going to make public, so the lack of bookmarking ability doesn't matter so much. The old Apple store was a good example of how this really breaks the user experience. They have even put in a whole load of nonsense in the address (1-800-MY-APPLE/WebObjects/AppleStore.woa/wa in every url !!!!) to try to hide the fact they're stuffing gobbledygook in there when there should be state info. Very bad design. I think now they've fixed it up a bit so that you can at least bookmark or share an URL with a product range, if not a specific product.
If your app loads only a single page, presumably it doesn't feature any resources that the user might want to refer to again with a URI, share with a URI, or otherwise come back to? The searches can't be saved except within your web app? It can't be cached by the web server/client? There are so many downsides to this and so few upsides. Interestingly, it seems Rails is moving more towards the opposite of this; exploring REST [softiesonrails.com] as a way of providing specific URIs for specific content, rather than trying to make web pages into a desktop application in a browser window.
Re:will AJAX development finally be easy? (Score:2)
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.
What's wrong with Gmail in this regard? What do you want to bookmark in Gmail? I don't necessarily think that all the web should turn into AJAX stuff, but there are certainly instances where a platform neutral, no-local-install desktop-like app is very convenient. And since Java has apparently failed to deliver on that front, I look to web browsers.
Then again, I'm almost always going to prefer using a native desktop app if it exists. I mean, Gmail is good for what it is, but when I'm sitting at my own computer, I'm running Apple Mail and aggregating several mailboxes into a single place (thank you Google for implementing IMAP!).
Indeed, the vast majority of my experience programming with AJAX is through Rails. Rails makes it fairly straightforward to fall back to non-ajax behavior. But at the same time, it would be fairly difficult to implement a Gmail-like app if only because Rails provides few of the client side application controls beyond the basic HTML inputs.
-matthew
Re:will AJAX development finally be easy? (Score:2)
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.
Re:will AJAX development finally be easy? (Score:5, Insightful)
Re:will AJAX development finally be easy? (Score:2)
Re:will AJAX development finally be easy? (Score:2)
That's how must of us learned it.
Re:will AJAX development finally be easy? (Score:5, Informative)
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? (Score:2)
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? (Score:2, Informative)
if, instead, time.asp outputs an XML file, in the code change
Re:will AJAX development finally be easy? (Score:4, Informative)
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.
Re:will AJAX development finally be easy? (Score:2)
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.
Re:will AJAX development finally be easy? (Score:5, Insightful)
Re:will AJAX development finally be easy? (Score:2, Funny)
Not using it.
Re:will AJAX development finally be easy? (Score:2)
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? (Score:5, Insightful)
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? (Score:3, Insightful)
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:will AJAX development finally be easy? (Score:3, Informative)
My only complaint is crappy documentation. To understand gwt-ext I actually have to read the documentation of ext itself, with is Javascript based. I wish they copied the comments to javadoc. Then also to have a standalone text box on your page you need to put it inside a form and then set a bunch of options to make sure the form does not try to decorate the space around the text box in any manner.
Re:will AJAX development finally be easy? (Score:2)
I don't know much about GWT (the fact that Google developed it is at least encouraging). But if it's like some of the other java based solutions that are designed to write HTML, I'd run away fast. If you want to be a web developer, then you need to learn the languages of the web (HTML, CSS, Javascript at the very least). I'd be shocked to find that GWT doesn't generate steaming piles of dung in place of good, clean, standards compliant markup, and that means you have all kinds of compatibility issues, accessibility issues, and code that is harder to maintain.
Re:will AJAX development finally be easy? (Score:2)
Re:will AJAX development finally be easy? (Score:3, Informative)
<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 image's dimensions being 50% of the div's width and 50% of the div's height. Not that you *should* use points for dimensions, but that's just in keeping with what you said you did.
That said, browser behavior is very flaky. Your frustration is not unjustified. Especially with IE. IE sucks. There's not much more to say about it.
"It would be even better not to use the defective product at all, but that is hard when the vendor has a monopoly status."
Preaching to the choir, dude.
Re:will AJAX development finally be easy? (Score:2, Insightful)
Re:will AJAX development finally be easy? (Score:5, Informative)
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.
Reduce the Quirks and Exceptions to HTML/CSS (Score:4, Insightful)
HTML skills are a commodity? (Score:4, Insightful)
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? (Score:2)
Re:HTML skills are a commodity? (Score:2)
How else would you like people to make clickable text that executes a JavaScript method, and how would it be better than that approach?
"
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? (Score:2, Informative)
Re:HTML skills are a commodity? (Score:5, Insightful)
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.
No, they aren't. They are absolutely useless for layout.
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? (Score:5, Informative)
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? (Score:2)
I have not said otherwise. Please pay attention to what I say rather than attempting to read between the lines.
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? (Score:2, Insightful)
Now you're just being pedantic. Obviously it's the CSS that positions things in your layout, but when discussing table layouts versus CSS layouts, most people will call the latter "div layouts" just because it's easier to understand ("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're doing a layout that would traditionally require a table, you have several blocks of information that need to be positioned correctly. Those blocks usually don't have any semantic meaning other than "I'm a block", in which case divs are appropriate. I'm going to lay out my page using CSS regardless, so if not divs then what? Spans marked as display: block?
Re:HTML skills are a commodity? (Score:3, Insightful)
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.
"Div layouts" is not easier to understand than "CSS layouts".
If you tell people to replace layout tables with divs, then you don't understand HTML. You replace layout tables with the most appropriate element type available.
I'm not telling you not to use divs. I'm telling you that you are confusing content and presentation. What element types you use is not a layout issue.
Re:HTML skills are a commodity? (Score:2)
Re:HTML skills are a commodity? (Score:2)
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.
Re:HTML skills are a commodity? (Score:2)
Re:HTML skills are a commodity? (Score:3)
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? (Score:2)
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? (Score:3, Insightful)
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.
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? (Score:5, Insightful)
Re:HTML skills are a commodity? (Score:2)
A screwdriver can also pry nails out of a 2x4. That doesn't mean you should do it. You will probably impale your hand.
A flamethrower can light the candles on your kid brother's birthday cake. But you might light grandma on fire.
Using HTML elements for things that are not quite correct might work on the browser you are using. Why, I could use <label> tags to lay out an entire site and use CSS to make it look ok in mainstream web browsers. That doesn't mean another user agent or screen reader won't totally freak out upon seeing it.
Table are necessary for some layouts. I have a site where it is just impossible to avoid using a simple table for layout. But you should know that it is semantically a faux-pas to do so. Part of being a professional is to know the rules and also to know when to break them.
Re:HTML skills are a commodity? (Score:2)
Re:HTML skills are a commodity? (Score:2, Insightful)
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.
Re:HTML skills are a commodity? (Score:2)
Re:HTML skills are a commodity? (Score:2)
Re:HTML skills are a commodity? (Score:5, Insightful)
I used to be on the side of using semantically neutral elements like divs and css to specify layout.
Most layouts work fine with semantically neutral elements (divs). Some don't. I have used tables for layout in one or two cases, but not before trying VERY hard to make a purely CSS driven solution. To approximate it using no tables, I'd have to put javascript in my CSS expressions to make IE simulate min-width and min-height, among other things. Since that's a clever but ultimately sucky solution, tables won out. We're talking very specific layouts here. Usually you shouldn't need tables.
I said it in another nearby post, but I'll say it again here: being a professional is knowing the rules. Another part of being a professional is knowing when to break them. Yes, using tables for layout is a semantic faux-pas. But sometimes it makes the most sense.
If you find yourself having to cobble together a collections of hacks to make a certain layout work without tables, then you either need to abandon the layout, or if you cannot, use tables. Semantically incorrect, but it's better than some of the hacks that you have to use to work around browser (IE) flakiness. I am not talking about wrapping floating divs in a container with negative margins. That's a pretty elegant solution. I am talking about several layers of nested divs with wacky CSS tricks and IE hacks on top of Javascript magic. That stuff is ridiculous. In short, use the best tool for the job and get over your prejudices about a certain design methodology being "bad".
Re:HTML skills are a commodity? (Score:3, Insightful)
Looking at your website I see you're using divs and spans in places where there are more appropriate semantic tags. It also looks as if you're using more nested block elements than should be necessary for that layout. I'd also suggest trying multiple CSS classes per element in some cases. An example (that will be entirely wrong because I haven't spent the time to learn how your layout is working): class="wrapper outer float-wrap center" instead of five separate divs with one class each. You're also often using classes that describe the CSS properties, rather than semantically describing the content. eg class="float-wrap" instead of class="newsitem" or some such.
I'm not trying to be condescending. I really like your design. I'm just saying that if you're ending up with the answer being tables then you need to acquire more skills so that you can better answer the question.
marchitecture alert (Score:5, Insightful)
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 (Score:5, Informative)
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 (Score:5, Interesting)
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.
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.
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 (Score:2)
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 (Score:2)
Yes, I am talking about rich clients, but only because in the end that's mostly what AJAX + HTML is trying to emulate. For example, the ThinWire link that someone else gave is trying to provide the same controls of a rich client, but through a medium that wasn't really designed to do that.
I have great respect for the people who write those libraries -- they've managed to take AJAX to its full potential, but it doesn't strike me in the end as a particularly elegant or final solution.
The only real "internet-ready" "rich client" GUI that I know is Java. Possibly TK/Tcl. In theory someone could take either the Qt or GTK+ libraries (minus some licensing issues for Qt, and platformability issues with GTK+ [at least last time I checked]) and make something that could easily be sent as an internet-app. Unfortunately no one really has at this point. At least not to the level where it's really easy to develop and deploy and have work inter-mixed with web pages they might be launched from.
Re:the suck/non-suck divide (Score:2)
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.
Re:the suck/non-suck divide (Score:2)
Besides which, there are plenty of web pages out already that are difficulty to semanticize. The more we enforce the distinction between content and function the easier it is to parse the pages.
when will AJAX skills become commoditized? (Score:5, Insightful)
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? (Score:2)
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? (Score:2)
>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>
</>
<method htm_inst>
<span>
<h1
<do
</>
</>
</>
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?
Re:when will AJAX skills become commoditized? (Score:2)
how far HAVE we come? (Score:5, Insightful)
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:
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? (Score:2)
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? (Score:2)
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)
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 (Score:2)
Or you could try Mozilla's XULRunner:
Re:silverlight (Score:3, Informative)
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 in existence.
* It is in no way cross platform. The DLR class libraries are not an open specification beyond 'do what MS does', whomever independently implements it will be forever playing catchup. Needless to say MS will not be releasing the a DLR runtime for Solaris on SPARC anytime soon.
* It brings C# to the browser. It is my opinion that this move to a less expressive, more heavyweight language would be a step backward. In my opinion it would be better to fix Javascript, than to rip and replace with another language.
* Granted, the web does not have universal vector and HD video native to the browser. Neither would DLR/Silverlight, only Microsoft's implementation could be relied on to have full support of any given video format, due to restrictive licensing of US software patents. SVG support is improving in all browsers except Internet Explorer.
* Ease of update of a runtime is an implementation issue. It has nothing to do with how widely deployed implementations of a revised standard would be.
Silverlight is not the web and it is not an improvement in my opinion.
Personal experience with AJAX (Score:2)
AJAX directions (Score:4, Interesting)
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? (Score:2)
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 adapts to change faster, but it's always chaotic, a bit difficult to deal with, and seemingly on the verge of breaking down.
AJAX still sucks (Score:3, Insightful)
-
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.Let's see (Score:4, Insightful)
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 (Score:2, Funny)
Re:Let's see (Score:2)
Re:When did AJAX stop sucking? (Score:3, Insightful)
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? (Score:2)
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? (Score:4, Insightful)
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.
Re:When did AJAX stop sucking? (Score:2)
I say this is one reason to champion resolution-independent interfaces. Now, NOT ONLY should it be able to draw elements at any level of dots per inch (like Apple recently took a "preview" step toward in Leopard -- applications do not use the features by default), it should collapse smoothly, or at least reasonably or predictably, to the degenerate case of not having a resolution at all. The case of accessibility for the blind and nonreaders notwithstanding: It's maddening that a person with poor vision can shell out for a 30" monitor, and the widgets are either as small or smaller than they ever were, or unforgivably blurry. I hope that someone develops the resolution-independence further for the sake of the visually impaired, and also (selfishly) so I can web-browse comfortably from my couch on a large HDTV. For those who don't know, OS X already has global zooming where you simply hold the control key and turn the mouse's scroll wheel. The screen pans around proportionately with the cursor, and antialiasing can be turned on and off. It has saved my in-laws many a time. Now, the next step is to keep the crispness of the interface elements when zooming, and hopefully provide some global setting (eg, monitor size: 1920x1080 pixels, screen area: 800x480 points) to adjust the relative size of the UI.
Re:When did AJAX stop sucking? (Score:2)
Re:Ajax will be obsolete before it becomes mainstr (Score:5, Informative)
Re:Ajax will be obsolete before it becomes mainstr (Score:2)
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 (Score:2)
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.
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.
Re:Ajax will be obsolete before it becomes mainstr (Score:2)
Re:Ajax will be obsolete before it becomes mainstr (Score:2, Interesting)
Do you also welcome AJAX hosts holding your data? (Score:4, Insightful)
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 (Score:4, Informative)
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 (Score:2)
Even if users are comfortable with hosted data, they can not be thrilled over the fact that buying a top-of-the-line quad core computer does nothing to speed up their applications. Eventually there will be a backlash and people will once again start using downloadable thick clients that communicate to the server when needed.
Java applets should have been AJAX. It's too bad that Sun had crappy UI and browser integration and Microsoft quite possibly leveraged their monopoly position to prevent Java from being widely bundled by OEMs at the critical stage in web app evolution.
Re:Do you also welcome AJAX hosts holding your dat (Score:5, Insightful)
Correct. And what happened to Netscape's market share?
I hardly think that a "minority" of the development community are the ones mad at Microsoft. Anyone who has used IE to any appreciable degree is mad at them. When 5.0 came out back in '99, it was incredible. The best browser, bar none. Microsoft released a fairly insignificant update called 6.0 in '01 and that was where the browser sat. For about 5 years. Then when everyone had almost given up hope that Microsoft would keep developing their browser, they announced 7.0. They also announced how they were going to meet W3C standards and make developer's lives better. 7.0 came out, and it turns out that Microsoft couldn't even be bothered to add support for simple things like DOM2 Events or SVG. (Things which they effectively already had support for, just in a proprietary-yet-not-quite-dislike manner.) In reality, they stamped out a few CSS bugs, screwed up the IE interface, then developed a new certificate scheme that was practically the same as the old one but made more money for all involved.
The funny thing is, the only reason why IE hasn't died out is aforementioned monopoly power. I have met very few users who prefer IE over Firefox or Safari. However, I have met managers who force the use of IE (thus leaving themselves vulnerable to IE's massive security holes) for the purpose of 100% Microsoft "corporate standards". As a result, IE has lost market share in the home computer segment, but is not taking any losses in the B2B arena. And it's NOT because it's a good product.
Re:Do you also welcome AJAX hosts holding your dat (Score:3, Insightful)
I'd say users have been leading towards "don't care". Of course the solution is to host your own web/app server. Then your client talks to your server and stores your data.
Javascript and HTML are for content and presentation, not processing data. That's because browsers are optomised as display platforms, because they are built to display documents. Javascript is not a programming language its a script language to allow designers to customise your display, just like CSS.
Want a customisable, interactive, client-server GUI. Code one in a real language. Use C, C++, C# or even Java, then throw an XML over HTTP client comms library in. Easy. Well easy for programmers with a little training. Not easy for script monkeys who can't code. AJAX is just a bastardisation of what was easiest for most people to build with.
AJAX is to the Web what Lego is to the building industry. Useful in its place.
Re:Do you also welcome AJAX hosts holding your dat (Score:3, Insightful)
Want a customisable, interactive, client-server GUI. Code one in a real language. Like Javascript. If you know what you're doing, you'll actually find it a LOT easier than writing a comparable C, C++, C#, or Java GUI.
Oh, and Javascript was NOT designed as a "display customization language". It was originally designed to script (drumroll please...) Java. As in Java, Java. Not Java Applets (though that was included in the spec), but straight-up, plain-Jane, gosh-darn-that-looks-like-semantically-funny-Java Java. Mozilla still supports the full Livescript API in case you want to play around at some point.
Re:Do you also welcome AJAX hosts holding your dat (Score:3, Informative)
Not exactly true. Javascript was not invented to be a scripting environment for Java. It wasn't named Javascript initially and the syntax is similar to C just as Java syntax is similar to C. In fact the name Javascript was more of a marketing ploy than anything else. Javascript was developed by a Netscape engineer and indeed seems to be invented for the purpose of web-based scripting, not Java scripting.
Re:Do you also welcome AJAX hosts holding your dat (Score:3, Interesting)
Self Java -> Mocha -> Livescript -> Javascript
Brendan Eich practically never talks about the Self Java/Mocha days of Javascript. Not all that many people even remember the working title "Mocha". (Implying its early relationship to Java.) Scripting of Java was the goal in those revisions. Javascript 1.0 was kicked out the door incomplete, but 1.1 addressed the initial issues. The JavaClass and Package objects were added, and it became possible to run Java code without an Applet. It was pretty darn nifty, and still can be if you have Firefox with a Java plugin. (See my response lower in the thread for more info.)
The branding concept was stupid, but there was solid reasoning behind it. And it was more than just because Netscape and Sun were partners.
Re:Do you also welcome AJAX hosts holding your dat (Score:3, Insightful)
Please check thy facts, kind sir. Javascript was conceived of as a Java-like script language. A poor man's Java for those that found object oriented concepts a little too brain intensive. Thrown in the first netscape browser to allow a little customisation of the DOM on the fly, for things that then then HTML 3 couldn't do properly.
Javascript is not an object oriented language. It is at best what can be called object-based, but then anything that uses "objects" can make that claim. There is no polymorphesm or inheritance, strong type checking, nor even much encapsulation. Its all function based monolithic code. And even if javascript, per se, is capable of the above, examples of such are very, very rare indeed.
As for the W3C specs, they aren't worth that much as most of the javascript interpretors - aka browsers - haven't given much more of a cursory glance at them either. No point writing code to spec if the interpretor won't run the code in the same way. At least Sun managed to force JVMs to be written to a more standard standard.
My brother builds model planes in his spare time. According to your Javascript defence guess he can call himself an "Aircraft Engineer" now. Everytime I see recruitment ads for "HTML / Javascript Programmer" I kack myself. Well, at least it leaves the real programming jobs for those of us that can.
Re:Do you also welcome AJAX hosts holding your dat (Score:5, Informative)
You may be surprised to know that I am well in possession of the facts. I used to believe that Javascript (formerly Livescript, formerly Mocha) got its name in simply a cross-branding deal. In fact, it was far more complex than that. Javascript was created to script Java as well as the DOM. The original concept would have blown today's AJAX out of the water in usability. Alas, it was not to be.
Here's more history for you: http://safari.oreilly.com/0768666775/ch01lev1sec1 [oreilly.com]
Also, here's a bit of Javascript for you, demonstrating how powerful it was intended to be:
(That will work in FireFox with a recent Java plugin. I guarantee that it will not work on Internet Explorer.)
;)
You have to remember, Java already existed in the browser when Javascript was created. Netscape internally discussed just using Java itself for scripting, but decided that a new, more dynamic scripting language would be more useful. (Source [netscape.com]) Thus the birth of Javascript. Eich described the first revision as "having gotten out of the lab a bit earlier than intended [scribemedia.org]". Javascript 1.1 was much closer to his vision, and what we think of today when we talk about Javascript.
You also need to understand that the Javascript language went beyond just the browser. Much of its development was driven by its use as a server-side CGI language [sco.com]. So it became a "real" language very quickly, despite its slow start.
And if you think that's cool, remind me sometime to tell you about how multipart/x-mixed-replace could have been server-side push long before AJAX, Comet, or <event-source> ever existed.
Incorrect. Prototype-based languages [wikipedia.org] are very much OO languages. They're different from class-based, languages, but that doesn't make them any less powerful.
I think you misunderstand the very meaning of polymorphism if you believe that.
Here's the "Runnable" interface implemented in Javascript:
The polymorphism appears to work fine?
Funny, Netscape's Client Guide has an entire chapter [mozilla.org] on that.
Strong typing [wikipedia.org] is not a OOP requirement. It is a feature of some languages. Nothing more, nothing less. In any case, Javascript actually has quite a few typing fe
Re:Do you also welcome AJAX hosts holding your dat (Score:3, Interesting)
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:AJAX vs. Flash is the real question (Score:2)
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
Re:AJAX vs. Flash is the real question (Score:3, Insightful)
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:From the start... (Score:2)