Re: [xml-dev] JavaScript (was Re: [xml-dev] Whither XML ?)

[David <dlee@calldei.com>]

My concern about JavaScript in the browser as the "VM of the Browser" is 
its lack of binary data support.   I am not an expert in JS myself, but 
my colleagues who are doing very heave JS development on mobile devices 
tell me this is one of the biggest problems.    There is no native data 
type to hold binary data.   Yes you can have an 'array of number'   but 
this is very VM inefficient, its really an array of *objects* not a 
contigous byte array.   Furthermore the API's that are supported 
(atleast in the mobile space) do not allow binary network transfer into 
JS, only text.   This is a huge problem for transferring large data to 
mobile devices to/from servers.  You have to text encode everything, and 
even then, you cant decode it to binary in the JS layer  because there 
is no binary type.   So everything has to be text.  And with JS's (like 
java's) UTF16 internal storage for strings were talking serious memory 
and CPU cycle wastes.

Somehow the underlying system can handle it (think images for web 
pages), but it is not exposed to the JavaScript API layer so developers 
cannot do anything with binary data that is not 'built in'.

I'd love to hear this is totally wrong so I can go back to my friends 
and tell them how to 'do it right', but I have confidence they've 
sweated over this for over a year and have no solution besides dropping 
down to the OS layer for all binary data and networking.   But the "OS 
Layer" is not portable, and on some devices not accessable.

With the advent of HTML5 with local storage, I think people will want to 
do more and more on the browser what mobile already has to do, which is 
pre-download large chunks of data so that they can run efficiently in 
low or no connectivity situations (disconnected, or intermittently 
disconnected).
Until the infrastructure catches up *a lot* the entire fantisy that 
every device is 'always connected' to a high bandwidth internet is a 
fools fantasy.    Even in metro areas where it is supposed to be true, 
its not, in fact its often worse due to congestion.   Lack of good 
binary support for transfer, internal use, and internal storage is a 
huge killer for JS, IMHO.




David A. Lee
dlee@calldei.com
http://www.xmlsh.org


On 11/11/2010 7:07 AM, Simon St.Laurent wrote:
>
> On 11/11/10 6:09 AM, Pete Cordell wrote:
>> Just wondering...
>>
>> If other languages such as Java, C# etc. can be compiled to 
>> Javascript, do
>> people see problems with Javascript being the bytecode of the Internet?
>
> I don't, unless everyone hates Lisp.  I don't even think compilation 
> to JavaScript is very necessary, though GWT demonstrates it can be 
> usefully done.
>
> JavaScript has grown tremendously over the last decade, not just in 
> sprawling reach but also in best practices.  It's making a lot of 
> people retire assumptions about object-oriented development that they 
> picked up from Java or C++, and to be honest it's beating out 
> assumptions people picked up from XML with JSON.
>
> I'm pretty much shifting to JavaScript completely these days, even 
> looking to Node.js for server-side JavaScript.  I'll be using it for 
> small things, but it turns out that JavaScript is also a good fit for 
> scaling up because you can write non-blocking code in it relatively 
> easily.  I still do like Ruby and Rails, but while metaprogramming is 
> cool, it's not necessary.
>
> Not that you all should drop what you're doing and grab a copy of 
> JavaScript Patterns, but I'm hoping that the JavaScript-bashing will 
> subside.  My favorite recent quote:
>
> "It used to be that if you programmed in JavaScript, no one took you 
> seriously.  Now, if you don't, they won't take you seriously."
>
> Good luck in a changing world,