Hacker News Reader

HTML is ok. Get rid of js. Rewrite DOM stuff, render HTML as more efficient graph mechanism (e.g. virtualized, can have 100k nodes)

> Typing something (URL etc) and accessing the latest version of an app, with latest content, and knowing that everyone else in the world is getting the same thing.

This is why I prefer managing the software I use myself. Upon first receiving a new version of a web app, I have never tried it or had a chance to review the changes to figure out how they affect my workflow. With software installed natively with my package manager, I have a chance to review everything and update only the software I want to update.

> • Linking to content within apps.

No, all major operating systems support scheme handlers.

> No, all major operating systems support scheme handlers.

No, you know that rarely works out in practice and is not what I meant.

Take this example: https://news.ycombinator.com/reply?id=32814887&goto=threads%...

Or: https://old.reddit.com/r/Gloomhaven/top/?t=month

But can we do something like this? file://Users/Me/Pictures/?filter=cats&sort=new

Or this? pixelmator.app/lastdocument/thumbnail

> No, you know that rarely works out in practice and is not what I meant.

No, as far as I know it works very well in practice and thus I don't know what you mean.

Take this example. Steam has registered as a handler for the steam scheme on my PC. Any other app can open e.g. steam://store/655480 to link to a game in Steam. It's up to the scheme handler how the URI works. Steam supports a bunch of different actions and forms of deep linking via the steam scheme.

Here's what Slack supports via its scheme handler, for example: https://api.slack.com/reference/deep-linking#client

It's exactly what you're asking for, so I have no idea what compelled you to immediately dismiss what I was saying.

If you control the application/backend then I don't see why you would need HTTP(S) URLs to get the right content.

Android actually allows registering HTTP(S) URLs with certain domains and wildcards (https://developer.android.com/training/app-links). Not a big fan of this "validate a token through Google to skip the app choice dialogue" approach but luckily Firefox always prompts before opening a registered app link anyway. iOS supports a similar feature. It's up to browsers on other platforms to implement their own support if this is something one would want to add to the browser.

Web 2.0/3.0 was a mistake.

https://idlewords.com/talks/website_obesity.htm

You can't "execute ANY content natively on any platform".

It is true that the things that you list are the actual problems, and there are many others, too. The modern WWW is a too messy design, and additionally to that, web pages and web browsers are also badly designed.

I had partially written specification of "VM3", which hopefully will be an improvement for cross-platform application programs. There is no CSS, nor Unicode (well, technically you can include Unicode text fragments, but it is discouraged), and it is independent of protocols (so you can use with local files, DVD, HTTP(S), Gemini, etc, but none of these are required nor is it limited to any specific kind). All I/O must be done using extensions (identified by UUID), which require a specification; it also has a mechanism for polyfills which is (in my opinion) superior than that of WWW. Furthermore, is intended better for the end user controls/customizations. Also, some of the internal design decisions I have done differently due to things that I think are better than what are currently done (e.g. how linking works, and many features use a binary format, etc). Extension declarations can also be linked with each other, too (note that this is linking the interface, not the implementation; the implementation is deliberately not specified by VM3).

Some VM designs are good for interpreted, and some are good for JIT, but I think that to make implementations competitive, and improve efficiency, it may be better for the design to be good for both, so that is what I have tried to do. For example, there are restrictions on how branch addresses can be derived (e.g. one feature is that you cannot store branch addresses in general registers).

VM3 cannot "execute ANY content natively on any platform" (and nor can anything else), but my intention is to make something better than existing systems.

Things similar to TerseNet, and other possible different things people will want to make, some of them may be possible as specific subsets of VM3. An implementation of VM3 can then support specific subsets or can have full capabilities (preferably, configurable by end user).

And we could make it rely on Postscript and call it "NeWS" :) https://en.wikipedia.org/wiki/NeWS

On the one hand, yes I like native apps. On the other, I don't want to have each site install its native app and have one more trojan/tracker to worry about.

I guess SPAs and WASM kind of give you that within the security of the browser's sandbox.

20 years ago I thought flash would take over. Shows you what I know.

> Ditch HTML/JS/etc. altogether and invent a new way to create, deliver, and execute ANY content natively on any platform

Sounds like you want WebAssembly.

That's just more turd polish.

Obligatory XKCD link: https://xkcd.com/927/

Variety is good. New browsers with new engines are good (though I think an announcement like this without any pre-built binaries for normies to download is a bit premature). I say this as a web developer who well remembers the IE6 struggles of yesteryear - but also fears the Chrome monoculture of tomorrow. UI differences between web pages are annoying, especially when they break things like scrolling and selecting, I agree, but the answer isn't to creatively flatten what the web can be, Big Brother-style.

As for Instagram, well, perhaps you should consider making a back-up of your own photos before you entrust them to a service owned by a company whose sole profit model is taking your content and putting ads next to it.