Slashdot Mirror
Domain: sergiopereira.com
Stories and comments across the archive that link to sergiopereira.com.
Comments · 11
-
Re:Subtitle of the book
Yeah, that's the way it used to be. Prototype is what I use, because along with a very useful AJAX library it has several useful tools that totally abstract browser differences. For example, it has the $() function. Plug the id of an element in there like such: $('chewbacca'). Assign that to a var, and you have an object var that references the fully qualified element regardless of which browser you are in.
That's pretty simple actually. I used to have my own library that did that and more. But Prototype also does some totally awesome AJAX stuff, and adds useful functions that simulate methods that SHOULD exist (like document.getElementByClassName(), which does what its name implies.) You can get prototype here: http://www.prototypejs.org/download. There is even an (unofficial) reference here: http://www.sergiopereira.com/articles/prototype.js .html.
I use this all the time, and it is a fantastic library. I never have to worry about feature sniffing or *shudder* browser string sniffing.
If you are on an intranet and you don't have to worry about some schlub having netscape 1 or something, then you can really do some very cool stuff with javascript (like AJAX) that makes the user experience much much better. Just be subtle with it. Going over the top with javascript and AJAX just makes you look ridiculous. If you are on the internet, I am not sure how well prototype works with ancient browsers (IE 3, etc). But unless you are amazon.com, who the heck cares? -
Re:FUD
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. -
Re:FUD
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. -
Re:Telcos have been doing this for years.
It can be. I use AJAX quite a bit, though, and find that prototype makes things pretty simple. It takes a while to get proficient with it, but it really does pay off. This coming from someone who generally _hates_ to use someone else's code libraries. I cringe when I see "professional" web developers grab scripts from websites like dynadrive.com and use them. I _always_ write my own stuff. I have to admit, though, that compared with when I used to have my own AJAX library, prototype has taken much of the difficulty out of using AJAX.
A lot depends on how you use it. I do not create spreadsheets and maps and so forth like google, but I find it extremely beneficial for 1) loading content from a DB that may be too slow for the initial page load, 2) allowing users to perform simple DB tasks (ex. deleting a row) without reloading the page, and 3) performing certain tasks on demand as opposed to when the page loads. I find that I can create a pretty functional AJAX page very easily.
The other nice thing is that you can use AJAX tchniques to better separate content from presentation.
I am sure you know most of these things, but I say them to illustrate the point that while it can be a hair more difficult (using prototype) to code AJAX pages than coding conventional pages, the benefits in terms of performance and user experience outweigh the negatives. I have not yet found that maintenance is more difficult, either.
If you think it's too complex/tedious to work with AJAX, just give prototype a shot. -
Re:script.aculo.us?
-
Re:DocumentationPrototype has some pretty good documentation. Also, it's pretty low-level, so it's easy to build into other stuff. Heck, Prototype is worth it just for the each() iterator method!
Dojo's docs are very much hit-or-miss. Some features are pretty smoothly documented. Others are like navigating a trackless wilderness with no more than the sun and stars to guide you. Also, Dojo's annoying because it requires you to add non-standard attributes to your HTML in order to identify widgets. For example:<button dojoType="Button" widgetId="helloButton">Hello World!</button>
dojoType? widgetId? Those ain't gonna pass no validator THIS little programmer knows of. -
Re:Saving AJAX
Have a look at Prototype, in particular Form.serialize().
Oh, and Ruby on Rails has helpers for this too, of course. -
Re:Weaknesses of "prototype.js"
Why should a a JavaScript framework NEVER define methods on Object.prototype or Array.prototype? Code that requires a static definition of Array is clearly making incorrect assumptions about how the language is used, so I'd place the blame there, not with prototype.js.
Most people treat JavaScript like its C's retarded little brother, but that's just one of many programming styles that it adapts to. Methods like Array.each and Array.grep allow JavaScript to be used in a very Ruby-like fashion, which, in addition to making the language more comfortable for its target audience, usually results in tighter, more readable code. Extending Array and Object might lead to some exciting bugs in code that doesn't expect it, but I don't see how this makes the practice wholesale wrong. Ruby on Rails does stuff like this all over the place. Being able to say 3.months.ago or some_random_object.to_json is part of what makes Rails such a pleasure to work with, and I don't see why its JavaScript library shouldn't be extended the same freedoms.
To quickly address your other two issues, I got all the documentation I ever needed from this site, and, while unit tests are definitely nice, prototype's proven track record is enough for me. I haven't had the slightest bit of trouble with prototype -- it's done nothing but save me time thus far. -
Re:Prototype still rocks
I'll admit that the library sucks for documentation but third party docs on both the script.aculo.us site and on http://www.sergiopereira.com/articles/prototype.j
s .html both have decent docs for it they aren't easy to find but they are there and actually pretty good once you find the core ones -
Re:Prototype still rocks
Prototype may rock, but the website (http://prototype.conio.net) sucks. It's only a page with a download link. So WTF is prototype? Where's the manual, or at least a quick overview of what it does? Not even the
I had to google around to find documentation, such as this site). -
Re:How about a new language