It might be because "just plain browser" got a very bad name back in the IE vs Firefox wars, and so everyone ran for the shelter of frameworks as protection against all the unimplemented and half-/buggily-implemented browser stuff? And now that "framework first" mentality has stuck?
just utterly insane things like, there's no builtin functions (or at least not sensibly named, easy to find ones) to test whether an object is an array, is Null or not, fallbacks for Null handling, vanilla 'sort' is DESTRUCTIVE, yeeeeagh. Things that, if you're doing database-query type stuff, you just don't want anywhere near your code.
It *hasn't* been fixed. Or rather, the dangerous, unsafe stuff is still there right alongside the correct stuff.
So, much better to never trust the builtins, just indirect everything through a different namespace. Otherwise for every single method call you have to go 'is this one of the good ones? or the evil ones?' and you'll occasionally get it wrong.
I can (and am looking at right now) run an entire emulated BBC Model B Computer running a BASIC adventure game in the browser... except there's no way of saving the game because, shrug, browsers aren't allowed to write to the local filesystem. Even just to one designated file selected manually by an out-of-browser 'file open' dialog box.
I guess I'm getting my information from nobody ever using it! Like, for instance, Tiddlywiki writing a whole baroque EXE plus plugin system to implement saving!
So it's there and it works? Cross browsers? And we can save files in it? And remember the file name across browser invocations?
like I wouldn't mind if, eg, I had to manually associate any given URL with a local folder, and then it couldn't ever access anything outside that folder (unless I manually accessed the file navigation UI, which the browser wouldn't be able to fake). I think I could cope with that level of manual intervention and I think that would give enough security maybe?
@natecull @teleclimber see i am a bit of a radical and i think fundamentally filesystems are a bad idea and if we can avoid ever using them we should. the main reason we are still kinda forced into using them is it’s the only non limited way we have of sharing information between systems, so if someone forward thinking like apple stops us from having a “real” file system it can feel like handcuffs when we want to get data in or out.
I wouldn't, in principle, be *completely* against replacing filesystems, with some kind of object store, as long as
1) I can still preserve my data as readable and transferrable to other media on a timeframe of at least several decades
2) access to my data is not gated through any Internet-connected entity.
I want the right to have my data stay physically local to my machine, and the right to copy and move it onto physical media.
@natecull @teleclimber the appealing thing about a file is that it’s a fucking thing. humans can deal with fucking things. we can’t as easily deal with giant webs of interdependant references, as i’ve seen you musing about.
the mac classic file system was really something though. each file could have a blob of data in it, sure, as you expect, but each one also had a database associated with it. if you’re an app developer you could just write to that database, and that’s your “file”
@natecull @teleclimber so you could really split the concept of “file system” into two peices: the physical inplementation, and the UI that presents users with “things”, and the list of affordances those things permit. the physical implementation of the thing doesn’t really need to be a stream of bytes.
Agreed, a stream of bytes is not very wonderful, it forces every program to be its own from-scratch parser, which is a hassle and a security nightmare.
I wonder though if we could do something like I'm suggesting (eg: gather up all the external references and bundle them together) for object-soup systems. I feel like it would solve a lot of issues we currently have with package management, version control, etc. The same pattern happens again and again.
@natecull @teleclimber i feel like maybe this was the missed lesson of smalltalk’s OOP. not that I’ve used it, but i think the idea was an “object” was supposed to be “the fucking thing”, and that you should be able to expect to pick up an object, stick it in an entirely foreign system, and have it just fucking work without it complsining about missing libraries. that the boundary of the object is message passing, not binary or lexical linkages. like the js worker api.
But of course it turned out that an object always relied on a whole bunch of other objects, and there was no way for objects to 'literally contain' other objects other than just referring to them. So we got all sorts of non-object metaphors for 'containment'. Modules, libraries, packages, projects...
@natecull @teleclimber so, i think that’s the key is if you want a thing to be self contained, it can’t reference or depend on anything, and where possible it interacts only with the outside world via messages.
it’s still possible to build a house of cards out of that but the goal would be to design the system to make not doing that the easier choice
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!