[erlang-questions] Two beautiful programs - or web programming made easy
Mon Feb 14 11:59:23 CET 2011
On Mon, Feb 14, 2011 at 10:50 AM, Vlad Dumitrescu <vladdu55@REDACTED>wrote:
> 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
> 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
>> something like
>> And to be able to configure Apache and MySQL - other combinations are
>> 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
>> 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
>> The only communication with the browser should be by sending it
> 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,
> [*] 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
> one has been working extensively with one or the other).
> 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.
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
> engine in the browser with an erlang one :-)
That's a wee bit more tricky.
> best regards,
More information about the erlang-questions