5 ms·

I would expect to hear something like that not from a respected tehnologist but rather from yet another "cool kid". He could just say "JavaScript is awesome" on

by kombine 14y ago

I would expect to hear something like that not from a respected tehnologist but rather from yet another "cool kid". He could just say "JavaScript is awesome" on a single slide and that wouldn't tell much less than what the whole presentation did. > First they said JS couldn't be useful for building rich internet apps Who said it is? Rich - yes. Anything near to match complexity of the desktop apps - never(think Photoshop). > Then they said it couldn't be fast Benchmarks, maybe? > Then it couldn't do multicore/GPU Webworkers are nice, but you can add bindings to all of this stuff for virtually any programming language. > JavaScript's parser does a more efficient job... than the JVM's bytecode verifier. Figures again? > No view source How viewing at minified JS is going to help me? Especially in the light of what he had on his previous slide: function f() { L0: g(); L1: if (p) goto L0; o.m(); goto L1; } Good luck "view source" on what he calls "the assembly of the web". Then the screenshots of 3D games that presumably use WebGL - that just doesn't cut it. Just about every game demo I tried out on my previous generation hi-end ATI graphics card had performance issues. And the level of graphics is comparable to what native games had 10 years ago. That's a joke. > Typed arrays Until they add records so that I can declare an array of any type efficiently don't even bring this up. This is an ad-hoc solution.

williamcotton 14y ago
Why do we need to make Photoshop in JS? I can't make a printing press in C++, but why would I want to? Photoshop was made during an era where computers were used to make media for physical printing. You would take a picture with an analog camera, digitize it, manipulate it in Photoshop, and then have it ready for print. "Save For Web" is the closest you get to using Photoshop for publishing to the web, and you'd have to admit it's a bit of an afterthought in the whole experience. Software doesn't exist on it's own. It exists in an input and output environment, beyond just mice and monitors. It exists to capture information, manipulate it, and then republish it. In many ways, memegenerator.net does a better job of consuming, manipulating, and publishing content for the web than Photoshop does. Photoshop will probably not go away. There are still printing presses and there are avenues to publish things made with them. Media tends to gain a lot of inertia by the time it gets to the point of being a household name. However, this inertia doesn't really impede some other form of media from gaining it's own momentum. Photoshop is busy being Photoshop, not memegenerator.net. If you ask my opinion, I'd say there is plenty of ground somewhere between memegenerator.net and Photoshop and there is no better language and environment to create these tools than the environment where they will be published: JavaScript running in a web browser.
- kombine 14y ago
  > Photoshop was made during an era where computers were used to make media for physical printing. You would take a picture with an analog camera, digitize it, manipulate it in Photoshop, and then have it ready for print. "Save For Web" is the closest you get to using Photoshop for publishing to the web, and you'd have to admit it's a bit of an afterthought in the whole experience. Javascript was made during an era where rich web applications didn't exist and there only was a need for client side verification for form input. Why do you refuse Photoshop in evolution but allow it for JS?
BrendanEich 14y ago
Photoshop is a notorious pig. I know many designers who have already ditched it for in-browser development. See the latest JSConf.eu talk on this topic: http://2012.jsconf.eu/speaker/2012/08/29/because-f-k-photoshop.html http://2012.jsconf.eu/speaker/2012/08/29/because-f-k-photosh... (slides: https://speakerdeck.com/u/nrrrdcore/p/js-dot-conf-dot-eu-2012-because-f https://speakerdeck.com/u/nrrrdcore/p/js-dot-conf-dot-eu-201... -- but you probably had to be there). I sense trollery here: "but you can add bindings to all of this stuff for virtually any programming language." Who said otherwise? The bogus claims against JS (going back to the "RIA" era, where IBM and Macromedia/Adobe made such arguments) already fell. The issue is not what languages can program the GPU somehow -- because only JS is supported directly in browsers, the issue is whether JS cannot. Clearly (WebGL, River Trail, even GLSL embedded in an unknown-type script and downloaded via JS) that's false. But it seemed true once, which led to the false anti-JS prophecy. At the risk of feeding a troll, I suggest you use the down arrow on the "goto L0" slide to see how JS enables compiling control effects without goto. And play BananaBread, for crying out loud (https://developer.mozilla.org/en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread). You simply do not know what you are talking about by your next-to-last paragraph. Yes, typed arrays were ad-hoc (so are many incremental web standards that win). Binary data (arrays and structs, which compose) as proposed in ES6 are not.
- kaffiene 14y ago
  I can't believe that you point out the Bananabread demo as proof that JS is doing WebGL in a performant fashion. Issues: * I have a PC that is set up for playing bleeding edge AAA games and Bananabread stutters on it. * The technology on display is worse than that on offer in Quake 2 (1997 era). * A Java applet (Jake) was playing the full Quake 2 game release EIGHT YEARS AGO which underscores how behind JS really is in the performance stakes. And Jake was hardly cutting edge for Java, at that point, either. Look, JS is fine for what it was intended for, but an actual bytecode VM for the web makes way more sense than JS being the only way to do it. Bytecode is much more amenable to optimisation and we have several existing examples we could use RIGHT NOW rather than do a poor job reinventing the wheel with a poor substitute. As a scripting language, JS is great. As a 'bytecode for the web', JS is utterly and completely unsuited and not intended for that task. The SANE thing to do is design a Bytecode standard, optimise the hell out of that, and allow people to use whatever tools they want to target it rather than insist that people must use JS or something else hobbled by JS's limitations as a compile target.

by kombine 14y ago

williamcotton 14y ago

Why do we need to make Photoshop in JS? I can't make a printing press in C++, but why would I want to? Photoshop was made during an era where computers were used to make media for physical printing. You would take a picture with an analog camera, digitize it, manipulate it in Photoshop, and then have it ready for print. "Save For Web" is the closest you get to using Photoshop for publishing to the web, and you'd have to admit it's a bit of an afterthought in the whole experience. Software doesn't exist on it's own. It exists in an input and output environment, beyond just mice and monitors. It exists to capture information, manipulate it, and then republish it. In many ways, memegenerator.net does a better job of consuming, manipulating, and publishing content for the web than Photoshop does. Photoshop will probably not go away. There are still printing presses and there are avenues to publish things made with them. Media tends to gain a lot of inertia by the time it gets to the point of being a household name. However, this inertia doesn't really impede some other form of media from gaining it's own momentum. Photoshop is busy being Photoshop, not memegenerator.net. If you ask my opinion, I'd say there is plenty of ground somewhere between memegenerator.net and Photoshop and there is no better language and environment to create these tools than the environment where they will be published: JavaScript running in a web browser.

kombine 14y ago
> Photoshop was made during an era where computers were used to make media for physical printing. You would take a picture with an analog camera, digitize it, manipulate it in Photoshop, and then have it ready for print. "Save For Web" is the closest you get to using Photoshop for publishing to the web, and you'd have to admit it's a bit of an afterthought in the whole experience. Javascript was made during an era where rich web applications didn't exist and there only was a need for client side verification for form input. Why do you refuse Photoshop in evolution but allow it for JS?

BrendanEich 14y ago

Photoshop is a notorious pig. I know many designers who have already ditched it for in-browser development. See the latest JSConf.eu talk on this topic: http://2012.jsconf.eu/speaker/2012/08/29/because-f-k-photoshop.html http://2012.jsconf.eu/speaker/2012/08/29/because-f-k-photosh... (slides: https://speakerdeck.com/u/nrrrdcore/p/js-dot-conf-dot-eu-2012-because-f https://speakerdeck.com/u/nrrrdcore/p/js-dot-conf-dot-eu-201... -- but you probably had to be there). I sense trollery here: "but you can add bindings to all of this stuff for virtually any programming language." Who said otherwise? The bogus claims against JS (going back to the "RIA" era, where IBM and Macromedia/Adobe made such arguments) already fell. The issue is not what languages can program the GPU somehow -- because only JS is supported directly in browsers, the issue is whether JS cannot. Clearly (WebGL, River Trail, even GLSL embedded in an unknown-type script and downloaded via JS) that's false. But it seemed true once, which led to the false anti-JS prophecy. At the risk of feeding a troll, I suggest you use the down arrow on the "goto L0" slide to see how JS enables compiling control effects without goto. And play BananaBread, for crying out loud (https://developer.mozilla.org/en-US/demos/detail/bananabread https://developer.mozilla.org/en-US/demos/detail/bananabread). You simply do not know what you are talking about by your next-to-last paragraph. Yes, typed arrays were ad-hoc (so are many incremental web standards that win). Binary data (arrays and structs, which compose) as proposed in ES6 are not.

kaffiene 14y ago
I can't believe that you point out the Bananabread demo as proof that JS is doing WebGL in a performant fashion. Issues: * I have a PC that is set up for playing bleeding edge AAA games and Bananabread stutters on it. * The technology on display is worse than that on offer in Quake 2 (1997 era). * A Java applet (Jake) was playing the full Quake 2 game release EIGHT YEARS AGO which underscores how behind JS really is in the performance stakes. And Jake was hardly cutting edge for Java, at that point, either. Look, JS is fine for what it was intended for, but an actual bytecode VM for the web makes way more sense than JS being the only way to do it. Bytecode is much more amenable to optimisation and we have several existing examples we could use RIGHT NOW rather than do a poor job reinventing the wheel with a poor substitute. As a scripting language, JS is great. As a 'bytecode for the web', JS is utterly and completely unsuited and not intended for that task. The SANE thing to do is design a Bytecode standard, optimise the hell out of that, and allow people to use whatever tools they want to target it rather than insist that people must use JS or something else hobbled by JS's limitations as a compile target.