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

[Alain O'Dea]

Websockets are designed to provide TCP full-duplex communication from a web
page.  HTTP does not necessarily apply.  SEBG could be used in the context
of a larger RESTful application to provide lighter-weight incremental
updates.  A RESTful server would still maintain the up to date
representations for subsequent full fetches, but user agents would be kept
up to date with a lightweight stream.  They are complementary, not
conflicting :)

An Erlang/OTP app built with one SEBG process per user should have no
inherent scalability problems.  Any bottlenecks that exist should be fixable
on the server-side by applying OTP principles.

Again SEBG is complementary to REST, not in conflict with it just as
Websockets are complementary to HTTP.

On Tue, Feb 15, 2011 at 10:50 AM, Alceste Scalas <alceste@REDACTED> wrote:

>
> I just wanted to quote a few excerpts of Frédéric's emails,
> because I completely agree with them (see below).
>
> I think that if you want to develop good web applications, then
> you need to know HTTP, and design the client-server interaction
> around its principles and its stateless nature, i.e. following a
> RESTful approach [1].  The user interface elements (HTML, CSS,
> Javascript...) just come on top of it, and usually require
> dedicated knowledge and experience in order to get them right.
>
> I also think that everything which tries to circumvent the
> HTTP/web architecture in order to "help" the programmer reach
> from the server-side to the client-side is doomed to fail,
> especially when scalability becomes an issue, either on the
> developer side (more than a few programmers are expected to
> work on a project) or the client side (more than a few users
> are expected to interact with a web application).
>
> Just to make a few examples, I'm referring to "cool" stuff like
> continuation-based web frameworks from the Smalltalk/Lisp/Scheme
> world, or automatic server-side Javascript generation (which
> reminds me of automatic SQL schema or query generation: it
> usually sucks, and thus it is hated and avoided by developers
> and DB admins who are actually proficient in SQL).
>
> IMHO, it is an error to focus on toy applications (and/or
> single-user applications, like the Appmon) and assume that an
> useful solution (at least from the POV of a single developer,
> or a small group) could "scale up" to real-world application
> development.  When projects start this way, and they grow,
> they usually need to be thrown away and rewritten ground-up.
>
> Here's a famous example: a few years ago, Reddit was considered
> a proof that "Lisp works", because it was a prominent web
> application written in Lisp.  When the user base grew, Reddit
> was completely rewritten in Python [2].  This was considered a
> "betrayal" by the Lisp community, and thus several developers
> started to write "a Reddit clone in just 20 lines of Lisp".
> Those were interesting exercises, but they didn't address any
> of the problems of the first Reddit: they didn't scale,
> didn't support templating, didn't support l10n or l18n,
> dind't offer battleground-tested libraries...
>
> From my experience, I can say that it's much better to
> start from the complete and realistic scenario of a "real" web
> application, and see if (and how) an approach that works at
> this level could "scale down" and become "easy" in single-user,
> single-developer scenarios.  IMHO it's also the most effective
> way to propose Erlang as a sound alternative for web
> development.
>
> References:
>
>  [1] http://en.wikipedia.org/wiki/Representational_State_Transfer
>  [2] http://blog.reddit.com/2005/12/on-lisp.html
>
>
> On Mon, 14 Feb 2011 07:43:57 -0500, Frédéric Trottier-Hébert <
> fred.hebert@REDACTED> wrote:
>
>> The truth here is that most programmers are awful at design. In any
>> somewhat large setup, your backend programmers, your designers and
>> your integrators (the guys just handling HTML, and CSS, maybe some
>> Javascript) are not necessarily the same person.
>>
>> Right now the ring of web technologies is divided in a way that makes
>> it somewhat simple to have different people from different background
>> and knowledges to work on different part of your software. It makes
>> sense to have the designer or integrator to be able to change the look
>> and feel of a website without having to play in your code and maybe
>> mess up database queries. Modern template engines in fact try to
>> forbid all kinds of seriously side-effecting code (like DB queries)
>> from happening in the templates.
>>
>> There should be no worry for your guy working in Javascript that he'd
>> not need to suddenly learn Erlang to be able to debug your
>> application.
>>
>> Then again, this separation of concerns allows specialists to work on
>> their speciality with more ease. It makes things somewhat simpler in
>> larger organisations, but quite painful for one-man operations. I'll
>> tell you that it makes a lot of sense when you know all of the tools
>> in the toolkit though :)
>>
>
> On Mon, 14 Feb 2011 20:50:11 -0500, Frédéric Trottier-Hébert <
> fred.hebert@REDACTED> wrote:
>
>> There is nothing wrong with what Joe is doing. There is nothing wrong
>> with exploration. However, things already exist in Javascript and on
>> the web in general and we shouldn't reinvent the wheel all the time
>> because we might be coming from a different domain or we don't have
>> the same experience as real web developers have.
>>
>
> --
> Alceste Scalas <alceste@REDACTED>
>
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>