Hacker News Reader

As someone still familiarizing himself with all the esoteric arcana that makes up modern web development, I'm always open to reading what-ifs. The modern web to me is WTF in a lot of ways. I remember reading an article on HN about the history of CSS that was quite fascinating. I have nothing against the author's article. It is pretty interesting and I even find his other blog posts quite illuminating to read.

IMO what's rubbing people the wrong way is not his specific points but how he is framing them. It really does not matter how brilliant his alternative is ... it's clear that HTTP is firmly entrenched and the network effects run so deep, it would require a miracle to really "start fresh". I'd really like to be proven wrong though.

I'm open to what ifs, but I've seen enough critiques of pretty basic stuff that he's got wrong to let me know that he doesn't really understand the web as well as he thinks he does, and therefore his criticism is pretty biased, and misleading, and unlikely to produce any real solutions.

Yea? Do you mind sharing the basic stuff that he's gotten wrong? Because I learned a few things and found the article to be well researched (but what do I know ...)

https://www.reddit.com/r/programming/comments/71y6dy/its_tim...

Douglas Crockford, who understands the web, making similar points:

https://youtu.be/fQWRoLf7bns

On the one hand, it's a common sentiment that we should just be grateful for how great things are today. See, for example, the famous comedy routine "Everything is Amazing and Nobody is Happy" by Louis CK [1].

On the other hand, would we have cell phones, ubiquitous credit card-capable point of sale machines, and airplanes with in-flight Internet, if people hadn't dared to dream that things could be better?

Yes, children can learn basic HTML, CSS, and JavaScript. But what if we had a platform that was easy to learn and not full of security pitfalls? One can dream. And the OP has some concrete suggestions for how to get there.

And sometimes, you have to drop existing systems, or aspects of them, to get to that better future. For example, on a cell phone, you don't actually get a dial tone and send DTMF in real time, as one did on a touch-tone landline phone. (This reminds me of jacquesm's contrast of DTMF and GSM [2], posted in the comment thread for part 1.)

[1]: https://www.youtube.com/watch?v=q8LaT5Iiwo4

[2]: https://news.ycombinator.com/item?id=15322196

It's not that I'm advocating being a luddite, stopping progress, or uncritically accepting the web, it's just that the most useful form of idealism (at least as far as I can see it), is realistic idealism because it's the most likely to be implemented and affect change.

It's just hard for me to understand how realistically a clean room implementation of NewWeb is gonna beat out something that's already had billions poured into it and even today is progressing. The much easier step is figuring out how to make the web better, but it isn't sexy. No matter what you come up with is gonna be imperfect and criticized and have holdouts anyway.

Yes, on reflection, I agree with you about that. After all, cell phones (my main analogy from the Louis CK sketch) are still compatible with the PSTN.

> Why is that not good enough?

I don't think "why isn't what we have good enough" has ever been the mantra of pioneers in their field, but ok

I don't get why you seem to take such exception to the stance that "we can do better". We can always do better.

Do you imagine 500 years from now the same technologies and web models in play as today? Even 100 years from now? Do you really think they are the pinnacle of the web.

If you really do, I'd sincerely love to read your counter blog post on this, as I reflect on this quite a bit and have generally always come to the conclusion that there's a long way to go.

> This is like sitting there in 1600 and saying that the printing press sucks because it doesn't encrypt documents

If that's so, isn't your comment akin to saying "why isn't the printing press good enough for you"? :)

> Why is that not good enough? We really so ungrateful to believe that reinventing everything is the right step now?

Just about every feature you list (apart from the distribution, got to give the web that) is stuff that we could do 20 years ago, so yes, I'm ungrateful that we've traveled so far but still gone no where, backwards in many ways.

> Children can learn HTML and CSS, modern web frameworks make it so that you can build great stuff on the back or frontend in a matter of days or weeks

Kids were doing that with basic since the 70's or 80's.

make me a p2p app that runs in a browser that has acceptable performance on mobile. I want soft real-time sync between n users with no central router or global data structures. I want to share arbitrary blobs up to 1MiB or so and stream larger data in with bit torrent. my traffic should be anonymized. I should also be able to automatically replicate my data across all of my of devices.

Perhaps go back to a sandbox VM model where you access an URI that's a program with attached data objects. Maybe have a standard for updatable "peripheral" modules, but provide standard sandboxed storage, display, messaging, & streaming APIs to start.

yes! this is actually something that i'm slowly hacking away at... and you've described the architecture pretty well!

https://www.heropunch.io/roadmap.html#finally-relax

site still has a few bugs (it isn't officially "out" yet, but its topical so why not).

the sandbox VM is a docker container with a standard interface for storage (relax/vfs), display (wayland), messaging (relax/pub).

vfs supports torrents and partial replication, so you're pretty much always streaming. we try to cache things to keep it fast, but different systems have different storage limits so we have to assume that we're always going to be fetching from the network.

applications can actually consist of multiple docker containers with different capabilities that can be scheduled on any host that has been paired with your user key. these can be updated individually or in tandem.

docker registries have to be explicitly trusted before you can run anything. we realize that docker isn't a security boundary by default, but we are attacking that problem from a few angles.

we implement a lot of this functionality as docker engine plugins. so you get anon overlay routing and distributed storage transparently from the perspective of the application.

That sounds pretty reasonable and interesting for prototyping, but also possibly heavy weight to run as a "browser". But I think it's basically what we seem to be moving towards anyway - if we could securely run it, the simplest model of interaction is to just download a program + data and run it.

for "browsing" you'd have a browser app along the lines of patchwork[0], might even be patchwork actually since we use the same core tech. i don't think they need to be the same thing, personally.

[0]: https://github.com/ssbc/patchwork/releases