How Do Browsers Scale? 141
An anonymous reader writes "Benchmarking browsers is a somewhat silly exercise, since scores cannot be replicated on a variety of hardware, and it is not uncommon for even the same system to fail to replicate benchmarks scores, especially in JavaScript tests in two succeeding runs. The guys over at ConceivablyTech have an interesting approach, running browsers through multiple tests on different sets of hardware (including an Android smartphone), and showing the scaling differences between browsers when you are using a dual-core netbook on the low-end and a six-core desktop on the high-end. They also tested HTML5 on Firefox mobile and found the browser has better HTML5 support than the current Firefox 4 Beta 6."
Fx 4 beta 6 is months old now (Score:2, Interesting)
Beta 7 is waiting for these blockers to be fixed. [mozilla.org]
Need a better client-side scripting language (Score:5, Interesting)
Why, oh why did javascript become the defacto client-side scripting language for the browser
If you want to scale horizontally across multi-cores, you need a language that allows easy multi-threading and concurrency
About the only thing JS offers for concurrency is that horrid settimeout function
What we need is a better scripting language
Why not incorporate a Python interpreter into browsers, and develop a stripped down sub-set of python for use on the web
I see no technical issues in doing this, only trying to battle the inertia of JS
Re:Need a better client-side scripting language (Score:3, Interesting)
No, like this [parrot.org].
Re:Need a better client-side scripting language (Score:4, Interesting)
Some people do [pyjs.org].
Re:Yay bench (Score:1, Interesting)
You are right. Besides, I don't care about browser scalability right now. On most systems they are fast enough. The only time I notice a slow browser is the 6+ year old P4 machines at work our data entry people use. What typically slows down my experience is Flash. I'm not even talking about download times, but resource usage of flash. When the web is slow, it's adobe's fault.
Re:Need a better client-side scripting language (Score:5, Interesting)
Why not a VM that runs bytecode, and JIT compiling, so your favourite language can be used?
Several reasons. First, all such VMs - the JVM, .NET, Mono - have far worse startup performance than JavaScript. That's why Java applets never took off. While those VMs improved in that respect, they still lag far behind JS in startup time. They are optimized for long-running processes, not small client scripts that should get going instantaneously. Different goals here.
.NET or Mono - Jython, IronPython, etc.). IMHO it makes sense to have a low bar for writing scripts for websites. You shouldn't need to do C/C++ memory management, or write lots of static typing definitions, to add a little scripting to your website. So something like JavaScript, Python or Ruby makes sense. But again, this last point is clearly debatable, that's just my opinion.
Second, there is no clear open standard for such a VM anyhow. The JVM and CLR are known to have various patents around them; we have recently seen Oracle sue Google, and Microsoft execs have admitted that Mono is only free from risk because it is licensed by Microsoft. So neither is a good foundation for something meant to be truly open and free, like the Web should be.
Third, existing JavaScript engines are, by far, the fastest implementations of dynamic languages out there (much faster than such languages running on the JVM,
Re:Need a better client-side scripting language (Score:1, Interesting)
Javascript is a very powerful language which is really very elegant if you understand how to use it. The trouble is that most people treat it as a bastardized child of C.
What the world really needs is several books describing the zen of javascript. Perhaps there is also a need for an application compiler for JS as well.
Re:Fx 4 beta 6 is months old now (Score:3, Interesting)
Forget firefox (Score:1, Interesting)
as a long time user of firefox, and for a number of years now, chromium, let me say: chromium appears to work much better than anything else on the low end - largely due to its sane memory utilization when not much is available.
ironically it would appear that chromium/chrome's current limitation is actually one they inherrited from firefox. the cache engine slows firefox, and chrome, to a fucking crawl. ironically, google just took ff's engine and scaled it way out - to the point where it's architectually poorly suited. apparently, this is being fixed - and has been fixed in firefox 4.
Lets start with basics... (Score:1, Interesting)
I just want my browser to render a large table with hundreds of thousands of rows without having to wait forever.
Re:Need a better client-side scripting language (Score:3, Interesting)
Java was THE cool new language to come out at the time, and Netscape decided that if they call it "Javascript" it'd make people think they're connected.