Well, the examples are pretty simple. In one case you don't check for malloc() failing condition. One if() less, several cycles less. In case of not enough memory the program would coredump instead of quitting with error code. In the other case the for(); {} does n dry runs of empty for(); (ignoring anything after the semicolon) which do nothing but increment the counter, then executes the {} once. Only the last element would get re-rendered because when for() ends, its index is left at its last value and that's what the next instruction will take. Normally you never put ; after for() unless you packed everything inside the round braces and the following curly ones would come empty, like for(int i=0,j=strlen(string);ij;i++,j--,c=string[i],string [i]=string[j],string[j]=c); (which is some bad (but working) example of programming.) Note you can't do the same thing with while(), while(check(x++)); won't work, you need while(check(x++)){} or (cleaner, not completely equivalent though) while(check(x)){x++;}
hehehe, a friend's father owned an arcade salon. He usually had one or two machines in the basement of his house and we would come to play. But sometimes the ROMs (often multiple boards the size of a big PC motherboard each) were missing, there was just one, with that space shooter I can't remember the name of, because it was buggy like this: You would just move to about 3/4 screen left and keep shooting in short bursts and all the enemies spawning would get killed before they could do anything. (if the screen was empty, the enemies would spawn in that particular place, only if there were some on the screen they would spawn elsewhere). So, after like 20 minutes of doing this, the enemies would stop spawning. At all. You would fly through the empty space, moving freely and shooting at nothing till you cycled power on the machine, as there was nothing and no one to kill you so you couldn't even even restart. Apparently some people in the salon figured that out too and were locking up the machine like that.
There were several implementations of River Raid so if you used a (any) ROM then it was likely other implementation than the one I was loading from tape (at 600 baud, argh!) I cheated too, and in my version after level 50 it would just loop through several "typical" levels at the same difficulty (I got bored around lvl 150, as nothing was perceivably changing). I guess the thing is, with each level the river grows more narrow, my version had a hard limit, your got to negative width values:)
Everyone gets oh-so-pissed and righteous about the game being about killing cops and nobody seems to give a shit about prostitutes, who are treated equally bad in the game.
hehehe, a game with an impossible winning condition?:D I wrote a pacman clone for my calculator. I managed to finish it in the normal mode, even though last 3 levels were a hell. (just imagine Pacman with most of the walls removed and no energy balls:) Then the game was switching to "expert" mode where after every life lost all the dots on the level would respawn so you have to start chomping anew. I never finished it.
AFAIR it did. You need to have the city to stable and prosperous enough to bring enough profit without extra attention to sustain itself, and generally "run by itself" (or something around these lines) plus 98% or more popularity. Then the game displays something about you being the most likely winner of the country's presidential elections, and then you're free to continue playing:) (quite a few games dump you into a world "after victory" letting you explore, play minigames etc. You won but you can still play around.)
Level 50 of River Raid could be considered the last: the game doesn't change after that, the level of difficulty remains. H.E.R.O. has about 16 levels, from which last 4 run in a loop. Boulder Dash, AFAIR shows some congrats, then dumps you back to level 1. Blue Max plays a nice mellody, then loops you seamlessly back into the same route. IIRC, Moon Patrol has 3 worlds with 3rd looped around. Behind Jaggi Lines never ends. Montezuma has that last room where you multiply your items, but then you can go all the way back (to the beginning of darkrooms where the ladders seem broken) and kill everything that moves with multiplied swords, and then you're left in the empty world. Frogger just grows in difficulty towards impossiblity...
Personally I dislike games where you have no winning condition whatsoever... but they were quite common in the past. Actually, unset frag limit, unset time limit and start deathmatch in any FPS, and you don't have a win condition either.
or this: for(int i=0; i<num_elements;i++); {
redraw(element[i]); }
Sanity checks take time. Omitting them saves this time. Doesn't matter if the code doesn't do the checks intentionally (design) or by omission (bug), it will be faster. Since evidently raw memory shows through from under an absolutely positioned element once moved, that's a result of a missing sanity check. The check would reveal a missing piece that needs to be rerendered or brought back from cache (which would take time). Instead, the part isn't re-rendered. I don't know the motives of Opera authors that cause this. I don't care if they did it intentionally or just forgot to fix it. It is an error that results in faster, but buggy drawing of the pages.
But that's just bad programming, not a bug. Now for a speed-up bug: Which code will work faster?
this: for(int i=0; iHow is Opera 6 relevant exactly? It is several years old. Opera 6 did have limited DOM support, but Opera 7 addressed that. So it was Opera 7, because we were doing that goddamn menu through DOM and suffering with shitty support that completely ignored distribution of style changes to descendant elements once the page stopped loading.
And you are clearly not competent enough to make comments about "shortcuts". Again, bugs are not shortcuts. So they are bugs that make Opera work faster. It doesn't do what it should do, omits some important operations while rendering pages. I don't care if they are intentional or not. They just make webdeveloper's life hell. You can see your page loading in Opera in 0.3s and in Firefox in 3s because it took me to write that piece of HTML for Firefox in 3 minutes and then to fix it to work correctly in Opera as well during next 3 hours.
A bunch of lies and baseless assumptions and speculation based on a couple of bugs you stumbled upon? A couple of bugs that avoided require increased CPU usage, bugs that are omissions of operations. Missing HTML/CSS/DOM features, interpretations of standards that reduce workload at rendering the pages while providing the worst defaults that are still legal, error handling routines that just bomb out whole processing instead of trying to avoid the error gratefully and continue and a gallore of stuff that just breaks when the circumstances are a hair width away from standard.
Moreover, writting in Perl is fast and easy. You can test your ideas, check if the game would be playable at all, create a working mockup in Perl and finding "not enough raw horsepower" move to C with the "final product". Sure it will take longer than writing everything in C from scratch, but shorter than writing everything in C and then deciding it sucks and abandonning it.
Bugs or features, hard to tell. Certainly saving on some sanity checks speeds things up. Opera is known to refresh only changed (through JS/DOM for example) elements and not the whole document, and this has led a long way of suffering for developers - Opera 6 or 7 did refreshing only of affected element while completely neglecting ALL the neighborhood and child elements, making all the drop-down menus etc a hell to make (you change visibility of the menu container but visibility of its child elements - menu items doesn't change. You just get an empty border popping up, no links inside) This has been corrected in Opera 8, but not completely. It affects child and neighbour elements and the changes usually propagate thorough the document (that is, a changed neighbour affects its own neighbours) but still sometimes (especially in case of absolutely/relatively positioned elements that appear elsewhere than the static flow would put them) it misses a thing or two with updating, redrawing, adjusting, resizing etc. That's a long line of bugs resulting directly from design considerations which were definitely speed savings (it IS easier for the programmer to do a full refresh/rerender of whole document than just a few items within it, but it takes considerably more CPU time). Doing the easy stuff instead of the right stuff is common thorough Opera. (Relatively positioned elements affect each other in the drawn position instead of at the source position. The scrollbars of textarea are another good example - "if nobody told us to hide scrollbars explicitly, we will show them even if they aren't functional"). Errors in CSS often tend to break processing of all the rest of CSS instead of just skipping the faulty entry.) Some of it may be bugs. Some are the design. Most of them make Opera fast by being less paranoid than other browsers.
I clearly know enough of Opera to point out all of the above which I have stumbled upon myself, trying to port a "standards-compilant" webpages to Opera. (of course they DO render correctly, according to some twisted interpretation of "correctly" though. I just need to jump through loops to make them display what I want and what both MSIE and FF have no problems displaying. The problem is w3c standards leave a lot of freedom for interpretation and Opera loves to interprete them some other way than the others.) You on the other hand, with no single solid argument sound like a rabid Opera fanboy. What about a good rebuttal instead?
Because Opera makes quite a few shortcuts while rendering HTML. It's standards-compilant in the way it passes most of basic checks. But it rarely tries to do the Right Thing when standards don't say what to do. I remember killing an absolutely positioned DIV and being left with 'memory view' junk instead of rerendering the elements below. Or a DIV being a draggable window leaving a trail of unerased 1-pixel border junk. I've tried hiding scrollbars on textarea through stylesheets, 'scrolling' property, no such luck - I can disable scrolling but the scrollbars are there. Well, the specs say when to display scrollbars, not when not to display them, though you'd think that's obvious. Oh, and what about the fun non-standard scrollTop property? Opera claims to support it, then ignores its content entirely when it comes to textareas and some other elements. There's currently no way to dynamically append some text to textarea contents without having it scrolled all the way up.
There are lots and lots of such examples. The developers have a great excuse, "the standards don't say what to do, so why should we care?" but these things are annoying as hell. If specs says "user agents may choose not to render..." Opera usually chooses so. When specs say "the behaviour is unspecified", Opera does the easiest thing, not the one that "feels right".
If I was to compare it to a human I'd say it's lazy. Least effort to achieve what the boss says, result as fast out of the desk as it can, half-assed job that will pass QA but won't satisfy the customer. Specs said so, so I did it. Specs didn't say anything so I didn't do anything.
Okay, you use tabbed browsing, tricks that turn linear back-forward navigation into tree-like structure. It works, it works okay. But still the AJAX thing does it cleaner, faster, easier, more pleasant. (plus DA puts really LOTS of crap on each of the pages and on my low-end computer loading it even in a separate tab freezes the whole browser for a good while, but that's not something you should fix by using AJAX but rather by rethinking the HTML structure...)
Also, this concept was there with HTTP and DHTML, so while you are definitely right about this being a potentially smart way to do this, it has nothign to do with AJAX other then that AJAX does not conflict with it, and in fact suggests using such solutions.
How else are you going to replace a piece of page with data from the server which wasn't available while the page was loaded, without reloading the whole page? Sure, DHTML using DOM, but you don't just paste what you typed in and send a copy to the server. You send your data to the server, it parses it, replaces markers with icons, validates for no malicious HTML, sends back parsed version and allows the app to include it in the page. (there are a few hackish ways to load external data without AJAX, say var import=createNode('script'); import.src="http://....js"; document.appentChild(import)) but generally AJAX is considered THE way to do it.)
The issue is that AJAX basicly adds an alternative for GET/PUT requests, no more and no less. and inserting the results into current page without replacing it whole.
I also guess this is why KDE for example loads itself and its whole bunch of applications all at once, you might just need them.
We're not talking about desktop environment or operating system. We're talking about an application. Most apps load up all the needed libs on startup.
(oh, and Gimp 2 takes all of 11 seconds to load here anyway..) Feel lucky.
Well, if that is the one web application you are going to need for the next 30 minutes or so you have a point. That works for some applications and not for others.
And here I agree 100%. If you looked at my/. user page, you'd see one of two accepted stories is "AJAX sucks most of the time". It really does, because in most of cases where it's used, it's misused. There are few cases where it makes sense and does a good work. I gave one of these examples - I'm really happy with this new feature of DA, because it seriously cuts on page load times and in my case they were often horrible.
Oh, and I still wonder why people think it is efficient to load everything upfront, regardless of if it is going to be used. Not only does it affect initial load time, it also affects overall resource use of the application in a negative way.
because for the user there's way less difference between 40 and 50 seconds than between 0.5s and 3s. One long disruption of flow is way less annoying than lots of small ones. Ever used Windows running out of RAM and going on Swap? When you press Start, wait 5s for the menu to show, hover the pointer over "Programs", wait another 5s, move the pointer to "Applications" and from habit move it right, before the submenu opens, so Start Menu closes and you need to repeat, "start", 5s, "Programs", 5s, "Applications", 5s, "Notepad", 30s. But somehow people don't complain much about Windows load times. Don't you hate when you travel the directory tree and the computer freezes, while spinning up the CD to read contents because they happen to be linked? It could have done this before, while you didn't look. Maybe it would waste some resources. Maybe you wouldn't ever open the directory. But if you did, you wouldn't wait. CPU time is cheap. User time isn't.
Adding one attribute at a time can be time consuming, though i suppose you could write a function and pass it all the values and let the function handle it for you
You can write a function to do everything. You can write perl interpreter in Javascript and that would certainly speed up development of further programs (writing in Perl is very fast and easy) but I guess that somehow misses the point.
I think, though, that a lot of this is encumbered by not being able to swear up and down that the data is valid xml data. Javascript can't be allowed to die a horrible, horrible death upon finding nodes that are a little out-of-spec Some of it, true. Most of it is just some legacies of design though, I think. Quite a few things could be made easier without loss of "durablity".
Grabbing content of <p> like in your example sure makes sense. But what about this: <p>[\n] <b>Hello World!</b>[\n] </p>
The specs say the single newline should be ignored. So some browsers ignore it by not rendering it, but the DOM still contains a text node consisting of a single linebreak before <b>. Some browsers ignore it totally, removing it from DOM. Shooting in the foot. Sure in your example <p> had 3 legal children. In my example it has between 1 and 3 depending on implementation. Which option is correct?
And more importantly, is there a programming language that already handles this in a sensible and concise manner? Something that can set the stage? I haven't played with the DOM in anything other than javascript and php.
If there is any, I don't know it. But I just mean we are stuck with uglinesses of javascript DOM in AJAX, no matter if it's underlying HTML, XUL or whatever else.
And don't get me wrong. It's powerful, it gives a lot of possiblities, it is quite reliable and has a lot of virtues. But it's really ugly. The backend is strong and reliable. But the "DOM Frontend", syntax, functions, programmer's interface, this all is one horrible kludge that shouts "ICK!" and should be rewritten from scratch.
or generally anything that would make it less verbose. Every smallest operation requires kilometers of DOM methods. Why the hell call parentNode.replaceChild() if you know the element you want replaced and you're really not interested in the parent? Why fun, pleasant methods like innerHTML are essentially made useless in the specs? ('adds a new page in history stack' or something). Why not push around some plaintext HTML strings and then call something like document.rerender(); to apply changes? Why no easy aggregation methods of changing multiple things at a time? Why no new data types that support new kinds of values? (document.class('header').style.fontSize+='1px'; document.form2.replyarea.style.{height:"5em + 8px",padding:"4px"} ?
Sure it IS powerful. But - you need to spell out the least detail of everything you want. No 'default actions', want an element? First specify type, then create attributes, one a time, then find the location of the parent in the tree, then use not-too-fun methods to put it at desired location between the children. - Awkward traversing of the element tree. this.parentNode.nextSibling.firstChild ? or document.forms[1].radio2[4].checked ? - Extreme verbosity. e=document.pleaseVeryMuchGiveMeAnElementWhoseNameS oundsLike('x'); - Specs asking to shoot yourself in the foot. (are newlines between tags 'textNodes'? How to find first non-textnode child of an element easily then? When ".value" is equal to innerHTML and when it's something different?)
> Art piece gets posted, now lets assume this is a big picture and give it 2mb.
Let's assume it's average and it's 100K. It's meant for viewing online, not printing. Some morons like to post 3000x2000 GIFs but most people try to stay around 800x600.
> comments get added, lets assume people really have something to say, and write 300 comments that average 2k bytes each.
Counting in the HTML overhead (borders, links, styles etc) yes, about 2k each.
> Now, the page also contains some other stuff like menus, logo etc, lets say this is another 50k for the html and 200k for pictures (logo etc).
Probably more but DA puts in lots of crap, so let's say yes.
> So, the first time you look at this, regardless of it using AJAX or some PHP based solution or the like, you need to download some 2850k.
Including HTTP headers for each request, about 1M. (100k instead of 2M)
> Next refresh this will be 650k in case of a traditional (CGI/PHP whatever solution), everything else will come from cache, and that is if the comments changed at all.
Add about 50 HTTP requests 1k each, checking if things (pics) didn't change since the last time. "Next refresh" occurs after you added your comment so the comments DID change. So, about 700k.
> It will be 600k in case of AJAX when the comments changed (the comments have to be loaded, the page layout etc not).
No, you load only new comments. Old ones remain in place. If one comment of 2k was added, there was about 1k of content, 1k of HTML overhead which sits inside the JS so isn't downloaded, 1k of xmlhttprequest overhead. So about 2k downloaded. Other comments didn't change, remain untouched.
> In either case it will be a few bytes if the comments didn't change (and the server is smart enough to realize).
They did, because you added one yourself.
> So, total gain for this example would be a bit less then 50k. Not really impressive, and not the huge kind of difference you seem to believe is possible.
700k - 2k = 698k. Profit: bandwidth usage reduced by 99,7%. Considering the server-side throttling (on one hand) and lag for exchange of the AJAX dialog (on the other hand), you get waiting down from about 40s to 2s.
> Ah yes... and luckily the JS code AND layout data for doing this didn't have to be sent to your computer beforehand, regardless of if you were going to reply..
Once. <script src="..."> Later just 1k to check if the script changed and needs to be reloaded. No matter how many pages of different artists I visit. With some luck, at next visit it will be still in the disk cache.
> If a website presents you with a form, it did have to send you that form first, REGARDLESS of AJAX. The form did not just magically appear in the memory of your computer.
But it sent everything in one batch, using heavily paralell transmissions. I didn't have to wait for the form to load separately. Before I click and I see the result, it takes at least some 2s, no matter how big is the page. But this is moot, the form being placed there dynamically is just a convenient trick. The idea is that after I add a comment, I don't wait to see it in context with the page reloading from scratch. It gets included at once, and I can go back to reading/writing more without waiting for the updated comments page to reload. 2s instead of 40s.
> AJAX has some very nice things, but it is not the silver bullet you seem to think it is when it comes to nice responsive web applications.
"nice" - needs good design. "responsive" is the keyword, and it IS the silver bullet here. You wait ONCE. Like with local apps, I start up my favourite GIMP and go read/. before it loads, but when it works, it works, same here, you need to let the AJAX app to load, go, read some other page in a different tab or have a cup of coffee, but then you go back to the AJAX-enabled page and everything gets very fast and responsive. Your workflow isn't continuou
Is there really something wrong with clear, simple HTML pages that load quickly without all this flash/ajax/flavour-of-the-month-tool crap shoved in just to please web fashion victims?
Yes. Amount of repeatable content, basic pain of CGI/PHP. Take a GOOD application of AJAX: DeviantArt comments. Each art piece posted to the site may be commented by the users. Sometimes there's 200-300 comments, discussion occurs etc. Indentation provides some threading, there are some basic forum-like features etc. You probably want to cut on page switching when you dig into the comments. You set it to display 100 per page. Including links, avatars, smileys and some more such crap plus bandwidth throttling from the server if you're not a subscriber, it starts getting really lengthy to load the comments page. But it's still better than loading 20 separate pages 10 comments each. Then you want to participate in the discussion...
Non-AJAX, non-javascript, pure CGI way: Click "Reply" in given thread. Wait for the "reply" form for given thread to load. Type your answer. Click "preview". Wait for preview to load. Click "send". Wait for the whole discussion page, 100 posts, plus your answer to load.
AJAX way: Click "Reply". Immediately a textarea appears, where your post would go, with "send", "preview" and "cancel" buttons. You type in your reply and press "preview". The border around the textarea blinks for a moment and then turns into your post's final look, in context of the 100 other posts, differing only by "preview" replaced by "edit" (which with no further delay gets you back to editing your post). You click "send" and the border blinks a moment more. Buttons vanish, your post is placed in the context amongst all the rest, where it was supposed to be. No single other post gets reloaded.
Been there. A Knoppix CD and a mp3 player for/home. Three months of heavy use (writing my thesis and lots of software associated with it, plus building a custom IDE for further work on that software). Ended up busting the Flash of the mp3 player.
mp3 players use cheaper, less durable flash memory than pendrives - meant to withstand one-two write operations per block a day, for several years. If you perform 10 write operations a second (Firefox cache?) you will murder it really fast.
Slashdot Mirror
...that they were concerned the game would promote THE OTHER aspect of the gameplay?
GoAT. Faults of FF are no excuse for flaws of Opera.
Well, the examples are pretty simple. In one case you don't check for malloc() failing condition. One if() less, several cycles less. In case of not enough memory the program would coredump instead of quitting with error code. In the other case the for(); {} does n dry runs of empty for(); (ignoring anything after the semicolon) which do nothing but increment the counter, then executes the {} once. Only the last element would get re-rendered because when for() ends, its index is left at its last value and that's what the next instruction will take. Normally you never put ; after for() unless you packed everything inside the round braces and the following curly ones would come empty, likeg [i]=string[j],string[j]=c);
for(int i=0,j=strlen(string);ij;i++,j--,c=string[i],strin
(which is some bad (but working) example of programming.)
Note you can't do the same thing with while(), while(check(x++)); won't work, you need while(check(x++)){} or (cleaner, not completely equivalent though) while(check(x)){x++;}
Ever played Mortal Kombat with 1-button joystick?
hehehe, a friend's father owned an arcade salon. He usually had one or two machines in the basement of his house and we would come to play. But sometimes the ROMs (often multiple boards the size of a big PC motherboard each) were missing, there was just one, with that space shooter I can't remember the name of, because it was buggy like this: You would just move to about 3/4 screen left and keep shooting in short bursts and all the enemies spawning would get killed before they could do anything. (if the screen was empty, the enemies would spawn in that particular place, only if there were some on the screen they would spawn elsewhere). So, after like 20 minutes of doing this, the enemies would stop spawning. At all. You would fly through the empty space, moving freely and shooting at nothing till you cycled power on the machine, as there was nothing and no one to kill you so you couldn't even even restart. Apparently some people in the salon figured that out too and were locking up the machine like that.
There were several implementations of River Raid so if you used a (any) ROM then it was likely other implementation than the one I was loading from tape (at 600 baud, argh!) :)
I cheated too, and in my version after level 50 it would just loop through several "typical" levels at the same difficulty (I got bored around lvl 150, as nothing was perceivably changing).
I guess the thing is, with each level the river grows more narrow, my version had a hard limit, your got to negative width values
Everyone gets oh-so-pissed and righteous about the game being about killing cops and nobody seems to give a shit about prostitutes, who are treated equally bad in the game.
hehehe, a game with an impossible winning condition? :D :) Then the game was switching to "expert" mode where after every life lost all the dots on the level would respawn so you have to start chomping anew. I never finished it.
I wrote a pacman clone for my calculator. I managed to finish it in the normal mode, even though last 3 levels were a hell. (just imagine Pacman with most of the walls removed and no energy balls
You put your olymous upside down so now it works as an onotrackba
AFAIR it did. You need to have the city to stable and prosperous enough to bring enough profit without extra attention to sustain itself, and generally "run by itself" (or something around these lines) plus 98% or more popularity. Then the game displays something about you being the most likely winner of the country's presidential elections, and then you're free to continue playing :)
(quite a few games dump you into a world "after victory" letting you explore, play minigames etc. You won but you can still play around.)
Level 50 of River Raid could be considered the last: the game doesn't change after that, the level of difficulty remains. H.E.R.O. has about 16 levels, from which last 4 run in a loop. Boulder Dash, AFAIR shows some congrats, then dumps you back to level 1. Blue Max plays a nice mellody, then loops you seamlessly back into the same route. IIRC, Moon Patrol has 3 worlds with 3rd looped around. Behind Jaggi Lines never ends. Montezuma has that last room where you multiply your items, but then you can go all the way back (to the beginning of darkrooms where the ladders seem broken) and kill everything that moves with multiplied swords, and then you're left in the empty world. Frogger just grows in difficulty towards impossiblity...
Personally I dislike games where you have no winning condition whatsoever... but they were quite common in the past.
Actually, unset frag limit, unset time limit and start deathmatch in any FPS, and you don't have a win condition either.
But that's just bad programming, not a bug. Now for a speed-up bug:
Which code will work faster?
this:
for(int i=0; i<num_elements;i++)
{
redraw(element[i]);
}
or this:
for(int i=0; i<num_elements;i++);
{
redraw(element[i]);
}
Sanity checks take time. Omitting them saves this time. Doesn't matter if the code doesn't do the checks intentionally (design) or by omission (bug), it will be faster. Since evidently raw memory shows through from under an absolutely positioned element once moved, that's a result of a missing sanity check. The check would reveal a missing piece that needs to be rerendered or brought back from cache (which would take time). Instead, the part isn't re-rendered. I don't know the motives of Opera authors that cause this. I don't care if they did it intentionally or just forgot to fix it. It is an error that results in faster, but buggy drawing of the pages.
Which code will work faster?
this:
int* x;
x=malloc(200);
or this:
int* x;
x=malloc(200);
if(x==NULL) exit(-1);
But that's just bad programming, not a bug. Now for a speed-up bug:
Which code will work faster?
this:
for(int i=0; iHow is Opera 6 relevant exactly? It is several years old. Opera 6 did have limited DOM support, but Opera 7 addressed that.
So it was Opera 7, because we were doing that goddamn menu through DOM and suffering with shitty support that completely ignored distribution of style changes to descendant elements once the page stopped loading.
And you are clearly not competent enough to make comments about "shortcuts". Again, bugs are not shortcuts.
So they are bugs that make Opera work faster. It doesn't do what it should do, omits some important operations while rendering pages. I don't care if they are intentional or not. They just make webdeveloper's life hell. You can see your page loading in Opera in 0.3s and in Firefox in 3s because it took me to write that piece of HTML for Firefox in 3 minutes and then to fix it to work correctly in Opera as well during next 3 hours.
A bunch of lies and baseless assumptions and speculation based on a couple of bugs you stumbled upon?
A couple of bugs that avoided require increased CPU usage, bugs that are omissions of operations. Missing HTML/CSS/DOM features, interpretations of standards that reduce workload at rendering the pages while providing the worst defaults that are still legal, error handling routines that just bomb out whole processing instead of trying to avoid the error gratefully and continue and a gallore of stuff that just breaks when the circumstances are a hair width away from standard.
Bye, troll.
Moreover, writting in Perl is fast and easy. You can test your ideas, check if the game would be playable at all, create a working mockup in Perl and finding "not enough raw horsepower" move to C with the "final product". Sure it will take longer than writing everything in C from scratch, but shorter than writing everything in C and then deciding it sucks and abandonning it.
Bugs or features, hard to tell. Certainly saving on some sanity checks speeds things up. Opera is known to refresh only changed (through JS/DOM for example) elements and not the whole document, and this has led a long way of suffering for developers - Opera 6 or 7 did refreshing only of affected element while completely neglecting ALL the neighborhood and child elements, making all the drop-down menus etc a hell to make (you change visibility of the menu container but visibility of its child elements - menu items doesn't change. You just get an empty border popping up, no links inside) This has been corrected in Opera 8, but not completely. It affects child and neighbour elements and the changes usually propagate thorough the document (that is, a changed neighbour affects its own neighbours) but still sometimes (especially in case of absolutely/relatively positioned elements that appear elsewhere than the static flow would put them) it misses a thing or two with updating, redrawing, adjusting, resizing etc. That's a long line of bugs resulting directly from design considerations which were definitely speed savings (it IS easier for the programmer to do a full refresh/rerender of whole document than just a few items within it, but it takes considerably more CPU time). Doing the easy stuff instead of the right stuff is common thorough Opera. (Relatively positioned elements affect each other in the drawn position instead of at the source position. The scrollbars of textarea are another good example - "if nobody told us to hide scrollbars explicitly, we will show them even if they aren't functional"). Errors in CSS often tend to break processing of all the rest of CSS instead of just skipping the faulty entry.)
Some of it may be bugs. Some are the design. Most of them make Opera fast by being less paranoid than other browsers.
I clearly know enough of Opera to point out all of the above which I have stumbled upon myself, trying to port a "standards-compilant" webpages to Opera. (of course they DO render correctly, according to some twisted interpretation of "correctly" though. I just need to jump through loops to make them display what I want and what both MSIE and FF have no problems displaying. The problem is w3c standards leave a lot of freedom for interpretation and Opera loves to interprete them some other way than the others.) You on the other hand, with no single solid argument sound like a rabid Opera fanboy. What about a good rebuttal instead?
On related note, how will the predator find which kid he is stalking?
Because Opera makes quite a few shortcuts while rendering HTML. It's standards-compilant in the way it passes most of basic checks. But it rarely tries to do the Right Thing when standards don't say what to do.
I remember killing an absolutely positioned DIV and being left with 'memory view' junk instead of rerendering the elements below. Or a DIV being a draggable window leaving a trail of unerased 1-pixel border junk. I've tried hiding scrollbars on textarea through stylesheets, 'scrolling' property, no such luck - I can disable scrolling but the scrollbars are there. Well, the specs say when to display scrollbars, not when not to display them, though you'd think that's obvious. Oh, and what about the fun non-standard scrollTop property? Opera claims to support it, then ignores its content entirely when it comes to textareas and some other elements. There's currently no way to dynamically append some text to textarea contents without having it scrolled all the way up.
There are lots and lots of such examples. The developers have a great excuse, "the standards don't say what to do, so why should we care?" but these things are annoying as hell. If specs says "user agents may choose not to render..." Opera usually chooses so. When specs say "the behaviour is unspecified", Opera does the easiest thing, not the one that "feels right".
If I was to compare it to a human I'd say it's lazy. Least effort to achieve what the boss says, result as fast out of the desk as it can, half-assed job that will pass QA but won't satisfy the customer. Specs said so, so I did it. Specs didn't say anything so I didn't do anything.
Sorry, but the rebuttal isn't "+1 insightful" but "-1 YHBT".
Okay, you use tabbed browsing, tricks that turn linear back-forward navigation into tree-like structure. It works, it works okay. But still the AJAX thing does it cleaner, faster, easier, more pleasant.
(plus DA puts really LOTS of crap on each of the pages and on my low-end computer loading it even in a separate tab freezes the whole browser for a good while, but that's not something you should fix by using AJAX but rather by rethinking the HTML structure...)
Also, this concept was there with HTTP and DHTML, so while you are definitely right about this being a potentially smart way to do this, it has nothign to do with AJAX other then that AJAX does not conflict with it, and in fact suggests using such solutions.
/. user page, you'd see one of two accepted stories is "AJAX sucks most of the time". It really does, because in most of cases where it's used, it's misused. There are few cases where it makes sense and does a good work. I gave one of these examples - I'm really happy with this new feature of DA, because it seriously cuts on page load times and in my case they were often horrible.
How else are you going to replace a piece of page with data from the server which wasn't available while the page was loaded, without reloading the whole page? Sure, DHTML using DOM, but you don't just paste what you typed in and send a copy to the server. You send your data to the server, it parses it, replaces markers with icons, validates for no malicious HTML, sends back parsed version and allows the app to include it in the page. (there are a few hackish ways to load external data without AJAX, say var import=createNode('script'); import.src="http://....js"; document.appentChild(import)) but generally AJAX is considered THE way to do it.)
The issue is that AJAX basicly adds an alternative for GET/PUT requests, no more and no less.
and inserting the results into current page without replacing it whole.
I also guess this is why KDE for example loads itself and its whole bunch of applications all at once, you might just need them.
We're not talking about desktop environment or operating system. We're talking about an application. Most apps load up all the needed libs on startup.
(oh, and Gimp 2 takes all of 11 seconds to load here anyway..)
Feel lucky.
Well, if that is the one web application you are going to need for the next 30 minutes or so you have a point. That works for some applications and not for others.
And here I agree 100%. If you looked at my
Oh, and I still wonder why people think it is efficient to load everything upfront, regardless of if it is going to be used. Not only does it affect initial load time, it also affects overall resource use of the application in a negative way.
because for the user there's way less difference between 40 and 50 seconds than between 0.5s and 3s. One long disruption of flow is way less annoying than lots of small ones. Ever used Windows running out of RAM and going on Swap? When you press Start, wait 5s for the menu to show, hover the pointer over "Programs", wait another 5s, move the pointer to "Applications" and from habit move it right, before the submenu opens, so Start Menu closes and you need to repeat, "start", 5s, "Programs", 5s, "Applications", 5s, "Notepad", 30s. But somehow people don't complain much about Windows load times. Don't you hate when you travel the directory tree and the computer freezes, while spinning up the CD to read contents because they happen to be linked? It could have done this before, while you didn't look. Maybe it would waste some resources. Maybe you wouldn't ever open the directory. But if you did, you wouldn't wait. CPU time is cheap. User time isn't.
Adding one attribute at a time can be time consuming, though i suppose you could write a function and pass it all the values and let the function handle it for you
You can write a function to do everything. You can write perl interpreter in Javascript and that would certainly speed up development of further programs (writing in Perl is very fast and easy) but I guess that somehow misses the point.
I think, though, that a lot of this is encumbered by not being able to swear up and down that the data is valid xml data. Javascript can't be allowed to die a horrible, horrible death upon finding nodes that are a little out-of-spec
Some of it, true. Most of it is just some legacies of design though, I think. Quite a few things could be made easier without loss of "durablity".
Grabbing content of <p> like in your example sure makes sense.
But what about this:
<p>[\n]
<b>Hello World!</b>[\n]
</p>
The specs say the single newline should be ignored. So some browsers ignore it by not rendering it, but the DOM still contains a text node consisting of a single linebreak before <b>. Some browsers ignore it totally, removing it from DOM. Shooting in the foot. Sure in your example <p> had 3 legal children. In my example it has between 1 and 3 depending on implementation. Which option is correct?
And more importantly, is there a programming language that already handles this in a sensible and concise manner? Something that can set the stage? I haven't played with the DOM in anything other than javascript and php.
If there is any, I don't know it. But I just mean we are stuck with uglinesses of javascript DOM in AJAX, no matter if it's underlying HTML, XUL or whatever else.
And don't get me wrong. It's powerful, it gives a lot of possiblities, it is quite reliable and has a lot of virtues. But it's really ugly. The backend is strong and reliable. But the "DOM Frontend", syntax, functions, programmer's interface, this all is one horrible kludge that shouts "ICK!" and should be rewritten from scratch.
document.e1.modeType='H1'; document.e1.value=reqResult;
e sult);
S oundsLike('x');
or
e1=document.createElement('h1',id='e1',value=reqR
document.e1.replaceWith(e1);
or generally anything that would make it less verbose. Every smallest operation requires kilometers of DOM methods. Why the hell call parentNode.replaceChild() if you know the element you want replaced and you're really not interested in the parent? Why fun, pleasant methods like innerHTML are essentially made useless in the specs? ('adds a new page in history stack' or something). Why not push around some plaintext HTML strings and then call something like document.rerender(); to apply changes? Why no easy aggregation methods of changing multiple things at a time? Why no new data types that support new kinds of values? (document.class('header').style.fontSize+='1px'; document.form2.replyarea.style.{height:"5em + 8px",padding:"4px"} ?
Sure it IS powerful. But
- you need to spell out the least detail of everything you want. No 'default actions', want an element? First specify type, then create attributes, one a time, then find the location of the parent in the tree, then use not-too-fun methods to put it at desired location between the children.
- Awkward traversing of the element tree. this.parentNode.nextSibling.firstChild ? or document.forms[1].radio2[4].checked ?
- Extreme verbosity. e=document.pleaseVeryMuchGiveMeAnElementWhoseName
- Specs asking to shoot yourself in the foot. (are newlines between tags 'textNodes'? How to find first non-textnode child of an element easily then? When ".value" is equal to innerHTML and when it's something different?)
> Art piece gets posted, now lets assume this is a big picture and give it 2mb.
/. before it loads, but when it works, it works, same here, you need to let the AJAX app to load, go, read some other page in a different tab or have a cup of coffee, but then you go back to the AJAX-enabled page and everything gets very fast and responsive. Your workflow isn't continuou
Let's assume it's average and it's 100K. It's meant for viewing online, not printing. Some morons like to post 3000x2000 GIFs but most people try to stay around 800x600.
> comments get added, lets assume people really have something to say, and write 300 comments that average 2k bytes each.
Counting in the HTML overhead (borders, links, styles etc) yes, about 2k each.
> Now, the page also contains some other stuff like menus, logo etc, lets say this is another 50k for the html and 200k for pictures (logo etc).
Probably more but DA puts in lots of crap, so let's say yes.
> So, the first time you look at this, regardless of it using AJAX or some PHP based solution or the like, you need to download some 2850k.
Including HTTP headers for each request, about 1M. (100k instead of 2M)
> Next refresh this will be 650k in case of a traditional (CGI/PHP whatever solution), everything else will come from cache, and that is if the comments changed at all.
Add about 50 HTTP requests 1k each, checking if things (pics) didn't change since the last time. "Next refresh" occurs after you added your comment so the comments DID change. So, about 700k.
> It will be 600k in case of AJAX when the comments changed (the comments have to be loaded, the page layout etc not).
No, you load only new comments. Old ones remain in place. If one comment of 2k was added, there was about 1k of content, 1k of HTML overhead which sits inside the JS so isn't downloaded, 1k of xmlhttprequest overhead. So about 2k downloaded. Other comments didn't change, remain untouched.
> In either case it will be a few bytes if the comments didn't change (and the server is smart enough to realize).
They did, because you added one yourself.
> So, total gain for this example would be a bit less then 50k. Not really impressive, and not the huge kind of difference you seem to believe is possible.
700k - 2k = 698k. Profit: bandwidth usage reduced by 99,7%. Considering the server-side throttling (on one hand) and lag for exchange of the AJAX dialog (on the other hand), you get waiting down from about 40s to 2s.
> Ah yes... and luckily the JS code AND layout data for doing this didn't have to be sent to your computer beforehand, regardless of if you were going to reply..
Once. <script src="...">
Later just 1k to check if the script changed and needs to be reloaded. No matter how many pages of different artists I visit. With some luck, at next visit it will be still in the disk cache.
> If a website presents you with a form, it did have to send you that form first, REGARDLESS of AJAX. The form did not just magically appear in the memory of your computer.
But it sent everything in one batch, using heavily paralell transmissions. I didn't have to wait for the form to load separately. Before I click and I see the result, it takes at least some 2s, no matter how big is the page. But this is moot, the form being placed there dynamically is just a convenient trick. The idea is that after I add a comment, I don't wait to see it in context with the page reloading from scratch. It gets included at once, and I can go back to reading/writing more without waiting for the updated comments page to reload. 2s instead of 40s.
> AJAX has some very nice things, but it is not the silver bullet you seem to think it is when it comes to nice responsive web applications.
"nice" - needs good design.
"responsive" is the keyword, and it IS the silver bullet here. You wait ONCE. Like with local apps, I start up my favourite GIMP and go read
Is there really something wrong with clear, simple HTML pages that load quickly without all this flash/ajax/flavour-of-the-month-tool crap shoved in just to please web fashion victims?
Yes. Amount of repeatable content, basic pain of CGI/PHP. Take a GOOD application of AJAX: DeviantArt comments. Each art piece posted to the site may be commented by the users. Sometimes there's 200-300 comments, discussion occurs etc. Indentation provides some threading, there are some basic forum-like features etc. You probably want to cut on page switching when you dig into the comments. You set it to display 100 per page. Including links, avatars, smileys and some more such crap plus bandwidth throttling from the server if you're not a subscriber, it starts getting really lengthy to load the comments page. But it's still better than loading 20 separate pages 10 comments each. Then you want to participate in the discussion...
Non-AJAX, non-javascript, pure CGI way: Click "Reply" in given thread. Wait for the "reply" form for given thread to load. Type your answer. Click "preview". Wait for preview to load. Click "send". Wait for the whole discussion page, 100 posts, plus your answer to load.
AJAX way: Click "Reply". Immediately a textarea appears, where your post would go, with "send", "preview" and "cancel" buttons. You type in your reply and press "preview". The border around the textarea blinks for a moment and then turns into your post's final look, in context of the 100 other posts, differing only by "preview" replaced by "edit" (which with no further delay gets you back to editing your post). You click "send" and the border blinks a moment more. Buttons vanish, your post is placed in the context amongst all the rest, where it was supposed to be. No single other post gets reloaded.
Been there. A Knoppix CD and a mp3 player for /home. Three months of heavy use (writing my thesis and lots of software associated with it, plus building a custom IDE for further work on that software). Ended up busting the Flash of the mp3 player.
mp3 players use cheaper, less durable flash memory than pendrives - meant to withstand one-two write operations per block a day, for several years. If you perform 10 write operations a second (Firefox cache?) you will murder it really fast.