Any discussion of "compact" subset for mobile devices?
-----Original Message----- From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of ToolmakerSteve98 Sent: 20. mars 2008 21:19 To: es4-discuss at mozilla.org 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 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
"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
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.
"ToolmakerSteve98" <toolmakersteve98 at shawstudio.com>
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
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
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
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
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
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
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
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 ;-).
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
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.
"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
"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
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.
Are you saying eval() and Function constructor are going to be optional?
Peter
On Mar 21, 2008, at 7:11 AM, ToolmakerSteve98 wrote:
"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.
This solution has existed for a while with ActionScript targeting
Flash. It has had successes for sure, but it's not yet taking over
the Web. I see Silverlight going not quite as hard toward offline
compilation, rather handling source-loaded script including Python
and Ruby dialects. Again, I suggest you are looking backward too much.
In any event, no standard body is yet set up to foist new, VM-
agnostic intermediate code and pre-compilation on JavaScript
programmers. It's a non-starter in Ecma, and since you mentioned the
w3c, even more of a non-starter there. The difficulties include IPR
around VMs and bytecode formats, different trade-offs among existing
VMs, developer hostility to the edit-compile-download-debug cycle,
and complexity in dealing with a distributed compilation/execution
pipeline.
-----Original Message----- From: es4-discuss-bounces at mozilla.org [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Peter Hall Sent: 21. mars 2008 12:27 To: Michael O'Brien Cc: es4-discuss at mozilla.org Subject: Re: Any discussion of "compact" subset for mobile devices?
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.
Are you saying eval() and Function constructor are going to be optional?
They won't be optional in the full language, and any implementation intending to serve the web will have to support them. But there are walled garden applications that may not need them but that can still make use of the rest of the language.
Are you saying eval() and Function constructor are going to be optional?
They won't be optional in the full language, and any implementation intending to serve the web will have to support them. But there are walled garden applications that may not need them but that can still make use of the rest of the language.
Offline discussion with Michael has got me to see how concerns such as this don't need to become a conflict between what is required for the public web, and what may be desirable in more streamlined situations.
I'm now aligned with where the es4 standardization thinking is coming from. I will be another voice raising concerns if I see anything that may have ramifications that haven't been thought of yet.
Just to understand where I am coming from, I would like to see handheld multimedia educational/communication devices in the hands of everyone in the developing countries, and anything that increases the resources required on such a device concerns me, w.r.t. what that means to humanity. But I can see how to deal with moderate amounts of fully-dynamic ES4 code coming off the web, AND leverage the development infrastructure that will grow up around ES4 at Adobe and elsewhere to develop mission critical parts that can be more tightly constrained.
Thanks for your patience -- keep up the good work!
~TMSteve
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