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