Any discussion of "compact" subset for mobile devices?

ToolmakerSteve98 toolmakersteve98 at
Fri Mar 21 07:11:30 PDT 2008

"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 

==> 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 

That's my take on this next step.


More information about the Es4-discuss mailing list