What? I really don't understand this comment. The web is almost totally file-based. Visiting any website is just downloading and executing files. Including Javascript and CSS files is really just like a copy-paste operation--it just spews everything into the global namespace, which is that of the HTML file that you're currently viewing.

I definitely find "The web has NOTHING to do with files" less agreeable than what kyllo is saying.

Now think about what the browser runtime can do with "files". Well, next to nothing, because the browser doesn't have access to a filesystem.

For a browser to communicate with a filesystem it has to do so through HTTP and only in a very limited way.

That functionality depends entirely on the file system and the file in question, as much as the operations available on an HTTP resource depends on the verbs that the resource implements and how it implements them.

Also, a file system will typically not execute your files. Nothing stops you from executing an HTTP resource in the same manner. Say,

    <script type="text/javascript.js" src="bla/bla.js">

    curl http://bla.com/bla.sh | bash

Using the standard HTTP verbs, you can read, write, create and delete resources.

And that's for HTTP--not to mention the other major protocol FTP, the name of which is self-explanatory: File Transfer Protocol.

If you use the UNIX-like definition of file (to say nothing of the Plan 9 definition), which can include dynamically-generated streams such as /dev/random, then sure, the whole web is a set of files. I assume Plan 9 will even serve web sites out of its "filesystem" with the correct poking.

If you use the DOS-like definition of a static file (ignoring CON and a couple of other special cases), then, no, the web is not merely a set of fancy static files on disk. Many, many, many things never have a rest representation on disk as a simple file, even if one could theoretically be manifested at a point in time for some particular web page.

I sort of feel you're trying to conflate these two distinct definitions, and using the fact that the web is a set of stream-files to assert that the web is nothing but a set of disk-files, but that's equivocation.

No, it's kept as an in-memory structure. Certain representations are serialized and cached to files, yes, but that's just a optimization to reduce network requests; you can disable it without affecting the browser.

In particular, "grep -r kyllo ~/.cache/mozilla/firefox/" returns zero results, despite having this post open on my browser.

A web browser is really just a fancy, scriptable file viewer.

I disagree; it's an hypertext engine, with renderers for multiple media types. That hypertext can be loaded and/or cached from files, but that's an implementation detail that does not define the application.

And that's for HTTP--not to mention the other major protocol FTP, the name of which is self-explanatory: File Transfer Protocol.

That's not part of the web.

Smalltalk was actually getting a foothold in the enterprise when Java happened and everyone switched to it.

Eclipse was originally a Smalltalk environment (Visual Age for Smalltalk).

Yes, files also played big a role, because it was not possible to use source control systems with Smalltalk that worked across implementations. So you were bound to a specific vendor.

Actually, Smalltalk projects failed hard in the enterprise during the 90-ies which lead to Smalltalk's demise. 'Java killed Smalltalk' is a myth.

My employer's official application development language has changed just twice in the last 30 years, from COBOL -> Smalltalk -> Java.