On the web, there's semantic HTML and Web Content Accessibility Guidelines which focus on making content for the Internet as broadly interoperable and accessible as possible. The former from a technical point of view, the latter from a human interaction point of view. They go together hand on hand.
this post was submitted on 09 Feb 2024
19 points (100.0% liked)
Programming
17352 readers
298 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities !webdev@programming.dev
founded 1 year ago
MODERATORS
Maybe Elm? It was the result of Evan Czaplicki's thesis.
At the rate frontend spits frameworks and languages it's pointless to write papers for it. Innovation on that field happens by bruteforce.
Have you looked at Elm?
It's very much not JavaScript, but I think that comes with the territory of wanting something significantly different.
For what it's worth, with wasm you could use any language that compiles to it as a frontend language. Rust has a few frameworks that can compile to standalone wasm web pages.
I’m confused why everyone sleeps on Purescript. I mean, it is currently QUITE obscure.. I could be wrong but I feel like Purescript has all of the same goals as Elm but better.
It does look pretty damn cool. One thing that bothers me is it is in the npm ecoystem :)
Thanks for that explanation. That makes sense.
I guess I should also mention IHP.
As far as npm and Purescript goes: I don’t interact with npm when I use it. I use nix and nixpkgs to build it which pulls packages from a predefined, fixed package set inside of Pursuit (Purescript’s package manager that feels a whole lot like Stackage). I suppose if I wanted to use it in the real world, I’d probably have to expose myself to some npm. But, from my cursory understanding and experience, it is probably less tainted by the safety issues in the npm than straight up JavaScript. Packages in Pursuit (particularly the ones exposed in the standard package set I use) tend to be super high quality code like the modules you’d find in GHC.
I also sleep on elm, JavaScript and typescript. (i.e. don't use then)
It's simply that I never heard of purescript.
I’m glad to introduce you. :)
htmx.org has tons of assays posted online. But I don't recall seeing any 'white paper' for frontend frameworks... maybe it's also related to "ux research" (if there's such thing) being more of a marketing discipline, and by its profit-seeking nature that's mostly secretive.
Concepts like Reactive programming are widely used in web/UI contexts. The problem of connecting a UI to an underlying data set is not trivial. Several frameworks deal with this.
As was already said, concerns like Accessibility are studied academically. They have more to do with user experience than the technology, so not sure if they match your question.
AFAIK, Halogen for Purescript is about as FP as it gets in the front-end world. It’s pretty complicated but Halogen takes advantage of “free monads”. Perhaps you are looking for something even more rigorous since you mentioned Idris but I figured I’d mention that one.
I’m learning it now and it has not been easy. I tried to port a simple vanilla JavaScript dynamic draggable table over to Halogen and it has not been fun at all. I got 80% of the way there then started to have to reach for FFI, unsafeCoerce, or build my own Purescript module to capture mousevents.