[erlang-questions] Two beautiful programs - or web programming made easy

[Edmond Begumisa]

On Mon, 14 Feb 2011 21:59:23 +1100, Joe Armstrong <erlang@REDACTED> wrote:

> On Mon, Feb 14, 2011 at 10:50 AM, Vlad Dumitrescu  
> <vladdu55@REDACTED>wrote:
>
>> Hi!
>>
>> I've been following the discussion with mixed feelings. I may be simply
>> confused, but isn't this something that one has been able to do with  
>> Flash
>> since quite a while? So yes, it's cool that it can now be done without
>> proprietary plugins, but is it new?
>>
>
> You're right I could have done it with flash, or actionscript, but I  
> didn't
> do it.
>

One difference is that you can send not just flash-looking SVG, but you  
can also send plain HTML rendered by the browser with no special rendering  
libraries or plugins needed.

With XULRunner, I'm sending chunks of XUL from Erlang.

- Edmond -


>
>>
>> 2011/2/14 Joe Armstrong <erlang@REDACTED>
>>
>> Ok so "separation of concerns" is good but having different notations  
>> for
>>> expressing the concerns
>>> is crazy- to make a web thing that interacts with a server you need to
>>> learn
>>> something like
>>>
>>>        HTML
>>>        Javascript
>>>        CSS
>>>        PHP
>>>        MySQL
>>>
>>> And to be able to configure Apache and MySQL - other combinations are
>>> possible.
>>>
>>> Then you have to split the flow of control to many places.
>>>
>>
>> What do you mean by "web thing", there are many species out there? Some  
>> are
>> content-based (regular sites), some are behaviour-based (games), some  
>> are
>> meant for machine consumption (web services), some are somewhere  
>> in-between.
>>
>>
>> Isn't it a matter of using the best tool for the job? If I need  
>> searchable
>> text, I use html. If I need user interaction, I use javascript or flash  
>> or
>> java.
>>
>>
>>> All of this is crazy madness. There should be *one* notation that is
>>> powerful enough to express all
>>> these things. In the browser is seems sensible to forget about css and
>>> html
>>> only use Javascript
>>> The only communication with the browser should be by sending it
>>> javascript.
>>>
>>
>> This is reasonable [*] for a behaviour-based "web thing". If one
>> wants/needs to be able to interact with the "web thing" from lynx,  
>> emacs,
>> via a web-bot or other non-javascript-enabled alternative, then this  
>> won't
>> work.
>>
>> [*] As reasonable as using flash or java applets. No flame wars here.
>>
>> Then half of the things you enumerated are for the server-side - I think
>> that's orthogonal to the issue of what kind of data goes to the browser.
>> PHP/MySql/apache or (for example) erlang/mnesia/yaws are still not
>> javascript, nor is one or the other easier to configure and setup  
>> (unless
>> one has been working extensively with one or the other).
>>
>> BTW, how do you mean that the javascript will draw things on the screen?
>> Wouldn't it be by manipulating the browser document model, building a  
>> html
>> document on the fly? So maybe I don't have to know the html syntax, but  
>> I
>> still need to understand how a html document is structured (which imho  
>> is
>> the more difficult part of the two). An alternative would be to actually
>> draw pixels, but then it would be easier to skip the browser altogether.
>>
>
> Javascript provides a abstract interface to the browser. Of course js
> actually manipulates the DOM
> but the user should not be aware of this. JS routines should manipulate  
> the
> DOM set css properties
> etc. to present the user with a uniform model of what's underneath.
>
>
>
>>
>> Re-reading my answer, it sounds a negative, but what I mean is to try to
>> clarify the intent of Joe's idea, maybe I'm missing the point.  
>> Personally, I
>> would go way out to the wild side and suggest replacing the javascript
>> engine in the browser with an erlang one :-)
>>
>
> That's a wee bit more tricky.
>
> /Joe
>
>
>>
>> best regards,
>> Vlad
>>
>>


-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/