[Ur] Strategy - UrWeb Backend

[Adam Chlipala]

Stephane Le Dorze wrote:
> Indeed, for a language/framework to break throught, it needs to get 
> momentum with a big/growing community and to play with current/hypped 
> technologies, take advantage of working with existing librairies and 
> getting a decent tooling. 

I'm not sure I buy into the importance of integration with "hyped" 
technologies.  Perhaps you could be more specific about some project 
that you feel can't be implemented adequately with Ur/Web as it stands 
today?  I'm asking for a description of the user experience you're 
aiming for; requiring integration with some specific technology that the 
end user doesn't see is "cheating." ;)

I also want to emphasize that I'm not trying to maximize adoption of 
Ur/Web.  Rather, I'm trying to maximize the effectiveness of people who 
do choose to use it.  This means that I'm completely happy if basic 
features of Ur/Web mean that 90% of programmers will never be able to 
use it.

> (a FFI via C only does not target the right community).

There's been a JavaScript FFI since well before the first Ur/Web beta 
release.

> When I think about it, I immediatly see a JS backend. Just being able 
> to integrate this community and run on NodeJS for instance or take 
> advantage of existing JS APIs and Tools.

Which benefits do you see from server-side JavaScript?  I'll be really 
surprised if any such system can get over the inherent costs of the 
JavaScript language, to match the performance and security of Ur/Web.

> Would a JS backend be hard to integrate with the current compiler 
> which is already targetting the JS frontend?. 

There wouldn't be anything technically interesting to do.  It would 
probably be a significant amount of mostly-boring work.

> Another question: are there other reasons than timing not to have 
> targeted a LLVM backend instead of the current one?

Since the Ur/Web compiler works via generated C code, I have a feeling 
it would be trivial to just drop in LLVM's clang as an alternate 
compiler to call in the last stage of compilation.  To me, the 
engineering benefits of going via C rather than a lower-level language 
are clear, so I wouldn't want to output LLVM bytecodes directly, just 
like I don't output assembly directly now.