Hacker News new | ask | show | jobs
by oso2k 3 days ago
I think we could learn from an old (gone?!) Google+ post from Ian Hickson on what could possibly replace HTML but a lot of the criteria applies to Web/Internet as a whole (https://www.sitepoint.com/will-html-ever-be-replaced/).

   Ian Hickson (“Hixie” — WHATWG specification editor, CSS2.1 co-editor and Google’s W3C representative) recently published an interesting post on Google+. He’s occasionally contacted by people suggesting a better alternative to HTML but, in all cases, none have come close. Ian states that any technology would need to satisfy at least five objectives to displace existing web technologies:

   Be devoid of licensing requirements.
   Be vendor-neutral and accept input from everyone.
   Be device and media-neutral; it should work on PCs, TVs, mobiles, tablets, screen readers and any future hardware.
   Be content-neutral and not restrict itself to types of document or application.
   Be radically better than the existing web in every way; faster, more usable, more features, easier to develop, easier to monetize, etc.


   HTML can fail objectives two and three. Technologies such as XHTML2 and XForms only satisfied one and three. Java and Flash struggle in all areas — and I’d also add Google’s Dart to that list.


Maybe this all means there’s a place on the net for gopher, Gemini protocol, or tilde.town or ssh BBSes?
11 comments

> Java and Flash struggle in all areas

Worth noting that Flash did succeed: It was widely used across the web and installed by enough web users that sites could usually assume it was available (though it was considerate to provide fallback content) - that even though it needed a separate installation step!

It took a conscious effort by browser vendors and Adobe to kill it and replace it with other technologies. Maybe for good reasons, but it was definitely not a "free market" development.

I also find the list a bit weird and even hypocritical in places, as, like you say, HTML itself doesn't pass all criteria.

I'd also question other points for the general usefulness as an alternative: Why does an alternative tech necessarily have to accept input from everyone? Not even open source projects do that.

Also, why does it have to be content-neutral and have to support any kind of application? Pre-web technologies generally were "host neutral" - they let you connect to any host that supported the protocol - but the protocol usually had very well-defined application semantics. It seems instead of trying to "boil the ocean", a better way would be to focus on specific domains that could benefit from alternative technologies the most.

Be device and media-neutral: Just to note, Apple only allows single-purpose apps and points to Safari for everything else. They literally forbid anyone from trying to promote any "alternative web" unless they have a say in it.

(Not quite sure about the Play Store right now, but they likely do something similar)

So taken strictly, thay point would be a nonstarter unless you already have connection to the higher-ups of current Big Tech companies.

Flash succeeding is subjective. There were many who were hostile to Flash (and Java) for a long time. I actively disabled the Flash plugin except when necessary.

HTML not passing the criteria doesn't negate it from being the current leading technology. All it indicates is that there could be a technology that does more (most) of these things better. And, it sets a certain benchmark for the next technology to aspire to.

I think accepting input from anyone is a resiliency feature. Imagine if only Governments drove the Web? Or Multi-national Megacorps? Billionaires? Choice and freedom helps to democratize and enable usage by participants who are diadvantaged.

Content-neutrality is experiential. That is to say, gopher is well known to be more organizationally efficient at transimitting data than http. However, it was primarily aimed at text transmission and was very poor at supporting applications (like banking, commerce sites or email). These were huge boons to the current Web.

> Flash succeeding is subjective. There were many who were hostile to Flash (and Java) for a long time. I actively disabled the Flash plugin except when necessary.

I would define "succeeding" as "having overcome the chicken/egg problem, having a wide enough support as to be practically usable as infrastructure and enough content/use that it is relevant", regardless of how well liked a technology is.

E.g. I think JavaScript very clearly succeeded on the web, even though many people still turn it off and there are a lot of good reasons to. By that logic I think Flash had succeeded as well.

> Maybe this all means there’s a place on the net for gopher, Gemini protocol, or tilde.town or ssh BBSes?

All of those fail #5 for sure. And that's one of the most important points to bring in users IMO.

We all (hopefully) know the world would be a better place with less JS but you can't put the genie back in the bottle.

Seems like the whole "no tracking, no targeted advertisements" is a great feature of Gopher & Gemini. BBSes do tracking but it seems rarely used for advertisement its more distributed anyway so if you don't like a BBS you can move to the next one connected to the same messaging networks.

Then there is also the communities, increased accessibility (it's just text) and the more structured nature of the "sites" which may be a feature.

So I would argue that there is definitely some benefits (for the user) to those alternative protocols.

Part of #5, "easy to monetize" leads inevitably to "easy to enshittify". I think this is a point that's not generally well enough understood. If a platform emphasizes monetization, its early adopters will all be grifters and it will provide no benefit to anyone else (cf blockchain).

Gemini and Gopher fail #4 because they aren't application platforms. But I think we probably need to step back and rethink the "deliver sandboxed application that you run automatically" use case. If we really want to still do that, we might want to design something for that purpose from the start. But we might also come to the conclusion that it's fundamentally not a good idea.

I'd presume we're almost all using the Web primarily on some employer's dime (except where we are self-employed but it still applies). Prior to the Web 1.0, I remember interacting with people/managers that discouraged reading email or news or forums or other casual/non-work uses of the Web. I remember articles about employers allowing their programmers to read their email "up to" 2 hours per day. Now we're expected to have rapid response/access to email, slack, SMS, etc.

I believe this is because the commercialization/monetization of Web usage is beneficial to commercial entities. If that isn't possible, then the few who build the Web aren't able to build it in the first place. It's akin OSS and concepts of commercialization in the GPL. You can't create equity if there is no method to transfer value.

#5 is entirely subjective and IMO impossible to fully satisfy as the different sub-clauses conflict.
> “…you can't put the genie back in the bottle.”

Not for nothing, if you’re “building a new internet” you can do whatever you wish.

You fail criterion four: you're limiting what kinds of documents and applications can be developed.
I actually prefer if whatever comes next does not include #5. I'd rather Project Gemini stay the way it is versus every website trying to browse my local storage, troll my localhost sockets, and use any scripting, to be honest. For me, personally, as my own choice, HTML+CSS and no scripting, especially third party scripting, is my kind of WWW replacement.

And this might be unpopular here, but monetizing the 'Net (advertising) is what got us in this Dystopian Digital environment in the first place.

I agree. It's also the evil that created the need and improvements like SSL/TLS, ssh, gzip, bzip2, lz4, Linux, etc. and so many other worthwhile innovations.
"We all (hopefully) know the world would be a better place with less JS but you can't put the genie back in the bottle."

I don't know that.

I suspect you hate javascript because so many ads and tracking software is written with it? Replace JS with something better and the ads will just be written in that.

Otherwise JS .. works and is simple. And compiling any language to wasm very doable nowdays. What would be the alternative?

(Personally I would like to see TS native in the browser)

"works and is simple"? You can argue JS works by definition because it is what people use, but it is far from simple -- JS and C++ are basically the only two programming languages where books plead with you not to use all their features but use a more maintainable subset.
It is simple as in people use succesfully javascript who have no idea what programming is.
Reasons vary per person but personally it's more about bloat. JS as it's used today is very different compared to its initial use case. We build entire applications in JS now, which is cool, but we do this by treating JS as a build target. The code we write is not executed as-is by the browser, it is transpiled and bundled up first. It's way too late to change now but I'd prefer something that embraced application development so that you don't need to pull in React/Vue/whatever and do all of this. Something more opinionated like what we use for native apps, but with the flexibility of HTML+CSS.
I mainly hate JS because when I go on the web I want to view documents with maybe simple forms for interaction and not complex applications. It's not the implementation that's the problem but giving websites compute capability without explicit permission.
The original blog post was migrated back to my blog when Google+ shut down: https://ln.hixie.ch/?start=1344621190&count=1
Thanks so much. It also managed to be captured by IA as I've just noted:

<https://news.ycombinator.com/item?id=48471296>

The archived copy includes comments, which are dropped from your blog version.

> Ian Hickson (“Hixie” — WHATWG specification editor, CSS2.1 co-editor and Google’s W3C representative)

How long after this post did AMP come out? Three years?

FWIW, while I represented Google in the HTML working group (for a few years; it was a complicated relationship), my work on HTML at Google was primarily done via the WHATWG.

I was not involved with AMP's development at any point that I recall.

Thanks for the response! I had a feeling that AMP came from some other part of Google not too concerned about open standards.
Point #5 seems near impossible and even furthermore undesirable. Unless we are envisioning an application with all the characteristics of a web browser, but using different layout languages.
Two is impossible unless you want to be overrun by spam. Three and four are incompatible. Five is not a real criterion, it's a pipe dream.
Maybe he overlooked a requirement because it’s so obvious:

Be human readable

Interesting link! I haven't heard of him, but I didn't have a new protocol in mind per se, since there are many old ones that are still good. But I would have removed the :// from http:// since even Tim Berners-Lee admitted that wasn't needed. I think HTML5 was an improvement from Flash, but there's a lot in the old web, like Xerox Star that had a smooth resolution in the files. Something like LaTeX..
I first heard of him via "Towards a Modern Web Stack (Ian 'Hixie' Hickson)" on HN [0]. Quite interesting. Note that the submission link is broken, the google doc link is added below [1].

[0] https://news.ycombinator.com/item?id=34612696

[1] https://docs.google.com/document/d/1peUSMsvFGvqD5yKh3GprskLC...

And that concept was bonkers, proof conclusive that he had lost the plot—if his involvement with and endorsement of canvas-only Flutter wasn’t proof enough—and should be ignored completely until he comes to his senses.

The obvious benchmark would be: can you implement an HTML/CSS/JS browser inside this environment and have it behave identically to the browser’s own HTML/CSS/JS? And the answer is: not a chance. WASM + WebGPU + ARIA + WebHID is simply not enough. Browsers provide a lot of functionality in ways that web content cannot see or interact with. Some of it could be mapped, other parts of it never can be, for security/privacy reasons. And the more you want to map, the bigger your spec gets, until you’ve added every diverse feature from every OS to the web’s API surface—and then you stop browsers from adding new functionality, too.

Some examples of things that can’t be implemented in web content (most fundamentally, one or two merely currently): Native text rendering in this WebGPU world. Links with all their functionality. Native font preferences. Text selection and its interactions with native platform functionality (including things like context menus). Native scrolling behaviour. The browser as a compositor (important for things like scrolling and video performance). Browser extensions (the user agency part of that first scathing comment).

The things you list that couldn't be implemented in such an environment are a mix of two things, first, things that browsers are specifically designed to _prevent_ a web page from doing, e.g. to avoid leaking privacy, and second, things that absolutely should be possible in that environment, because if they're not, then the environment isn't yet complete.

But in practice I don't think either is especially critical. You can already do pretty much what I suggested just by running the Wasm code against WebGL in a stub HTML page; it hasn't stopped people from creating such things (e.g. Google Docs, Figma, Flutter, etc). The core thing I proposed was allowing the inversion of the architecture so that the Wasm code could be a top-level resource the same way text/html and application/pdf are today. Sure, it could be improved in time by allowing some of the things you list, but that doesn't mean it wouldn't be useful today. The perfect is the enemy of the good, and all that.

Your concept is an extension of what I call the pure-canvas approach. Less bad than current pure-canvas, but a lot of the problems of pure-canvas will persist.

Google Docs is not pure-canvas. If it were, it would be horrible. As it is, it’s… meh, fine I guess, merely somewhat worse than before it started using canvas at all (incorrect keyboard behaviours, worse performance, terrible latency and jitter, though still not as bad as whatever Microsoft call their version of Word that runs in a web browser).

Figma only uses canvas for its canvas, which pretty obviously should indeed be canvas; all UI is DOM, and it would be much worse if it were not.

In a web browser, Flutter is horrible. I loathe, detest and abominate it with vitriol befitting sulphuric acid.

(I’ve written about all of these before. https://news.ycombinator.com/item?id=42253177 is a fair starting point.)

I've written about it before too :-) https://news.ycombinator.com/item?id=34622514
I’d say Markdown meets every one of those criteria except “more features” (which is a feature IMO) and “easier to monetise” (which is another feature. :D )
You mention it fails number 5, but I think Markdown also fails number 4. It’s pretty restrictive with the types of documents it can create. It’s HTML and traditional web technologies that gives it the illusion of flexibility.

To be displayed in a pleasing way to most humans, it’s also rendered as HTML, usually with some kind of styling. In a world without HTML, what is Markdown going to use?

LaTeX? That's actually the primary use case I've seen for markdown -- to write papers/presentations/code notebooks in markdown that are then turned into LaTeX for typesetting.
Sorry, I meant one of the early X-Window predecessors from the Alto era- I don't remember which one(s), but it had a pixel perfect rendering aspect that appeared at least much lower level and the GUI used far less memory. The most recent one that resembled that is X11R1, which I have tested on a VM linux image from ~2005, called Xwoaf.

https://en.wikipedia.org/wiki/X_Window_System#History I recall some pdfs of the Xeroc PARC showed more info on it.

Edit: I might have confused LaTex with https://en.wikipedia.org/wiki/NeXTSTEP. I think it was more efficient in handling data, but then again, platforms age whenever a new application needs more memory, so they got abandoned because it was more efficient to bundle it into something like Wayland...

Possibly Interpress, a precursor to PostScript.

Otherwise the Alto used Bravo and Gypsy for WYSIWYG typesetting:

<https://en.wikipedia.org/wiki/Xerox_Alto>

Yes, that's it- Interpress/PostScript. I remember Forth used it. There's something about the typesetting that I love and can't figure out. But I notice it, even on old monitors. Wonderful stuff. I really like the DTSN displays too: https://retro.swarm.cz/20170902/1143/
Ian Hickson's original post lives on the Internet Archive's Wayback Machine here:

<https://web.archive.org/web/20130913091125/https://plus.goog...>

Raw URL:

  https://web.archive.org/web/20130913091125/https://plus.google.com/107429617152575897589/posts/SiLdNL9MsFw
For those wondering how I found this ...

There was an attempt to preserve G+ content, and however heroic it was far less successful than I'd have liked.

The two key parts are the UserID and the PostID. That's "107429617152575897589" and "SiLdNL9MsFw" respectively.

I found Ian's G+ UserID from an archive of his homepage, here:

<https://web.archive.org/web/20120214010013/http://ian.hixie....>

That links to:

  https://web.archive.org/web/20120214010013/http://ian.hixie.ch/+
Which redirects to

  https://plus.google.com/107429617152575897589/posts
And those paying close attention will of course immediately recognise the highly distinguishing 21 digit string "107429617152575897589", a/k/a Ian Hickson's G+ userID / UUID.

Google+ placed all posts under the '/posts' URL segment, and has a wildcard syntax for searching for all captures under a given URL:

  https://web.archive.org/web/*/https://plus.google.com/107429617152575897589/posts/*
Which you can access directly here: <https://web.archive.org/web/*/https://plus.google.com/107429...>.

Going through those individually, I eventually turned up the original link.

It's also possible to see the first 2-ish 'graphs of the post by looking at captures of Ian's G+ profile page. Unfortunately, there is no direct link to the full post from this view, though if you view source you can find the post-ID, notably in the JSON data at the top of the post following "AF_initDataCallback". I'd turned it up by going sequentially through the captured posts above however, and only discovered that the postID is actually on the Profile page afterwards. The two (partial) 'graphs begin with:

Occasionally, people e-mail me to say something along the lines of "I've come up with something to replace HTML!"...

<https://web.archive.org/web/20121112102441/https://plus.goog...>

Oh, and the Internet Archive is one of the few parts of the Internet which do not precisely suck. If you can send them love, or better, money, please do.

Thanks for finding this!
> Maybe this all means there’s a place on the net for gopher, Gemini protocol, or tilde.town or ssh BBSes?

By your question (and Betteridge's law of headlines): no, as they fail at least (2), (4) and (5).

> as they fail at least (2), (4) and (5).

Can you explain how you see that they fail 2 and 4?

To me it seems with Gemini, Gopher and BBSes (tilde.town is html so let's skip that) they can serve any type of content they want and you can probably already connect to it and retrieve something readable.