1. 86
  1. 16

    You know, it would be nice to have a “simple HTML” mode for lobsters. We’re most of the way there, but there are some actions that require JS. Notable examples include voting and replying to comments. I’m posting this comment from a text-mode browser, but if someone replies to me and I want to reply to them, I’ll need to spin up firefox.

    Would patches be welcome? I’m willing to put my money where my mouth is, so to speak. Where would I start?

    1. 18

      Would patches be welcome? I’m willing to put my money where my mouth is, so to speak. Where would I start?

      @pushcx has stated in the past that he’s willing to accept patches to the Lobsters codebase that makes JS optional for replying/voting/&c. (I think. It was a while back and I’m not entirely sure I remember correctly.)

      I’m posting this comment from a text-mode browser

      Just FYI: there is a mailing list mode that you can enable from your settings, and which can be used to comment and reply on stories without a browser. I’m using it right now to reply to you :^)

      1. 11

        Yes, that’s correct. I’d take patches to make js entirely optional. A contributor doesn’t need to do it all in one PR, either.

        1. 7

          Speaking of, I don’t know how stupid I am for waiting this, but an NNTP mode would be very neat.

          1. 3

            technetium e-mailed

            Well what do you know!

            1. 2

              That’s awesome. I never realized you could use mailing list mode to reply to comments. I’ve been using it to receive story submissions for a while.

              FWIW I tried replying to you with it, but since the “Technetium has replied to you” email didn’t come through mailing list mode, my reply got dropped on the floor.

            2. 12

              I don’t find the small amount of Javascript objectionable.

              Lobste.rs is as about as simple as you can get without having to do a bunch of clunky navigation for commenting etc.

              1. 20

                I do not find lobste.rs use of JavaScript egregious most of the time. But when I’m in my living room, using my Raspberry Pi, spinning up Firefox is kind of annoying. And I find the phone to be suboptimal for writing anything more than “k thx lol”.

                I’m blind and I use a screen reader. I’m not complaining about anything; I’m interested in adding something optional to the site to help me and perhaps others, not in imposing “clunky navigation”. I have skin in the game, and skin in the game is a huge driver of open source.

                1. 8

                  It is quite disappointing if we look at the web in absolute terms, that we got to the point where people even need to state that they have skin in the game. Everyone has skin in the game. Here I am today without any disability… who knows about tomorrow, my sight could go bad for whatever reason, I could have an accident and end up in a wheelchair. Accessibility should be everyone’s concern, specially so where it is basically free as with simple HTML.

                  In browser javascript is a tremendously useful technology, I’m not challenging its merits by any means. But the fact that virtually no one resisted the temptation of adding if for aesthetic reasons is a sad outcome. A huge percentage of the web would work just fine without javascript. Sure, some things could have a bit of a humbler look, but it is sad and conter productive for us as a species to give that much preference to the looks instead of content.

                  It mirrors a society where things like braille, accessibility ramps or even public transportation don’t exist because they don’t look good to those who don’t need them. The developed world has such things and their gains are well studied, not to mention the ethical obligation they are in themselves.

                  1. 3

                    I must admit I totally forgot about the accessibility angle, and that’s doubly bad because my wife is blind.

                    I think that if JS is used in a way that’s prejudicial to a11y, it should be reworked/removed. I was reacting to the puritanical aversion to JS in all its forms because some bad actors misuse it for ad tracking etc.

                    1. 4

                      Yes, there are legitimate uses for JavaScript. Yes, there are sites that use it in a positive, user-experience-enhancing, non-egregious way. Case in point: lobste.rs. However, tons of sites use it for user-hostile purposes, such as ad-tech and tracking. And another fraction of sites use it to add glitz and bling that breaks the web for folks like me. I do on some level object to the proposition that in order to use a website, I need to let randos execute un-vetted code in a Turing-complete language on my devices. Again, lobsters is the exception rather than the norm: I can easily vet the code, and I trust the people who are in charge.

                      I don’t know how to square the above tangle of conflicting assertions. I’d love a solution that works for all of the stakeholders – excluding surveillance capitalists; they can pound sand.

                      Another point to note here is that we are in the middle of a climate crisis. “Buy a faster / more capable machine” is not an acceptable answer to “the web is too complex for my device”. It never was, and that’s doubly true right now.

                      1. 2

                        I can quickly think of another bunch of disadvantages too: battery life, mobile network congestion, device longevity, load times, development costs, latency (html is a single request from primary domain), security, etc.

                        Further, i’ve seen websites that I’m guessing destroy accessibility by using fancy things likes clickable divs instead of actual buttons.

                  2. 4

                    Making the vote things work without javascript should be trivial: the same UI, just put them in a form object. Onsubmit javascript, ajax submit it instead. But without javascript, it would POST the appropriate data and then send you back where you started.

                    It is right now an <a> element it appears, which is a bit nonsensical anyway, a form with a button (but styled the same way) is surely better for several reasons.

                    1. 1

                      It might actually stay as an anchor html element I think. Should be even easier then (at least should be less code to change/add). I guess one will need just to implement the web endpoint that would redirect after registering the upvote and can leave the actual javascript stuff in, just short-circuit the event at the end so if javascript is present it will do the upvote as it now does, no change in most of the code needed, and if it is not present the normal link behavior will do the job.

                      Haven’t looked at the code base, just guessing based on my own experiences. So take it with a pinch of a salt.

                      1. 3

                        Might be fun with webbrowser that want to preload certain links.. Suddenly you’ve upvoted most comments in the thread you were reading. I think @adam_d’s idea is better, to have a form POST.

                        1. 1

                          Good point! There is always rel=“nofollow” option for the preloading problem and browsers as far as I know should not prefetch if the link does not have rel equal to “prerender”, “prefetch” or “dns-prefetch” but I guess there might be some broken web browsers so it would be safer to go with forms.

                        2. 2

                          Semantically, a link is always a GET and gets are never supposed to have side effects. (I know they do a lot in practice but they aren’t supposed to - and this is a potential security problem too since doing a XSRF for a get is trivial; just put an img tag on your website and all your visitors who happen to be logged into lobsters will automatically upvote you! (unless your session cookie is explicitly SameSite=Strict of course).)

                          So since it changes something, it should be a POST, and that means html form. But you can css style it so it looks identical to the current button, and encapsulate the html in the template so even developers can kinda forget about it too.

                          Though the current code isn’t even a link, it is just an anchor w/o href, still the same logic applies.

                          1. 1

                            You are right. Just checked again and HTTP protocol states that GET’s should be idempotent just as you said. even if it is so easy to use them as not to ;-) My bad.

                            Cheers, a.