4 ms·

Why do you doubt that it makes a difference in the real world? One of the things you need to remember is that in general, web app developers need to target yes

by lambda 14y ago

Why do you doubt that it makes a difference in the real world? One of the things you need to remember is that in general, web app developers need to target yesterday's browser on yesterday's hardware. So they tend to be fairly conservative about the performance requirements. But as browsers and hardware improve, the benefits trickle down until suddenly, it's possible to do something that you never could do before. So sure, the average web app, which is designed to run on old versions of IE on outdate hardware, probably won't see much of an improvement to this. But cutting edge demos absolutely will. And when this version is the "old browser running on old hardware", general purpose web apps will absolutely be able to take advantage of these improvements and do things that would simply be unheard of beforehand.

corresation 14y ago
One of the things you need to remember I have been building and architecting very rich web applications before most caught onto this web thing. I was an original tester of XmlHttpRequest back when it was a safe-for-scripting ActiveX "abomination". I recently made a ridiculously full featured stop-motion recording studio -- in the browser -- for my children after they were enamored by something similar at the Science Centre. And JavaScript performance has not been -- remotely -- an issue for a long, long time. The facets that make these apps powerful are technologies like WebGL, Canvas, SVG, CSS, and so on. Things that I wouldn't imagine doing more than simple orchestrations in code. People use JavaScript performance on a completely artificial benchmark like Sunspider as a proxy for real-world browser performance. Yet it is at most a minor correlation, and has incredibly little to do with causation of a good experience. If you think I'm joking or overstating, turn off the JIT in your browser and use it for a day. Is your experience devastated? Can you even tell the difference?
- kkowalczyk 14y ago
  There's a big difference between "my use case" and "all use cases". Sure, JavaScript is fast enough for a lot of things. But it's also too slow for many things that reasonable people would like to do on the web. See Mozilla's pdf.js: it makes perfect sense to have a PDF viewer written in JavaScript (and not a blob of insecure C++ code in the form of the plugin). pdf.js would not be possible at all "long, long time ago", even though JS was adequate for your use cases at that time. pdf.js is barely possible today - it works for simple documents but its performance on more complex documents is still so much worse than what C++ plugin gives that many people go back to plugins. Performance is one of the most important competitive aspects of software. Given 2 products with similar features, people go for the faster, which is a big reason why Chrome was so successful. We're still far away from making JS speed covering all the important use cases. Until JavaScript can decode mp4 in JavaScript (at speeds not much slower than optimized C++), JavaScript is not fast enough.
  - nnethercote 14y ago
    > There's a big difference between "my use case" and "all use cases". Yes. This is an appropriate response to a significant fraction of the complaints on this site and all other tech sites. I usually think of it as "your experience is not universal".
  - tracker1 14y ago
    Given the direction of gaming and streaming, your mp4 example seems apt... I think being able to do a 1080p stream at 30-60fps in JS is an appropriate goal for both hardware, and software. Canvas+JS is likely to be the "thin" client structure or the future... I think if it were possible to do this in JS, we wouldn't need ignorant plugin points for DRM.. encrypted streaming could "just work" on any platform, not that I want more DRM. I like that we are finally at a point, where legacy emulators in JS are a reality. I do think some attention to worker interaction, and perhaps locking say a canvas, or audio channel to a worker should be something able to be done.
    - corresation 14y ago
      I think being able to do a 1080p stream at 30-60fps in JS is an appropriate goal Why is that an appropriate goal? How about a video element -- which the browser implements in the ideal manner (which is usually a thin layer over hardware decoding) -- that handles h264? Why in the world would you want to do that in JavaScript, besides as a "because I can" challenge? Further your notion that DRM would "just work" is really unclear. I don't think you understand the concerns of the DRM folks if you think that you'll just do it in decrypt.js and all will be good.
- lotyrin 14y ago
  I'd like to have a meet-up and invite all the dudes like you and all of the kind of dude that complains about how asm.js performance is still so slow that they don't see the point and will just keep writing "native".
  - corresation 14y ago
    You're wading into a discussion that is above you. Generally that isn't a good idea. JavaScript proper cannot be a high performance language because of fundamental design choices. Asm.js, which I've referenced multiple times, undoes many of those choices, effectively becoming a completely different language (which is why you target it with C/C++ and LLVM, not by writing it directly). The notion that there are going to be legitimate video stream processing or h264 decoders in JavaScript -- that are more than a impractical "if you ignore normal considerations" demo -- is 0%. It makes no sense, and it is using the wrong tool, making everything into a nail because someone "knows JavaScript". This is doubly true on mobile where you want to make every instruction count. All of the examples in here are a riot. Further gaming in HTML5 thus far has been "welcome to the 80s". It has gone nowhere. Nor has any other "pure JavaScript" high computing adventure. nodejs, which I love, is a wonderful asynchronous glue, but everyone knows that you dare not do any actual computations in it because...JavaScript.
    - lotyrin 14y ago
      > You're wading into a discussion that is above you. Generally that isn't a good idea. Making assumptions about the knowledge of people you're responding to is cool though. > Further gaming in HTML5 thus far has been "welcome to the 80s". Oh, see I guess I was thinking Unreal 3 and Sauerbraten were released much more recently than that. Oops, silly me. You're right, the browser should just only ever be for web pages, everything should just stay how it is now and all these damn kids should get off your lawn.
      - corresation 14y ago
        Oh, see I guess I was thinking Unreal 3 The Unreal 3 demo was an entirely different thing. Asm.js is a dramatic rethinking of JavaScript that tosses much of the language, and adds hacked typing metadata, to essentially act as a proxy for C. The single benefit that it brings over just going with C is that existing browsers can limpingly run it in crippled mode. You're right And then you boringly completely misrepresent my argument. You should tell the kids to get off your lawn, as you're busy trying to pretend everything is a nail because all you know is your hammer.

by lambda 14y ago

corresation 14y ago

One of the things you need to remember I have been building and architecting very rich web applications before most caught onto this web thing. I was an original tester of XmlHttpRequest back when it was a safe-for-scripting ActiveX "abomination". I recently made a ridiculously full featured stop-motion recording studio -- in the browser -- for my children after they were enamored by something similar at the Science Centre. And JavaScript performance has not been -- remotely -- an issue for a long, long time. The facets that make these apps powerful are technologies like WebGL, Canvas, SVG, CSS, and so on. Things that I wouldn't imagine doing more than simple orchestrations in code. People use JavaScript performance on a completely artificial benchmark like Sunspider as a proxy for real-world browser performance. Yet it is at most a minor correlation, and has incredibly little to do with causation of a good experience. If you think I'm joking or overstating, turn off the JIT in your browser and use it for a day. Is your experience devastated? Can you even tell the difference?

kkowalczyk 14y ago
There's a big difference between "my use case" and "all use cases". Sure, JavaScript is fast enough for a lot of things. But it's also too slow for many things that reasonable people would like to do on the web. See Mozilla's pdf.js: it makes perfect sense to have a PDF viewer written in JavaScript (and not a blob of insecure C++ code in the form of the plugin). pdf.js would not be possible at all "long, long time ago", even though JS was adequate for your use cases at that time. pdf.js is barely possible today - it works for simple documents but its performance on more complex documents is still so much worse than what C++ plugin gives that many people go back to plugins. Performance is one of the most important competitive aspects of software. Given 2 products with similar features, people go for the faster, which is a big reason why Chrome was so successful. We're still far away from making JS speed covering all the important use cases. Until JavaScript can decode mp4 in JavaScript (at speeds not much slower than optimized C++), JavaScript is not fast enough.
- nnethercote 14y ago
  > There's a big difference between "my use case" and "all use cases". Yes. This is an appropriate response to a significant fraction of the complaints on this site and all other tech sites. I usually think of it as "your experience is not universal".
- tracker1 14y ago
  Given the direction of gaming and streaming, your mp4 example seems apt... I think being able to do a 1080p stream at 30-60fps in JS is an appropriate goal for both hardware, and software. Canvas+JS is likely to be the "thin" client structure or the future... I think if it were possible to do this in JS, we wouldn't need ignorant plugin points for DRM.. encrypted streaming could "just work" on any platform, not that I want more DRM. I like that we are finally at a point, where legacy emulators in JS are a reality. I do think some attention to worker interaction, and perhaps locking say a canvas, or audio channel to a worker should be something able to be done.
  - corresation 14y ago
    I think being able to do a 1080p stream at 30-60fps in JS is an appropriate goal Why is that an appropriate goal? How about a video element -- which the browser implements in the ideal manner (which is usually a thin layer over hardware decoding) -- that handles h264? Why in the world would you want to do that in JavaScript, besides as a "because I can" challenge? Further your notion that DRM would "just work" is really unclear. I don't think you understand the concerns of the DRM folks if you think that you'll just do it in decrypt.js and all will be good.
lotyrin 14y ago
I'd like to have a meet-up and invite all the dudes like you and all of the kind of dude that complains about how asm.js performance is still so slow that they don't see the point and will just keep writing "native".
- corresation 14y ago
  You're wading into a discussion that is above you. Generally that isn't a good idea. JavaScript proper cannot be a high performance language because of fundamental design choices. Asm.js, which I've referenced multiple times, undoes many of those choices, effectively becoming a completely different language (which is why you target it with C/C++ and LLVM, not by writing it directly). The notion that there are going to be legitimate video stream processing or h264 decoders in JavaScript -- that are more than a impractical "if you ignore normal considerations" demo -- is 0%. It makes no sense, and it is using the wrong tool, making everything into a nail because someone "knows JavaScript". This is doubly true on mobile where you want to make every instruction count. All of the examples in here are a riot. Further gaming in HTML5 thus far has been "welcome to the 80s". It has gone nowhere. Nor has any other "pure JavaScript" high computing adventure. nodejs, which I love, is a wonderful asynchronous glue, but everyone knows that you dare not do any actual computations in it because...JavaScript.
  - lotyrin 14y ago
    > You're wading into a discussion that is above you. Generally that isn't a good idea. Making assumptions about the knowledge of people you're responding to is cool though. > Further gaming in HTML5 thus far has been "welcome to the 80s". Oh, see I guess I was thinking Unreal 3 and Sauerbraten were released much more recently than that. Oops, silly me. You're right, the browser should just only ever be for web pages, everything should just stay how it is now and all these damn kids should get off your lawn.
    - corresation 14y ago
      Oh, see I guess I was thinking Unreal 3 The Unreal 3 demo was an entirely different thing. Asm.js is a dramatic rethinking of JavaScript that tosses much of the language, and adds hacked typing metadata, to essentially act as a proxy for C. The single benefit that it brings over just going with C is that existing browsers can limpingly run it in crippled mode. You're right And then you boringly completely misrepresent my argument. You should tell the kids to get off your lawn, as you're busy trying to pretend everything is a nail because all you know is your hammer.