Also, the use cases for javascript and webassembly don't overlap enough for one to replace the other in most cases. Javascript is a text-based scripting language you can write in any editor (the sprawling morass that is the current js development ecosystem notwithstanding,) but WASM requires knowing another language and having a compile step, which adds friction and complexity. You can't really replace a language with a bytecode.

It may mean that other languages can be deployed in the browser as easily as javascript, which may or may not be good depending on your point of view.

I personally look forward to the day when Hacker News embeds the Arc runtime as WASM and replaces all of their javascript with Arc code.

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.

Rust on the other hand is doing some genuinely exciting, powerful stuff with allowing WASM to talk to the DOM and allowing native developers to target HTML directly within their apps. Rust's approach is to treat the language like a minimal, drop-in replacement for Javascript that doesn't require you to ship an entire rendering engine alongside it.

It is yet to be seen which approach to web portability is going to win. Obviously I'm rooting for Rust, and I personally think apps that are written using Rust's strategy will nearly always be higher quality than apps written using QT's strategy. But that doesn't necessarily mean that Rust will win, there are a lot of factors at play here. It'll be interesting to see.

But agreed, native apps are definitely coming to the web in some form or another. Funnily, the opposite is also true, since there's been a lot of buzz about using WASM for native sandboxing. I like to think that Gary Bernhardt[0] is pleased about that.

[0]: https://www.destroyallsoftware.com/talks/the-birth-and-death...

A third party that offers a way to run that on their iPad at the cost of a one-time 100MB download will find customers.

archive.org also might find something like it useful. How else are you going to show old sites in 20 year’s time?

We can debate about minified JS if you so desire but its a different debate.

This is all still traditional web development. It's just a way to target other runtimes to a sandbox in the same environment.

Cross-compilation has been a thing for a while now -- WASM is the followup to ASM.js, which was already being used as a compile target for languages like C.

Now, reverse engineering ASM.js is easier than reverse engineering WASM (although ASM.js is still a giant pain). And reverse engineering minified Javascript is even easier -- most competent JS engineers could debug a React project without source maps, even if it took them longer.

But it's not clear to me that WASM makes the process meaningfully harder. As in, you're still going to want to use source maps like you use today, and it'll still be totally possible to figure out what a program is doing without the original source. It'll just be a pain.

And the benefits to the web as an open, language-agnostic platform that can be used for memory-intensive tasks outweigh the downsides of needing to work harder to reverse engineer software.

You real sentence should be "RISC-V instruction set is open, therefor I can see whatever a binaries is doing via the instruction it is executing." Doesn't mean its free, doesn't mean its easy to reverse engineer whatever the binary is doing, but you have everything to do it.

The good parts of the web in terms of debugging is the separation of concerns -- having separate interfaces for CSS, HTML, network requests, and the DOM, and having each of those interfaces be relatively inspectable.

I am a little worried about frameworks that target WASM spitting everything onto a Canvas, bypassing HTML and CSS (coughQt*cought). That would be a substantial loss for the Open web. But I don't lose any sleep over the idea of replacing Javascript.

In contrast, WebAssembly would be a terrible project to implement directly in logic; there are no relative offsets so incrementing an instruct pointer register simply doesn't work, which hardware is very good at. fn calls are referred to by name indexed into a table at the bytecode level, so you're inherently dealing with a level of indirection that would require 'flattening' or inlining the table values to work around before being executed, or, alternatively, you'd have to just bite the bullet and put limits on their size, and eat the cost of the indirection. Similarly, CFG blocks in WASM are represented as literal scoped blocks with nested instructions at the syntax level -- not simple jumps/calls. You need to extract the back/forward edges from the CFG to recover that information and translate it to direct jump operations.

At this point, you are just implementing a compiler, and if you choose to do it in hardware, you are willingly trying to shoot yourself in the foot (or the face), and it will end badly. You're far better off calling a spade a spade and compiling, in software, to a representation that actually can be implemented efficiently in hardware. But you could of course hide this compiler in the firmware to make it "seem" like WebAssembly is the native ISA, and the small surface area of the specification can help ensure you do it safely and correctly. This is probably for the best anyway, because it's dramatically harder to design correct hardware vs correct software.

That's not the problem source maps are meant to solve. They exist to debug transpiled code.

> The source for GNU and Linux is viewable by everyone, which negates the inability to view what is happening inside a binary.

That's not true. It is non-trivial to verify that the binary you received was built with the source code that's openly available. The point of FOSS is that you always have the option to build your own binaries so that you can be 100% certain of what is running on your machine. Most people aren't going to do that, so they need to place their trust on a third party (like whoever built their kernel). FOSS just makes that trust optional instead of mandatory (like it is with something like Windows)

(Example of the day, Parsec; example from yesterday, NVidia's driver-update software :( )

Sounds very "open" to me.

Shhh! Don't tell them!

As for debugging, this is not a particularly hard or fundamental problem. It’s basically solved already.

https://developers.google.com/web/updates/2019/12/webassembl...

And from there it is just the next step to run a base platform like Android user space or a simple runtime like blazor.

In the end wasm is a runtime. There were physical Java Processors and I am pretty sure there will be webassembly processors.

Thanks for dooming us all, hombre. I'm holding you personally responsible when it happens.

In fact I think it may already have. Took a look at a web based learning portal for my niece the other day, and after poking around in devtoolsfound it was pretty similar to what you described.

2. The underlying code of the web's infrastructure is available on a royalty-free basis, and shall remain as such!! There's immense benefit in maintaining this equal-opportunity status-quo.

You don’t need javascript for this. People reverse engineer native binaries all the time. Reversing wasm isn’t much more difficult than minified javascript as my sibling commenter states.

The main challenge is that variable and function names are not available, but minified js is no better in that regard.

Yes, one could say that the Web has "jumped the shark" sometimes after 1997 (took some years), remember the mess when Flash and Java applets were everywhere ? (WebAssembly might be more sleek, but the issue is likely to be the same...)

I guess that multimedia could be part of the Web, but support for basic features like audio/video search is (still!) sorely lacking... (Though I'm pretty sure that the capability has been here for more than a decade.)

With the ability to run arbitrary code comes the loss of a common standard, and therefore the inability to communicate, especially for machines - you might have noticed that you hardly see search engines pulling up results for supposedly "Web"Sites like Facebook or Discord or Twitter ?

All it will take is for ADK to a have button that produces a wasm version of your app.

For better or worse the web never did that work, HTML+CSS+JS is meant to be both a way to make static websites, but also interactive e-shops, but also mail clients, but also videogames, but also ultra-heavy single-page apps like Discord etc...

And that's the greatest power of the web, but I can't see how this state of affair won't lead, one way or the other, towards a more monolithic architecture. Keeping HTML and CSS cleanly separated and JS only for the fancy stuff (but always optional!) is noble but it's a pipe dream when the use cases are so diverse. WebAssembly, or something like it, seems to be clearly the path forward.

Overall I think we should be happy too, at least it's not a closed source blob. Remember how long it took us to get rid of bloody Flash? Actually if Steve Jobs hadn't decided to drop it from iPhones I wouldn't be surprised if it had survived in common use to this day.

This is one place where HTML does not give enough primitives for a quality library-based solution.

Maybe not.

If data binding, dynamic markup, reactivity, etc, were baked into browser we'd save a ton of kbs and CPU cycles.

Getting the JS engine to be fast was a tremendous trouble and you wouldn't want to sink as much engineering power into another runtime that will have a smaller reach than the JS engine.

Rather use that skills to make WASM faster.

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 everyone -- it forces you to sit down and build a human-digestible, pure-text tree that communicates your current application state to users.

HTML on its own is a render target. CSS is a completely optional secondary display modifier that you put on top of that render target.

This is why adblockers work, it's why stuff like Reader View works in Firefox. Because it turns out that forcing interfaces to be pure-text has substantial benefits for end-users. Try building something like a UI-level adblocker for a native app. You can't do it -- it's impossible.

I don't know much about web assembly, but x86, which is much more complicated with thousands of instructions, has been successfully reverse engineered basically since forever. There are decompilers that can automatically reconstruct source code in C or C++ from a binary blob.

Compared to javascript, the best you can hope for is to just format the code so its in a more readable structure, but that isn't going to untangle purposefully obfuscated logic. Add to that the fact that even a regular javascript program is an untyped mess, and it becomes clear that anyone specifically trying to confuse readers will have a very easy time of doing so. There are a lot of messy things you can do in javascript, almost COBOL levels of messy.

Also, I'm curious about this

> but as someone who ran a small business in high school that usually involved reverse engineering obfuscated Javascript,

What type of clients paid you to reverse engineer obfuscated javascript? Malware research? Something else?

JS can do better, and it will if other languages can do things it does now.

I'm not talking about the sandboxed browser being able to "clear your hard drive", etc. I'm talking about users having no real agency when it comes to controlling the presentation of websites. (Sure, it's code running on your computer. You're free to attach a debugger to step thru native code that runs a VM that runs a nested VM that's ultimately running the code you'd actually like to influence. Let me know how that goes for you.)

Have you seen JSLinux[1]?

[1] - https://bellard.org/jslinux/

Have you not worked in tech long? One of my 'favourite' things about one tech stack I once worked on was that someone decided to implement a file-system inside the a database that is stored on the file system. Even better, the database itself effectively just reimplements the features of a database.

So we have a file-system storing a database that exposes a completely different database that holds a file system.

What does a "separate field" have to do with anything? Now a site is or isn't part of the web based on how Google formats them in their search listings? These sites serve media meta-tags specifically so that Google will index them, they depend on SEO. Find someone famous with a Twitter or Facebook presence and search their username and whatever public information they have, including excerpts of recent posts, will probably show up.

>Browsers can do a lot of things these days that are not part of the Web : display pdfs, ftp folders, rtsp streams...

But your assertion was that websites which use javascript to render text, applets or flash weren't part of the web, but somehow just part of "the internet," despite everything on the web also being on the internet.

We seem to fundamentally disagree on what the web is - it seems like your definition is more aesthetic than technical, and that you believe only static HTML pages should be considered part of the web.

But according to at least the w3C's Help and FAQ page[0], the difference between the internet and the web is:

    The Web, on the other hand, is defined in W3C's 
    Architecture of the World Wide Web, Volume I as 
    follows: "The World Wide Web (WWW, or simply Web) 
    is an information space in which the items of interest, 
    referred to as resources, are identified by global 
    identifiers called Uniform Resource Identifiers (URI)." 

But nothing supporting the claim that "If your "web"site can execute arbitrary code, and/or violates HTML guidelines (...) then it might be part of the Internet, but it's certainly not part of the World Wide Web!"

I mean, the <SCRIPT> and <APPLET> tags were added in HTML 3.2, and the reason <SCRIPT> had a "type" attribute was that the intent was for browsers to support multiple languages. It seems kind of absurd to argue that somehow embedded code was never intended to be a part of the world wide web, when it was considered so early.

No one who was actually involved in the architecture of the web appears to have ever had such a rigid definition of it, or such a limited vision of what it should or shouldn't be. Here's a thread from the www mailing list from 1995 about web scripting languages[2], I don't see anyone arguing that the concept is fundamentally hostile or antithetical to the web or HTML. Rather, as hackers tend to do, they discuss the ramifications and pros and cons and possible implementation.

You may not like that this is the web, you may not agree that this should be the web, but this is the web.

[0]https://www.w3.org/Help/#webinternet

[1]https://www.w3.org/TR/webarch/

[2]https://lists.w3.org/Archives/Public/www-talk/msg00099.html

Writing a web application is different than writing a web document (or set of documents). I think what people are anxious about here is that many, if not most, sites are documents or sets of documents, but FE trends are "everything is an app", which leads to difficult situations like "in order to talk to my mom on the Internet, I essentially have to buy into the surveillance state".

We haven't done a good job at letting people do only what they want on the web, because so much of the web has been built by companies with ulterior motives. What people are worried about here--and this is true whether we're talking about WASM, Flash, Java Applets, Silverlight, etc.--is this is a giant leap down the road to a co-opted web, devoid of user choice and controlled entirely by moneyed or state interests.

Personally I feel like this happened a long time ago, so WASM doesn't worry me any more than I already am. But I think it's important to keep in mind more is at stake here than CSS-in-JS, or any one FE's career.

Perhaps webassembly doesn't change this either?

they have a problem with it in that unless you are rendering server side your pages won't work for someone who does not want to enable JS.

In the same way it goes against lots of ways the web has worked for 2 decades in regards to user customization, the ability to scrape content etc. so these things are irritating to anyone familiar with how "things used to be" in the same way that new freeway development destroying an ecosystem can be irritating to people familiar with the beauties of that ecosystem.

For what it's worth I also make my living doing the same thing, but I can certainly see the benefits to the other way.

I don't generally have a problem with this. I use JSX at work too. My take is it's just another templating system, I don't think it's special. I don't have anything against templating. To a certain extent, my point is that template systems are good -- put your two-way data bindings and special components in them.

When I write JSX though, I make sure it renders out as semantic HTML. If your approach to JSX is, "I'm going to write my render code in JS and output HTML", I don't have a problem with you, you're doing great. If your approach to JSX is, "my interface is just Javascript, so it's fine to spit out poorly organized divs that are absolute-positioned everywhere", then I think you've missed the point of HTML.

React isn't an antipattern. But React doesn't remove your need to think about the final HTML that your app is going to spit out. Apps like Youtube and Twitter are particularly bad at this -- Youtube's DOM is a horrifying mess, it's completely unreadable and way too difficult to work with or style. It's not because they're using a component system to build it, it's because they're fine treating the HTML as a non-readable render target. They don't care about HTML as a user interface.

The broad mistake people make on the web is to look at HTML and say, "because I can't build a scalable app on JQuery and hand-coded HTML, therefore HTML is bad." Google's hot-take with HTML custom components is not that you could put your template logic inside your other component logic -- it's that the HTML layer shouldn't matter at all and you should stop thinking about it.

Separation of concerns is for users, not for you. It's not about where you organize your logic, or even if you mix up your languages into the same file. It's about what gets spit out onto the final page.

> We’re killing CSS classes and building styled-components.

I would caution a bit against doing styles in JS -- not because adding a template layer or JS layer that generates CSS is bad, but because many codebases that I've worked with use CSS-in-JS as an excuse to rewrite basic CSS controls like hover effects in Javascript and inline the remaining styles. That doesn't mean you shouldn't do CSS in JS, it just means you should take the time to use a library that spits out actual CSS and that allows you to take advantage of native selectors and pseudo-elements. React does itself a disservice by using tutorials that teach people to apply styles directly to elements instead of pointing people towards any of the more decent companion libraries that will let you do styling correctly.

Unless your engineering team is the size of Facebook's and you can't communicate about your components at all, you probably should still be using classes. Of course that doesn't mean you can't use JS to restrict class scope or template that CSS. I personally tend to be more of a proponent of BEM than I am of JS styles, but I'm not going to fight someone over that.

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.

So, on something like iOS, it could be game over (but I'm also curious what Apple is going to do with wasm there, given that it goes contrary to their strategy of being the gatekeeper for all code running on the platform). But not for the rest.

This is your opinion, and your opinion deserves to be fulfilled. My opinion is that the web is a multimedia platform that can do combinatorial designs where text motion and visualizations can be combined into something like this:

https://neal.fun/deep-sea/

In my opinion what you see as 95% of all user interfaces is largely a because HTML and CSS are the rendering target not the other way around. There are less games and those types of UI interfaces on web browsers because HTML + CSS is bad for doing those things.

So if we have different opinions what's the best way to fulfill both? Libraries. One library for your text based philosophy and one for mine. The lower level technology should be agnostic to both of our opinions. What I don't like is having to submit myself to your design philosophy and write my canvas library on top of HTML + CSS.

webassembly makes logic language agnostic on the front end. It's time to do the same for the "render target"

That said, I don't know of any webassembly decompilers, although I guess they must exist by this point. But also historically decompilers have been imperfect as some of the structure of the code is lost in the compilation process and has to be inferred, sometimes incorrectly, by the decompiler. Compare to a minifier where all you lose is the variable names, comments, and possibly helpful whitespace. All of the structure of the code is still there and there are no heuristics necessary to recreate something that resembles the original source.

https://medium.com/@pnfsoftware/reverse-engineering-webassem...

https://youtu.be/8ev9ZX9J45A

To turn the question sideways a bit, there's nothing stopping some conglomeration from developing an alternative to 802.11 standards. All they have to do is create the hardware, convince people to use the hardware, create software to adapt a novel protocol to the higher layers of the networking stack to make it usable by application software (including addressing all of the ways that a new lower layer inevitably breaks an abstraction or two), and create the tooling necessary to make an ecosystem of non-802.11 wireless devices easy to install, maintain, and interoperate.

... But outside of particular special applications where something about 802.11 protocols or the frequencies they communicate upon makes them an ill-fit, there aren't many reasons to do so. Good enough displaces perfect in the common case.

It won't look right because it literally blanks out the page if Javascript and CSS aren't enabled. That's not a limitation of the web, that's a conscious design choice by the author.

Without CSS, what this would look like is pure data -- a list of animals with a picture and their relevant depth printed next to them. It would be perfectly functional. This is your render target: "what is the information that I wish to convey?"

Now we move to CSS and we make things pretty. A pure CSS/HTML version of this page would look pretty much the same, it just wouldn't have animated backgrounds or an interactive depth calculation. But it would still look nice, and it would still get the point across.

Now we move to JS and we add fun touches like an animated background and interactive depth view. And at this point, we're back to the original page layout and we haven't sacrificed anything at all to get there.

> The point is to get to the above, you need to basically hack your way there.

I want to be clear here -- I'm not advocating for a less experimental, uglier web. The reason you (or whoever the author is) needed to hack their way to this page is because they are over-complicating and over-engineering their UI. This page is using a CSS grid, for no reason at all. It's pulling in webGL code to render a background that could be handled with a simple Canvas. None of the elements on the page are in the right order, so good heckin luck trying to read this if you're blind. Even though, to be clear, the information this page is displaying is an ordered list of animals with some text next to them.

There is zero reason for this page not to be accessible to blind people. There is zero reason why this page can't degrade gracefully without Javascript. Making it accessible would not require you to compromise on the design or the visuals in any way at all. It doesn't need React, it doesn't need inline styles, it doesn't need CSS grid -- you could build the exact same page with no frameworks, and the code would be cleaner and easier to understand.

> Heck under your logic, why even have the OS expose the pixel level api? Just have the OS expose a DOM. 95% of apps are that way so an OS that does this is perfectly fine.

I'm not going to go quite so far as to advocate that native apps shouldn't have direct access to a pixel-level API. And from a pure engineering perspective, it does make sense to build high-level controls on top of low-level ones. But what I will say is that on Linux right now, we still don't have fractional scaling in Gnome, very few of the native apps are responsive, and most will break layouts if you try to mess too much with your OS's font-size or settings. The last time I talked to the MyPaint devs about building a touch-friendly version of MyPaint with bigger buttons, they told me it was impossible because of whatever Python-based widget library they were using. And holy crap, the menu/toolbar in MyPaint is not complicated. If the widget library doesn't support fractional scaling, it doesn't mean that MyPaint menus are doing something crazy or revolutionary, it means the Python widget library being used is crap.

And that kind of makes me think, if we had forced native developers to use an HTML-like interface instead of building pixel-perfect interfaces that aren't future-proof, would touchscreen Linux on HDPI screens be in such an awful state today? Would Purism have needed to rewrite half of Gnome's apps to get them working on a phone?

I'm not sure I agree that the state of native apps is perfectly fine. And I definitely disagree that caring about stuff like accessibility necessarily means that you can't be creative, or that we'll be holding the web back. I think that 95% of the native apps on your computer are probably text based UIs, except they've got a little bit of styling applied on top of them to turn unordered lists into drop-down menus. We have escape hatches for the web apps that are more complicated, that genuinely need to do crazy pixel-level things. Most of them don't.

It's not about getting rid of that styling, it's not about making things ugly. It's about recognizing that we're working twice as hard for interfaces that are half as functional as they could be, and we wouldn't need to sacrifice any of the fun visual stuff we're doing to improve that situation.

Elaborate? Rather than using different ports for different protocols and filtering what you don't want/need, you instead tunnel everything through port 80 and effectively don't filter at all?

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 to change because engineering everything to account for these people come with an engineering cost.

It is not "pointlessly excluding," it's just not worth the engineering cost. But you know this. Any person is aware of this and the reality of the world. There is zero need to call it "pointlessly excluding" that's just a manipulative way of advocating your agenda.

>And I don't know anyone who would seriously claim that the Godfather is lessened as an artistic expression just because deaf people can turn on subtitles.

I don't know either. Did you or I make this claim? Perhaps nobody made this claim and your pulling this example out of nowhere to serve your agenda. You know video games don't account for blind people. This is purely out of cruelty of course, no way does it have anything to do with engineering cost. Obviously you don't know a thing about the cost of engineering mechanisms to get these games to work for blind people so that's why you didn't mention it. Of course it wasn't at all a deliberate choice not to mention the engineering cost to serve your own agenda.

Please stop accusing everyone of being biased and having an agenda. Not that there is anything wrong with that, since everyone is biased and has an agenda (including you), but the way you're saying it makes it sound like you think it's an important component of other people's comments but not yours.

No. statements of observation do not have agendas. "The sky is blue" is a statement without an agenda. Statements can be made separate from agendas, which makes the statement unbiased.

>Being biased is pretty much a part of the human condition since we are limited, finite beings. Do you have all the information? Are you certain you have all the information? Have you taken into account everyone's wishes, desires, needs, analyzed every possible scenario in existence according to some yet-unspecified objective reasoning system? Then you are biased. You are missing something, you are concluding something erroneously. (using the generic you as a stand-in for anyone)

This is completely false. Biased, means a leaning of ones mind towards a particular viewpoint. People usually use this word in the context of a leaning of ones mind despite being aware of evidence to the contrary or lack of supporting evidence. If the mind does not lean then it is unbiased.

Your judgement of the statement has leaning towards your agenda despite you being aware of lack of evidence supporting it. My statement does not have leaning.

>Your agenda is to incorporate a pixel-level API into the web. And that's okay. Mine is to prevent the web into devolving into an opaque black box. That's okay too.

This "agenda" had nothing to do with my observations, but for yours it colored your interpretation of words. Your observations were biased, mine were not. This is not something that is Okay. Biased observations are usually false.

Given at face value the sentence is referring to a world of engineering with the context of the web as a specific example out of a more general point. You need to make a biased modification to the sentence in order for it to fit your world view.

>As to the topic at hand, I won't try dissecting comments word for word, because I think this is a loss of time and devolves into a lot of who-said-what, when we can sidestep it by concentrating on the most charitable explanation.

The most charitable explanation is here:

Given the original sentence we are referring to:

"You're not advocating for a bold, artistic world when you talk about engineering things to pointlessly exclude people."

The terms:

   "Bold artistic world" "engineering things"

   "Bold artistic web" "engineering web pages"

"You're not advocating for a bold, artistic web when you talk about engineering web pages to pointlessly exclude people."

You applied context to the statement relevant to your agenda. I did not. There is no doubt when I say that your perspective is in alignment with your agenda given lack of supporting evidence within the sentence itself. When you are biased you are unaware of it.

Definitively from the logic your statement is biased, mine is not.

>Specifically, I do not think he was arguing doubling or tripling a movie budget in order to make another similar movie for blind people. But then again, we weren't talking about movies. We were talking about web sites, in which the loss of HTML would lead to a net loss compared to what we have now.

Earlier you were rude to me. Therefore I don't care to debate this topic with you. Keep your opinion. I care little for it. If you had chosen more wisely earlier I would have gladly engaged with you on this very topic but since you chose not to, there is now zero possibility of further discussion on this topic.