There's real irony in this statement, since you can't get much more fundamental than that. WorldWideWeb.app (Nexus) was created as a read-write client for both navigating and authoring content. Not only are modern Web apps not a necessary precondition for that, but neither JS nor any form of mobile code are necessary, either.
(The thing that Docs does wrong where "fundamentals" are concerned is its de-emphasis on the importance/role of the URL and making every Docs doc a sort of second-class publication that exists in this "other" kind of space—i.e., Google Drive and the Docs editor, which you always get a sense of being "inside", instead of the content just being out there on the Web.)
* If someone really wanted to be a stickler, they could point out that that you've set up Google Docs to fail your own rubric, since it involves indirect editing. The browser itself has no direct role in the editing process. It only manages to do so by fetching and executing the minified bundle on the Docs site.
Supposing I just want to create an internal tool that allows me to collaborate in realtime with my colleagues on a document (multiple cursors, everyone editing at once) and I have to do it in an existing browser because I don't write C++ and only have a few weeks to deliver - how would I do this without JS? Also, it needs to work on Android, iOS, Windows, and macOS in FF, Chrome, and Safari.
First, you're moving the goal posts...
> so you don't have to write JS
... and attacking a strawman. (No, I'm not worried that I might "have" to write JS. I've written a lot of JS. And I put a lot of effort making sure there was high quality documentation about the language in the early days of developer.mozilla.org—so that other people could have a nice time when they write JS.)
Secondly, you are aware—I'm certain of it—that the company behind Google Docs actually does have a browser.
So your users will need a specific browser to use your Web app?
This goes against a primary advantage of Web apps... They work on many different browsers/devices*
No. For the use case mentioned (editing and sharing docs in Google Docs), no one would be using a Web app, because there isn't one anymore. With the browser itself able to do directly what Google Docs is being used for, there's nothing left.
There are certainly refinements that can be added with JS, but JS is not a requirement, and certainly is not for rendering an editable page.
And as a user, it is a hard requirement for me too. I never want to go back to locking and versions, that's absolutely terrible and completely kills the workflow I have with my colleagues. Collaborative docs editing is single most awesome development of the modern web and users are choosing the otherwise not-so-good Google Docs solely based on this feature. Perhaps not every user needs it - but there are countless users that do. If I wanted to edit without collaboration I'd use Word - much better UX and document editing capabilities... Sadly no truly working collaboration - it's too much like locking/versions, so it's not an option. I'd rather use collaborative raw text editor than the best of the best locking/versioned WYSIWYGs.
I also think you grossly overestimate the average user's abilities. They literally cannot tell what is possible and what is not. They don't want simple, they want something to solve everything, as easily as possible.
Clearly this means that office politics is good for your company
Largest economies in Europe have the oldest and most drafty, poorly insulated housing stock. Therefore shitty housing stock must be good for the economy.
Largest economies in the world have the most pollution. Therefore pollution must be good for the economy.
Backwards reasoning.
The answer tends to be "wellll I hate most of these features anyways, let's get rid of them and then it can be as simple as HackerNews!" But obviously, millions of people use those features every day and like them. The tooling solves a real problem.
Desktop and Mobile application are reasonably robust, have very complex software and could do everything Facebook does trivially. All this 'robust tooling' has evolved because we are trying to shove an application into a browser, and despite decades of effort. it still kinda sucks.
If Apple, Microsoft and various distributions of Linux pulled the finger out of their collective asses and agreed on a half-decent, cross-platform GUI software package in 2005, none of this JS madness would exist.
And cross-platform APIs, cross-platform libc, cross-platform networking... and then the same shuffle on mobile, making sure everything is compatible? Supporting x86 and ARM?
The web does suck, there's no getting around that. HTML and the DOM are garbage even at their original purpose, let alone at writing applications, and everything on top of that is a kludge on a kludge on a kludge.
But let's not pretend dealing with OS APIs from the 90s is much better. We've been trying to get away from that as early as we could with e.g. Java.
I work in Fintech. There's a lot of tooling to make JS-as-a-language more robust, including TypeScript and some of the best linters, debuggers and introspective libraries available in the entire tech industry.
The only reason JS isn't used more than it is, is because its robustness is young, not non-existent.
This is what browsers are. You are describing browsers. They run on any device, on any architecture, and nowadays even on the edge. This isn't just about GUIs. I can't stand this lazy mentality of "pfft, I know better than these billion dollar companies, have they tried just making it good???"
He argues tooling is a necessary but not sufficient* condition to performant web apps that solve meaningful user-facing problems
You argue he claimed correlation is causation
*Edit: had necessary and sufficient backwards
I don't fully agree with the person you're responding too, but it feels like you're making their point for them with this. Users are engaging with a tool or some content for themselves and today. Startups are the ones dreaming of standing among the "largest, most successful websites" someday.
Users don't care how efficient or inefficient your development process is, or how much technical debt you carry, or how many concurrent users or requests you can run, or how scalable you are if things go well. If your service stands up and works for them today, none of those things are relevant to them at all.
That's not to say that the startups concerns aren't critical to making sure that the service is still capable tomorrow and the day after, and that the company doesn't collapse under bad process and inefficiencies, and that the service maintains utility rather than becoming data and stale. They're valid concerns.
But the users are so far removed from those concerns that it can be legitimately frustrating when pursuit of those long-term concerns degrades their immediate experience.
This is an old, tired take that boils down to "we should be ashamed for wanting nice things." If only everyone would just accept simple websites like HackerNews! This is backwards, it is user-blaming. It turns out that the web is an incredible platform that has revolutionized the world, and thousands of people have worked hard to build tools that make it easier to develop on. "Web fundamentals" can't give you Google Docs.