Earlier quoted context omitted.
Well, yes, lower level protocols are harder to implement and deploy because they require new hardware - but I'm not sure how are they relevant in a discussion about higher level protocols that are in software and build on the Internet Protocol?
The details of the complexities change, but the complexities are still there. You still need adoption by multiple parties, you still need to solve the application level challenges that HTTP solves (including, most importantly, secure communication over an open network), and you still need tooling to understand the protocol in flight, including its failure modes, to debug an application built atop the protocol. And yo…
W3C recommends WebAssembly
331–340 of 350 posts
Re: W3C recommends WebAssembly
#332Earlier quoted context omitted.
The details of the complexities change, but the complexities are still there. You still need adoption by multiple parties, you still need to solve the application level challenges that HTTP solves (including, most importantly, secure communication over an open network), and you still need tooling to understand the protocol in flight, including its failure modes, to debug an application built atop the protocol. And yo…
I can only be suspicious about too much complexity and stacking in what is essentially infrastructure - that should be reliable, and therefore have minimum complexity. Any initial opportunity costs are tiny when these protocols are used by billions of devices !
Nobody's stopping anyone from building new protocols... Except, of course, the fact that nobody wants to adopt a new protocol. But if someone does come up with an indispensable alternative to HTTP(s), it should find traction, right?
Re: W3C recommends WebAssembly
#333Earlier quoted context omitted.
I can only be suspicious about too much complexity and stacking in what is essentially infrastructure - that should be reliable, and therefore have minimum complexity. Any initial opportunity costs are tiny when these protocols are used by billions of devices !
But they aren't. The vast majority of novel protocols never see a billion adopters. There are a handful that have; the email protocols are one, HTTP is another. Nobody's stopping anyone from building new protocols... Except, of course, the fact that nobody wants to adopt a new protocol. But if someone does come up with an indispensable alternative to HTTP(s), it should find traction, right?
Re: W3C recommends WebAssembly
#334Earlier quoted context omitted.
But they aren't. The vast majority of novel protocols never see a billion adopters. There are a handful that have; the email protocols are one, HTTP is another. Nobody's stopping anyone from building new protocols... Except, of course, the fact that nobody wants to adopt a new protocol. But if someone does come up with an indispensable alternative to HTTP(s), it should find traction, right?
Google and Facebook were very glad to "adopt" XMPP : https://salibra.com/p/the-death-of-jabber-8ea395e82f5b
Re: W3C recommends WebAssembly
#335Earlier quoted context omitted.
Google and Facebook were very glad to "adopt" XMPP : https://salibra.com/p/the-death-of-jabber-8ea395e82f5b
XMPP is an excellent example of why existing flexible protocols push out novel protocols. When Google and Facebook wanted to improve the user experience of their XMPP clients, they encountered roadblocks in the fundamental design of the protocol itself. They finally reached a point where exiting the protocol was easier than improving it.
Re: W3C recommends WebAssembly
#336Earlier quoted context omitted.
Even if we don't lose the HTML-centered model, we are probably going to lose control of our browsers. Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser. The "inner browser" won't have content filtering, privacy controls, DOM inspector, or a Javascript debugger (for the Javascript engine running on the "inner browser") that you can inter…
This already happens. See Figma: https://www.figma.com/blog/webassembly-cut-figmas-load-time-... To be honest, it's a unique property of the web for you to be able to easily read the source; however, users of other platforms such as Qt are not expected to read the source. The web is simply moving in the direction of all other UI platforms, so I don't quite understand the outrage. Yes, it sucks, but it'll make apps fa…
Also, arguments of the form of "X is unique, all others are doing the bad thing" are suspicious to me. This would mean we should cherish and preserve X, bringing the good aspect to other platforms, not devolving it into mediocrity or worse.
Re: W3C recommends WebAssembly
#337Earlier quoted context omitted.
95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. Of course HTML for interfaces is more complicated than something like canvas, because it forces you to think about your UX on a deeper level than "this component should be on the left". The point of HTML is that it forces you to build a universal interface that works for e…
>95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. This is a design opinion. I disagree with it. Minimalism is simply a design philosophy just like brutalism or complexity. The underlying mechanisms should be design agnostic. >HTML on its own is a render target. CSS is a completely optional secondary display modifier that…
But the web is not a graphical API and that is precisely the point. The web is a semantic API and its components represent meaning. Devolving to pixels makes drawing graphics easier but it destroys meaning.
When you want to simply draw meaningless graphics, you get an element which represents an element into which you can draw pixels which aren't expected to be meaningfully structured: canvas. What's the problem with rendering into a canvas, again?
And no, HTML not being similar to graphics APIs doesn't count as a downside of canvas being a child object.
> while this is true I wouldn't center the design of a platform on whether or not ad blockers work for it. It is not central to the problem which is the creation of a universal platform that is versatile. Rather it is the implementer of the adblocker who must conform to the platform.
It should most certainly be the center point of this design if you truly want this platform to be universal and versatile, or even usable. It's not like we need to guess how an ad-infested web would look like -- we've experimented with the web of ads, we've seen how horrible it is and the only reason we are still using the web is because we can block those ads.
I'm genuinely surprised how easily some people are to dismiss the openness of the web, surrendering users' freedom in the process, simply for... I'm not sure why actually. I don't understand the argument.
Re: W3C recommends WebAssembly
#338Earlier quoted context omitted.
I feel like your comments on accessibility kind of speak for themselves, and I don't want to rehash the same technical arguments over again. You're not advocating for a bold, artistic world when you talk about engineering things to pointlessly exclude people. You're just advocating for a smaller world with fewer people in it. I do want to mention very quickly that on the subject of books and movies, literally every H…
>You're not advocating for a bold, artistic world when you talk about engineering things to pointlessly exclude people. This world already exists. You're delusional if it doesn't. I use the word cruel, but you must know that cruel = reality. That's all I'm saying. 99% of the world is not designed for deaf people or blind people. There are arbitrary restrictions on certain things but this is reality and it's not going…
It's not a coincidence that this design also increases accessibility -- it encodes the most meaning.
Re: W3C recommends WebAssembly
#339Earlier quoted context omitted.
>95% of the time, if you can't represent your app state as pure text, you're overcomplicating your design and haven't thought enough about your UX. This is a design opinion. I disagree with it. Minimalism is simply a design philosophy just like brutalism or complexity. The underlying mechanisms should be design agnostic. >HTML on its own is a render target. CSS is a completely optional secondary display modifier that…
> Render targets are usually more fundamental with libraries built on top for more specific use cases. It would be better if the web browser world had pixel level render targets with HTML built on top as a library. This is how most graphical APIs work. Rather then what is now, HTML as the render target, and canvas as a child object of HTML. But the web is not a graphical API and that is precisely the point. The web i…
Make the semantic API a library. Or how about seperating semantics from component. Semantics are listed in a single file which can be crawled and only possesses meta data that links to other semantic files. The pixel level API and web crawlers have libraries that can interpret these files. This is a much better design then the adhoc way the web formed.
>What's the problem with rendering into a canvas, again?
It's using low level components as a composition of high level components. The design is backwards and vendor locks people into html. There are other ways to display semantic UI. Html is an arbitrary choice.
> And no, HTML not being similar to graphics APIs doesn't count as a downside of canvas being a child object.
How can you be so sure footed about your argument when you literally say you don't understand the argument later on. You don't understand the argument therefore your entire argument is baseless. Little lesson for you: you need to ask questions and understand before you compose an argument otherwise your wasting time.
>It should most certainly be the center point of this design if you truly want this platform to be universal and versatile, or even usable.
Your saying ad blockers should be the center point of design? You realize that right now in html and css ad blockers aren't the center point of design. An adblock centered design implies something along the lines of replacing the html tag with one that has the word adblock in it. Literally adblockers are designed for the platform not the other way around.
>I'm genuinely surprised how easily some people are to dismiss the openness of the web, surrendering users' freedom in the process, simply for... I'm not sure why actually. I don't understand the argument.
You should of put your declaration of lack of understanding and comprehension in the beginning. That way readers can dismiss your entire argument without first reading it because things need to be understood first before you can make a counter argument to it. Reread my argument until you understand or take some classes at reading comprehension then you'll have what it takes to make an argument.
Honestly let's get a little more meta at what's going on here. Someone has composed a response that is rather rude. The responder dismisses my argument by implying that my arguments are so baseless that he doesn't "understand." Highly offensive. When you play games like this nobody wants to participate in an informed discussion. I'll play his game and say that his lack of understanding makes his whole counter argument ludicrous but literally this argument was over before it even began when the responder decided to be a rude and offensive. If I were the rude responder, I'd just walk away because nobody cares for his opinion anymore.
Re: W3C recommends WebAssembly
#340Earlier quoted context omitted.
>You're not advocating for a bold, artistic world when you talk about engineering things to pointlessly exclude people. This world already exists. You're delusional if it doesn't. I use the word cruel, but you must know that cruel = reality. That's all I'm saying. 99% of the world is not designed for deaf people or blind people. There are arbitrary restrictions on certain things but this is reality and it's not going…
When the other poster said "pointlessly excluding", I understood it to refer to examples such as the deep sea one, where there is an easy and straightforward way to design the page and allows it to fail gracefully. This design doesn't require more engineering effort. In fact, I'd say it's quite the contrary. It's not a coincidence that this design also increases accessibility -- it encodes the most meaning.