[Haskell-cafe] Gitter Haskell Community

[Joachim Durchholz]

Am 12.12.2016 um 20:14 schrieb MarLinn via Haskell-Cafe:
> It's probably because
> the whole web dev world is a bit bonkers.

My impression: Lack of generally accepted style guidelines, plus too 
many hard technological challenges to leave much energy for making the 
UI slick.
To make matters even worse, some of the solutions to the technological 
challenges make some UI patterns more difficult than others, so people 
start to think technology-first, usability-later, so the whole usability 
thing doesn't get the attention that it deserves.

E.g. incremental loading over an (inherently) unreliable and laggy 
network collides with a type-to-search approach - you can't search in a 
list that you haven't fully loaded yet.

 > But if any community has the
> right people to add a voice of reason, I'd still think ours might be a
> strong candidate. Naturally it's not a really loud voice, but then we do
> have some great server libraries as a selling point.

If it turns out to work better than existing libs, loudness will come 
without even working much on it.
However, language&lib quality factors only partly into final framework 
quality. Being a good Haskeller is orthogonal to being a good at web UI 
usability, so there's no reason to assume that Haskell will bring better 
quality to the masses in this specific area. Doesn't mean that it is a 
bad idea to try it anyway, just don't expect to get specific leverage 
out of Haskell :-)

The various things that are important:
- Ability to easily shift computations between frontend (browser) and 
backend (server). Because latencies or changing data volumes might force 
you reversing decisions about whether something is processed on the 
server or on the client.
- For anything that happens on the client, the server needs to be able 
to re-check it (because the user might be trying to hack the server). 
Absolute must: No need to code this twice, once in JS and once in 
Haskell (otherwise you'll get inconsistent checks, which are one of the 
worst security problem generators because people will mistakenly check 
browser logic when they should be checking server logic and vice versa).
- "Reactivity", which means that the majority of pages should be equally 
displayable on a desktop, in a desktop browser, and on cramped 
smartphone space.

Setting up such a framework definitely requires excellent Javascript and 
DOM knowledge over a range of implementations, and either a 
Haskell-to-Javascript compiler or a DSL-to-Javascript compiler (DSL 
would be pretty restrictive though because then you'd have to limit the 
DSL so that it can never execute arbitrary Haskell).
It's a really big thing to do, but I suspect doing anything smaller 
isn't going to get any attention outside the Haskell community.

Just my ramblings, YMMV :-)

Regards,
Jo