<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: ECMAScript Harmony: Coming together after Oslo</title>
	<atom:link href="http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/feed" rel="self" type="application/rss+xml" />
	<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo</link>
	<description>Cleaning up the web with Ajax</description>
	<lastBuildDate>Thu, 17 May 2012 07:43:39 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: mob590</title>
		<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/comment-page-1#comment-266737</link>
		<dc:creator>mob590</dc:creator>
		<pubDate>Sun, 17 Aug 2008 23:55:33 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4091#comment-266737</guid>
		<description>Here is the response by Ejscript - an early implementor of the future Javascript.  http://www.embedthis.com/blog/?p=14</description>
		<content:encoded><![CDATA[<p>Here is the response by Ejscript &#8211; an early implementor of the future Javascript.  <a href="http://www.embedthis.com/blog/?p=14" rel="nofollow">http://www.embedthis.com/blog/?p=14</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chris Phillips</title>
		<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/comment-page-1#comment-266721</link>
		<dc:creator>Chris Phillips</dc:creator>
		<pubDate>Fri, 15 Aug 2008 20:13:39 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4091#comment-266721</guid>
		<description>Cold Hard Fact: They majority of Flash developers did NOT transition to AS3... The reason why is the reason that an AS3 like language in the browser would have failed too.</description>
		<content:encoded><![CDATA[<p>Cold Hard Fact: They majority of Flash developers did NOT transition to AS3&#8230; The reason why is the reason that an AS3 like language in the browser would have failed too.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: eyelidlessness</title>
		<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/comment-page-1#comment-266684</link>
		<dc:creator>eyelidlessness</dc:creator>
		<pubDate>Thu, 14 Aug 2008 19:15:10 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4091#comment-266684</guid>
		<description>I&#039;ll second the desire for an implementation of MXML/AS in the browser. (Although I&#039;d prefer it if MXML could be implemented and allow any scripting language [eg JS] to manipulate it.)</description>
		<content:encoded><![CDATA[<p>I&#8217;ll second the desire for an implementation of MXML/AS in the browser. (Although I&#8217;d prefer it if MXML could be implemented and allow any scripting language [eg JS] to manipulate it.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Diodeus</title>
		<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/comment-page-1#comment-266657</link>
		<dc:creator>Diodeus</dc:creator>
		<pubDate>Thu, 14 Aug 2008 12:42:51 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4091#comment-266657</guid>
		<description>Hartmann: If people really believed that, it would have already happened.</description>
		<content:encoded><![CDATA[<p>Hartmann: If people really believed that, it would have already happened.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon Hartmann</title>
		<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/comment-page-1#comment-266653</link>
		<dc:creator>Jon Hartmann</dc:creator>
		<pubDate>Thu, 14 Aug 2008 12:23:08 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4091#comment-266653</guid>
		<description>Some one needs to create an browser that can render and display sites designed in uncompiled Flex code (MXML + AS), or the equivalent. Let it be able to read HTML and grab out the flash too (for sites that are all flash). We spend so much time bickering about how the web needs to catch up, that it might just be simpler to start over with a new syntax and design. People updated from paper to the web, let them update from the web to something better.</description>
		<content:encoded><![CDATA[<p>Some one needs to create an browser that can render and display sites designed in uncompiled Flex code (MXML + AS), or the equivalent. Let it be able to read HTML and grab out the flash too (for sites that are all flash). We spend so much time bickering about how the web needs to catch up, that it might just be simpler to start over with a new syntax and design. People updated from paper to the web, let them update from the web to something better.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: LeoHorie</title>
		<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/comment-page-1#comment-266650</link>
		<dc:creator>LeoHorie</dc:creator>
		<pubDate>Thu, 14 Aug 2008 11:39:23 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4091#comment-266650</guid>
		<description>I think comparing the ECMAScript spec to OpenGL and APIs in general is bit like apples and oranges. There really isn&#039;t anything functional that future versions of ECMAScript will allow that are not possible with the current specs.
Things like video support aren&#039;t dependant on language semantics: you can call &quot;video.play()&quot; in js today and it&#039;ll be up to you how that&#039;s implemented under the hood - the language will not barf.
I think language design decisions won&#039;t compromise the future of the ajax/open web/whatever-you-wanna-call-it-next.</description>
		<content:encoded><![CDATA[<p>I think comparing the ECMAScript spec to OpenGL and APIs in general is bit like apples and oranges. There really isn&#8217;t anything functional that future versions of ECMAScript will allow that are not possible with the current specs.<br />
Things like video support aren&#8217;t dependant on language semantics: you can call &#8220;video.play()&#8221; in js today and it&#8217;ll be up to you how that&#8217;s implemented under the hood &#8211; the language will not barf.<br />
I think language design decisions won&#8217;t compromise the future of the ajax/open web/whatever-you-wanna-call-it-next.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: cromwellian</title>
		<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/comment-page-1#comment-266645</link>
		<dc:creator>cromwellian</dc:creator>
		<pubDate>Thu, 14 Aug 2008 07:26:58 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4091#comment-266645</guid>
		<description>I&#039;m concerned about how this kind of implies that the OpenWeb architecture is at &quot;end of life&quot; kind of like Java. What do I mean by this? Well, once too many people are invested in a previous technology, and way too much code depends on buggy semantics or previous design flaws, it becomes progressively hard to make future improvements.
 
You see this today with all of the folks protesting adding closures to Java, with the crappy Java Generics introduced in 1.5, with Internet Explorer being stuck in the past for fear of &quot;breaking the web&quot;, or breaking intranets. You see it with OpenGL 3.0, recently announced. People waited for AGES for a radically redesigned API, and what they got in the end was something akin to Harmony. Why? Legacy. No one wants to risk breaking existing apps.

Essentially, hands are being tied by decisions made in Netscape 2 and IE4 with respect to semantics. In those days, browser vendors would just introduce a proprietary change, without needing a commitee to approve it. We&#039;re stuck with those decisions today.

This all seems to suggest that all future improvements to the browser will be bound by the mistakes make previously. They&#039;ll innovate around the edges: syntactic sugar, storage, messaging, video, canvas, maybe 3D. No one seems willing to deprecate previously undesirable behavior with another mode switch.

I mean, it&#039;s not that bad, but it seems kind depressing thinking about what the Web will be like in 10 years, in 2018. Will we still be limited by what was decided in 1995-7?

I would caution people to look at what happened with OpenGL vs DirectX.</description>
		<content:encoded><![CDATA[<p>I&#8217;m concerned about how this kind of implies that the OpenWeb architecture is at &#8220;end of life&#8221; kind of like Java. What do I mean by this? Well, once too many people are invested in a previous technology, and way too much code depends on buggy semantics or previous design flaws, it becomes progressively hard to make future improvements.</p>
<p>You see this today with all of the folks protesting adding closures to Java, with the crappy Java Generics introduced in 1.5, with Internet Explorer being stuck in the past for fear of &#8220;breaking the web&#8221;, or breaking intranets. You see it with OpenGL 3.0, recently announced. People waited for AGES for a radically redesigned API, and what they got in the end was something akin to Harmony. Why? Legacy. No one wants to risk breaking existing apps.</p>
<p>Essentially, hands are being tied by decisions made in Netscape 2 and IE4 with respect to semantics. In those days, browser vendors would just introduce a proprietary change, without needing a commitee to approve it. We&#8217;re stuck with those decisions today.</p>
<p>This all seems to suggest that all future improvements to the browser will be bound by the mistakes make previously. They&#8217;ll innovate around the edges: syntactic sugar, storage, messaging, video, canvas, maybe 3D. No one seems willing to deprecate previously undesirable behavior with another mode switch.</p>
<p>I mean, it&#8217;s not that bad, but it seems kind depressing thinking about what the Web will be like in 10 years, in 2018. Will we still be limited by what was decided in 1995-7?</p>
<p>I would caution people to look at what happened with OpenGL vs DirectX.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: cromwellian</title>
		<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/comment-page-1#comment-266643</link>
		<dc:creator>cromwellian</dc:creator>
		<pubDate>Thu, 14 Aug 2008 05:42:49 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4091#comment-266643</guid>
		<description>This reminds me of the Java Generics fiasco. There, we got a much watered down version of parameterized types because they didn&#039;t want to make any changes to VM semantics.  Now it seems, we&#039;ll only get language constructs in future JS versions which are essentially syntactic sugar for what you can already do.

If the Open Web guys were really gutsy, they&#039;d make Javascript syntax just one of many syntaxes that can run on top of a standardized p-code interpreter.  The problem I see is that JS 1.x semantics are essentially being enshrined as the fundamental browser VM  semantics. Is this what we want going up against Silverlight and Flash in 5 years? 10 years? (It&#039;s fine if you don&#039;t want to use optional static typing, but why impose this restriction on everyone else?) 

I think there is far too much focus on syntax because of language bias. The browser should really be a high performance VM for manipulating a DOM layout engine, optimized for speed.

And no, as is frequently stated, a more abstract intermediate representation does not mean you can&#039;t &quot;View Source&quot;.</description>
		<content:encoded><![CDATA[<p>This reminds me of the Java Generics fiasco. There, we got a much watered down version of parameterized types because they didn&#8217;t want to make any changes to VM semantics.  Now it seems, we&#8217;ll only get language constructs in future JS versions which are essentially syntactic sugar for what you can already do.</p>
<p>If the Open Web guys were really gutsy, they&#8217;d make Javascript syntax just one of many syntaxes that can run on top of a standardized p-code interpreter.  The problem I see is that JS 1.x semantics are essentially being enshrined as the fundamental browser VM  semantics. Is this what we want going up against Silverlight and Flash in 5 years? 10 years? (It&#8217;s fine if you don&#8217;t want to use optional static typing, but why impose this restriction on everyone else?) </p>
<p>I think there is far too much focus on syntax because of language bias. The browser should really be a high performance VM for manipulating a DOM layout engine, optimized for speed.</p>
<p>And no, as is frequently stated, a more abstract intermediate representation does not mean you can&#8217;t &#8220;View Source&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ibolmo</title>
		<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/comment-page-1#comment-266642</link>
		<dc:creator>ibolmo</dc:creator>
		<pubDate>Thu, 14 Aug 2008 05:03:29 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4091#comment-266642</guid>
		<description>Correction. There&#039;s not need for an Open Standard &amp; Source Engine. If all browsers used the same Engine(s) then there&#039;s no need for standards.</description>
		<content:encoded><![CDATA[<p>Correction. There&#8217;s not need for an Open Standard &amp; Source Engine. If all browsers used the same Engine(s) then there&#8217;s no need for standards.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ibolmo</title>
		<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/comment-page-1#comment-266641</link>
		<dc:creator>ibolmo</dc:creator>
		<pubDate>Thu, 14 Aug 2008 05:02:05 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4091#comment-266641</guid>
		<description>Sounds great. Too bad this will not see light until everyone has adopted the browsers that support the new language/standards. 

It&#039;s great to have all the big players in the room, but one issue that they all seem to lose sight of is adaptability. In contrast, ActionScript has shown faster maturity and language development than any other language [{missing reference}]. Why? Because Flash players have a tendency (understatement) of being up to date. 

I wish there was a solution, but until all browsers surrender their engines to an Open Standard &amp; Source Engine (do I need to trademark this?) and all browsers require their users to [automatically] upgrade (not a problem if **all** browsers require this).

It&#039;s extreme -- I know. One can dream, however.</description>
		<content:encoded><![CDATA[<p>Sounds great. Too bad this will not see light until everyone has adopted the browsers that support the new language/standards. </p>
<p>It&#8217;s great to have all the big players in the room, but one issue that they all seem to lose sight of is adaptability. In contrast, ActionScript has shown faster maturity and language development than any other language [{missing reference}]. Why? Because Flash players have a tendency (understatement) of being up to date. </p>
<p>I wish there was a solution, but until all browsers surrender their engines to an Open Standard &amp; Source Engine (do I need to trademark this?) and all browsers require their users to [automatically] upgrade (not a problem if **all** browsers require this).</p>
<p>It&#8217;s extreme &#8212; I know. One can dream, however.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JustinMeyer</title>
		<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/comment-page-1#comment-266640</link>
		<dc:creator>JustinMeyer</dc:creator>
		<pubDate>Thu, 14 Aug 2008 03:11:25 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4091#comment-266640</guid>
		<description>very exciting!</description>
		<content:encoded><![CDATA[<p>very exciting!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: genericallyloud</title>
		<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/comment-page-1#comment-266639</link>
		<dc:creator>genericallyloud</dc:creator>
		<pubDate>Thu, 14 Aug 2008 01:23:58 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4091#comment-266639</guid>
		<description>wow</description>
		<content:encoded><![CDATA[<p>wow</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JohnResig</title>
		<link>http://ajaxian.com/archives/ecmascript-harmony-coming-together-after-oslo/comment-page-1#comment-266636</link>
		<dc:creator>JohnResig</dc:creator>
		<pubDate>Wed, 13 Aug 2008 23:47:27 +0000</pubDate>
		<guid isPermaLink="false">http://ajaxian.com/?p=4091#comment-266636</guid>
		<description>I&#039;ve detailed many of the changes that are taking place and provided some back story to what&#039;s going on here:
http://ejohn.org/blog/ecmascript-harmony/</description>
		<content:encoded><![CDATA[<p>I&#8217;ve detailed many of the changes that are taking place and provided some back story to what&#8217;s going on here:<br />
<a href="http://ejohn.org/blog/ecmascript-harmony/" rel="nofollow">http://ejohn.org/blog/ecmascript-harmony/</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>

