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

[Vlad Dumitrescu]

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?

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.

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 :-)

best regards,
Vlad