1. 35
    1. 14

      I guess this is a little off topic, but creating a browser engine is so difficult, I wonder if anybody has considered creating Markdown browsers and communities around them?

      The key ideas would be:

      • Serve markdown (maybe an extended version) over HTTPS
      • Reuse existing server infrastructure
      • Only text, images, video, and audio - no client scripting
      • Leave all rendering decisions to the browser
      • Participating sites would (ideally) only link to other markdown sites

      The HTML and Javascript web seems to get more and more like TV every day, with less user control and more centralized/corporate control. A new browser engine might help, but it feels like it’s beyond saving at this point.

      1. 25


        Gemini is a new, collaboratively designed internet protocol, which explores the space inbetween gopher and the web, striving to address (perceived) limitations of one while avoiding the (undeniable) pitfalls of the other.

        While not a browser per say, this is similar in spirit to your markdown browser idea.

      2. 12

        Leave all rendering decisions to the browser

        I’m torn on this. I don’t really care for the CSS or layout for random news sites, but at the same time I really like the distinctive and wacky styles I see on people’s personal sites. Removing that element of individuality would, IMO, make the web more corporate.

      3. 6

        Sounds kind of like the existing Gopherverse, sans HTTPS.

      4. 5

        Reminds me a bit of this post calling for a “Khyber Pass Browser”. I saw it in another forum, so I’ll paste my comments here as they also apply to your idea, and I’m intrigued by the design space and problem of staying simple:

        What are your use cases or goals? I ask because I am ancient, and this sounds like a design doc for Mosaic 1.0, down to opening an external application to deal with those newfangled jpegs.

        Depending on those high-level questions, maybe you want to lean way, way more into unix and do the most extreme version of “defer any content-specific rendering to user-specified helper programs” and like make a FUSE filesystem for browsing IPFS/DataShards or similar? Then you don’t even have to define a document format and write a renderer. (But more likely there’s some context/assumptions I’m missing.)

        [discussion turned to the “should be implementable by a motivated undergad in a year of free time” heading]

        I think an undergrad with a high-level binding like fusepy could bang out an integration pretty quickly. But I’m not married to the idea, I was throwing it out there to try to figure out what’s important to you in this project, same with the use case/goals question. Is it networking? Is it a new document markup? Is it use of mimetypes?

        A point I meant to make with the comparison: Mosaic was an undergrad project and thirty years later, here we are with browsers that have 10x more code than the OS it ran on. What about this project keeps it from growing? How would you allow it to change and adapt, but not grow? That’s a really fascinating problem; how do you repeal Zawinski’s Law? Is there something in your design space that you think will help a KBP become a living fossil?

      5. 1

        I could see myself using that, though I assume it’s going to mostly for personal websites, so one will still need an extra conventional browsers.

        Really interesting idea

    2. 3

      I think we seriously lack diversety on a lot of technological fronts. Monocultures and situations close to them tend to inhibit innovation.

      Else we return to IE times when it was nearly impossible to browse large portions of the web without it.

      Despite mostly basing off open standards now I’m coming across more and more websites or better web applications that pretend to only work using Chrome. I say pretend because often time there isn’t another reason than a browser check.

      I’m pretty surprised by this though, because looking at popular JavaScript libraries, frameworks, etc. a lot of them do in fact check features rather than for browsers.

      So what can be seen happens despite open standards and library crrators that at least in large don’t push for singling out browsers.

      But coming back to innovation and standards. Standards can sometimes be a double edged sword, because when there is only one, few or even just very similar implementations standards usually evolve around their designs, strengths and shortcomings which makes it harder to approach things differently, even when that approach might be better in various ways.

      This can be a real innovation killer and also why people sometimes despise standards which otherwise seem to have beneficial effects for innovation.

      1. 1

        A lot of the UA sniffing is specific sites not wanting to guarantee support for any browser they don’t test in their pre-release testing; this frequently ends up at a ridiculous point where browsers like (current) Edge or Opera, based on the same Chromium release, are blocked while Chrome works fine. (This is a large part of why Brave has exactly the same UA string as Chrome.)

        But yes, standards can constrain behaviour, but at the same time if major implementations converge anyway then in practical market terms any new implementation is going to have to match that behaviour: consumers rarely like, “oh, no, the website is broken, we’re implementing the standard fine!”, because they just stop using your browser then.

    3. 1

      It’s great to see a new entrant in the browser space, but kinda sad that it’s implemented in memory-unsafe C++. I guess the S in IoT is still for security. :/