> mobile apps [...] aren't nearly as locked down as something like a web app is.Not sure why you brought up mobile, but anyway... mobile OSs have very fine-grained policies and sandboxes that can lock apps down as tight as any website. The problem is that most of them get waived away by lazy developers and unsuspecting users, and walled gardens' owners have an interest in not bothering developers too much (for fear of losing them). It was like this for browsers as well, when they were an IE monoculture; and it will likely go back there if Mozilla ever croaks under pressure from Google.
> Then current browsers were designed with more prompts
Yeah, but current browsers are part of the problem: they've decided to be runtimes, so they will act as runtimes. People who want document browsers have been left by the wayside. That is my point in a nutshell.
> I thought those groups all had to do with file access.
Of course: standard Unix philosophy is that everything is a file, including your devices; so they were secured as such.
> Is there something i'm missing there, or were my systems just not configured correctly?
Linux desktops can be locked down to various degrees; there are so many different ways to enforce policies on all sorts of things (from traditional permissions to ACLs to SELinux to PolicyKit and whatnot). What distributions decide to allow out of the box is due to their target markets. Try doing the same on OpenBSD, to see what life is when a system is completely locked down by default: you'll have to explicitly authorize many, many things...
> Yeah, that was how it was done in the past, but it's not how it's done now.
The point is, the aim of the effort is the same; but since people couldn't agree on the best way to do it, it was done on the most politically acceptable way, piggybacking on a system that was not designed for it but that nobody could object to.
It's a bit like QWERTY: a keyboard layout nobody ever liked, but that somehow became The One Way To Type. JS was retrofitted to replace plugins and be the "web runtime" for everyone. In a way, that was the objective that Firefox pursued almost from the start, although it came to life in a slightly different way from their specific implementation.
I'm not saying JS is completely bad, but that it was clearly designed for "quick and dirty" scripts and it shows. There is very little philosophy, very few stylistical choices in the core language beyond "it has to be OO" when OO meant Java and Smalltalk. It's to "mainstream" OO languages what PHP is to C: a quick hack to use a familiar syntax in a context where the original cannot go.
Sure, it's evolved and we can use it to do all sorts of things (which is not at all a recent development, btw; Netscape had a server-side product almost from the beginning), but its roots are undeniably weak. The fact that we need rocket-science VMs on state-of-the-art processors to move a few boxes with it (slowly) IMHO is proof enough.
>I wouldn't call XMLHttpRequest an accident.
It pretty much is. Microsoft's vision for it was a mechanism to fetch XML and mash it with XSL, which is what the web was supposed to become at one point.
It became a way for the runtime to interact with any networked resource, for all sorts of purposes (loading other code, APIs, authentication, tracking, data etc etc) without having to reload the full layout.
But again, it did not come from "the web runtime camp" and it wasn't even a JS thing (it was a COM object): it was a cool feature added by a browser vendor with a completely different view of what the web should be,
but it was retrofitted because it sorta worked. They had to tack-on same-origin limitations because originally it was ripe for abuse, and tbh even now it looks a bit silly when compared with any other mainstream language http-request implementation. Random evolution at its finest.
I say this as someone who, when "ajax" started to become a buzzword, was like "oh yeah I've been pushing that concept for ages". I just think we've gone too far.
> Personally, I really like the direction everything is heading (with only a few exceptions).
Well then, to each his own :) personally, I'd very much prefer to start again with a clear separation between "content browser" and "application runtime".
You can have your runtime, but let me read content in peace without having to execute anything. Which is why I've always liked RSS: I fetch the content and then I'm free to read it as I damn well like.
Beside, a runtime rebuilt from scratch could do cool things like supporting multiple languages by design, an extended stdlib, proper sockets, etc etc, removing the need for the current "selection of features by marketing popularity" process that produces framework over framework over framework.