completely agree, just want naive IE users to get a decent experience whenever they upgrade to the next version of windows. (windows 8 will be one of those rare win upgrades I will recommend to f&f when it comes out)
I am displaying the standard "use at your own risk" message box when users launch the shell from the main site on IE and we detect there is no canvas tag support.
YES! Minimizing IE6-8 *DOES* improve performance, and I found that interesting as well.
My take is that IE is "close" to the kernel in a lot of ways, and so you get them turning off their blitter or whatever (even though the scene is still rendered in the offscreen buffer). IE really is a mix of very fast and very slow parts (mostly the JavaScript engine is the "slow".) You know, while I was developing that code, I found so many interesting ways to hack the code to squeeze out marginally better performance. IE8 is an odd egg, only slightly better than IE6 and 7, in my opinion. I'm praying IE9 will rock.
The code only maxes out one core at the moment, so your experience is in-line with what I see as well (I run while compiling and running the dev server with the box gettin' all swappy, and it runs okay even then).
Darn. Well, I built IE support because I had to, not because I cared to. But that is really terrible how it behaved, sorry it didn't work well/at all. Sounds like Firefox and Chrome performed in-line with others though, so at least we got 2 out of 3.;)
Well, just trying to give the kids a simple language to start with. The site is for everyone, but it's supposed to be something a kindergardener or first grader could be introduced to. I feel we have a moral responsibility to get kids trained on how to code and learn 'em on what computers can be made to do. And so, that's why we made ClubCompy.
That said, I completely concur with you. We have plans to add a sort of "byte code" VM behind the scenes that we could target with an assembler or with a higher level language compiler. That's my dream to see that happen, anyways. Big kids need to learn assembly once they get bored with our "Tasty" language.;)
iPad! Very cool. Unfortunately, we haven't been able to get compy keyboard working with the iPad/iPhone's touch screen keyboard. So, if you go to the main site, I doubt you'll be able to play around with the shell. Sorry bout that, you'll have to stick with PC (or use the Compy Clipboard only to input code) if you want to write your own compy programs.
On a semi-related note, I don't have a handle on how much faster the iPad is over the iPhone (if at all). Last time I tested on those (~6 months ago) I recall the iPad was markedly faster. Do you happen to have an iPhone as well? Can you compare/contrast?
Most efficient? No. First of all, we want to accentuate the positive with HTML5, and that means leveraging Web Workers and freeing up the DOM thread to do DOM-like things. That is tricky though, lotsa delicate messaging required between modules, and we only halfway refactored the code for that before the Christmas release deadline hit. So, I anticipate all Web Worker-capable browsers will double in Tasty script interpreter performance once we get a chance to implement that. But, as for now, we're single-threaded on the DOM thread.
Also, Chromatic is a computer languages and VM expert since he's been knee deep in Parrot code for years, and once he can get some wrench time in, I'm sure he'll provide all sorts of optimizations. What I put together isn't horrible architecture-wise, so don't let me sell myself too short.
Anyways, for now you'll have to settle for this being a measurement of how well your favorite JavaScript engine's optimizers can JIT compile my less-than-optimal Javascript into okay-fine machine code.:)
Ew, like, IE didn't even load a test? It's ok if IE6-8 runs super slow and gets 1/6th of Firefox. IE6-8 doesn't have the Canvas tag after all, so we had to make do with VML. Bleh. But, if it didn't load at all for you on IE and all you saw was a blank canvas, then something must have broke.
Thanks for the report, your numbers look nearly the same as mine and I have a slightly slower AMD with less ram and running XP.
Re:JavaScript is ok, DOM is a train wreck
on
JavaScript Cookbook
·
· Score: 1
So what can we do?
In my opinion, there is not much we can do, short of running for office ourselves and making it a platform item that we are . This exchange has prompted me to send an email to my local library administrators, and I will probably make a follow-up phone call or two just to register my feelings. Honestly, I don't believe there will be any change in the system here until there absolutely must be change.
You tell me why I should expect anything different when we pay disinterested people to do uninteresting work and there's no consequences for bad behavior or bad performance because there are entrenched interests guarded and fostered by unions whose only mission is to get more gifts for their members... you tell me, why should I expect anything good to come out of the dumb public system we have setup for ourselves?
I tell you, the only answer is systems run and funded by unpaid volunteers, because state-run [anything] is always just the worst.:(
Re:JavaScript is ok, DOM is a train wreck
on
JavaScript Cookbook
·
· Score: 1
That's true.
Re:JavaScript is ok, DOM is a train wreck
on
JavaScript Cookbook
·
· Score: 1
That's not how the world works, and that's definitely not how public organizations work. You talk as if public institutions are hyper-competent and on the ball or something.
Sometimes the just and right thing to do is also the uncomfortable thing. You don't get to just spy an inequity and say, "it shouldn't be that way!" and then break your arm patting yourself on the back because your work is done here.
If you can actually EFFECT positive change in public libraries, then I would salute you, because foisting IE6 on poor people is such an injustice when, as you say, there are such superior free alternatives! But I suppose that you nor I can effect change, and so we land at the painful reality: justice is not served until the IE6 compatibility battle is won. And quite honestly, that's a modest battle if you consider that IE7 and IE8 are nearly as flawed animals. IE9 is going to be the first passable browser that MS releases.
Finally, IMO, starting any statement off with "let..." or "let them..." is elitist because it assumes far too much.
Re:JavaScript is ok, DOM is a train wreck
on
JavaScript Cookbook
·
· Score: 1
Yes you are a negative guy! "xml sucks"? Canadian email address? Pat answers? Negativo!! A heck of a lot of poor folks get internet connectivity from public libraries running IE6, you would deny them our collective experience! Neg-a-tive.
Re:JavaScript is ok, DOM is a train wreck
on
JavaScript Cookbook
·
· Score: 1
OH! Sounds like you have sixteen percent of the entire online world figured out. I sure am glad you don't run things.
I went to XML Sucks, and surprise surprise: I disagree with practically everything you have written. I disagree generally with your negative attitude.
Re:JavaScript is ok, DOM is a train wreck
on
JavaScript Cookbook
·
· Score: 1
A few seconds of googling shows you are uninformed:
IE6 is browser #3 in total market share with 16% share. IE8 is first with 28% followed by Firefox 3.6 with 16.8%.
You can't make the same argument about Netscape Navigator because its numbers are 1%.
I'll change my tune when IE6 finally drops off in usage, but that's only when XP finally falls out of widespread use, which will be in, what... 3-5 more years?
Re:JavaScript is ok, DOM is a train wreck
on
JavaScript Cookbook
·
· Score: 1
Oh I knew that statement was going to be controversial. Yes, IE is a huge source of pain, but for goodness sakes, butch up! Don't be so whiny and/or smug: usually we do not get a choice about what we must support, and often it is only IE that we must support. Are you doing something custom, and you wanna make a political statement and not support IE? Knock yourself out.
I am myself a huge critic of Microsoft, and I relish in the fact that the market demanded they support the Canvas tag in IE9, for instance. But, I'm not a zealot, and it currently makes a lot of sense to support IE.
And, regarding my assertion about supporting IE6 vs later IE's... Clearly, some issues like security/stability will not be addressed since that browser is EOL. But from a presentational and computational standpoint, you can get IE6 to do most everything IE7 and IE8 can do. In my opinion, if you can show support for IE6, you automatically get support for IE8 - so you might as well take your medicine and support it all and be available to the largest possible market.
I've found the JavaScript language implementations on most browsers to be generally competent and compatible with each other, differing only in memory use and execution speed. The DOM and its flavors and the way the browsers differ or are bugged is the real pain. The DOM is what makes the browser a poor application delivery platform.
This is why JQuery is such an important innovation. Of course the DOM is a data structure that should be queried and whose result sets are then manipulated. It just makes so much sense, and that model has enabled me to suffer the travails of cross-browser compatibility.
Here is what I suggest to anyone who is thinking of starting any sort of serious application development in JavaScript on the browser:
Do your day to day development using tools like Firefox/Firebug. But, if you're planning to support IE, test your code with IE6 every day.
Develop a convention you are comfortable with to create JavaScript classes (prototypes) that works reliably on the browsers you want to target. Learn how inheritance works so you can use it if you need it.
Learn how to scope your symbols, that local or private functions can be namespaced away in anonymous functions. Decide up front if you can get away with global variables or not in your application, and if not, get used to passing context objects to all static functions and constructors.
Discover and rigorously adopt a subset of the JavaScript language that works on all of the browsers you want to target.
Watch presentations on how to make your javascript more performant and easier to compress.
Pick a JavaScript library and focus your development around it. Try not to mix and match JavaScript libraries in your app that could run at cross purposes. JQuery is my favorite that I've found so far.
Your typical experience with the library should be that you write code that runs good in one browser and with little or no changes, it runs on the other browsers.
When the opposite occurs, there should be a reasonable workaround that leverages features of the library. The library should have masking browser incompatibilities as a primary concern (because that's where the cost lies, duh!)
Addons or plugins should be available to extend the functionality of the library.
Write really generic, clean, and compatible CSS and avoid the painful IE hacks as much as you can - instead, have no shame and use your JS library to patch up the DOM and behaviors on IE onLoad.
Browser feature detection libraries (like Modernizr) are really helpful in gracefully degrading your user experience when lesser browsers are missing a new, but non-critical feature.
"Build" your JavaScript files into some single deployable javascript file. Look into javascript compressors/packers, and gzipping your javascript before its transferred.
Look at the human tragedy. Thank God today you don't live like that.
And it's no one's fault over here, no unsigned treaty, that could create that kind of depravity. Please just for once put down your politics and look a problem square in the eye: China's just got a bad culture and a worse form of government. It's shameful to allow people to live so rotten, period.
NO, before you get all guilt-ridden and try to heap the blame on "us": shameful, rotten, PERIOD, end of story! Good day, sir.
Microsoft finally caved and built the canvas tag! ActiveX: Bonk with radioactive danger signs. Silverlight: Bonk. SVG? Meh, retained mode scenes with tags all over again. Souped up VML. I'm going to give that a Bonk too (even though it was hardware accelerated).
But canvas, now that's a pixel buffer: simple and beautiful! Now we are *talking*. DING DING DING!
Microsoft's building in canvas is a huge concession that they are losing mindshare to HTML5. And what they're doing is half right by building theirs faster and all micro-optimized and kernel-hooked as they love to do.
But this won't save them, they won't recapture the mojo. Well... that is, not until they backport these new HTML5 features to XP. Here's my take: adding features to an IE that is locked to Windows 7 does not make consumers want to buy Windows 7. Not when it is far simpler for the consumer to install a competing browser that runs on XP (and earlier.) I will go as far as to say that adding canvas to Windows 7's IE is really just advertising new features in the competition's browsers.
I love this canvas tag move by Microsoft, and its far overdue! But they're not back in the game until they stop all this nonsense and backport IE9 to XP (and, heck, Win2K while you're at it!) If your retort is "oh it costs too much to support, oh the API's have changed, oh you should upgrade your 9 year old turd of an OS!". C'mon. Cost? API's? We're talking about moneybags Microsoft here! They can do whatever they want; I have no pity for them when or if they fail due to another botched marketing plan and neither should you. And I will not upgrade my XP/Server 2003 until the reboots get faster on Windows 7. It takes my friend 5 minutes on cherry hardware to get a usable desktop after reboot, and his harddrive is always doing something in the background when nothing is going on! On my XP, the harddrive is quiet unless I am doing something with it, the CPU is idle unless I do something.
Upon further reflection over canvas... Here's a thought Microsoft, maybe I can meet you half way. How's about backporting canvas to IE7/8 but with no hardware acceleration? This way you can sell the merits of a Windows 7+IE9 upgrade. See, I can be reasonable.:)
Slashdot Mirror
thank you so much for the follow up, so cool that even the older ipod finished the tests!
completely agree, just want naive IE users to get a decent experience whenever they upgrade to the next version of windows. (windows 8 will be one of those rare win upgrades I will recommend to f&f when it comes out)
I am displaying the standard "use at your own risk" message box when users launch the shell from the main site on IE and we detect there is no canvas tag support.
Those are some beautiful numbers! And that chrome score is monstrous! Thanks for testing iphone, I'm glad it woked
YES! Minimizing IE6-8 *DOES* improve performance, and I found that interesting as well.
My take is that IE is "close" to the kernel in a lot of ways, and so you get them turning off their blitter or whatever (even though the scene is still rendered in the offscreen buffer). IE really is a mix of very fast and very slow parts (mostly the JavaScript engine is the "slow".) You know, while I was developing that code, I found so many interesting ways to hack the code to squeeze out marginally better performance. IE8 is an odd egg, only slightly better than IE6 and 7, in my opinion. I'm praying IE9 will rock.
The code only maxes out one core at the moment, so your experience is in-line with what I see as well (I run while compiling and running the dev server with the box gettin' all swappy, and it runs okay even then).
I am simply floored it works at all. (I have a Palm Pre, and it's a no-go there.) This truly is a brave new world we're entering.
Darn. Well, I built IE support because I had to, not because I cared to. But that is really terrible how it behaved, sorry it didn't work well/at all. Sounds like Firefox and Chrome performed in-line with others though, so at least we got 2 out of 3. ;)
Well, just trying to give the kids a simple language to start with. The site is for everyone, but it's supposed to be something a kindergardener or first grader could be introduced to. I feel we have a moral responsibility to get kids trained on how to code and learn 'em on what computers can be made to do. And so, that's why we made ClubCompy.
That said, I completely concur with you. We have plans to add a sort of "byte code" VM behind the scenes that we could target with an assembler or with a higher level language compiler. That's my dream to see that happen, anyways. Big kids need to learn assembly once they get bored with our "Tasty" language. ;)
iPad! Very cool. Unfortunately, we haven't been able to get compy keyboard working with the iPad/iPhone's touch screen keyboard. So, if you go to the main site, I doubt you'll be able to play around with the shell. Sorry bout that, you'll have to stick with PC (or use the Compy Clipboard only to input code) if you want to write your own compy programs.
On a semi-related note, I don't have a handle on how much faster the iPad is over the iPhone (if at all). Last time I tested on those (~6 months ago) I recall the iPad was markedly faster. Do you happen to have an iPhone as well? Can you compare/contrast?
Most efficient? No. First of all, we want to accentuate the positive with HTML5, and that means leveraging Web Workers and freeing up the DOM thread to do DOM-like things. That is tricky though, lotsa delicate messaging required between modules, and we only halfway refactored the code for that before the Christmas release deadline hit. So, I anticipate all Web Worker-capable browsers will double in Tasty script interpreter performance once we get a chance to implement that. But, as for now, we're single-threaded on the DOM thread.
Also, Chromatic is a computer languages and VM expert since he's been knee deep in Parrot code for years, and once he can get some wrench time in, I'm sure he'll provide all sorts of optimizations. What I put together isn't horrible architecture-wise, so don't let me sell myself too short.
Anyways, for now you'll have to settle for this being a measurement of how well your favorite JavaScript engine's optimizers can JIT compile my less-than-optimal Javascript into okay-fine machine code. :)
That says blazin' fast to me, you got a third of the ideal # of iterations on bumperbots. Was that on Safari?
Amazing celphone score, sweet!
I think your scores are good, it's all relative anyways, that's why I asked people to post what they get.
Thanks!
We're just reporting what JQuery reports. We'll get a better browser identification library and get more accurate values.
Ew, like, IE didn't even load a test? It's ok if IE6-8 runs super slow and gets 1/6th of Firefox. IE6-8 doesn't have the Canvas tag after all, so we had to make do with VML. Bleh. But, if it didn't load at all for you on IE and all you saw was a blank canvas, then something must have broke.
Thanks for the report, your numbers look nearly the same as mine and I have a slightly slower AMD with less ram and running XP.
Sorry, my bad, didn't mean to post anonymously
-- Dave
In my opinion, there is not much we can do, short of running for office ourselves and making it a platform item that we are . This exchange has prompted me to send an email to my local library administrators, and I will probably make a follow-up phone call or two just to register my feelings. Honestly, I don't believe there will be any change in the system here until there absolutely must be change.
You tell me why I should expect anything different when we pay disinterested people to do uninteresting work and there's no consequences for bad behavior or bad performance because there are entrenched interests guarded and fostered by unions whose only mission is to get more gifts for their members ... you tell me, why should I expect anything good to come out of the dumb public system we have setup for ourselves?
I tell you, the only answer is systems run and funded by unpaid volunteers, because state-run [anything] is always just the worst. :(
That's true.
That's not how the world works, and that's definitely not how public organizations work. You talk as if public institutions are hyper-competent and on the ball or something.
Sometimes the just and right thing to do is also the uncomfortable thing. You don't get to just spy an inequity and say, "it shouldn't be that way!" and then break your arm patting yourself on the back because your work is done here.
If you can actually EFFECT positive change in public libraries, then I would salute you, because foisting IE6 on poor people is such an injustice when, as you say, there are such superior free alternatives! But I suppose that you nor I can effect change, and so we land at the painful reality: justice is not served until the IE6 compatibility battle is won. And quite honestly, that's a modest battle if you consider that IE7 and IE8 are nearly as flawed animals. IE9 is going to be the first passable browser that MS releases.
Finally, IMO, starting any statement off with "let ..." or "let them ..." is elitist because it assumes far too much.
Yes you are a negative guy! "xml sucks"? Canadian email address? Pat answers? Negativo!! A heck of a lot of poor folks get internet connectivity from public libraries running IE6, you would deny them our collective experience! Neg-a-tive.
OH! Sounds like you have sixteen percent of the entire online world figured out. I sure am glad you don't run things.
I went to XML Sucks, and surprise surprise: I disagree with practically everything you have written. I disagree generally with your negative attitude.
A few seconds of googling shows you are uninformed:
http://marketshare.hitslink.com/browser-market-share.aspx?qprid=2
IE6 is browser #3 in total market share with 16% share. IE8 is first with 28% followed by Firefox 3.6 with 16.8%.
You can't make the same argument about Netscape Navigator because its numbers are 1%.
I'll change my tune when IE6 finally drops off in usage, but that's only when XP finally falls out of widespread use, which will be in, what ... 3-5 more years?
Oh I knew that statement was going to be controversial. Yes, IE is a huge source of pain, but for goodness sakes, butch up! Don't be so whiny and/or smug: usually we do not get a choice about what we must support, and often it is only IE that we must support. Are you doing something custom, and you wanna make a political statement and not support IE? Knock yourself out.
I am myself a huge critic of Microsoft, and I relish in the fact that the market demanded they support the Canvas tag in IE9, for instance. But, I'm not a zealot, and it currently makes a lot of sense to support IE.
And, regarding my assertion about supporting IE6 vs later IE's... Clearly, some issues like security/stability will not be addressed since that browser is EOL. But from a presentational and computational standpoint, you can get IE6 to do most everything IE7 and IE8 can do. In my opinion, if you can show support for IE6, you automatically get support for IE8 - so you might as well take your medicine and support it all and be available to the largest possible market.
http://ban.org/photogallery/index.html
Look at the human tragedy. Thank God today you don't live like that.
And it's no one's fault over here, no unsigned treaty, that could create that kind of depravity. Please just for once put down your politics and look a problem square in the eye: China's just got a bad culture and a worse form of government. It's shameful to allow people to live so rotten, period.
NO, before you get all guilt-ridden and try to heap the blame on "us": shameful, rotten, PERIOD, end of story! Good day, sir.
Microsoft finally caved and built the canvas tag! ActiveX: Bonk with radioactive danger signs. Silverlight: Bonk. SVG? Meh, retained mode scenes with tags all over again. Souped up VML. I'm going to give that a Bonk too (even though it was hardware accelerated).
But canvas, now that's a pixel buffer: simple and beautiful! Now we are *talking*. DING DING DING!
Microsoft's building in canvas is a huge concession that they are losing mindshare to HTML5. And what they're doing is half right by building theirs faster and all micro-optimized and kernel-hooked as they love to do.
But this won't save them, they won't recapture the mojo. Well... that is, not until they backport these new HTML5 features to XP. Here's my take: adding features to an IE that is locked to Windows 7 does not make consumers want to buy Windows 7. Not when it is far simpler for the consumer to install a competing browser that runs on XP (and earlier.) I will go as far as to say that adding canvas to Windows 7's IE is really just advertising new features in the competition's browsers.
I love this canvas tag move by Microsoft, and its far overdue! But they're not back in the game until they stop all this nonsense and backport IE9 to XP (and, heck, Win2K while you're at it!) If your retort is "oh it costs too much to support, oh the API's have changed, oh you should upgrade your 9 year old turd of an OS!". C'mon. Cost? API's? We're talking about moneybags Microsoft here! They can do whatever they want; I have no pity for them when or if they fail due to another botched marketing plan and neither should you. And I will not upgrade my XP/Server 2003 until the reboots get faster on Windows 7. It takes my friend 5 minutes on cherry hardware to get a usable desktop after reboot, and his harddrive is always doing something in the background when nothing is going on! On my XP, the harddrive is quiet unless I am doing something with it, the CPU is idle unless I do something.
Upon further reflection over canvas ... Here's a thought Microsoft, maybe I can meet you half way. How's about backporting canvas to IE7/8 but with no hardware acceleration? This way you can sell the merits of a Windows 7+IE9 upgrade. See, I can be reasonable. :)