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

Joe Armstrong erlang@REDACTED
Mon Feb 14 11:59:23 CET 2011

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.

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


> best regards,
> Vlad

More information about the erlang-questions mailing list