3 ms·

There's a difference between a language and an API. JavaScript is a very powerful language in itself that has features like closures to please professional deve

There's a difference between a language and an API. JavaScript is a very powerful language in itself that has features like closures to please professional developers but is also easy to grasp by novice or amateur programmers. This makes it ideal for the role of being a client-side script engine of the web. There might be issues with the standard JavaScript API (I mean, the DOM) but this could be fixed by correcting the API, there's no need to "kill" the language.

gdp 17y ago
Which API are you talking about? I don't mean to sound condescending, but following the general tone of your post, are you sure you know what an API is? The take-home point for me was that the execution model for Javascript is inherently poor security-wise. Changing this would require changing the semantics of the language (i.e. you would break most Javascript code in existence), at which point it essentially ceases to be Javascript (unless you want to start to argue about replacing axe handles and such, but the original point stands - you could take a new language which fixes the execution model and call it "Javascript", but it would still not be the Javascript we use right now).
- DrJokepu 17y ago
  I was, of course, talking about the JavaScript DOM API: https://developer.mozilla.org/En/DOM https://developer.mozilla.org/En/DOM
  - gdp 17y ago
    That was both not-obvious from your comment, and quite irrelevant, given that I can only see one complaint that stems from the design of the DOM API. The rest of them are all based on the flawed language security model. Basically an "API" is only as dangerous as the language that permits its use.
    - axod 17y ago
      It's not a flawed language security model. Change browsers to use separate execution contexts for each <script> tag, and specify permissions about what they can and can't do to the containing context. <script> tags are not part of the js language.
      - gdp 17y ago
        But there is lots of code that relies upon that behaviour. We can argue about the exact source of it if you like, but if the language execution model is dependent on that behaviour, then the language execution model is flawed, which was my original point, I think.
        axod 17y ago
        There's no js code that relies on <script> tags using the same execution context, because <script> is not js code. It's an HTML tag. It's outside of the scope of javascript. It's the Browser security model that needs toughening up.
        gdp 17y ago
        You have chosen a particularly strange definition of "code". <script> var a = "hello, world"; </script> <script> doSomething(a); </script> My program is either syntactically invalid (because 'a' is undefined) or functionally incorrect (because it doesn't do anything) if you treat these blocks separately. This is Javascript code that relies upon script tags using the same execution context. Once again, I (recursively) refer you to this comment: http://news.ycombinator.org/item?id=843320 http://news.ycombinator.org/item?id=843320
        axod 17y ago
        I'm tired of this now, you don't seem to be reading comments, and putting up silly straw men. You're well aware we're talking about <script> tags when used to load external source from other domains, so your example above is pretty irrelevant. Good luck on your quest to rid the world of javascript!
  - jgrahamc 17y ago
    The DOM is unrelated to JavaScript's global variable/function/everything oriented nature, the ability to do stuff like redefine the Object constructor, the fact that there's no real protection between objects (e.g. guess the name of a variable or function and you have access).
    - axod 17y ago
      The issue isn't that js has a global namespace, it's that scripts included on the same page all use the same global namespace. This could easily be changed/fixed in browsers without changing anything about js. It'd be nice to be able to specify in a <script> tag if you want a new js execution context setup, and also what access you want to give that script to your own execution context. For example, maybe: <script src=http://widgetmaker.com/wm.js http://widgetmaker.com/wm.js newContext=true permissions="modifyDom:false,readNamespace=false,passMessages=true"> <script src=http://hitcounter.com http://hitcounter.com newContext=true permissions="NONE"> With such a scheme, everything is executing in completely separate contexts, with clear permissions about their interactions. Some script messes with the Object constructor? only affects its own execution context. Saying a blanket "js must die" isn't really understanding the issues, as they are actually in browsers, not js. It's like saying python/perl/etc is an insecure language and must die, because it usually shares the same filesystem between processes.
      - gdp 17y ago
        The security needs to be in the browser - as in the user needs to enforce the security, not the code - leaving it up to developers to specify what permissions things should have is a recipe for lazy developers getting us into a situation much like the one we're in now.
        axod 17y ago
        I agree! Improve the BROWSER security model. Javascript is an innocent bystander in the mess. It's the browser that allows 20 scripts from different domains all come together in the same execution context each with full permission to do anything.

gdp 17y ago

Which API are you talking about? I don't mean to sound condescending, but following the general tone of your post, are you sure you know what an API is? The take-home point for me was that the execution model for Javascript is inherently poor security-wise. Changing this would require changing the semantics of the language (i.e. you would break most Javascript code in existence), at which point it essentially ceases to be Javascript (unless you want to start to argue about replacing axe handles and such, but the original point stands - you could take a new language which fixes the execution model and call it "Javascript", but it would still not be the Javascript we use right now).

DrJokepu 17y ago
I was, of course, talking about the JavaScript DOM API: https://developer.mozilla.org/En/DOM https://developer.mozilla.org/En/DOM
- gdp 17y ago
  That was both not-obvious from your comment, and quite irrelevant, given that I can only see one complaint that stems from the design of the DOM API. The rest of them are all based on the flawed language security model. Basically an "API" is only as dangerous as the language that permits its use.
  - axod 17y ago
    It's not a flawed language security model. Change browsers to use separate execution contexts for each <script> tag, and specify permissions about what they can and can't do to the containing context. <script> tags are not part of the js language.
    - gdp 17y ago
      But there is lots of code that relies upon that behaviour. We can argue about the exact source of it if you like, but if the language execution model is dependent on that behaviour, then the language execution model is flawed, which was my original point, I think.
      - axod 17y ago
        There's no js code that relies on <script> tags using the same execution context, because <script> is not js code. It's an HTML tag. It's outside of the scope of javascript. It's the Browser security model that needs toughening up.
        gdp 17y ago
        You have chosen a particularly strange definition of "code". <script> var a = "hello, world"; </script> <script> doSomething(a); </script> My program is either syntactically invalid (because 'a' is undefined) or functionally incorrect (because it doesn't do anything) if you treat these blocks separately. This is Javascript code that relies upon script tags using the same execution context. Once again, I (recursively) refer you to this comment: http://news.ycombinator.org/item?id=843320 http://news.ycombinator.org/item?id=843320
        axod 17y ago
        I'm tired of this now, you don't seem to be reading comments, and putting up silly straw men. You're well aware we're talking about <script> tags when used to load external source from other domains, so your example above is pretty irrelevant. Good luck on your quest to rid the world of javascript!
- jgrahamc 17y ago
  The DOM is unrelated to JavaScript's global variable/function/everything oriented nature, the ability to do stuff like redefine the Object constructor, the fact that there's no real protection between objects (e.g. guess the name of a variable or function and you have access).
  - axod 17y ago
    The issue isn't that js has a global namespace, it's that scripts included on the same page all use the same global namespace. This could easily be changed/fixed in browsers without changing anything about js. It'd be nice to be able to specify in a <script> tag if you want a new js execution context setup, and also what access you want to give that script to your own execution context. For example, maybe: <script src=http://widgetmaker.com/wm.js http://widgetmaker.com/wm.js newContext=true permissions="modifyDom:false,readNamespace=false,passMessages=true"> <script src=http://hitcounter.com http://hitcounter.com newContext=true permissions="NONE"> With such a scheme, everything is executing in completely separate contexts, with clear permissions about their interactions. Some script messes with the Object constructor? only affects its own execution context. Saying a blanket "js must die" isn't really understanding the issues, as they are actually in browsers, not js. It's like saying python/perl/etc is an insecure language and must die, because it usually shares the same filesystem between processes.
    - gdp 17y ago
      The security needs to be in the browser - as in the user needs to enforce the security, not the code - leaving it up to developers to specify what permissions things should have is a recipe for lazy developers getting us into a situation much like the one we're in now.
      - axod 17y ago
        I agree! Improve the BROWSER security model. Javascript is an innocent bystander in the mess. It's the browser that allows 20 scripts from different domains all come together in the same execution context each with full permission to do anything.