JAVASCRIPT omtimization

[Dannii]

I can think of only one main addition that would be good for SMF to have, to obtimize the output files gmail style through javascript. To do this, you have to have large complex javascript files which create the webpage. the server sends only the barest minimum: the html header which cant be done through javascript, a little javascript code, and the actual text of the posts. no tables, formating or anything repeditive is sent from the php - all is created from javascript. doing so would probably decrease file size at least 60%, and the forum would also then run at least 60% faster.

look here to see an example of what i'm talking about: http://hosting.thegaminguniverse.com/seldonshand/

[Trekkie101]

That forum is VERY slow. Also i dont see a difference.

[Louis (CSpotkill)]

I agree that using XmlHttpRequest will be the future for speedy dynamic standards-compliant web programming. But the world's not ready for it yet. Google just recently created a plain HTML version of their excellent XmlHttpRequest-based site, because many older browsers still don't support it. So while it's a great idea, it's not going to happen in any default configuration without a fair bit of work co-ordinating both non-JavaScript & JavaScript versions. I suspect it would be easier to try to write a custom XmlHttpRequest-powered theme, with as few changes to the core SMF code as possible. And that if nothing else, a "find-as-you-type" (LiveSearch) feature would be an extremely cool mod. I was thinking of implementing it a month ago, but had other things to work on ...

[Dannii]

That forum is VERY slow. Also i dont see a difference.

difference with what? did you view the source code of the page? not the forum..


Now i realise that this might be harder. it would need a combined effort of work from the main coders and the theme designers.

Hm that XMLrequest stuff is different from what i had been doing. but my way would be compliant for all, although maybe slightly slower.

[mytreo]

Hi eldacar interesting topic! I checked out the page source and it's a cool thing that you've done there, even if I'm not quite sure how you done it!

However in all honesty I don't think building pages through server side javascript is really going to catch on - surely XML is already more advanced at delivering "content only" and it has fully defined standards. While you say you method would be compliant for all, I disagree because many browsers don't support javascript (especially on mobile devices) and many users turn javascript off entirely. Also I'd hate to think of the server load if you were serving thousands of dynamic pages through javascript!

It's a real interesting method and a great topic for discussion, but if SMF were to introduce such a feature then IMHO it really should be XML based.

I can't see any benefit of using javascript over XML which I guess is why I never even heard of this method before - where did you find it?!! It sometimes seems to me that ever since javascript was invented people have been desperately trying to find a reason for inventing it

Chris

[Louis (CSpotkill)]

Okay, I can see some people are confused about XmlHttpRequest. Basically, it lets you send out say, index.template.php and the formatting of one boardIndex row, then use XmlHttpRequest to pull a small file that just contains a list of the boards, and can populate the boardIndex table on-demand.

This way, if the user clicks a link on the homepage then goes back to the homepage (boardIndex), all it has to ask for is another small file with the board list (OR just ask if it has changed) and the server doesn't have to send out the same data over and over. As I mentioned, even Gmail needed to add an HTML-only version, but I fully believe you could implement this with just a theme (and maybe some minimal code changes through a mod). Because this technique is so new, it's highly doubtful that anyone who currently makes themes for SMF would understand it. (Most of the HTML would have to be in a JavaScript API so the formatting is called client-side through functions. Here's how Gmail worked over the summer.)

Again, a great example of how dynamic this can be is the interesting Find-as-you-type "LiveSearch" mod for blog software, which I still think could make a good SMF mod. (I've too many mod ideas, lol.)

[[Unknown]]

There are clear benefits with this methodology, but there are also very clear detriments.  Most notably, it makes support of browsers with JavaScript disabled or unavailable difficult, and it much increases accessability problems.

It can be faster or slower depending on whether the client machine/implementation of JavaScript is slow or fast, as well.

-[Unknown]

[Louis (CSpotkill)]

Well, that's why you'd need the current HTML for a backup. It would simply be a "layer" to add optimization for the current HTML code. It's a bit of a gimmick still, though.

[Dannii]

It can be faster or slower depending on whether the client machine/implementation of JavaScript is slow or fast, as well.

Yes but the transfer speeds would be much faster because of only sending vital info. and bandwidth use would be far less.

I don't know anything about this new XML stuff I will look into it =)

A new mod based on this would be good. but full html backup would be required. prehaps it is only done if you set it to a specific mod, and the defualt forum mod be full html?

[Dannii]

I've been thinking a little more about this, There is much that can be stored locally, such as board names and descriptions. i've developed a patching system that stiches together 4 JS databases, all updated with different frequencies. The themes of course can be stored locally, and even somethings like site news. Leaving the only info to be transmitted to be actual posts and data that changes regularly, such as post counts.