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

[Ryan Zezeski]

2011/2/14 Richard O'Keefe <ok@REDACTED>

> I just ran into trouble with a couple of "smart" pages today,
> including one hosted at this very University (but not a science
> department).
> In both cases I was seriously searching for information, on behalf of
> someone else having a fairly pressing need for it.
> In both cases, what *could* have been a simple static page linking to a
> bunch of other static pages went through an unholy mix of Javascript
> and SQL, and ended up spewing buggy SQL over my screen instead of useful
> information.
>
> Heck, one of these was even a cross-site-scripting bug.
> (Page here has Javascript that creates 'whatever?at=code, accessed at
> <some date>' in a link, user clicks on harmless text of link, server
> at other end trusts blindly, crashy time.)
>
> Javascript *can* be used competently to do wonderful things.
> But not for the 2-10% of visitors using browsers with Javascript
> support missing or switched off.
> And WebSockets will be used competently to do wonderful things.
> But not for the [27% to 70% depending on who you ask] of visitors
> using Internet Explorer.
>
> We shouldn't fall into the trap of "one page sites".
> (See http://catless.ncl.ac.uk/Risks/26.34.html#subj8 )
>
> If you are providing information through the Web and it does not
> get communicated, you have *failed*, no matter how wonderful the
> experience might have been had it worked.
>
>
Sure, but not all applications have this requirement.  I'll go right back to
my appmon example.  appmon is a great little utility in the Erlang world for
visualizing your process graph, but it suffers from a absolutely horrible UI
(at least in OS X).  Using Joe's work to make a new UI would be really cool
and useful to those that have the appropriate support, and it wouldn't hurt
anyone that doesn't.  Furthermore, this would not be something exposed to
the web, and even if it was it's not something anyone expects to search.  Of
course, if you really wanted to, you could use HTTP's content negotiation to
handle different representations.

For the very reasons that everything should _not_ be a "one page site" I
would also argue not everything needs to be a "multi-page site."  There is
room for both.  Think about video games, they perfectly fit the model of a
"one page site."  How about google maps, google docs, etc?  If the historic
web was so good why all the fuss over Ajax/DHTML, and more recently HTML5
stuff like canvas, video, webgl, 3D CSS, websockets, and the like?  For
certain things, namely "applications," people want an experience that the
current web doesn't give them.  Personally, I'm all for it.

-Ryan