If you look at the history of the web it's clear that the tendency has always been towards "shinier things". This "historic separation" was the result of technical limitations, see how popular Flash used to be for instance.

HTML and CSS standards were always at least 10 years too late. If you wanted something that looked modern you've always had to use browser-specific extensions, plugins or, at best, "beta" features.

Seriously, I know that nowadays many devs have started straight with web technologies and don't have a lot of experience besides that but if that's your case do yourself a favor and give a quick look at a proper UI toolkit like Qt. Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself? Crazy, I know.

If anything this "historic separation" and people who still hold onto it might be one of the reasons the modern web is such a messy patchwork of technologies, if web engineers had accepted that an open source Flash was actually the endgame and not a problem we might have saved us some time and some trouble.

To be clear I'm not saying that it's a bad idea per-se, I personally believe that the web is way too complicated as it is, I just feel like it's similar to arguing that "literally" shouldn't be used to mean "extremely" in modern English. Sure, I get your point, but I don't think it's a battle you can win.

The change in dev culture worries me more than the change in technology. At least Flash sites used to be considered bad taste. Dare to grumble about something unnecessarily requiring gratuitous JS now, and you'll get berated as an out-of-touch Luddite who needs to shut up and get with the times.

My impression was the criticisms of flash stemmed from its security issues, it’s closed nature, it’s relative unfamiliarity (compared to popular languages of the time), and the nuisance that was making sure you had the right version running on your machine at any given time. Modern JavaScript addressed these issues, hence its popularity over Flash. This doesn’t endorse the gratuitous application of JS for fundamentally static content, but it sets the context for your perceived “shift in dev culture”.

> Modern JavaScript addressed these issues, hence its popularity over Flash

I think that while this is technically true, technical adequacy didn't lure developers away from Flash player. I believe that the real turning point was when Apple decided to break Adobe's monopoly on the web by disallowing Flash player on all their products.

I agree that that was a turning point for usage, but we're discussing popularity among developers. Flash was unpopular among developers long before Apple banned it.

Flash was on approximately 30% of websites before. It's hard to understand the argument that it was unpopular amongst devs.

Devs hated Flash for all of the reasons cited above, but browsers didn't support anything better for many use cases.

Indeed. As an example for a long time you had to have Flash to play a video on your page. The HTML5 video support eventually ended the need for Flash to do this, but it came much later and very slowly became supported cross-browser.

Although that event was a nail in the coffin, developers were moving away from flash long before Apple banned it.

One of the reasons of the downfall of Flash were those tiny Flash sites in the middle of a full screen page when we suddenly moved from small screens to 1366x768 or better. Many sites didn't have the resources to upgrade and started looking like something 100 years old.

I always thought the primary driver of the demise of Flash was that Apple simply decided not to support it in iOS Safari. Is that not right?

Apple did decide to not support it, but they didn't decide not to support a thriving product - it's like 3 1/4 floppy disks, when the iMac decided not to include a 3 1/4 drive people grumbled but it was mostly dead tech, writable CDs had become wide spread enough to obsolete it - with flash, when Apple decided to drop support, they did so in an era where preferred alternatives already existed and the tech was thoroughly reviled - so Apple put the final nail in the coffin, but flash was already in the ground at that point.

> when the iMac decided not to include a 3 1/4 drive people grumbled but it was mostly dead tech, writable CDs had become wide spread enough to obsolete it

The G3 iMac did not include a CD writer, so if you wanted to use writable CD to get data out of your iMac, you needed to buy an external drive.

You aren't quite right on writable CD being wide spread then--you are early by at least a year or two. When the G3 iMac came out CD-R drives were still above $300, and CD-RW drives were above $450. CD-R discs were around $2 a disc, and CD-RW discs were more like $15-20 a disc. (I'm getting prices from the November 1998 issue of MacWorld).

My recollection is that the usual ways people dealt with the lack of floppy were:

1. External floppy drive.

2. Iomega Zip drive. An external Zip drive suitable for use with the G3 iMac was about $120 when that iMac came out.

3. Ethernet to exchange files with another computer on the LAN that does have a floppy.

That's not correct. Flash usage was trending down fairly rapidly even before that as javascript, css, html5, canvas, and DOM became more feature filled.

By definition, everyone agrees that "gratuitous" use of JS is bad. You're glossing over the nuance of the debate which comes down to the specifics of when something is actually gratuitous.

You mean when the amount of JS you have to download eclipses the size of the original DOOM executable?

You hit the nail on the head. At this point I’ve done about equal amounts of time building native apps and web apps. I’m very fortunate in that I don’t have to “pick a side” because I understand the strengths of both platforms and I try and learn from the strengths of both and apply that to whatever I’m working on.

For example I’m a huge fan of the declarative UI trend going on in the web community. Now, granted, Microsoft came out with MVVM and XAML way before React or Angular existed, but native UI libraries are so historically imperative that declarative UI wasn’t making much of a dent in the native sphere.

But even though these older native frameworks are imperative, they are much more powerful than anything like React out of the box. They’re much more comparable to component frameworks like Bootstrap, SemanticUI, AntD, etc. But even still, those libraries don’t come anywhere close to the power of Qt or UIKit in iOS. If you’ve used both, I can’t imagine you saying that it’s even close.

But it’s precisely because of the tension between the web as a document platform vs. the web as an application platform. The web has never doubled down on being an application platform, it always keeps its document roots in the background in some way. Personally, I’m torn. I love the transparency and inspectability of the web. Literally yesterday I opened up the dev tools inn twitter and I learned about its timeline architecture just from inspecting the requests. This is the biggest thing I miss when I’m working on a native app.

But WebAssembly may be the web finally doubling down on being an application platform. Whether that’s good or bad is irrelevant at this point. It’s the direction it’s headed in.

> Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries

No, not any more than C#'s giant standard library blows my mind.

Keeping the web small is a strategic decision -- it may look like chaos, but it's really just that we realized that embracing 3rd-party libraries is a better architectural decision than polluting the core spec with features that will be outdated in a few years.

QT doesn't have these problems because QT doesn't have to be infinitely backwards-compatible. If QT makes a mistake, it can fix it in the next version. The web can't do that, so we have to be more careful. If anything, my biggest criticism of the web is that we move too quickly and stick too many "modern" features in. I would have been happy to drop Classes and Arrow Functions from the JS spec, and I would have been happy to drop `sticky` from the CSS spec. As an engineer, I absolutely don't want a hamburger menu as a core HTML component.

I've had people argue to me that HTML needs more 2-way data binding and element types -- they want the ability to tie a list to a JSON object or something, instead of needing to render out separate `<li>` elements. These people are missing the point.

HTML is your user-presented state. We have a few elements that break this convention, but for the most part we want your final HTML to be static and human-readable. It's not for you, it's for your users. And 2-way data bindings would get in the way of that.

For laying things out and creating complicated lists, we have third-party libraries/frameworks -- and honestly, they work fine. If you think the web is overcomplicated or has too many frameworks right now, just wait until we start stuffing a new first-party component into it every time any design trend becomes popular.

And even if we did add all of that nonsense, people would just ignore those components anyway. No manager I've ever worked with has ever said to me, "you know, pure HTML select inputs look great and I don't mind them rendering differently in different browsers." I would be reimplementing them in JS anyway just to get the styling consistent between IE and Firefox. The good HTML components I can actually use are the low-level ones like simple input fields -- because they're small and simple enough that they can be styled and incorporated into larger custom-built solutions.

Heck, I've had managers complain to me about scroll-bar styling before. But sure, they'd totally be happy with a giant, pre-built, monolithic tree-view component that's using mid-2000s styling.

I'd argue that the problem isn't so much backward compatibility than being opinionated vs not. Qt knows what it's doing, knows what it isn't doing and then from there defines the perimeter of its APIs.

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.

It's hard to identify specific decisions made by Jobs from the outside, but killing Flash on the iPhone seems like something _only_ Jobs could have done. Sure he and Adobe were in a tiff... Anyway, it's likely that this is a rare case where one person making a unilateral, perhaps tyrannical, decision benefited the whole world.

The fancy stuff can go live in apps, it has nothing to do in a browser designed for webpages first. I mean, just compare the GUIs of VLC and YouTube!

But with the strong advantages of access to the Internet that a website brings (which is itself a whole bag of hard problems to solve), the appeal of building things accessible via browser user-agent (regardless of what the thing is) is huge.

It shouldn't be necessary to toss out the cookie jar, the HTTP connection handler, the XSS protection just because one wants to do something a bit different with the final rendering stage.

What prevents access to the Internet from a non-website ? Why use the HyperTEXT Transfer Protocol for things completely unrelated to text - it's not like other, more appropriate protocols are not available, or cannot be designed ! (Or that URLs are limited to HTTP...)

At this point, HTTP has enough tooling around it to do enough significant application-layer things that the opportunity cost of rolling new protocols is extremely high.

It's not just text transfer... HTTP also goes hand-in-glove with HTTPS, which is a technology few people want to build an alternative for (and fewer people should be trusted to do correctly).

Trying to force everything over HTTP is a bad practice that is slowly killing the Internet.

[citation needed]. Traffic, usage, diversity of usage, investment, all of these are higher than they've ever been and still trending upwards. What definitions are we using by which we can look at these numbers and claim the internet is being "killed?"

If that's the definition by which people think the internet is dying, I find the definition suspect. And I find the solution suspect, because the notion of building protocols instead of platforms doesn't address the question of how to route those protocols over a network that has evolved to address the problems associated with laissez-faire protocol management in the past.

There's a very good reason that so many systems block everything except port 80. Does the idea of protocols instead of platforms address that reason? Because most people don't want to make themselves vulnerable to attacks along threat vectors they aren't even aware exist.

> There's a very good reason that so many systems block everything except port 80.

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?

Remember when Windows installs didn't have firewalls on by default and it was pretty trivial to attack people's installations via insufficiently-secure protocols running on open ports? It was a bad time.

HTTP has both elaborate tooling for deep packet analysis and a battle-hardened secured protocol, which we don't get with new protocols.

Well, yes, we used to not care about security as much.

These days, don't you think that consumer routers sold without firewalls should be about as illegal as selling cars with only motor braking ?

What? How is SSL dependent in any way on HTTPS?

Ftp and sftp are different protocols. So are HTTP and HTTPS. So are IMAP and IMAPS. And that's the issue with new protocols being added: the security question is a protocol-layer question, but one can't just hot-drop a new protocol into SSL and call it a day; security requires abstraction-breaking considerations.

Partly firewalls and proxies. If you've not read it already you might be interested in https://tools.ietf.org/rfc/rfc3205.txt ("On the use of HTTP as a Substrate"). I wish we still built protocols too.

Indeed. IMHO the right move would be to put pressure on bad actors that only allow HTTP over port 80 and still claim to be "ISPs"... (And with IPv6 having been finalized, NATs are now obsolete.)

And, as they say : > It would be useful to establish guidelines for "firewall-friendly" protocols, to make it easier for existing firewalls to be compatible with new protocols.

I believe that the Internet is fundamentally about protocols, and that platforms are to be banned if we care about it : https://knightcolumbia.org/content/protocols-not-platforms-a...

Novel protocols have their uses, and when that use can be demonstrated they can find their niche. But their value has to be extremely high to justify the opportunity cost of using them over something more established.

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.

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 you lose the utility of libraries and infrastructure built around using the other protocol.

The opportunity cost to do that with a brand new protocol instead of taking advantage of HTTP's flexibility to build new protocol atop HTTP is high.

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?

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.

"Exiting" doesn't seem to be the right word? How do we stop Google, who is currently "exiting" HTML ?

Should we? I thought you were making the argument that HTML was a bad fit for non-hyperTEXT content. From up-thread:

"Why use the HyperTEXT Transfer Protocol for things completely unrelated to text..."

If Google agrees with you, would we want to stop them?

By "exiting", I mean Embracing-Extending-Extinguishing.

Complicated lists on the web are really bad. If you have a lazily populated table, it breaks the browser's Find, it typically breaks the scroll bar positioning, there's visible holes while it populates, scrolling is janky slow, the scroll bar will jump unexpectedly.

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

> These people are missing the point

Maybe not.

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

> Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself? Crazy

QT is a third party library that wraps the underlying OS primitives.

A really fancy tree view in JS is 10KB, maybe 15KB, given desktop+mobile support, proper accessibility, and good support for theming.

And that is if you are getting really fancy. A simple one is just some DIVs and a CSS animation for opening and closing.

That is assuming you even bother with JS, since you can do a treeview in the browser with CSS alone[1].

UI toolkits exist for the web as well, and they tend to be rather small, browsers ship with a lot of UI primitives after all!

The UI portion of code for my B2B web-app with all custom UI elements and with mobile+desktop support is around 100KB unminified.

Now the libraries I pull in to do the real time database streaming and authentication to my back end? Those dwarf the UI code (they are hundreds of KB each), but the native versions of those libraries are far larger (10x)[2], than the JavaScript equivalents.

> Would it blow your mind if I told you that you can create a complex treeview without having to use third-party libraries or reinventing half the wheel yourself?

The browser comes with a lot of wheels included, very few are getting re-invented unless someone wants indulge themself.

> To be clear I'm not saying that it's a bad idea per-se, I personally believe that the web is way too complicated as it is

Get rid of the weird things that happen to make advertising possible and most websites are pretty simple. Even complex web-apps are pretty easy to understand now days, though you'll have to learn whatever data-binding technique the dev team decided to use, but that is the same case for modern desktop applications.

[1]https://codepen.io/kobusvanwykk/pen/NqXVNQ

[2]https://stackoverflow.com/questions/41750553/what-is-the-est...

For your #1 example, there is now the details and summary element that accomplish this too.

> This "historic separation" was the result of technical limitations, see how popular Flash used to be for instance.

I thought HTML was developed with HATEOAS in mind. So I don't see the seperation as a technical limitation but a powerful abstraction. Flash was what people wanted but HTML was what a good web needed (imagine the internet with only Flash/WebAsm from the beginning).

I agree that the web is heading in a direction where it'll be easier to build cool websites. I think a possibly unintentional side effect of HTML as a base was that everything was hackable. It's like everything was open source and DRM free, whether you like it or not. I think this was probably a driver of the web becoming what it did. Imagine building pagerank when you can't scrape text or hyperlinks.

The reason behind 'the Web' resembling the mess unfortunately best exemplified by 'the Net' has a much simpler and trivial reason:

We have globally networked local Networks of locally networkable Networks and most of us naively think that this Global Network of Local Networks networking Local Networks actually functions as a universally internetworking Internetwork of universally internetworkable Internetworks internetworking internetworkable Internetworks internetworking internetworkable Networks[([¹]1)], because we trust the people who've labeled both IPv4 and IPv6 as the "Internet Protocol" despite it not in any way, shape or form having the ability to perform what the people who came up with the concept of internetworking (no, NOT the ARPA people.) actually meant by the term.[2]

As the simplest proof of this fact: We've almost reached 2020 and all of our 'solutions' for multi homing don't ACTUALLY work in a not-pants-on-head-dysfunctional despite the fact that we've faced that issue since, to quote Wikipedia, "In 1972, Tinker Air Force Base wanted connections to two different IMPs for redundancy. ARPANET designers realized that they couldn't support this feature because host addresses were the addresses of the IMP port number the host was connected to (borrowing from telephony)."

Our 'Inter'net at the moment still resembles just a global network, aka just plain old phone calls, with extra steps. Which explains both the mess we call the WWW, and the global dominance of large telcos.Can't give an AS number and BGP access to just anyone[([²]4)] , as we know ever since L0pht Heavy Industries testified before the US Senate, over 2 decades ago, back in 1998.[3] NOTHING has fundamentally changed about this since. We've just written bigger and bigger macros ignorant of why we keep having to fight windmills & having to reinvent the wheel over and over again.

[1 (¹ yes, I did intentionally phrase that in & as a reference to a certain Cisco exam question.)]

[2 see https://news.ycombinator.com/item?id=21108796, but also see http://ict-arcfire.eu/index.php/rina/ & http://ict-arcfire.eu/wp-content/uploads/2018/06/OCARINA-ind... ]

[3 https://youtu.be/VVJldn_MmMY]

[4 (² Of course, I don't advocate that we should. No. I do however argue that each of these situations shouldn't exist in the first place.)]

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 interact with. You'll have to agree to let them run arbitrary code on your machine to even view the "website". There will be no "browse w/o Javascript" option in that future.

The kind of jerks who liked adding Javascript to block right-clicking, blocking "Paste" into password fields, etc, are going to absolutely love using the browser-in-a-browser product to deliver their "website".

For the inevitable replies: Yes-- you can already do this with minified Javascript. WASM, being targeted for performance, is just going to make this kind of asshattery faster.

Unfortunately, I must agree with you that there are definitely some very troubling implications to how WebAssembly might be used to build more effective walled gardens on the web.

I can easily imagine a "platform" WASM module which acts as a runtime for other WASM modules built by "app" developers. This Platform module can be easily cached by FAANG or other big commercial interests, similar to AMP by Google (maybe even be pre-bundled into the browser?). The only way to discover, download and run these other apps is through this curated Platform module. All this could be rendered through something like the Canvas API instead of the DOM, which again is managed on a low level by the Platform and in turn exposes higher level API's for the Apps. The Platform also has built in support for Ad networks, tracking, etc., which cannot be disabled without disabling the whole ecosystem of apps. And of course, like any good play/app store, it is completely incompatible with anything else, leading to new levels of Balkanization of the web.

I hope that this isn't the case, and I'm completely wrong about this. But I just can't shake the feeling that as a community, we are championing WebAssembly as purely a performance win, without considering how big commercial interests might seek to exploit this new technology.

Edit: typo with AMP

This platform wasm will come. And it does not You do not need to be evil, especially in the beginning. Java or .NET Runtime and Libraries are a bit heavy for a small web page.

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.

There were not physical Java processors, because it’s too hard to emulate jvm in hardware. But there were processors with instructions optimized for interpreting jvm bytecode. These would be pretty useless nowadays (for either jvm or wasm) because baseline compiler which translates vm bytecode to native bytecode is easy and more efficient than direct vm support in hardware.

Delete this!!!

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.

This would be no different from an app, just delivered via web. So not really anything new.

It makes no sense to me. You are saying, that instead a 5 kB webpage, you would load 50 MB code, which emulates a browser, just to show you the same webpage?

Every webpage pays for the traffic in some way, and everybody tries to save web traffic as much as possible (optimizing images, videos, minifying JS, CSS ...). It makes no sense to expect, that websites would turn the opposite way just for fun.

I would be very glad, if you can emulate a computer in a browser, so you can e.g. use VirtualBox or VMWare comfortably in your browser. Still, it will be sandboxed (it can not turn off your computer, or clear your hard drive, etc.).

I think the web is the most open, independent, secure and versatile platform today. And I hope it will become even better and more powerful in the future.

Yes. I am saying that some website operators would like to load an entire browser into your client just so they can control the presentation (make sure you're not able to block their ads, control their scripts, etc).

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/

I don't think it is necessary to make websites extremely complex, to prevent you from blocking ads.

I think blocking ads is a game you can never win. If you are able to block ads on some websites today, it is just because the site owners allow you to do so (they could easily prevent you from doing so). Ads technologies can evolve to a point when you as a human can not distinguish between ads and the rest of the content.

It would make content control more complicated, but it can't make it impossible.

If the embedded browser uses the host's HTTP implementation, then you can filter and edit content there.

If it implements HTTP itself on top of raw sockets, then you can intercept traffic on socket level (although you'd need to MITM any SSL connection).

If the inner browser has its own client certificate or simply checks for a set of known server certificates, MITM won't get you anywhere. Done right, this could well be game over.

For it to be truly game over, the wasm implementation it's running on must also protect the wasm payload itself, otherwise it would be trivial to patch that to MITM it.

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.

Adding a ton of obfuscation will do the trick. Patching wasm requires reverse engineering and that is very cumbersome. For Blu-Ray it took months to reverse engineer the copy protection VM and that was with a mechanism that took a lot of attention. If it's your average website, it's far easier to stay ahead of the game.

Instagram, Facebook, Pintrest, Youtube apps are already this thing. Tens of megabytes embedding a browser to view web content. Their traffic covers a significant portion of the entire web. All of these have a lot to gain from rendering ad blocking impossible. And for keeping people on their "platform", inside their walled garden. Right now they are shipped as native apps, which the web version will nag you about until you install it. I don't think it is so farfetched that they will try to use WebAssembly for the same.

> It makes no sense to me. You are saying, that instead a 5 kB webpage, you would load 50 MB code, which emulates a browser, just to show you the same webpage?

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.

Obligatory: https://www.destroyallsoftware.com/talks/the-birth-and-death...

I wouldn’t be surprised if 50 MB was a more common webpage size than 5 KB these days.

Well, someone attempting that will have a long row to hoe to get the thing working with the needs of networks with different performance standards, useragents with different screen structures, and users with different accessibility requirements.

Browsers are large and complicated software packages for a reason. Best of luck to whoever tries to compete with it in a browser in a browser.

The inner browser doesn't need to be a general purpose browser. It just needs to render the site-owner's content, run their scripts, etc. Once there's an API for WASM to manipulate the DOM accessibility becomes easier.

So react native?

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 faster than the Electron mess we have now.

The outrage is because the web isn't simply a "UI platform". That's only one use of it. It's also a document platform.

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.

Yes, and for games it will be great. And a mixed bless for web applications.

What won't be great are sites that do this to enforce ad viewing. But if it becomes common enough, you can expect ad-blockers to act on the frame-buffer of that virtual browser.

Anyway, the most annoying will be the stupid people that do that just because "Even Google does it!" "It's webscale!", or whatever people will be saying 5 years from now.

> Eventually somebody is going to ship a product that's nothing more than a browser implemented in WASM that runs inside your browser

Sounds like a slippery slope to me. What makes you think users will be satisfied with load times for something like that, which also probably will have a frustrating-to-use interface?

Users seem pretty satisfied with single-page apps. They are slow to load and have frustrating-to-use (inconsistent) interfaces, at least compared to my memory of 1990s desktop software. If users actually cared about performance then software would get faster over time.

Consider some company running some web application for their employees that “works best in” IE 6 or, for example, Chrome, but the 2018 version.

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?

Smart phone apps already do this.

Emulate Android or IOS in the browser- that way you only have to write an app, and not bother with a website..

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

Unity and UE4 are very close to having exactly this today. There's no big reason why this shouldn't work for apps targetting a readonable subset of Android.

> Could we ever lose the HTML centered model?

This is what people should be worried about, not replacing JS. It became a kind of popular hot-take for a while to say that separation of concerns was a mistake, and that's not how apps get built in the real world, and what we really need is a way to encapsulate all of our DOM and CSS in JS. We need to start pushing back against that idea and keep emphasizing that separation of concerns is really important for end users.

HTML is the interface you write to. It's not a document layout language for authoring, it is a render target that is understandable and manipulable by the end-user. It's a fantastic idea that enables a lot of user-land innovation, and it's one of the biggest reasons why the web is still a relatively good platform to interact with as an end-user.

A lot of architecture decisions on the web haven't aged well, but separating content, styling, and logic was a fantastic architecture decision that is still as relevant today as it ever was. And the rise of the web as an application platform has only made it more important, not less.

Frontend Engineer here. That “popular hot-take” is my career, and I happily combine HTML and CSS into my JS every day.

React.js has been the most significant JavaScript library in the past decade. Over 50% of JS developers on the web are writing HTML inside JavaScript. In recent years, CSS-in-JS libraries like Styled-components are becoming standard.

We’re killing HTML templates and writing JSX. We’re killing CSS classes and building styled-components. It’s all compiling to HTML, CSS and JS in the end. We just get to do our jobs faster. Why people have a problem with that is beyond me.

Hey, I'm a full stack eng and while I think React is net good, I don't think that's the same thing as "DOM/CSS is bad".

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.

As another react developer. The separation goes deeper than just having styles, logic and the dom in separate files. It's the underlying data structures that are important in the end. And in that regard react doesn't change the field. We still have the same essential structure and building blocks. Just a different way to reason and interact with it.

Perhaps webassembly doesn't change this either?

If anything I'd prefer it if styles, logic and dom lived together in the same file.

I hate the sheer number of files people create in projects. The worst one I've seen is a ".types.ts" file. Everywhere.

So, .vue files then?

That is one of the thing I like about vue.

The last decade? In 2009 JQuery ruled the world, the last 6 years definitely.

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.

> It’s all compiling to HTML, CSS and JS in the end.

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.

CSS files are in a league in their own for how badly they represent the state of my app. In no other data structure would we say "oh sure, lets arbitrarily name groups of key/value pairs in a nested hierarchy that may or may not match where they are applied. Also, its a global namespace so let's preface every name with our application name". At scale, CSS classes are really difficult to find when looking at your component and have ambiguous naming and nesting patterns. They shouldn't exist.

Styled-components solves all these problems, randomly generating CSS classes under the hood, while still creating CSS files for you. Check out https://www.styled-components.com/docs/basics#motivation.

I'm not sure I can be sympathetic to "the final HTML DOM output" matching your expectations here. Think about a Dropdown select. We still need to create a library with a bunch of absolutely positioned <div>s here because you literally can't build a good looking dropdown with normal HTML. It's really hard for me to think fondly of HTML/CSS when all they provide is assembly-code level specification. Flexbox and Grid are great counter-examples here. Still no nice looking dropdown.

> because you literally can't build a good looking dropdown with normal HTML.

I disagree. Build a drop down field using the normal form field elements; it is up to the browser to render them in a suitable way. (Which way is suitable may depend on details which the author is unaware of.)

> The point is to let me as a user override or ignore your styles, and to keep your styles away from your core content. ... I just want devs to render clean styles that I can work with as a user, and to stop using JS mouseover events to poorly recreate a hover selector.

That I agree. Let the user to override/ignore the styles, or to use them without changing if that is what the user wish.

> because you literally can't build a good looking dropdown with normal HTML.

I want to push back against this in particular, not only because I think it does HTML/CSS a disservice, but because I've maintained codebases that took this approach and they're really bad to work with. You're trading a little bit of CSS annoyance for constant positioning/z-index errors -- and you'll need to update your positions whenever your page scrolls or a component grows... there are just so many ways for this to go wrong, and there's always an edge case that developers miss.

Nothing is absolute, but most of the time the proper way to do something like a custom dropdown selector or tooltip is to semantically group it with the component it's attached to, and then at most absolute-position one element to center it relative to its parent.

  <div class="Input">
    <input class="Input__Field">
    <ul class="Input__Options Input__Options--hidden">
      <li>Option One</li>
      <li>Option Two</li>
    </ul>
  </div>

  .Input { position: relative; }
  .Input__Options { position: absolute; /* etc */ }
  .Input__Options--hidden { display: none; }

I don't like everything about CSS, there are a number of problematic design choices in the language -- particularly specificity. I also wouldn't necessarily be against a new primitive for scoping CSS to specific DOM trees. But annoyances aside, overall CSS is pretty great, and on net the apps I maintain that make heavy use of CSS are easier to maintain and less buggy than the apps I work on that try to use JS code to accomplish the same tasks. Obviously that's anecdotal.

Again, this doesn't mean you can't compose your CSS in JS. But separation of concerns is not for you. The point is to let me as a user override or ignore your styles, and to keep your styles away from your core content. When you spit out HTML and CSS, you are spitting out an application interface.

You're really worried about where you write your CSS, and I couldn't care less. I just want devs to render clean styles that I can work with as a user, and to stop using JS mouseover events to poorly recreate a hover selector.

Because I run noscript. Mostly, when a site requires javascript for static content, I just hit back and move on.

It’s a bad render target, and it’s only half the story. It’s html + css that’s the render target.

Separation of concerns happens because the render target is a over complicated mess. So separate the good parts out of the mess as much as possible but the mess is still there.

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 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.

>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 you put on top of that render target.

Sort of like turing completeness, HTML on its own is not "render" complete. There are many objectives that cannot be achieved with HTML alone. You must consider aspects within and outside of your "design philosophy" as the modern browser is intended to be a universal platform for multimedia applications. This is why HTML alone cannot be the render target.

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.

This maintains "render completeness" and gives users the ability to use higher level DSLs like HTML + CSS or to (switch to)/write another library.

>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.

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.

This is not a design opinion to me. Unless your application state can be represented as pure text, it can not be efficiently conveyed to blind users. So we force you to do that.

> It would be better if the web browser world had pixel level render targets

We also have escape hatches when you need pixel controls: Canvas, and webGL which can be rendered to a Canvas. The only difference is that they're not the core that HTML is based on. This is on purpose, because using Canvas should be very rare. You should embed your (rare) pixel-based rendered component into an HTML tree with appropriate non-visual markup around it to describe what it is and what it does.

Pixel-level render targets are a design antipattern for most apps. Not all apps (games for example), but the vast majority of them.

To me this isn't a design thing -- it's a purely practical decision. Your app state needs to be accessible to people, people need to be able to build on it, programs need to be able to parse it and manipulate it, it needs to be responsive when high-definition displays or Apple Watches come out in the future, and it needs to degrade gracefully when parts of the browser stop working. We've been able to observe for a long time that apps that are built this way are better for end-users.

In the browser, text is your pixel. Of course you are welcome to build things on top of that with CSS, images, and Canvas. More to the point, I'm not saying that 95% of the time you should abandon your design and make a minimalist terminal interface -- I'm saying that for 95% of the phone apps and native apps I see, HTML would be fine. There is a pretty good chance the design someone has come up with is already representable in pure text, and they just haven't thought hard enough about how to do it. I'm not saying design everything minimalist, I'm saying your design is probably already a lot more minimalist than you think, and it probably wouldn't be that hard to separate content from pixel-positioning and style for most apps.

>In the browser, text is your pixel. Of course you are welcome to build things on top of that with CSS, images, and Canvas. More to the point, I'm not saying that 95% of the time you should abandon your design and make a minimalist terminal interface -- I'm saying that for 95% of the phone apps and native apps I see, HTML would be fine. There is a pretty good chance the design someone has come up with is already representable in pure text, and they just haven't thought hard enough about how to do it. I'm not saying design everything minimalist, I'm saying your design is probably already a lot more minimalist than you think, and it probably wouldn't be that hard to separate content from pixel-positioning and style for most apps.

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"

> into something like this

Unless I'm misunderstanding, this example seems to be exactly what I'm talking about.

Even in its current state, there are only 2 or 3 things on this page I can see using Canvas. Everything else is already using HTML and CSS. It's not even lazy-loading the images -- this is a static page that is dynamically generated. And yet despite ultimately being a static page, it works fine. Great even, it's responsive if I resize the browser. HTML is doing everything you would ever need here.

You can use Canvas for the (optional) background animations in the deep water, Canvas (or gifs) for a few minor animations like the waves on the top. You use a very small amount of JS to update the text tracker and swap the sub to a fixed position when you hit its scroll-point. The sub is already an image being animated via CSS, so you're doing that correctly.

To me, this page is the perfect example of something that has an incredibly simple tree-based UI that is nevertheless being dynamically rendered with webGL for some inexplicable reason. I'm actually a little annoyed that it doesn't currently work with JS disabled. I wouldn't expect the depth-tracker to work without Javascript, but I should still be able to at least scroll to the bottom and see all of the pictures and text. It would not be hard to make this page degrade gracefully.

What do you want this page to do that isn't possible with the current state of HTML/CSS? I might be missing something, but I don't see what the complication is.

> 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.

I'll make a bolder claim then: 95% of native apps are just interactive documents (with a few category exceptions like games), and most native developers who claim that their interfaces couldn't be represented on the web in HTML are kidding themselves. In the majority of cases, HTML/CSS would be fine for what they're building.

That page actually goes against your point of HTML as a singular render target. You need CSS or that entire page won't look right at all.

The point isn't whether or not you can do this in CSS + HTML. (Which by the way CSS + HTML is proven to be turing complete so you can actually do anything in CSS + HTML including writing a JS interpreter so you can use javascript on non-JS enabled pages)

The point is to get to the above, you need to basically hack your way there. HTML + CSS is not the ideal medium to program something like that in. It would be better to have a library written over a pixel level API to construct the interfaces you see in the page rather then either hack your way through HTML and CSS or create a library of hacks on top of HTML and CSS.

>I'll make a bolder claim then: 95% of native apps are just interactive documents (with a few category exceptions like games), and most native developers who claim that their interfaces couldn't be represented on the web in HTML are kidding themselves. In the majority of cases, HTML/CSS would be fine for what they're building.

Sure make that claim, even if it were true nobody wants a computer to just be a platform for text based UI. Nobody wants the internet to be JUST that. People want the computer to be a universal computing platform. Games may be category but it's a huge category as no one will buy a computer that only has the capability of displaying text, they buy it for the computing potential to do anything.

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.

If you want to restrict the potential of what the internet is, then yes. If you want to expand it while keeping your design philosophy in place then the platform must expose a pixel level API and HTML and CSS must be moved to a library. It makes no sense for a lower level library to be written as a component of a higher level library, it should be reversed.

> You need CSS or that entire page won't look right at all.

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.

>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?"

No. The author wishes to convey a multimedia experience. This is evident, the page is unique because of this.

The author does not care to convey just textual information. You're just breaking down the core components of the system and picking the one that's required to have any semblance of a page. The "fun touches" are ultimately required. It's like a script vs. a movie, the movie isn't required and the script is ultimately all that's needed but nobody cares about the script do they? It's not even embedded in the movie.

>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.

I have to be honest with you, and this is cruel. But when I design a page... I don't care for blind people. I don't focus my design so that it will cascade down into something blind people can read. Books don't have this property, movies don't and because of this... neither should web pages. It is not worth the effort.

>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.

I never said native apps are perfectly fine. I'm also not advocating all sites be designed with pixels. What I am advocating is freedom from HTML and CSS. If the platform of the browser exposed pixel level control with HTML and CSS only as a library and given the amount of people who hate the CSS + HTML... it's almost a guarantee that people will create sibling API's that are on the same High level as HTML + CSS but offering different philosophies. There are multitudes of UI layout languages and tools out there, who said HTML and CSS was the best, and why does it have to be the only way?

That's all I'm saying. You expose pixel level control at the core for the purpose of being able to use and create multiple high level libraries rather being vendor locked into HTML and CSS.

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 Hollywood movie you can buy ships with subtitles for the deaf, and since ~2015 US law has required that new theaters also include equipment that provides audio descriptions for blind viewers[0]. 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.

[0]: https://www.govinfo.gov/content/pkg/FR-2016-12-02/html/2016-...

>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 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.

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.

You understood it in a biased way that not coincidentally supports your agenda. Clearly the topic is more general then the specific example.

Clearly, and I'm not claiming it's not. I just understood that the OP was using the phrase like that.

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.

>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.

Ok first of all. There is no universal law that says everyone has to be biased and have an agenda. There's no logic to it. This false notion comes from the fact that most people (not all) people are biased and that when people are biased they are unaware of it. However this does not mean that people can't be unbiased or have no agenda.

Second: Examine the sentence in reference to that phrase. It is literally word for word referring to "engineering" and Not a specific set of engineering projects.

Literally what you are doing is inserting your own opinion onto what that "engineering" is referring to and I am taking it at face value. So I am not wrong when I say that your observations are biased. There is no accusation here, just observation of events.

Having an agenda simply means wanting something. If you do not want anything, then you do not have an agenda. If you do, you have one. By your own admission, you want something, and if you did not, you would not be discussing in this thread.

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)

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.

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.

Reading through the thread again, I think the other poster's point was that there are many situations (not all) where designing things in the simplest and most direct way, using HTML as the semantic underpinning, leads to both less engineering effort and to a more accessible design.

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.

>Having an agenda simply means wanting something. If you do not want anything, then you do not have an agenda. If you do, you have one. By your own admission, you want something, and if you did not, you would not be discussing in this thread. 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)

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"

under your biased agenda becomes:

   "Bold artistic web" "engineering web pages"

Which makes the original sentence become:

"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.

Okaaay. This is getting a bit too crazy for me. Enjoy your unleaning mind.

The humble thing to do is to apologize for you previous rudeness. Passive aggression does nothing to serve your agenda.

> 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 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.

>The web is a semantic API and its components represent meaning.

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.

> 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.

I'm not convinced it's a better design. It just makes semantics a separate, additional concern, rather than a frontal concern which you have to think about. It allows you to be lazy by not supplying the semantical layer at all, in any shape or form. Granted, you can have document websites with some pretty opaque form even today, but I would argue that enforcing the basic structure of HTML still keeps us in a much better place than we would otherwise end up.

I also don't think the way the web formed was ad hoc when you consider it from a semantical perspective. The most ad hoc bit about it is JavaScript, which was of course necessary due to the expansion of the web into being an application platform.

Pixel-level control sounds wrong to me as a default choice. You don't need pixel-level control in most cases, whereas meaning is crucial, both for humans and for ease of interoperability and extension.

> It's using low level components as a composition of high level components. The design is backwards ...

This is only so due the arbitrary meanings of "low" and "high" you picked here. You're imagining pixels as fundamental, meaningless atoms out of which meaning is built. Why not have meaning at the forecenter, though?

I would argue that having a semantic layer exposed as the front is the right design, not backwards. By default, you have a set of meaningful components composed in a meaningful way. One of those components can be "an array of arbitrary pixels", a canvas to draw on. That doesn't sound wrong nor difficult to me.

Does this argument boil down to the design being "wrong" due to some kind of first principles, or does it genuinely make things substantially harder in a large number of cases? Bear in mind that changing the web like this would also be an exceedingly hard effort.

> vendor locks people into html.

Which vendor would that be?

> There are other ways to display semantic UI. Html is an arbitrary choice.

I agree, but HTML is what we have and it's not half-bad compared to some other things we could have ended up with.

> 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.

Let's not get too literal. I was clearly pushing back to your suggestion that we shouldn't take requirement of ad blockers as a design consideration at all.

What I meant to say was that, given the knowledge we have today, any design should take the possibility of ad blockers as one of its central points. Ad blockers need to remain easy and they will remain easy as long as the platform forces you to encode basic meaning in a transparent way.

> 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.

That's uncalled for. I read your argument multiple times and the best I've found is "I don't like being forced to write HTML." Even though you'd need only a small amount of boilerplate HTML in order to get a canvas which then gets you the pixel API you wanted.

I only realized I don't really understand your argument midway through writing that since I consider your request to have a pixel interface reasonable. I just don't consider it reasonable to request to uppend the web fundamentally -- to the detriment of the document platform facet and the use case of writing freely interoperable, transparent documents -- in order to cut away a small bit of boilerplate.

I decided to leave my comment as it was to reflect the time evolution of my thought. You may not like the style of my comment, but it's a bad reason for rudeness and instructing me to take reading comprehension classes.

> 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.

I'm not sure, but are you talking about me? I'm truly sorry if I was rude and offensive, it was not my intention to be. That said, I got the same feeling about your responses to other people and the topics of lock-down, opacity and vendor lock-in are dear to me, so I may have got a bit worked up.

I wonder if perhaps we need to revive FOP...

>HTML is the interface you write to. It's not a document layout language for authoring

I'm with you on speration of concerns but HTML is not for rendering; it's for structuring and adding semantics to your documents. (CSS is for presentation control and JavaScript is for behavior.)

Well QT can easily render on any device context (like Canvas) or Xamarin could also easily ship their own controls to render on a Canvas (Microsoft owns more that enough code to do that).

It is a matter of time till we see desktop application hosted in a wasm enabled browser.

QT is already experimenting with rendering to Canvas using WASM in the browser, I've tried to call them out on it as bad practice a couple of times in the past.

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...

It may be sad to see the web grow well beyond it's original scope of a web of documents, but at the same time, consider the alternative: without a solid standardized execution format, that ground would likely be permanently ceded as being under the guise of the existing native players. We all can see where the native vendors are headed: it seems likely in 10 years, you will not be able to distribute binaries to users of mainstream native operating systems without going through a centralized approval process by those vendors. Apple set the ball in motion with the App Store a decade ago, and we're well on our way towards seeing the end result as it creeps into our 'legacy' PC operating systems.

The core dynamic of the web, more than document sharing, has been decentralization and removing lock-in and gatekeepers around content distributed through the Internet. As long as we continue to feel that is true (which becomes less believable as browser diversity declines) I feel we should be excited every time the web expands the scope of what can be done with it. It seems likely that 100 years from now, WASM will still exist, and it will allow people to create and distribute software without gatekeepers. If it never existed, or nothing like it did, it seems like the future would have been markedly worse for creators.

Each of these enabling browser technologies that get into the standards should be heralded as having potentially massive positive counterfactual effects on our ancestors and future selves (WebXR being another notable example, landing soon.)

I think about this too. uBlock origin is already running into issues with trackers disguising themselves as first-party, what about when those trackers are genuinely first-party, and bundled with the page's js (which you can't just outright block)? What happens when those trackers are bundled and compiled to wasm along with the sites js? Do we then analyze the wasm and try to guess which parts are necessary for a site to function and which parts are the tracking?

I'm not trying to be overly cynical here, all of these topics remind me of high school when I'd download mildly-sketchy executables, decompile them, and try figure out whether or not they were safe to run. I would love to poke around with reverse engineering wasm, but I'd rather not have to do that every time I visit a new website.

And this is why if blocking the "web"site JavaScript breaks the "web"site itself, then it never was a website to start with!

(Trackers using these kinds of tactics was only a matter of time between trackers and blockers...)

How I wish the problem were only breaking the "web" - these days, blocking tracking scripts on my router ends up breaking my desktop applications...

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

Just wow. I won't be surprised if doing something like that will break the os.

Yes, I'm not sure what the future holds for HTML but I'm confident the ultimate goal of webassembly is to make the browser a secure place to run full native like apps. That suggests some apps will not use HTML and just render everything themselves

There's some incentive to use HTML as it's indexable but it doesn't seem to be affecting mobile, although maybe mobile is in large part successful because of the web? Like the fact that you can post a tweet or a facebook post or a youtube video everywhere. Not sure that HTML is required for that and if it's not then it seems at least possible HTML will die.

>Yes, I'm not sure what the future holds for HTML but I'm confident the ultimate goal of webassembly is to make the browser a secure place to run full native like apps. That suggests some apps will not use HTML and just render everything themselves

Fortunately advertisers are renowned for their self-restraint, and can be trusted to not abuse this capability to simply shove in as many ads as they possible can, wherever they can, with masses of unblockable trackers underneath it all.

> I hope the evolution towards "browser as OS" doesn't hurt the content vs interactivity separation.

What, exactly, is "content"? Are binary formats content? (Audio, Video, etc?) Are textual comments and notes on other text content, or is only the work being commented on content? Are languages that rely on unicode encodings content? Must content be static or can it change frequently, even second by second? (Stock quotes, for example). Must things be easily scrapeable to be content?

Furthermore, must we lock down the structure of content from now until the end of time as HTML or ASCII, or should future generations be allowed to define what they mean by content?

There may be merit in a separation of content from browser, but we should not artificially limit ourselves to content that only fits into our legacy notion of what a browser is. If the browser must become a general purpose OS that can host whatever content people can dream up, I'm all for it.

No, the browser should not be used for all content. It's not designed for it, and we already have the OS itself for that, why do you want to add needless levels of abstraction??

I agree that we should free up the constraints. But text is everywhere for a good reason. Assuming that while we add more non-text, we still keep making more text too, I hope we don't lose the ability to openly parse that new text.

I worry more about the war against the URL than js progression. a simple way to send state to people is incredible.

"I love the historic separation between content and interactivity. I dislike that so many static pages won't load without JS and that we're moving further in that direction. ..." This I agree with you.

I think JavaScript and WebAssembly are not so bad programming languages, but I do think that scripts in web pages are overused (regardless what programming language is used, which isn't the issue).

Opaque single page apps are also bad for URL. Also I often use curl when I want to download a file (or in one case, to stream audio), so do not want to have to deal with the web browser to do that.

There's a push towards more server-side rendering, though it's generally a pain in the butt at the moment.

Also, executing JavaScript when scraping isn't that difficult, depending on what you're using to scrape. Node.js has Puppeteer: https://github.com/puppeteer/puppeteer

I agree that executing js when scraping isn't difficult, but wonder what that will look like a couple decades into the webassembly world. It might be closer in difficulty to trying to parse a netflix stream when scraping.

A couple of takeaways:

I’d love to see a XAML implementation for wasm, because it’s cleaner than html/css.

Looking forward to .NET Core running in warm.

I could see hackability actually improving since data and API access could be well-defined.

I could see Publishers adopting wasm so their websites are more under their control.

But most of all, software development getting out of the scripting business, which has such a wide range of misuse that it becomes expensive and unwieldy to maintain.

Funny thing is, that JS lead to exactly that, separation of content (APIs) and interactivity (PWA/SPA)

Perhaps for web applications but they're already like that.

Indeed, HTML = World Wide Web

If your "web"site can execute arbitrary code, and/or violates HTML guidelines (required for web crawlers or accessibility software to work, or for browsers to tweak the layout) and/or requires JavaScript / Flash / Java to run properly, then it might be part of the Internet, but it's certainly not part of the World Wide Web!

> Indeed, HTML = World Wide Web

The WWW is a network built on a set of protocols. HTML is a markup language that allows for (indeed, that is is designed to facilitate) embedding and linking binary and executable content, including javascript, flash, java, audio, video, as well as marking up text. HTML is one, but not the only, content-type which can be distributed across the WWW. This is fundamental to the design of HTTP and the intent of HTML and the web itself.

By your rationale, no site created after the addition of the <SCRIPT>, <APPLET> or <OBJECT> tags in HTML could be considered a part of the WWW, which would exclude the entirety of the web after HTML 3.2. This is "not even wrong" levels of ridiculousness.

Why do you find this stance ridiculous ?

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 ?

It's ridiculous because you're claiming that HTML is "the web", but that somehow the content that HTML marks up is "not the web."

I can guarantee that no one was looking at a Java applet or a Flash site in the 1990s and thinking "I don't know what this is, but it definitely isn't part of the World Wide Web."

>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 ?

On the other hand, Flash allowed animators and game developers an outlet for creative expression and distribution and led to an explosion of content, and launch more than a few professional careers. And Java applets... existed.

At the very least, I think it's controversial to say the web jumped the shark at that point.

>you might have noticed that you hardly see search engines pulling up results for supposedly "Web"Sites like Facebook or Discord or Twitter ?

I do see those results in search engines. Visibility in a search engine is a result of SEO and those sites' indexing rules, it has nothing to do with whether or not a site is part of the web - if I can reach it in a browser, it's part of the web by definition.

Some examples of search results from Facebook / Discord / Twitter ? And on the same level as other pages, not in some separate field ?

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

The browser becoming an OS inside the OS is at the crux at the issue. (And the main reason is likely Google trying to wrest control of personal computing from Microsoft.)

> Some examples of search results from Facebook / Discord / Twitter ? And on the same level as other pages, not in some separate field ?

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)." 

And in the Architecture of the World Wide Web[1] page we see a lot of information about URIs, HTTP requests, XML etc.

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

Right, thanks for the discussion, it has allowed me to pinpoint/remember the actual issue that I have :

It's about trying to push too many things on the Internet through HTTP, about trying to transform the browser into an OS inside an OS (which is a lot about the Microsoft vs Google battle over personal computing).

Protocols, not platforms ! https://news.ycombinator.com/item?id=20841059