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.
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.
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:
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.