Any discussion of "compact" subset for mobile devices?

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Any discussion of "compact" subset for mobile devices?

ToolmakerSteve
Wow, there's a lot to ES4. I sort of thought the most important next step in
web evolution was the increasing role of mobile devices, and it's hard to
imagine all this running on a cell phone any time soon. Adobe's ActionScript
3 seems more the right amount of stuff. (Well, I'd personally use a
statically-typed language given the power and memory restrictions in order
to preserve performance, but that's another topic.)

Is there a working group discussing possibly standardizing a "compact"
subset of ES4?

~TMSteve

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

RE: Any discussion of "compact" subset for mobile devices?

Lars Hansen-3
> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]] On Behalf Of ToolmakerSteve98
> Sent: 20. mars 2008 21:19
> To: [hidden email]
> Subject: Any discussion of "compact" subset for mobile devices?
>
> Wow, there's a lot to ES4. I sort of thought the most
> important next step in web evolution was the increasing role
> of mobile devices, and it's hard to imagine all this running
> on a cell phone any time soon. Adobe's ActionScript
> 3 seems more the right amount of stuff. (Well, I'd personally
> use a statically-typed language given the power and memory
> restrictions in order to preserve performance, but that's
> another topic.)
>
> Is there a working group discussing possibly standardizing a
> "compact" subset of ES4?

I don't know what makes you think it is "a lot", but several
companies that participate in the ES4 work are planning to
ship on small devices.  And they have been participating in
the work in part to make sure that's possible.

I can only speak for Adobe (if I can even do that); we believe
that ES4 will work in browsers on phones.

Anyhow, subsets are pretty pointless on the public web.  An
implementation that wants to play needs to support the full
language.  ECMAScript 3 has a compact profile (no eval, no
Function constructor, and no "with" statement IIRC) but it
has no relevance at all on the web.

--lars
_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

ToolmakerSteve
"Lars Hansen" wrote:

> but several companies that participate in the ES4 work are planning to
> ship on small devices.  And they have been participating in
> the work in part to make sure that's possible.

I am very glad to hear that you are pressing for that.

> Anyhow, subsets are pretty pointless on the public web.  An
implementation that wants to play needs to support the full
language.

That's what concerns me. To my mind, the next step in logic execution for
the web should be strongly biased to favor low power low memory devices. We
want complex application logic running on client devices. ALL client
devices. Looking at all the technical approaches that have been tried, what
would give the most bang for the buck?

After a rough look at the size of the language grammar and spec, and
perusing some of the past mail discussions about subtleties in
parsing/analyzing certain constructs -- WHOA - this is stuff we take for
granted on our multi-GHz and GB desktop PCs today, but ES4 would
web-standardize a language that would require every web client to take on
that burden. My gut reaction is that Microsoft has taken a better tack: let
this stuff be resolved at authoring time down to a CLR. Don't burden every
web client device with it.

That's why I ask about "compact" subset. I'm initially skeptical that what
I'm seeing is the right next step for the web. But I think there are a lot
of good ideas here, so I'm working through it, looking for common ground
between stuff I see at Microsoft and stuff I see here.

~TMSteve

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

ToolmakerSteve
In reply to this post by ToolmakerSteve
 "ToolmakerSteve98" wrote:

> "Lars Hansen" wrote:
>
>> Anyhow, subsets are pretty pointless on the public web.  An
> implementation that wants to play needs to support the full
> language.

Another way I could say this is:
maybe y'all have designed "Javascript 3" (so to speak), and it would be
worth identifying a "Javascript 2" -- what every device could afford to do
in 2009. Adopt in stages.

~TMSteve

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

Brendan Eich-2
In reply to this post by ToolmakerSteve
On Mar 20, 2008, at 10:56 PM, ToolmakerSteve98 wrote:

After a rough look at the size of the language grammar and spec, and 
perusing some of the past mail discussions about subtleties in 
parsing/analyzing certain constructs -- WHOA - this is stuff we take for 
granted on our multi-GHz and GB desktop PCs today,

I think you need evidence to justify your gut ("WHOA") reaction. I'll be first to admit we need evidence to prove the incremental cost of ES4 over ES3 is not excessive, but participants in Ecma TC39 who believe this can be done are targeting mobile devices and working on real, small footprint implementations right now (e.g. ESC plus Tamarin Tracing). Anyway, whatever the jump in JS evolution (ES3.1, ES4), IMHO there's no "third" way that forces a static language and offline/AOT compilation.

but ES4 would 
web-standardize a language that would require every web client to take on 
that burden.

Browsers have to handle today's JS plus several other content languages and image formats, with video and audio coming. Life in the big city. The CPU budget should not go up significantly due to ES4 features, and compiled and burned-into-ROM code footprint may shrink if we make the right self-hosting trades. But we have to prove this, as noted above.

My gut reaction is that Microsoft has taken a better tack: let 
this stuff be resolved at authoring time down to a CLR. Don't burden every 
web client device with it.

That's not the web, sorry. JavaScript is and will remain a web source language for the foreseeable future. The Ecma TG1 (now TC39) group charged with maintaining and improving its standard is not going to throw it out and require a CLR-like VM and standardized interchange bytecode. Nor are web developers going to switch horses (really, ride both old and new horses) like that in significant numbers, from what I can see.

That's why I ask about "compact" subset. I'm initially skeptical that what 
I'm seeing is the right next step for the web.

You may not have heard from many people (see my blog for some comments from them) who think a statically typed language that must be compiled ahead of time is the wrong thing for the web. Opinions vary, but it's clear there is no practical way to move web browsers and content en masse to such a model in anything like the timeframe contemplated for ES4. Such a move seems obviously a much bigger effort than the ES4 effort.

But I think there are a lot 
of good ideas here, so I'm working through it, looking for common ground 
between stuff I see at Microsoft and stuff I see here.

Why do you believe static typing is necessary for performance? Just curious.

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

ToolmakerSteve
In reply to this post by ToolmakerSteve
"ToolmakerSteve98" <[hidden email]>
> That's what concerns me. To my mind, the next step in logic execution for
> the web should be strongly biased to favor low power low memory devices.
> We want complex application logic running on client devices. ALL client
> devices. Looking at all the technical approaches that have been tried,
> what would give the most bang for the buck?

I want to underline the last sentence. The question isn't whether the
language will "run" on a cell phone. The question is whether the language
will allow that cell phone to maximize the potential of its limited
resources.

I'm not remotely an expert on that; I've just been on a project [ScriptX at
Kaleida Labs early 90's] that got burned in part by failing to carefully
make this distinction. Sometimes, a lesser architecture is more appropriate
in the short term.

~TMSteve

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

Michael O'Brien-4
In reply to this post by ToolmakerSteve

On Mar 20, 2008, at 10:56 PM, ToolmakerSteve98 wrote:

> "Lars Hansen" wrote:
>
>> but several companies that participate in the ES4 work are planning  
>> to
>> ship on small devices.  And they have been participating in
>> the work in part to make sure that's possible.
>
> I am very glad to hear that you are pressing for that.
>
>> Anyhow, subsets are pretty pointless on the public web.  An
> implementation that wants to play needs to support the full
> language.
>
> That's what concerns me. To my mind, the next step in logic  
> execution for
> the web should be strongly biased to favor low power low memory  
> devices. We
> want complex application logic running on client devices. ALL client
> devices. Looking at all the technical approaches that have been  
> tried, what
> would give the most bang for the buck?
>
> After a rough look at the size of the language grammar and spec, and
> perusing some of the past mail discussions about subtleties in
> parsing/analyzing certain constructs -- WHOA - this is stuff we take  
> for
> granted on our multi-GHz and GB desktop PCs today, but ES4 would
> web-standardize a language that would require every web client to  
> take on
> that burden. My gut reaction is that Microsoft has taken a better  
> tack: let
> this stuff be resolved at authoring time down to a CLR. Don't burden  
> every
> web client device with it.


We are doing exactly that in our implementation. It is only a subset  
of ES4 currently, but
does many of the big pieces including classes, static typing,  
namespaces, packages, units,
most of the grammar, type annotations, conversions, strict and  
standard mode. The online
spreadsheet tracks progress pretty well.

We are using an off-device compile phase and then running a VM on  
device to execute pre-compiled byte code.
We are running this on standard feature phones using a C based and a  
java based VM. Our footprint is < 200K
to startup. I expect that when we have all the language that this  
number will go up to ~350K.

We do provide compilation directives to allow OEMs to "deselect"  
features that are not required
in their device. This results in a "non-standard" OEM implementation,  
but compatibility with the
web is not a concern.

So while we have a long way to go to be compliant and fully featured,  
I am confident that ES4 can run
on very modest devices with acceptable performance.


>
>
> That's why I ask about "compact" subset. I'm initially skeptical  
> that what
> I'm seeing is the right next step for the web. But I think there are  
> a lot
> of good ideas here, so I'm working through it, looking for common  
> ground
> between stuff I see at Microsoft and stuff I see here.

So I'm against defining a compact subset standard. The reason is that  
everyone wants a different subset and
defining a hobbled edition won't meet anyones needs.

I'd rather have one standard and then provide a mechanism for those  
who must defeature the language to
select the portions required. This does prevent interoperability of  
programs, but it does strengthen the
integrity of what "is" ES4.


Michael O'Brien


>
>
> ~TMSteve
>
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

ToolmakerSteve
> We are using an off-device compile phase and then running a VM on  device
> to execute pre-compiled byte code.
> We are running this on standard feature phones using a C based and a  java
> based VM. Our footprint is < 200K
> to startup. I expect that when we have all the language that this  number
> will go up to ~350K.
> ...
> So while we have a long way to go to be compliant and fully featured,  I
> am confident that ES4 can run
> on very modest devices with acceptable performance.

But you got it to run by using an off-device compile phase. Is there going
to be a W3C spec that goes along with ES4 that says that it is a server's
responsibility to query the client device, and if the client requests it, to
perform this phase before sending the information to the client? If so, then
you've got my attention -- that would work.

~TMSteve

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

Michael O'Brien-4
The main issue for portability of apps to mobile phones is other than  
the language: ie. image sizes and resolutions, keyboard layouts
and other device capabilities. The ability of the device to support  
the language is lower down the list. We typically don't need
to query the device to select language features. We find we can target  
a wide variety of devices with the same language feature set.

Michael



On Mar 20, 2008, at 11:42 PM, ToolmakerSteve98 wrote:

>> We are using an off-device compile phase and then running a VM on  
>> device to execute pre-compiled byte code.
>> We are running this on standard feature phones using a C based and  
>> a  java based VM. Our footprint is < 200K
>> to startup. I expect that when we have all the language that this  
>> number will go up to ~350K.
>> ...
>> So while we have a long way to go to be compliant and fully  
>> featured,  I am confident that ES4 can run
>> on very modest devices with acceptable performance.
>
> But you got it to run by using an off-device compile phase. Is there  
> going to be a W3C spec that goes along with ES4 that says that it is  
> a server's responsibility to query the client device, and if the  
> client requests it, to perform this phase before sending the  
> information to the client? If so, then you've got my attention --  
> that would work.
>
> ~TMSteve
>

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

ToolmakerSteve
In reply to this post by Brendan Eich-2
> I think you need evidence to justify your gut ("WHOA") reaction.

Agreed.


> I'll be first to admit we need evidence to prove the incremental cost of
> ES4 over ES3 is not excessive, but participants in Ecma TC39 who
> believe this can be done are targeting mobile devices and working on
> real, small footprint implementations right now (e.g. ESC plus
> Tamarin Tracing).

OK, good to hear.


> Anyway, whatever the jump in JS evolution (ES3.1,
> ES4), IMHO there's no "third" way that forces a static language and
> offline/AOT compilation.

Yeah I know. But it seemed worth raising the point at this juncture. I
appreciate hearing your comments about this, and will take a look at the
blog posts about dynamic vs. static on the web.


> Why do you believe static typing is necessary for performance? Just
> curious.

Good question. I have a vague impression that the cache size required to
achieve performance when dynamic typing is significantly larger than JIT-ing
statically typed code. That is, it either cost performance or memory, and
the memory cost became unacceptable. But my thinking developed at a time
when we didn't have so many MBs to throw around. Maybe in an era of
streaming video, it has become less of an issue.

~TMSteve

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

Michael O'Brien-4

On Mar 21, 2008, at 12:00 AM, ToolmakerSteve98 wrote:

>>
>> Why do you believe static typing is necessary for performance? Just
>> curious.
>
> Good question. I have a vague impression that the cache size  
> required to
> achieve performance when dynamic typing is significantly larger than  
> JIT-ing
> statically typed code. That is, it either cost performance or  
> memory, and
> the memory cost became unacceptable. But my thinking developed at a  
> time
> when we didn't have so many MBs to throw around. Maybe in an era of
> streaming video, it has become less of an issue.


Static typing does allow the compile phase to do early binding more  
easily and
so save lookups. Accesses via an untyped object must do this at the  
point of
execution whereas if the object is statically typed, this can be  
computed once.
If doing pre-compile - this happens at the development phase.

We see a good reduction in byte code size and in execution time if  
using typed object
references.



Michael



>
>
> ~TMSteve
>
> _______________________________________________
> Es4-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es4-discuss

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

ToolmakerSteve
In reply to this post by Michael O'Brien-4
> We typically don't need to query the device to select language features.

Michael, I think you've missed my main point. You are using an off-device
compile phase. THAT'S the "feature" I was talking about.

I'm trying to understand how that fits into "public web" compliance. If the
answer is that you have enough control over the situation to intercede
between the phone and the web, then I totally get it. Not a solution I had
thought of, but works for me.

Is that approach agreeable to all the cell phone carriers? (If not, then I'm
back to my original "are you sure this is practical?" gut reaction.)

~TMSteve

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

Brendan Eich-2
On Mar 21, 2008, at 12:12 AM, ToolmakerSteve98 wrote:

> I'm trying to understand how that fits into "public web"  
> compliance. If the
> answer is that you have enough control over the situation to intercede
> between the phone and the web, then I totally get it. Not a  
> solution I had
> thought of, but works for me.

And for Danger (now MIcrosoft), Opera Mini, Skyfire, and probably  
others I don't know about.

Not favored by many carriers, but who cares? :-P

> Is that approach agreeable to all the cell phone carriers? (If not,  
> then I'm
> back to my original "are you sure this is practical?" gut reaction.)

Don't conflate technical practicality and "political" (best word I  
can think of at the moment) acceptability. Don't target the trailing  
edge. But this is getting off topic for es4-discuss, and on-topic for  
betting ;-).

/be

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

Michael O'Brien-4
In reply to this post by ToolmakerSteve
This may be a little off topic for this group, so lets continue this  
offline after this.

The ES4 spec is being written to not preclude off-device compilation.  
After all, that is what AS3 does very well. So both approaches 1) all-
in-one compile/execution and 2) pre-compile then execute later are  
possible and desirable in different situations.

In our case, sometimes the compilation happens at the development  
phase. In other cases it happens hosted at the server
and can be tailored based on the phone features and capabilities. The  
former being simpler, the latter being more comprehensive.

Michael



On Mar 21, 2008, at 12:12 AM, ToolmakerSteve98 wrote:

>> We typically don't need to query the device to select language  
>> features.
>
> Michael, I think you've missed my main point. You are using an off-
> device compile phase. THAT'S the "feature" I was talking about.
>
> I'm trying to understand how that fits into "public web" compliance.  
> If the answer is that you have enough control over the situation to  
> intercede between the phone and the web, then I totally get it. Not  
> a solution I had thought of, but works for me.
>
> Is that approach agreeable to all the cell phone carriers? (If not,  
> then I'm back to my original "are you sure this is practical?" gut  
> reaction.)
>
> ~TMSteve
>

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

ToolmakerSteve
> This may be a little off topic for this group, so lets continue this
> offline after this.
>
> The ES4 spec is being written to not preclude off-device compilation.

The aspect of this discussion that I believe is on-topic for this group, is
what overhead is practical on mobile devices today.

After you and I have talked off-line, we can come back to this in the group.

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

ToolmakerSteve
In reply to this post by Brendan Eich-2
"Brendan Eich" wrote:
> That's not the web, sorry. JavaScript is and will remain a web source
> language for the foreseeable future. The Ecma TG1 (now TC39) group
> charged with maintaining and improving its standard ...

Just consider me to be one more voice concerned that if technically
misjudge, would cause a delay in the "improved" standard catching on. That
would be a damn shame. Or worse IMHO, it does catch on, but increases the
number of websites that aren't practical to browse from mobile devices.

> ...is not going to throw it out and require a CLR-like VM and standardized
> interchange
> bytecode.

Quite true. Let me describe this a different way. Maximal compatibility
between different platforms. If there is a subset of ES4 that is
demonstrably more compatible with certain Microsoft technologies, I would
recommend to anyone who cares that they restrict themselves to that subset.
I would also recommend to toolmakers such as Adobe that they give their
customers an option to invoke that restriction. If this subset turns out to
be powerful enough, and advantageous enough, there would then be a solid
argument to use it. As long as it validates as ES4, it would not be
non-standard. And if it turns out to have strong enough practical benefits
(including "politically" practical), there may be a strong de facto argument
for widespread adoption. At that point (if such a point is reached), I would
argue that anyone who wants to target low-end clients should so restrict
themselves in what they put on their servers.

The burden of proof is on my end. Just giving you a heads up that I have
some concerns, though those are only a gut check at this time, and plan to
make some concrete demonstrations regarding those sometime before ES4 goes
final.

~TMSteve

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

performance of OO dispatch in inner loops

ToolmakerSteve
In reply to this post by Brendan Eich-2
was [Re: Any discussion of "compact" subset for mobile devices?]

"Brendan Eich" wrote:
> Why do you believe static typing is necessary for performance? Just
> curious.

I woke up in the middle of night, remembering one detail we hit in 1992.
Advanced OO programming styles lead to inner loops that contain (potentially
subclassed) method dispatches. THAT'S the bottleneck, not the speed of
arithmetic computations. Doesn't JIT well, because each "inner loop" (code
bottleneck involving repetition) is a cooperative effort between multiple
objects, any one of which might show up as a different subclass in the next
loop iteration.

Not awake enough right now to think through whether more modern JITs
(tracing) successfully unravel this case. If so, then it is a matter of
careful cache design. If not, then I think this is where static typing (or
more precisely, constructing an object knowing that it has given interfaces;
in theory this could be done for dynamically typed objects if you can
determine at construction that it satisfies the interface) makes possible
higher performance execution than dynamic typing.

~TMSteve

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: performance of OO dispatch in inner loops

David Teller-3
I'm not sure about "necessary" but for "useful", see for instance _Practical Soft Typing_, by Andrew Wright. Performance analysis for softly typed Scheme show that, on the benchmark, 20% to 50% of the time of the execution was spent performing run-time checks which may be automatically removed.


Cheers,
  David

Quoting ToolmakerSteve98 <[hidden email]>:

> was [Re: Any discussion of "compact" subset for mobile devices?]
>
> "Brendan Eich" wrote:
>> Why do you believe static typing is necessary for performance? Just
>> curious.
>

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: performance of OO dispatch in inner loops

ToolmakerSteve
In reply to this post by ToolmakerSteve
ToolmakerSteve98" wrote:

>
> "Brendan Eich" wrote:
>> Why do you believe static typing is necessary for performance? Just
>> curious.
>
> I woke up in the middle of night, remembering one detail we hit in 1992.
> Advanced OO programming styles lead to inner loops that contain
> (potentially
> subclassed) method dispatches. THAT'S the bottleneck, not the speed of
> arithmetic computations. Doesn't JIT well, because each "inner loop" (code
> bottleneck involving repetition) is a cooperative effort between multiple
> objects, any one of which might show up as a different subclass in the
> next
> loop iteration.
>
> Not awake enough right now to think through whether more modern JITs
> (tracing) successfully unravel this case. If so, then it is a matter of
> careful cache design. If not, then I think this is where static typing (or
> more precisely, constructing an object knowing that it has given
> interfaces;
> in theory this could be done for dynamically typed objects if you can
> determine at construction that it satisfies the interface) makes possible
> higher performance execution than dynamic typing.

More bad news for dynamic typing as I remember the details more clearly:
turns out the quentessential activity in the complex control logic we were
seeing for interactive multimedia, is that one object queries another object
for one or two properties, does a tiny bit of decision making using that
info and its own properties, modifies its state a bit, then fires a message
off elsewhere. Performance was dominated by how fast you could get at
properties on yourself and on the objects you were cooperating with. The
better you could pin down ahead of time how to get hold of those properties,
the better your performance.

~TMSteve

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Any discussion of "compact" subset for mobile devices?

ToolmakerSteve
In reply to this post by Brendan Eich-2
"Brendan Eich" wrote:
> That's not the web, sorry. JavaScript is and will remain a web source
> language for the foreseeable future. The Ecma TG1 (now TC39) group
> charged with maintaining and improving its standard is not going to
> throw it out and require a CLR-like VM and standardized interchange
> bytecode. Nor are web developers going to switch horses (really, ride
> both old and new horses) like that in significant numbers, from what
> I can see.

Having thought this through, I am sorry to say that based on my experience
over the past 25 years, that would be a better solution than where we are
headed. Do we all grasp just how much logic we could have executing in real
time on future devices in a few years? Virtual reality in the palm of your
hand,  with everyone having their own custom appearance. Artificial
intelligence agents doing your bidding. Massive information searches on your
100 TerraByte storage cube.

I know, you are just responsible for improving this language that is used to
give a common ground for exchanging information on the web. Important.
Sorely needed. But damn it, we don't need the web to go one way, while other
forces are going another, equally complex way -- if that other way has the
better long-term potential. (An arguable point I realize -- stating my POV
here).

==> I believe that whatever is standardized as ES4, bucketloads of code are
going to be written in it. Insane amounts of code, that will bring our
current devices to their knees. I'd like to get as much bang for the buck
out of that code as possible. <==

> I'll be first to admit we need evidence to prove the incremental cost of
> ES4 over ES3 is not excessive...

The easiest way to achieve that, would be to "think minimalist" on the
client side. One way to achieve this would be to put the burden on the
server to query the client device. For a low end device, the bulk of the
logic would execute on the server. The client would run a simpler
presentation engine.

That is, rather than requiring that all web clients run ES4, require that
the the server-client combination as a whole runs ES4.
==> Force an upgrade on both ends of the pipe. <==
As it stands now, you are saying the server side gets a free ride -- just
send this whiz-bang new language to the client and you're done. I believe
this is a fundamental mistake in deciding how to evolve the web. Demand more
of the servers. Make it POSSIBLE for clients to carry more of the load (for
better performance, by less round-tripping), but don't REQUIRE clients to do
so.

That's my take on this next step.

~TMSteve

_______________________________________________
Es4-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es4-discuss
12