Hello Forum Users, We are a yet small, but innovative and dynamic company from Poland. During our over 2-year activity we have developed several interesting projects. We would like to share our experience with programmers community, that's why we decided to start our company programmer's blog. Each month (according to the plan we will publish one, as we wish interesting, article concerning wide area of webdevelopment. First of all we introduce our self-developed jQuery plugin - AjaxGetContent. It allows to transform traditional, standard website into a dynamic web page based on AJAX calls. Thanks to this, site achieves ultrafast behavior, maintaining full visibility for search engines and functionality of browser navigation buttons (back/forward). Some sample projects with the plugin implemented (mainly in Polish): www.implico.pl (our company homepage) www.ptchprie.pl (Polish Plastic and Aesthetic Surgeons Society) www.finestra.pl (windows manufacturer) www.klin-winter.pl (household goods wholesaler) www.sportolimp.pl (sport goods wholesaler) The article and files for download are available here: http://www.implico.pl/lang-en/ajaxgetcontent_dynamic_ajax_website,7.html Github link: https://github.com/implico/AjaxGetContent Enjoy reading Any feedback will be appreciated. Bartosz Sak, Project Manager Implico, www.implico.pl/lang-en/ P.S. Next article title: "Params class. Easy multiple arguments handling in PHP".
Great idea for those who can't develop their own code. (But there are easier ways to maintain navigation with AJAX, and a properly written site will be indexed properly. Since the AJAX content is usually sent to the browser in response to user action, hard code can't load what the user will load, so invisible default data will be seen by search engines.)
A stellar example of how not to build websites, thanks entirely to scripting bloat pissing on pages... particularly since it DOES seem to break forward and back here, with half a megabyte of scripting that even once compressed is larger than the upper limit I'd allow a page on a normal site to be -- that's HTML+CSS+SCRIPTS+non-content images! Starts out sad with jquery bloat, and just gets worse from there... and for what? Some noodle-doodle BS about "pageloads are evil?" -- using AJAX to replicate the functionality of framesets, something that was deprecated for a reason? Really, if the sites you used are examples of how you build sites, I truly pity your clientèle... since 483k (1.1 megabytes uncompressed) in 80 files to deliver 1.6k of plaintext and 6 or 7 content images in an inaccessible "WCAG, what's that?" layout is NOT how things should be done. Perfect example of javascript bloat for NOTHING of any value... though entirely what I've come to expect from the folks who think jquery is a good thing.
@Rukbat: thank you @deathshadow: we do not expect to evaluate our website, but to review our plugin. Our website is quite old, basicly IE6 compatible; see our newer projects to get more optimized code. But as I can see, you are generally a jQuery adversary - so I guess we can do nothing to convince you. Why replicate the functionality of framesets? Websites run very fast and save bandwidth. That's a lot.
I fail to see how throwing a couple hundred K of javascript at the firstload is going to save bandwidth when well written markup for most of those sites should come in at below 3k after compression. Doesn't make any sense, never has. Like "sportolimp" (ouch, that name is BAD in english -- ranks right up there with expertsexchange) which is one of the better written sites has what, 12k of markup served gzipped as around 3k? Since AJAX is the same number of requests with the same overhead, and it's not exactly the type of thing to have a user revisiting the same pages over and over, how exactly is that 62k (180k unpacked) of javascript saving you anything or making anything 'faster'?!? The extra markup around the part you're AJAX replacing doesn't even total 5k uncompressed, and around half a K compressed -- and if you stripped out the HTML 5 bloat, polyfill nonsense, meta's that nothing actually uses, and pointless scripting, unnecessary classes (The old 'if every like tag inside a parent is getting the same class, none of them need classes), that could be cut roughly in half. (I figure around 3k). Seriously, that site seems to at least ATTEMPT to use semantics and separation of presentation from content (though the semantics need some SERIOUS help) so what's it need this AJAX bloat for? Just trying to make it slower, use MORE bandwidth and break normal navigation? (seriously, site works better and faster scripting off!) Basically, the difference in 'speed' and bandwidth should be half a K per pageload less using AJAX so as not to retransmit the extra markup -- and realistically could be as little as a quarter k if the pages were just written better -- while spending 62k to do it? Yeah, that makes sense -- not. MAYBE if you get 124 or more pageloads per visitor you might break even... Using AJAX to replace pageloads is basically just throwing more code at a non-issue -- and more code is NEVER faster or less bandwidth no matter how much some people will vehemently claim otherwise! It's just replicating what people used to do with iframe, forgetting that much like the painfully bad abuse of 'target' it was deprecated for a REASON. It's scripting like this that makes people block scripts on sites. It is a stunning example of abusing javascript to make pages bigger, fatter and slower -- despite the wild claims and outright lies that it does the exact opposite. Poster child for everything wrong with how people are using javascript for nothing these days.
Oh, also if you're going to have an English language page and are serious about that, get a native English speaker to review your copy. It sounds like a mix of Yoda and Zathras.
Of course there are a few legitimate uses for AJAX, but it's like tables. "Ooohh, now I can just put things in tables and move them around." But a page that gives the user access to a database, where the same page can be used over and over to display the next 25 rows, then the next, then the next, etc., runs faster and is nicer to the user if the only thing that changes as he hits the Next button is the table (and it's also a legitimate use of tables). A little (it doesn't take much) Javascript and the contents of the table changes. The only data going across the network is "next" or "previous" (which can be a single character) and the new data from the database coming back, maybe with a JSON wrapper (and a count, if you want to save a line of JS in the browser). As far as nav is concerned, the nav buttons on the table do that. About all you can't do, without some additional code, is bookmark a particular part of the database being displayed.