replacing all views / frontend separation / ...

[buhman]

background

pb (or at least the "core", whatever that actually is) was originally supposed to not require javascript/client side code execution; this idea was primarily motivated by opinionated #archlinux regulars. By contrast, other implementations like hastebin were considered unusable and/or of a lower caste than the universally bad pastebin.com.

Despite this, ptpb.pw/f exists, mostly doesn't work without javascript, and is subjectively quite popular. I think the problem isn't javascript, but badly-performing javascript.

I also wrote elm-ui-test ages ago, which despite the name is actually an incomplete write-side pb client. The main problem that prevented its completion was that it was attempting to design new UI/features that nobody asked for.

charter

On the read side, I'd like to implement:

https://github.com/ptpb/pb/issues/215 https://github.com/ptpb/pb/issues/224

I'd also like to ideally see either:

• markdown/rst rendering done entirely in-browser
• markdown/rst rendering as a separate service, totally agnostic of any concept of "paste"

While the former is probably the fastest, it sacrifices correctness/completeness. For example, elm-syntax-highlight has 7 lexers currently.

In the latter case, conceivably, there could even be multiple rendering providers/services, written in different languages. This would allow things like #222.

[buhman]

ghcjs + miso or reflex-frp seem like fascinating options. I read ~20 mins introductory material for each:

• as advertised, miso looks almost like elm, with a few haskell-isms mixed in
• reflex-frp looks approachable, but very different

Haskell also has a much more mature ecosystem, with relevant packages like skylighting