4 ms·

>Screw this, it's 2AM and tomorrow I have to work to pay a mortgage. Have fun, you silly kids. Sorry, my comment ended up being more aggressive than i wanted,

>Screw this, it's 2AM and tomorrow I have to work to pay a mortgage. Have fun, you silly kids. Sorry, my comment ended up being more aggressive than i wanted, and i apologize. But I really do want to keep having a bit of a discussion without it dissolving to insults. Clearly we both think we are right, and i'm curious where the disconnect is. >... except the ones that were built exactly for the purpose of being sandboxed VMs: java applets, flash, mobile apps etc. But most of those are gone now (or at least gone from "popular" usage, and for good reason), and while mobile apps are still around and aren't going anywhere they aren't nearly as locked down as something like a web app is. When comparing mobile apps and web apps, i'm not saying one is better than the other, just that they are different. >The browser might have more prompts now simply because Microsoft showed everyone how not to do it with ActiveX, but it was not designed that way. Then current browsers were designed with more prompts... Maybe not from version 0, but their current versions are designed to have them. >That's staggering ignorance, sorry. Why do you think you have groups like "cdrom" in Linux? Now i'm not nearly as knowledgeable about linux as i should be, but I thought those groups all had to do with file access. I've installed applications and had them access GPS hardware, cameras, microphones, and more without a single prompt on multiple linux platforms (as well as windows). Is there something i'm missing there, or were my systems just not configured correctly? >No, that's exactly "web development" as you understand it (i.e. building "apps"), just on previous iterations. But again, that's like comparing current desktop/server application development with x86 real mode applications. Yeah, that was how it was done in the past, but it's not how it's done now. I agree with the rest of that statement though, JS was pretty awful, but it's grown significantly and I wouldn't call current day JS bad by any means. It definitely has it's warts (more than many other languages, but it is extremely capable and it's becoming a language i reach for more often than not. Once people successfully started writing non-trivial server side code in JS instead of alternatives that argument kind of goes out the window IMO. >No, in most cases they are simply accidents of history like XMLHttpRequest. I wouldn't call XMLHttpRequest an accident. It was designed to allow script access to Http Requests... And then it was adopted by other browser vendors because it was great functionality. There were mistakes in web development and javascript (like automatic semicolon insertion making it's way into the standard), but things like XMLHttpRequest wasn't one of them. >No, the web has mutated in an application platform. Big difference. Regardless of the terminology that you want to use, it is an application platform, and a very capable and secure one. It's far from perfect and it is still rapidly changing, but arguing about how awful it was in the past isn't going to make anyone's lives better. Like the linked article is saying, let's try to work on making sure that things get better in the future. Personally, I really like the direction everything is heading (with only a few exceptions).

toyg 10y ago
> 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.

toyg 10y ago

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