Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: open
are familiar with? When you felt like you knew
concept pushed that boundary?
Here is how they answered.
author of "Ajax Design Patterns"
There's a lot of cool stuff going on right now, standards-based graphics and sound foremost in my mind. But I'll focus here on something I've always found oddly fascinating: fragment identifiers and the quirky exploits around them. The humble "frag ID" is not exactly the pinnacle of the Ajax revolution, but it remains misunderstood and under-utilised by developers, and a feature which the browsers could do more to support. By design, fragment identifiers do just as their name suggests - they identify fragments of a document. Type in http://example.com#foo, and the browser will helpfully scroll to the "foo" element. However, they can be used for a lot more than that, thanks to peculiarities in the way they are handled by browsers.
I first researched this stuff for Ajax Design Patterns [ajaxpatterns.org] in 2005, and at that time, there were only a couple of scattered blog articles on the topic. Today, we can see the pattern in action in various high-profile places such as Google Docs and GMail. When I view my starred documents in the former website, for example, the URL is [docs.google.com ]. That said, many developers still aren't using this feature to its fullest, and library support is somewhat lacking. It's encouraging to see IE8 has a new event for monitoring the fragment identifier, which suggests the story is not over for this rarely discussed property.
Senior Web Developer and MooTools Enthusiast
Contributor: MooTools JS Framework, Author of MooTools Essentials (Apress)
This kind of development is very expressive and very fast, but eventually it becomes unwieldy. Now I try to think of everything as classes - even things I never plan to reuse. From the smallest 4 lines of code to the really long sets of functionality that describe something totally unique to the UI of a site. The result has been remarkable. I find myself re-using things far more often, the code I author is far more legible and maintainable, the footprint between my application and the code I write is very, very small (where I once had dozens and dozens of lines in a DomReady statement, now I just had invocation statements - new Foo(options)). All these things come together to encourage me to write cleaner, more abstract, and more manageable code and the upshot is I end up with more portable, reusable stuff.
All excerpts quoted with permission from their respective authors
Add yours below.
Another technique that recently blew my mind was using the window.name property to store state. It's gettable and settable and totally hidden and exists for as long as the current window is open, even across domain boundaries. It's a nifty back door to cross-site data transfer, but I fear it's only a matter of time before browsers notice the leak and plug it.
I use simple JS to run things such as countdown timers, making an image visible at different times of the day, even form handling. The things that really get me thinking and reminds me why I enjoy this line of work, is when I have to use JS to work with other languages/programs. Things like using JS to grab things about the user, send it to flash and have actionscript add more to it, and send it back to the JS so it can be sent to a CGI script to get it recorded on a log file (yes, this was a task for a survey my CEO wanted). Funny thing is, this was easier achieved then it sounds.
I cannot speak for all, but the reason for the example I gave, is that JS is awesome by itself, but it makes things interesting and a lot more fun for the developers when we can use other languages and programs to really put our scripts to work.
Im sure that i will have some more difficult challenges to overcome in the future - but for someone starting off with JS frameworks are massively useful.