- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
Distributed computing works for spammers... now it can work for the web too!
Admin
So, they're using JavaScript to create JavaScript which creates HTML elements?
Hmm. Maybe there's a need to dynamically redraw the client page without having to wait for a call to the server... ah, screw it. I'm not even going to try to justify this one. WTF!
Maybe this code was written by that guy who said "Have you tried JavaScript?" in every meeting.
Admin
XMLHTTP is IE only no?
Admin
Forgot to clarify -- we developed Intranet applications. IE only.
Admin
It was originally done by IE. There's a different model that works for Mozilla, and that has apparently been adopted by others as well... either Safari or Opera, but I don't remember which.
Admin
Opera is the only one lagging behind with XMLHttpRequest from modern browsers.
Admin
the latest beta of Opera includes support for XmlHTTP. Enough to get gmail working at least.
Admin
Well there's nothing wrong with advocating a thick client, but implementing the client stuff in JavaScript...bleuggghh!!
Admin
It's not that bad.
This is the work of true believers in caring for the server and offloading as much work for the client.
I mean, how often do you see such an example of dynamic programic such as this? This horribly inefficent-yet-inoccently looking method actually compiles this code. Naturally they didn't want to use this recourse wasting techniqe in a loop on the server.
This is quite a neat solution, having the client do all the work.
I wouldn't be suprise if the application had something to do with selling more hardware, so that is a good point too... [Y][B]
Admin
Sorry to defend the WTF, but I personally don't find it that bad. Sure it's a bit of a clunky method; but the first time you send it down the wire to the client in a js file and it's cached, then any table you want to produce you just need to send the data (and not the mark up) and it's formatted by the JS.
Mind you, the rendering of that table is not exactly going to be processor intensive; what this code will save is a little bandwidth here and there if tables are being sent to the browser regularly.
Admin
You would have to send down quite a few tables for this piece of maintenance nightmare to pay off.
Admin
ugly... shivers
we've come a long way, baby
Admin
Their concept is fine, offloading the server and making [heavy] use of the client is wonderful, and when done right can lead to wonderful things like gmail, oddpost and bindows.net.
The problem is their implementation. It's been a while since I've seen such horrid JS.
Admin
Heh, I use this method all the time, and this is why:
Sending HUGE clumps of HTML to the client can be slow. An example from real-life: we have a product in use somewhere with 9000 users. Sending over the userlist in HTML takes about 5 seconds on the server itself, but as it's an Internet app, it's usually sent to a remote location. On a not too fast line this can take up to 20 seconds, which is seen by many as too slow.
Anyhoo, I usually send my data through XML to the webpage (IE only apps, so i use the XML data island method), and then let javascript build the (mostly very repetetive) tables for me. This way I can for instance build 16 items, show them to the user and the build the next 16, so the user has xome idea of something happening, and isn't staring worriedly at his screen for 20 seconds.
I also use the object approach at times, when the data is static, but still very bulky, but i have two notes about the way this method is used here:
Just my two cents. The WTF about this is making such a HUGE datatype (how many columns???) instead of using an array for that.
Drak
Admin
Hmm... code that writes itself... sounds like the Evolution Pattern to me!
You know, those two might just have written the first internet AI...
Admin
Yeah, too bad for them that the Javascript to do this is way bigger than the actual HTML, and that's just for static content. The overhead for the server to get the data to the client to mangle into the table is more or less the same.
From that little story at the beginning, though, I think that developers who think that way think that the primary bottleneck on the server is the CPU, and not the bandwidth used to send the resulting data.
The one reasonable justification someone posted for this (speeding up large tables on slow links) almost makes sense, but wouldn't it make more sense to just implement some sort of pagination control and maybe an export into CSV format which can be parsed by programs which are meant to handle large tables (like spreadsheets)?
Admin
The web is full of popular servers with major CPU/memory shortages. I mean, bandwidth is still the primary shortage, but spending 30 seconds waiting on a server just to get a timeout message, or 15 seconds every time you click for another page in peak hours (and sometimes off-peak), really slows the whole web experience way down and frustrates people.
That said, most slow servers can be traced to shitty code or sucky shared servers, but fixing shitty code is much harder than pushing out half the processing to the client side with an off-the-shelf app framework like bindows.
There should be a whole category for wtfs involving long long long [snip] long chunks of cut & paste code.
Admin
<i>Never ever build a table like this. Just build its HTML totally in an array of strings which you later join. This is a huge amount faster. (And more understandable for others if you format your building code nicely)</i>
It is faster still to build each row as an array of strings that you then join and add to the array of rows. Then join the array of rows at the end.
The problem is that in JavaScript the += operator has to recopy all of the data. Therefore building a long string incrementally using += takes quadratic time. Building an array and then joining it solves that problem, but it introduces the new one of having a very large number of objects for garbage collection to deal with. Eventually that becomes a bottleneck. The approach that I outlined doesn't recopy strings too much, and also keeps down the number of objects.
Note that this general problem is not specific to JavaScript. You'll find it in many scripting languages like Ruby and Python. (Perl is a notable exception.) You'll also find it in "real" languages like C and Java (admittedly Java does have a datatype which allows you to build strings incrementally and efficiently, but by default strings are slow).
Cheers,
Ben
Admin
The implementation is not very hot, but offloading things to JS sometimes is a good solution.
We had to develop a timetable for our intranet app. It had to show 2 weeks of data, with around 5-15 "rooms" per day, with time ranges like 9:00-20:00, with table cells for each room/half hour.
If you do the numbers, this works up to a very large amount of cells. Sending this information as a table takes up several megabytes of data, so someone reimplemented this as JS. The table is quite sparse, so we can just send the used cells and work out the layout on the client.
Of course, this later became a bottleneck performance-wise on the client, so we applied a very low-tech solution. Just render the huge table on the server again, but install mod_gzip. The repetitive layout compresses very well and it becomes just a few k's that download fast even over slow links.
Alex the Koala
Yes, we probably should have applied a thicker-client approach; maybe an applet (we are a mostly Java shop). Probably we will hit some problems with this part in the future and I'll look into a Flash solution, or maybe an XMLHttpRequest solution, but both of our "rough" solutions were good enough at the time.
Admin
Depending on details, you may be able to replace the table with sparse cells (positioned via CSS) on top of empty cell borders (as a tiled background) - something like this:
<style type="text/css">
whole-thing { top: 0px; left: 0px; height: 1024px; width: 768px; background-image: "cell-borders.gif"; }
cell1 { top: 100px; left: 200px; height: 16px; width: 48px; }
cell2 { top: 300px; left: 400px; height: 16px; width: 48px; }
</style>
<div id=whole-thing>
<div id=cell1> <!-- data --> </div>
<div id=cell2> <!-- data --> </div>
</div>
Admin
Fluffster,
It would make sense, if you can force the people who are going to use this to have spreadsheet software on each client PC, or to have a policy where ActiveX is allowed. Sadly, our company cannot do that.
As for CSV, I don't trust the format. This is all Excel's fault. I once exported a CSV from Excel, and then couldn't load it into the same Excel again, properly. It seems that as a foolproof way of sending data you can't really beat XML, unless people start putting ]]> in their text [:P]
Drak
Admin
Please do me a favor, Never apply for a job at the company I work at.
Admin
Argh. What forum software is this? A bajillion script errors in IE (more on that in a moment), even.
Anyway. On the subject of XML as a data format:
"It seems that as a foolproof way of sending data you can't really beat XML, unless people start putting ]]> in their text"
User input ought to be escaped anyway, so that you have only ]]> rather than ]]>.
Back to IE: for some reason, the site refuses to work properly in Firefox. It'll load a portion, then it seems to get stuck in an infinite loop or something, since all the formatting disappears and only the picture and text on the top left can be seen.
I really hate this forum software. Why does it have 7 buttons for creating tables but no straightforward way to quote another post?!?
Admin
Things like this remind me of what a beautiful thing Flash Remoting. is.
Admin
It's not the forum software, it's the editing JS that causes the errors. Actually, if you don't move over any of the editing buttons while the thing is loading it will generate a lot less or even no errors.
There's a quote button next to each post to quote it...
I figured using CDATA you wouldn't need to escape... PCDATA yes, CDATA no.
That could just be my ignorance though.
Drak
Admin
Ah. The bit about not moving the mouse over it did help; last time, though, the "script error" dialog invariably popped up directly over the images, and I didn't realise that moving the cursor over them would cause errors, so... :)
Regarding quoting: what about if you need to quote multiple posts? I normally do that, and having no simple button to just wrap quote tags around text is very annoying.
Hrm... you're right there. My mistake.
Admin
Admin
Embrace the standard. Extend the standard. Extinguish the competition, no matter how much you plagarise from their proprietary features, break the standard, or destroy the reputations for build stability, web compatibility, and bug-freedom of everyone involved. Cue one of my stock "quotes": "Stupid browser people: They could be satisfied with good useable browsers but no every so often they have to have an orgy of buggy stupid-gimmicky-feature-of-the-day releases just to screw with us and then they have the gall to dignify it with the term "browser war"."