

Web Applications that Scale Forever and Upgrade Seamlessly [video] - tenslisi
https://www.youtube.com/watch?v=rtfbQJGQj0Q

======
skore
I don't know that much about Haskell and I don't consider myself strong enough
to make judgement calls on the theory side of systems architecture. That being
said, here is what I was scratching my head about:

1\. ("form over content comment", sorry) Not necessarily a criticism of the
speaker as this is mostly a typical room mic issue, but the volume differences
made this rather hard to follow. But in the delivery, it often seemed like the
filler language was very loud and more in-depth details were mumbled into the
screen.

2\. I keep wondering "why?". It was just brushed over in the beginning, but I
did not hear a compelling reason being presented on doing everything in
Haskell. I do get that it is questionable to build this ever-growing API that
does nothing but glue the client (javascript app) and server side to
eachother. But isn't that what the internet is about? Having contained nodes
that communicate?

And how is basically automatically generating the same sort of API... but now
instead of a growing list of named end points (paths and maybe even GET
variables), you have an RPC style protocol that _directly adresses the
internal code via the tree it sends back as part of the request_ ... better?

Later (around the 48 minute mark) the very valid question is brought up -
isn't binding UI updates to server interaction very, very expensive? Expensive
in such a way that encouraging it as a basic part of the systems design is a
bad idea. And the speaker kind of makes a joke of it and says we can just
throw more servers at it. Well maybe, but that seems to be a rather
substantial error in the entire system design. It might solve some other
problem and the problem created may have a simple solution, but... I just
don't get how all that sums up to being a great idea.

3\. Is this, in some sense, about avoiding to write an application in
javascript? Because I have found a lot of people doing that - building the
most incredibly colorful systems only to avoid to finally let go and just
build a javascript application already.

In this particular instance, it seemed to be about trying - as much as you can
- to do everything in Haskell. I have also seen people build frameworks on the
idea of writing everything in XML files and interpreting them at runtime in
PHP. It's possible and you can conjur up advantages, but at the end of the
day, it's still not a good idea.

Nor is it compelling to other devs to join in, which brings it back to the
LISP problem: an incredible potential for flexibility, but at the end of the
day, it's just not very social. And thus, no matter how much nerds despise
that conclusion, doomed to obscurity.

4\. How can this ever "upgrade seamlessly"? It seems like this pushes the
syncing issues down to the code level. I'm not sure that is an advantage to
having syncing issues on the data level.

------
cordite
I watched it, it reminded me a lot of opa [1].

The problem with opa was it generated a gigantic load of code and when I tried
running a basic app I made (to learn the language), it set off alarms on
dotCloud's system (as if I were bitcoin mining or something) even though I was
the only person using it for 5 minutes.

I foresee similar problems with any other system that attempts to make the
client and server a system on continuations.

Secondly.. yeah, creating disjoint systems can be frustrating to maintain
_together_ , but thinking a web browser is the only platform that will be
supported can be really limiting in future developments.

[1]: [http://opalang.org](http://opalang.org)

------
lukeholder
seems like this would work with react[0] since react manages its own virtual
DOM and its components combine js and html into a single unit.

[0] [http://facebook.github.io/react/](http://facebook.github.io/react/)

