A clean start for the web (2020)

> I just want to read text based content without downloading google analytics + 20 other trackers, 5 java script libraries, 7 frameworks of some kind and 20 ads. It's inefficient.

I agree. I have JavaScripts disabled, but it may still try to download CSS, pictures, and other stuff, and might try to hide the document, etc.

I dislike FTP and think that it is not a very good protocol. (There is one advantage of FTP over HTTP, which is that it has directory listings, although you could also do with HTTP possibly by a new file format (e.g. application/httpdirlist) for directory listings.)

You can serve other file formats (including text/gemini) over HTTP. Although I could manage to make the web browser I have to support text/gemini files over HTTP (and local files), this isn't commonly done, and the protocol does not support file format polyfills (although I have a proposal that can make it work).

However, that isn't good enough if you want to serve NNTP or IRC or Telnet or something else like that. If I want to serve discussion forums, I will want NNTP. If I want fast communications, I will want IRC. There may be other possible protocols too. We shouldn't force everything into HTTP(S); it doesn't fit properly. (I do have a NNTP server, as well as HTTP and Gopher.)

> A blog post can be just a markdown file. Want to read it? Use a markdown viewer (from the application web).

I had a idea that is a bit similar, which is a Interpreter header; if the MIME type is not understood by the client software, it can download an interpreter (i.e. a polyfill) (written in HTML or WebAssembly, although your own language might also be a possible alternative); if the client software does understand the format (or the end user already has their own implementation installed, possibly one that they wrote by themself), then it will use that one instead.

> You can hardcode/bake the content into it (like we do today).

While you can, it may make sense to be a separate block so that you can also use the data separately.

> An "URL" could instead be something like an application+datasource pair. The applications are automatically hashed and signed and you can provably verify they haven't changed if you want to. When you request an application to the network, you'll download it from the closest peer (maybe from multiple peers at the same time!). Since it's hashed and signed you only have to trust the signer.

That is a interesting idea, and could work (although making the URL longer, probably). Although it may be useful to add additional arguments too, like command-line arguments/switches (so an implementation could be launched by command-line arguments, too).

This would easily allow an end user to substitute their own application implementation too (by changing the "application" part of the URL), which is also an advantage, and can have a rewrite system to do their own. If it has a hash then you could also cache the application file if wanted (and if you do not have a working internet connection, even to operate on local files that the user gives permission to access), in addition to overriding it with your own implementation, too.

> In fact I've started exploring what that language could look like: https://flame.run/

I like this idea and a few days ago had started to make up the design of something called "VM3" (the name might or might not change in future), which has some similar goals and ideas. However, there are many differences too. VM3 is a binary format (designed to be suitable for both interpreter and for JIT, an static analysis; e.g. there is no way to treat a number from a general register as a return address or vice versa, other than using a static lookup table which is specifically designated as containing program addresses), and all I/O (including the equivalent of JavaScript's Date and Math.random) must be done using extensions. Extensions must be statically declared (cannot be dynamically declared), and an implementation must allow the end user to manage and override them too; polyfills (both included and installed separately) are also possible, too. VM3 can be used with any protocols (HTTP(S), Gemini, IPFS, etc) and any storage media (CD, DVD, etc). (VM3 is also not limited to a specific kind of user interface; you can have command-line, GUI, pipes, etc.)

Someone else also had wrote some ideas about TerseNet. Some ideas of VM3 are similar, and the capabilities of TerseNet could be implemented as a subset of VM3. Multiple implementation types are possible, and possibility of static text, and applications that are only lauched by the user, also has with TerseNet and VM3.

However, unlike Flame which it seem your idea to combine effectively HTML+CSS+JS together, TerseNet and VM3 do something a bit different: parts of HTML (the documentation format) are one format, and other parts of HTML+CSS+JS are the other format; they can easily be separated and work independently.

Your statement doesnt resemble any gui toolkits Im familiar with. Not Flutter, not Swift, not Gnome, nothing. The DOM closely resembles other ui construction systems & has similar ideas lile event handling.

And then the pretense that developers are the only thing that matter. The web is vastly better than apps because of the dom, because our systems are in a malleable hypermedia that ysers can modify eith userscripts, userstyles, extensions, eith whatever manner of accessible browser/user agent they please.

It's such sad thing to hear people advocating so strongly for the winnowing od possibility. Leaving all responsibility & all power with the app developer sounds perverse to me, sick, unworthy of being called a part of the internet. Not only does "just need something to draw on" not reflect the needs of developers, it represents an mortal threat to user agency.

> I think supporting everything but javascript for the "document browser" would automatically enable a ton of websites and make it easier for creators and consumers to use the tools and languages they already understand.

There are some merits for that, but I think that is both excessive and deficient at the same time.

> https://erock.lists.sh/browser-monopoly

I think that these are valid points, which I have some comments relating to.

> Support HTML 5, CSS 3, HTTP, TLS

You can add other file formats and protocols too, such as Gemini, Gopher, and possibly Markdown too.

> Maybe remove website specific styling altogether and instead design a consistent design that optimizes navigation and readability.

That is what I think too; even the HTML with no CSS, will be OK. Perhaps let the end user to specify colours, fonts, etc.

> Allowing the user to query for information and have that data displayed without full page reloads (AJAX)

For data-oriented stuff, you could also have such things like , you can just get the data and use your own software to display it.

> I want a minimal, modern set of browsing tools where I don't have to make any sacrifices between usability and compliance with the standards.

Yes, I think so, too. Splitting all of the components separately is one start, I suppose (although it is not good enough by itself) (a C program can then be written to tie them together, and this can be changed as needed, including to add/remove components) (this is like reversing core and extensions the other way, so that e.g. HTML and HTTP are now extensions instead of core). However, half of the standards are I don't want quite compliance and should deliberately implement them in a better way than what they say.