<br><br><div class="gmail_quote">On Tue, Jan 27, 2009 at 3:05 PM, Michaeljohn Clement <span dir="ltr">&lt;<a href="mailto:mj@mjclement.com">mj@mjclement.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">John A. De Goes wrote:<br></div></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">...<br>
There is very little wrong with ECMAScript if people would only<br>
learn it properly and play to its strengths instead of trying to<br>
turn it into things it is not.<br>
<br>
Treating ECMAScript as a compiler target language will be a win<br>
eventually, I expect, but not by compiling from Haskell. &nbsp;Haskell<br>
could certainly play a role, e.g. as an implementation language<br>
for ES-to-ES or DSL-to-ES compiler writers.<br><br>
...<br>
--<br>
<font color="#888888">Michaeljohn Clement<br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br><br>Javascript itself is such a versatile language I don&#39;t think it needs to be hidden by a DSL, but, as you mentioned an ES-to-ES wrapper, with the exception that the framework could auto generate a few helper functions on the client side. <br>
<br>
I think the optimal approach is to create a sort of generator of &quot;client&quot; applications.<br>
These applications will use XHTML for graphical structure and Javascript for logic. <br><br>The haskell framework would streamline the creation of dynamic HTML and offer a fast and simple means of specifying an RPC interface from the client to the server. It would also make sense to leverage an existing set of libraries for this purpose. JQuery RPC is fantastic (as is the rest of JQuery) and, IMO, it provides enough abstraction to make Javascript tolerable for any type of programmer. <br>
<br>Using the Client/Server paradigm, one could gain additional performance benefits from templates.&nbsp; Since all of their dynamic state is set an runtime via javascript, they can all be precompiled into XHTML and JS. To avoid the initial request for values after the page load, an appendix could be sent from the server with the XHTML file that automatically sets all of the dynamic values. <br>
<br>I have been slowly building a proof of concept of these ideas using HAML as the template engine and JQuery.RPC as the communication mechanism. It&#39;s not intended to be a full framework, but a client generator that could make JSON RPC requests to any RESTful interface (sorry for the buzzwords) <br>
I&#39;ll yell when I have something to show. <br>