-
Notifications
You must be signed in to change notification settings - Fork 52
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
replacing all views / frontend separation / ... #228
Labels
Comments
ghcjs + miso or reflex-frp seem like fascinating options. I read ~20 mins introductory material for each:
Haskell also has a much more mature ecosystem, with relevant packages like skylighting |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
#215
#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.
The text was updated successfully, but these errors were encountered: