Comment by vbezhenar | Hacker News Reader

Comment by vbezhenar | Hacker News Reader

I would take an alternative position in this matter. What we need is a simple yet functional subset of web. The point is to be able to build a browser in a reasonable amount of time with many languages reusing some commonly used libraries, while being able to use latest Chrome to browse those websites as well.

TLS: keep it as it is. Crypto is hard and TLS is proven crypto. Mandate something like 1.2+ and be done with it. Every mature language has TLS implementation or bindings.

HTTP: use subset of HTTP/1.1. Parsing is very easy: it's just bunch of lines. Full HTTP/1.1 is hard and probably unnecessary. Things like connection reuse are not necessary and should be excluded for simplicity.

HTML: use subset of XHTML. It must be valid XML, so parsing is just one call to the XML library which is available on every language.

CSS: I don't really know, that's a tough one. Something like CSS 2 I guess. There must be a balance between complexity of implementation and richness of presentation.

JavaScript: just nope. That rabbit hole is too deep.

If you take this position to the extreme, you can even reduce HTML + CSS to some kind of markdown-like language, but I don't think that we need to go that far.

In my opinion, there should be no CSS and no styling at all. The original idea of logical document markup and letting the client render the document is best. It shouldn't be the content provider's business if and how the content is processed on the client machine. Once you open that door, you just duplicate the kind of aberration we already have.

A good WWW provides linked documents in a format that is easy to display and process (e.g. extract links, text, headlines, images, etc.) and makes it impossible to hide content. If you publish a document, it should be publicly accessible.

Honestly, you've just described about 95% of gemini exactly. It's TLS required (even 1.2+), line-based parsing with text/gemini content, it's actually even simpler to parse than XML, since it's line-based (just peek at first 3 characters, you know the line type from that). It doesn't use CSS or JS at all, styling is totally up to the client.

So like I said, you've basically just described gemini :)

The difference is you can't just open Gemini protocol in the browser, so you're limiting audience of your resource to a very minority. That's what I want to highlight: something that is compatible with modern web, yet simpler so alternative browsers could be implemented.

You actually can open Gemini in a web browser, using a proxy like proxy.vulpes.one or portal.mozz.us. I tried to write a Firefox extension a la OverbiteWX for gemini to automatically redirect links, but my JS-fu isn't strong enough.

I think "just" going for CSS 2 would be a mistake. In my opinion, it would be preferable take new concepts that are simple to implement and simplify life for everybody (e.g. vh, vw units and flexbox, box-sizing). Goal should be to get a minimal deterministic rendering engine for content that's easily written manually with a minimal subset of modern XHLTML+CSS.

Re:XHMTL: as somebody pointed out here, there are rules to "normalize" unbalanced HTML5, but they have to be implemented and add to the mountain of "implicit" knowledge one has to have and implement...

> a simple yet functional subset of web

a body with sequence of <img>, displayed vertically. you can look at imgur and see such format has been used for simple messages, blogs, collections of memes, recipes, news, informational content, engineering content, fitness advice etc etc.

no css, no nothing, the user agent takes care of formatting them according to the display device etc.

I can't think anything more flexible, simpler and yet capable of doing 90% of what the static web can do today. you can even have a comments section, just add <img> to the bottom and alt the commenting user&Timestamp.

Sounds like AMP.

I think WebAssembly+low-level DOM API would be a good compromise for the lack of JavaScript.

I think the grandparent's point is specifically against embedded scripts rather than JavaScript itself, since it can be used to make HTML less like a document, and there's also the proverbial can of worms where you automatically run Turing complete code from an unknown person.

Actually I'm thinking about complexity of implementation and security consequences. I'm not sure that JavaScript interpreters are so common and bundling V8 just kind of defeats the whole purpose... Implementing JavaScript is not an easy task, it also requires implementing plenty of APIs like DOM access, XHR, complex event system, to be any useful. And ability to evaluate a Turing-complete code poses just another level of security issues.

Whether it makes HTML less like a document is up to author to decide, IMO. Some JS snippets are pretty useful, some are not. You can use JS to implement an interactive learning system or you can use JS to spy on users.

Wasm probably is easier to implement that JavaScript. But it still carries other issues mentioned above.

I'm a big fan of WASM. And I imagine that a naive but functional implementation is easy to make. However, as the web becomes increasingly heavy over time, there will be pressure on the dominant browsers to accelerate WASM, and they might resort to the same complex tricks that modern JS interpreters must do to stay competitive.

I think anything real Web 2.0 (I'm takin' it back, it's not their word anymore) would allow for both models. Whatever is next needs to be both simpler, more generically useful, and fill the requirements of this project as well as the most progressive "web app". At this point, I am open to "starting over."

Remove HTML, CSS and JS. just have a markdown for the UX.

I think you could keep JavaScript at this stage. It’s mature enough and very useful. There are a few strong implementations out there. Make it an add-on with well specified interfaces and object models.

'use subset of XHTML. It must be valid XML, so parsing is just one call to the XML library which is available on every language.'

HTML5 defined a concrete, final mechanism for parsing tag soup and presenting it as a standardized tree. While the library itself isn't simple, using it is, and being standardized, most non-fringe languages ought to have a library for it by now. It should probably use that, for all the same reasons trying to use XHTML didn't work the first time. XHTML raises the bar on writing correct HTML too far.

Reply on news.ycombinator.com