compiled to JavaScript idea
Howdy,
On Monday 05 November 2007 1:18 pm, Thomas Reilly wrote:
There's this hookey idea percolating that somehow we can use whatever language we want and compile it to JavaScript and that will be great. Hold that thought, now check this out:
community.netikatech.com/demos
I don't care how tricked out your JavaScript VM is, or how awesome your source language and compiler are, JavaScript today will never reach this richness of UI. Look how big and snappy the Flash data grid example is. (I love how slow the silverlight one is so slow to load, can anyone say applets? sorry couldn't help it...)
The flash version is indeed snappy by comparison, but it's kind of a rigged game. The silverlight version it needs is an alpha, and they'll have plenty of chances to iterate. I don't think this demo is a dig against ES3 in any way. Indeed, we can do better than the Silverlight example without resorting to plugins of any variety:
see: download.dojotoolkit.org/release-1.0.0/dojo-release-1.0.0/dojox/grid/tests
for locked columns and virtual scrolling: download.dojotoolkit.org/release-1.0.0/dojo-release-1.0.0/dojox/grid/tests/test_change_structure.html
For full effect, try it on Safari 3 or a recent Minefield/GranParadiso build.
If we can get similar performance for tasks like this in raw-browser environments (on today's ES3 implementations), then biting off the entire rendering phase is absolutely the wrong problem to solve. Your example points out to me not that having a better VM matters...it's that the level of effort to get to a UI which is completely inappropriate on my Mac is tremendously high ;-)
[ snip ]
Salient point: we should pimp the performance potential of ES4 more and label the anti-ES4 crowd as performance-haters which I don't think is far from the truth.
This strikes me as both dangerous and wrong. That many of the folks railing against ES4 are using weak arguments doesn't seem to me to be a green light to do the same in favor of the new language.
On Nov 8, 2007 12:33 PM, Alex Russell <alex at dojotoolkit.org> wrote: [...]
The flash version is indeed snappy by comparison, but it's kind of a rigged game. The silverlight version it needs is an alpha, and they'll have plenty of chances to iterate. I don't think this demo is a dig against ES3 in any way. Indeed, we can do better than the Silverlight example without resorting to plugins of any variety:
see: download.dojotoolkit.org/release-1.0.0/dojo-release-1.0.0/dojox/grid/tests
for locked columns and virtual scrolling: download.dojotoolkit.org/release-1.0.0/dojo-release-1.0.0/dojox/grid/tests/test_change_structure.html
For full effect, try it on Safari 3 or a recent Minefield/GranParadiso build.
If we can get similar performance for tasks like this in raw-browser environments (on today's ES3 implementations), then biting off the entire rendering phase is absolutely the wrong problem to solve. Your example points out to me not that having a better VM matters...it's that the level of effort to get to a UI which is completely inappropriate on my Mac is tremendously high ;-)
[ snip ]
if you stay on ES3 the only place where you can improve the performance is the engine interpreting the JS, but even with the best of breed interpreter you ll hit a dead end at one moment or another (I mean you can not infinitely squeeze performance out of the engine, it has limits)
types and other things added in ES4 can help an engine to have better performance wether if you got an engine that interpret the raw script or a VM that run the bytecode of the compiled script, but even with that I think a VM will be able to squeeze out even more performance.
I don't say Tamarin and ES4 are fully related, but the combination of the two is exactly what gonna bring huge performance improvement imho.
so, you must have guessed, I don't agree
zwetan
Thanks for the rebutal, I was wondering if my wild claims would go unchallenged ;-)
The flash version is indeed snappy by comparison, but it's kind of a
rigged game.
Despite my allegences to the mother ship I wasn't recommending Flash or Silverlight. I was pointing out that folks are feeling compelled to resort to them for performance reasons. Why does Gmail use flash under the covers for instance? I'll leave it as a dtrace exercise for the curious but I bet performance might have something to do with it.
If we can get similar performance for tasks like this in raw-browser environments (on today's ES3 implementations), then biting off the entire rendering phase is absolutely the wrong problem to solve.
Again, not my point, its not like these engines are using ES3 to do the rendering (although I could go off on a tangent about how if you had ES4 and certain key optimizations in the JIT than you could write a fine renderer in ES4).
Your example points out to me not that having a better VM
matters...it's that the level of
effort to get to a UI which is completely inappropriate on my Mac is
tremendously high ;-)
I know right? Where's the mac love? If you don't need more performance out of your JS engine then good for you! Lots of people I think want more performance out of there browsers scripting language and ES4 will be a catalyst for getting there. My point is that certain ES4 features (ie classes and strong typing) will enble (in theory) ES4 implementations to provide the same level of performance Java and C# have.
This is the second time I've heard Safari 3's performance being raved about. Anyone have any benchmark pointers?
Salient point: we should pimp the performance potential of ES4 more and label the anti-ES4 crowd as performance-haters which I don't think is far from the truth.
This strikes me as both dangerous and wrong. That many of the folks railing against ES4 are using weak arguments doesn't seem to me to be a green light to do the same in favor of the new language.
Why is my argument weak? Please tell me how ES3 can reach the same level of performance as Java/C#, I'd love to hear it!
Maybe its an indulgence on my part to jump to the conclusion that certain ES4 detractors are doing so b/c they don't want ES4 implementation to match their own preferred language/platform in performance but I stand by my claim that ES4 is an enabler for such performance gains.
There's this hookey idea percolating that somehow we can use whatever language we want and compile it to JavaScript and that will be great. Hold that thought, now check this out:
community.netikatech.com/demos
I don't care how tricked out your JavaScript VM is, or how awesome your source language and compiler are, JavaScript today will never reach this richness of UI. Look how big and snappy the Flash data grid example is. (I love how slow the silverlight one is so slow to load, can anyone say applets? sorry couldn't help it...)
My point is that to reach JVM/CLR speeds ES4 with its strong typing and early binding are necessities. Sure a VM can be smart and take simple untyped code and get you most of the way there with type inference and runtime profile based JIT'ing but with ES4 dumb (and smaller) VM's can get great speed just by looking at the typing (ie Tamarin). But that really only applies to microbenchmarks doing math in a loop, Tamarin does good here but that's not what most real applications do. Most real applications spend all their time looking up variables, pounding on symbol tables and visiting memory like crazy. I'm unaware of any workable and implemented techniques to get early binding accomplished in ES3 w/o breaking the language. Tamarin resorts to no trickery and gets variable lookups down to a couple instructions and one cache line load, that's why Tamarin/Java/C# do well in big real world applications that JavaScript will never be able to handle in its current incarnation. I guarantee all JavaScript implementations out there take hundreds of instructions and at least half dozen cache line loads to look up a variable today (not counting AS3/Tamarin), if your JavaScript VM can beat that my hat's off to you (but I won't believe you unless you can show me the code or explain it in full detail ;-)
My point is that while in theory you don't need ES4 for performance reasons (as accurately espoused by Brendan) in practice ES4 will greatly help performance and enable more powerful applications like people might want to built with netikatech's library. Their stuff is also cool b/c under the covers I think they are employing a C# to abc (Tamarin's byte code format) compiler. Notice they didn't implement a C# to JavaScript compiler and target DHTML? Not realistic. Sure there's other good reasons for wanting static typing and classes but lets face it, they help a lot in the speed department and speed is king and ES4 will blow the doors off of ES3 in practice I bet (although I wouldn't be surprised if certain unmotivated browser vendors may run ES4 more slowly).
Salient point: we should pimp the performance potential of ES4 more and label the anti-ES4 crowd as performance-haters which I don't think is far from the truth.