1. 30
  1.  

  2. 13

    If you provide a Turing machine, some idiot will implement a Turing machine on it.

    “You were so preoccupied with whether or not you could, you didn’t stop to think if you should.” (with apologies to Ian Malcolm)

    1. 6

      Is Lobsters a document or an app?

      1. 4

        Presentation wise I would lean more towards a set of documents.

        1. 2

          The article talks about client side and server side processing, but its logic seems very client focused, and Lobste.rs uses a very lean client.

          On the server, there’s always going to be some code that translates an incoming HTTP request to obtain data from a static file. It doesn’t make a huge amount of difference if that code is getting the data from a database, or a zip file. There’s going to be code running either way, the difference is the maturity of that code.

          1. 5

            It does make a difference because http is designed with full support for downloading files. With headers reserved for filename hints, and even for things like if it should be displayed in the brow as we or downloaded to the local filesystem. The first webservers did this and still to do this day. It’s fisrt class functionality and if you keep things limited to that, it is trivial to move the site. Heck, it is even browsable directly without http involved at all.

            I agree with the author, but @carlmjohnson question is not to be disregarded so quickly. From the point you exposed a database view, you introduce expectation on the dynamic nature of the content. And from there, arises demand for interactivity. And at that point you are fiddling with the DOM in the client. Then you ask yourself… Ok… Does it really make sense to assemble html in the server and in the browser? What about the server having a well defined http API that spits whatever data I need? We have arrived to SPAs.

            By all means, I’m all for sites like lobsters with full page form submissions, simple forms and buttons. But the pressure for shiny looking websites from the general public is just enormous.

            1. 3

              But the pressure for shiny looking websites from the general public is just enormous.

              I wonder if that pressure comes from the the general public?

              1. 4

                It comes from the boss who saw something shiny on a competitor’s site.

                1. 3

                  I think it does. While there are many non tech savvy people that instinctively would prefer their tried and true software that works… I believe they are still the minority. Sexy screenshots trump everything. If you are in the industry as a worker, you get left behind if you don’t embrace it. Engineers that put together shiny things with flashy colors and lots of padding will be promoted.

                  1. 1

                    You can have “sexy” “documents”, https://lobste.rs/ is pretty sexy design wise, but it still and acts and looks like a “document”. Content is niche but I don’t believe its design would be rejected by the general public.

                    1. 2

                      I don’t think so at all. People would reject it in an eye blink given an alternative with huge title text, lots of padding, large round avatars and all links looking like buttons with large rounded corners and flat design.

                      Look at how discord completely took over all existing forum software. What other reason are there besides flashy looks?

                      1. 1

                        Did Discord take over all forum software? I recall the old web forum model becoming unpopular well before Discord became a thing; it seems like Facebook replaced it as much as anything. Since Discord is a chat program, it doesn’t seem to me to be comparing like with like.

                        As for why these proprietary platforms won, I see there as being two reasons. The first is that these platforms realised they could use graph data (or in Discord’s case, multiple “servers”) to create a platform which scales to an infinitely large number of people and infinitely large number of communities, enabling a network effect which leads to a network effect monopoly. In short on Facebook you’re “bubbled” according to your position in the graph (the people you’ve friended). Compare this with a web forum in which everyone sees the same thing (and in which new subforums can only be created by administrators). This model naturally scales only so far and a traditional forum will always have some specific subject of focus for this reason. Moreover, if you were involved in web forums, you might recall that smaller forums (in which everyone knew each other) had a very different feeling to larger ones; and as smaller ones grew to be larger ones, their feeling changed in this way. By using graph data the modern social network can allow one to have a more “local” community while also being able to communicate with a much larger global network of people. Of course, this requires people to provide this graph data to them (which they do by adding people); the value of this graph data to commercial and state surveillance interests is a very convenient coincidental benefit to these platforms.

                        A second likely reason might easily be “dopamine engineering”. That’s not quite the same thing as “people want flashy UI”.

                        1. 2

                          I meant discourse. Sorry.

                          It is essentially the same functionality of phpbb and the like, with a flashier design.

                          1. 4

                            I’d argue Discourse is a lot less flashy than phpBB; phpBB style forums have a lot of extraneous chrome (unless it’s a buy/sell forum, why do I care about the poster’s location?) that Discourse ditches in favour of content and widgets focused on navigating content. (Of course, Discourse isn’t the first; it feels like a spiritual successor to Vanilla for me.)

                            1. 1

                              https://try.discourse.org/ doesn’t like an app to me.

                              Edit: But it is.

                              Could very well be a progressively enhanced SSR web site. Design would be mostly the same.

                  2. 1

                    I think @calmjohnson’s question is interesting because lobste.rs is a document, it’s just not the same kind of document as a static web page and that serves to highlight the underlying problem: web browsers have evolved from a mechanism for displaying a document to being a framework for providing document viewers. This isn’t a new development. Netscape 2.0 was the first web browser to support a mechanism for providing custom viewers for other kinds of documents (Mosaic / Netscape 1 provided a mechanism for opening other kinds of document in a different application).

                    Perhaps the real questions that need asking are:

                    • To what degree is this document different from a static HTML page?
                    • What is the smallest possible viewer for a document of this kind?
              2. 6

                I expected a “get off my lawn” old-person rant, but I was pleasantly surprised to find a balanced, rational discussion about content on the web. 10/10, would click again.

                I entirely agree that content should be displayed as content. Honestly, it’s so much easier to do, I’m really not sure why anyone uses JavaScript to display a blog or whatever.

                1. 5

                  The crux of the issue is when does it go from documents to application? Is it a simply a binary option? Everyone has a different conceptualization of when a document goes to an app.

                  1. 2

                    When you start to collaborate on something like the lobste.rs comment section then you approach app territory. I think there is a native composition mechanism missing in HTML. If that existed, you could post your comment as a document and compose these in HTML without resorting to a full language on the server or the client.

                  2. 7

                    This post has a lot of arguments that basically boil down to:

                    If your personal website turns into an “app”, you’re doing it wrong.

                    It makes fun of 2 sites:

                    Your serverless, headless, Micropub-powered personal website is unreliable precisely because you chose to introduce unnecessary complexity.

                    and

                    Here’s a recent example of a website, made up of documents, that decided to re-invent the wheel: https://slc.is/.

                    The first site was submitted here a month ago, got 10 upvotes and no massive pushback. It’s clearly a webdev tech demonstrating new technology, partly as a fun thing to do, partly as a tech demo, and partly as advertising.

                    The second has a long post about the tech behind it: https://slc.is/#Creating%20My%20Site. To me, this reads as someone who is as passionate about blogging as the author of the linked post. They should be celebrating that others want to publish on the web. But no, they’re doing it wrong. That kind of attitude grinds my gears.

                    Look, I’m sympathetic to the idea that people should host their own content. I mean, I do too! But this kind of gatekeeping isn’t helping that. If you create your own way of publishing , from scratch, you’ll get pushback from SSG purists. What a sad state of affairs.

                    1. 2

                      We don’t need to call out everything we see wrong. We can accept a technology for what it is, and recommend only using it in certain conditions.

                      That’s why people didn’t push back. The discussion would get very stale, quickly.

                      1. 1

                        So true! But there are always haters out there, you can’t make everyone happy…