6 ms·

Currently DOM interop is a distant wishlist, so I wouldn't hold my breath. JavaScript isn't a perfect language, but it does have native lexical scope, which ma

Currently DOM interop is a distant wishlist, so I wouldn't hold my breath. JavaScript isn't a perfect language, but it does have native lexical scope, which makes it a good fit for the architecture of web technologies. > Seriously JS should not be the lingua franca of the web What would you recommend for a replacement? When I typically see this it is from people can't figure out JavaScript as opposed to any rational technological reasoning. I cringe at the idea that people would offer forth really bad things that don't fit well merely to satisfy their own insecurities.

askvictor 9y ago
JS is not particularly accessible to beginners and makes it easy to write bad/dangerous code. A good programmer can write in anything, but it's the not-so-good programmers that you have to worry about.
- austincheney 9y ago
  Agreed. To be a strong candidate for a web scripting language you need three things: * native lexical scope. This is how all web technologies work. * Minimal reliance on white space as syntax. The language needs to be portable. Overloading white space as syntax makes a language more brittle, particularly in distribution. * Immediate interpretation without a prior static compile step. This keeps the code open to examination and minimizes compile time delays. Find another language that doesn't have all the stupid crap that JavaScript has and yet still excels in those three points and I will agree upon a replacement.
  - askvictor 9y ago
    While I don't agree with your second point, which seems to be there purely to exclude Python, I'll run with it so as not to devolve into religious war territory. How about Lua?
    - austincheney 9y ago
      A line terminator on *nix isn't a line terminator on Windows, which is a big deal if line termination ends a statement, and that assumes the file isn't modified in transit.
      - askvictor 9y ago
        And semicolons are optional in JavaScript, makes it whitespace sensitive I suppose.
        austincheney 9y ago
        Yes and no. The language specification requires the use of semicolons. If a semicolon is not supplied the interpreter will insert it for you. That magical insertion step is referred to as ASI. I don't remember if ASI is mentioned in the spec (as I don't think it is), but at the very least it is a de facto standard as missing ASI breaks the web. As stupid as all that sounds... semicolons are actually required to terminate statements in JavaScript.
        askvictor 9y ago
        And yet somehow the web doesn't break when one programmer uses \r\n while another uses \n. What was your original point about line terminators in this context?
        austincheney 9y ago
        I suppose that goes to how the language defines line termination and whether that language is OS aware. JS is completely independent of its execution context. Python may achieve this as well, and if so, then I am wrong in my thoughts about Python. Here is how JavaScript does this: * https://www.ecma-international.org/ecma-262/#sec-source-text https://www.ecma-international.org/ecma-262/#sec-source-text * https://www.ecma-international.org/ecma-262/#sec-line-terminators https://www.ecma-international.org/ecma-262/#sec-line-termin... ASI is defined in the spec here: https://www.ecma-international.org/ecma-262/#sec-automatic-semicolon-insertion https://www.ecma-international.org/ecma-262/#sec-automatic-s...
- ams6110 9y ago
  > JS is not particularly accessible to beginners and makes it easy to write bad/dangerous code That describes just about every programming language ever.
sixdimensional 9y ago
If you have the ability to compile <insert your favorite language> to WASM, and a little glue in the form of an isomorphic application framework (something to glue together server-side with client-side processes), I'd say it's quite a compelling alternative to JS. If you look at all the large Javascript frameworks, the increase in hardcore software engineering approaches taken to the front-end are an interesting signal. We have MVC in the front-end, we have MVC in the backend. Why have two MVCs if you can write an isomorphic application and have one? I'm thinking, for example, something like this... write C#, use a framework (fictional "Isomorph#") that can determine whether code should run on the client or server, and if you have interfaces to UI, you have the full solution. C# (client/server) + WASM/JS + remoting/web services + HTML/CSS/SVG/etc UI = real "apps". And that could just as easily have been Python (client/server) + WASM/JS and the rest of the stack, or Go + WASM/JS.. etc. etc. I was shocked when I learned of Skulpt.org, which is a python interpreter running in the browser - so we can't be far off from the same thing running on WebAssembly.
- austincheney 9y ago
  > If you look at all the large Javascript frameworks, the increase in hardcore software engineering approaches taken to the front-end are an interesting signal. We have MVC in the front-end, we have MVC in the backend. Why have two MVCs if you can write an isomorphic application and have one? That is not necessarily a language oriented concept. JavaScript can run on the front-end and back-end having an MVC architecture at both points. A better question is why a developer should wish to impose MVC at all at either point? These concepts become easier to reason about when the software runs at a single location using an HTTP service (on localhost) to talk amongst its clusters. It is just a multiprocess application with the bits running asynchronously from each other. When one (or more) ends of the environment are distant factors change drastically. First, you don't control the remote environment. You are completely at the mercy of what the user is willing to execute and they may modify your application in ways you do not anticipate. Secondly, there is a delay between distant ends. Regardless of the application or language in question the environmental and security considerations at hand will continue to impose a separated JavaScript-like web application.

askvictor 9y ago

JS is not particularly accessible to beginners and makes it easy to write bad/dangerous code. A good programmer can write in anything, but it's the not-so-good programmers that you have to worry about.

austincheney 9y ago
Agreed. To be a strong candidate for a web scripting language you need three things: * native lexical scope. This is how all web technologies work. * Minimal reliance on white space as syntax. The language needs to be portable. Overloading white space as syntax makes a language more brittle, particularly in distribution. * Immediate interpretation without a prior static compile step. This keeps the code open to examination and minimizes compile time delays. Find another language that doesn't have all the stupid crap that JavaScript has and yet still excels in those three points and I will agree upon a replacement.
- askvictor 9y ago
  While I don't agree with your second point, which seems to be there purely to exclude Python, I'll run with it so as not to devolve into religious war territory. How about Lua?
  - austincheney 9y ago
    A line terminator on *nix isn't a line terminator on Windows, which is a big deal if line termination ends a statement, and that assumes the file isn't modified in transit.
    - askvictor 9y ago
      And semicolons are optional in JavaScript, makes it whitespace sensitive I suppose.
      - austincheney 9y ago
        Yes and no. The language specification requires the use of semicolons. If a semicolon is not supplied the interpreter will insert it for you. That magical insertion step is referred to as ASI. I don't remember if ASI is mentioned in the spec (as I don't think it is), but at the very least it is a de facto standard as missing ASI breaks the web. As stupid as all that sounds... semicolons are actually required to terminate statements in JavaScript.
        askvictor 9y ago
        And yet somehow the web doesn't break when one programmer uses \r\n while another uses \n. What was your original point about line terminators in this context?
        austincheney 9y ago
        I suppose that goes to how the language defines line termination and whether that language is OS aware. JS is completely independent of its execution context. Python may achieve this as well, and if so, then I am wrong in my thoughts about Python. Here is how JavaScript does this: * https://www.ecma-international.org/ecma-262/#sec-source-text https://www.ecma-international.org/ecma-262/#sec-source-text * https://www.ecma-international.org/ecma-262/#sec-line-terminators https://www.ecma-international.org/ecma-262/#sec-line-termin... ASI is defined in the spec here: https://www.ecma-international.org/ecma-262/#sec-automatic-semicolon-insertion https://www.ecma-international.org/ecma-262/#sec-automatic-s...
ams6110 9y ago
> JS is not particularly accessible to beginners and makes it easy to write bad/dangerous code That describes just about every programming language ever.

sixdimensional 9y ago

If you have the ability to compile <insert your favorite language> to WASM, and a little glue in the form of an isomorphic application framework (something to glue together server-side with client-side processes), I'd say it's quite a compelling alternative to JS. If you look at all the large Javascript frameworks, the increase in hardcore software engineering approaches taken to the front-end are an interesting signal. We have MVC in the front-end, we have MVC in the backend. Why have two MVCs if you can write an isomorphic application and have one? I'm thinking, for example, something like this... write C#, use a framework (fictional "Isomorph#") that can determine whether code should run on the client or server, and if you have interfaces to UI, you have the full solution. C# (client/server) + WASM/JS + remoting/web services + HTML/CSS/SVG/etc UI = real "apps". And that could just as easily have been Python (client/server) + WASM/JS and the rest of the stack, or Go + WASM/JS.. etc. etc. I was shocked when I learned of Skulpt.org, which is a python interpreter running in the browser - so we can't be far off from the same thing running on WebAssembly.

austincheney 9y ago
> If you look at all the large Javascript frameworks, the increase in hardcore software engineering approaches taken to the front-end are an interesting signal. We have MVC in the front-end, we have MVC in the backend. Why have two MVCs if you can write an isomorphic application and have one? That is not necessarily a language oriented concept. JavaScript can run on the front-end and back-end having an MVC architecture at both points. A better question is why a developer should wish to impose MVC at all at either point? These concepts become easier to reason about when the software runs at a single location using an HTTP service (on localhost) to talk amongst its clusters. It is just a multiprocess application with the bits running asynchronously from each other. When one (or more) ends of the environment are distant factors change drastically. First, you don't control the remote environment. You are completely at the mercy of what the user is willing to execute and they may modify your application in ways you do not anticipate. Secondly, there is a delay between distant ends. Regardless of the application or language in question the environmental and security considerations at hand will continue to impose a separated JavaScript-like web application.