3 ms·

A couple of problems with his argument: 1) Web entrepreneurs working now still need to optimize for speed. It's not like the desktop world where you are laun

A couple of problems with his argument: 1) Web entrepreneurs working now still need to optimize for speed. It's not like the desktop world where you are launching a year or two from now and can wait for the computers to catch up. You are launching a month from now and it needs to be fast. I would prefer to use a web mail client other than GMail, simply because I'm scared of my Google dependency. But every other web email client I've used ( Yahoo, Joyent, inbox.com, Zimbra) feels much slower. Google spends enormous effort optimizing their javascript load times and it really pays off. 2) Broadband speeds are not growing at Moore's law. Terrible regulatory law trumps technological gains. 3) It be hard for a company to lock everyone into its javascript platform when the entire source code is downloadable. 4) The trouble with javascript is not cross browser incompatibility. If you use a good library and have learned common gotchas you should not have to spend too much time debugging IE ( I probably spend less than 10% of my javascript coding time on cross browser issues). The trouble with javascript is that there are still a number of things it just can't do, and won't be able to do until the browsers change. For instance, there is no way to detect the exact pixel size of a character of text. This makes it impossible to build a real word processor in javascript. Nor can you detect a collision between the opaque regions of two png images (this is needed for most simple 2-d games). Well ... it's almost impossible to do these things. I suppose you could define your own image and font formats completely in javascript, and render the entire screen using 1 pixel divs. But that's just crazy talk. It would be a huge library - maybe 250 MB - and would be very slow until computers got faster. And it would require eating at least 6000 packages of ramen to build the thing. Hmmmmm .... maybe I have an idea I can apply to YCombinator with ... :-)

bootload 19y ago
"... 3) It be hard for a company to lock everyone into its javascript platform when the entire source code is downloadable...." I hazard a guess that the real value is not (just) in the generated source code in the design tools - site used to generate the end result?
Goladus 19y ago
Another open question is how difficult it will be to obtain the different APIs. If NewSDK and ExtremeSDK are both compatible with your system, and both free/inexpensive, then monopoly conditions may not occur. People in the 90s had more reasons to choose only one platform.
lupin_sansei 19y ago
> Nor can you detect a collision between the opaque regions of two png images (this is needed for most simple 2-d games) Crazy idea. At the start of the game use the server to determine the image's boundary, then send the info up to the client and get Javascript to use that pre-calculated boundary to detect a collision rather than getting Javascript to try and look inside the png.

bootload 19y ago

"... 3) It be hard for a company to lock everyone into its javascript platform when the entire source code is downloadable...." I hazard a guess that the real value is not (just) in the generated source code in the design tools - site used to generate the end result?

Goladus 19y ago

Another open question is how difficult it will be to obtain the different APIs. If NewSDK and ExtremeSDK are both compatible with your system, and both free/inexpensive, then monopoly conditions may not occur. People in the 90s had more reasons to choose only one platform.

lupin_sansei 19y ago

> Nor can you detect a collision between the opaque regions of two png images (this is needed for most simple 2-d games) Crazy idea. At the start of the game use the server to determine the image's boundary, then send the info up to the client and get Javascript to use that pre-calculated boundary to detect a collision rather than getting Javascript to try and look inside the png.