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.

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

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.

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.

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?

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.

Yet somehow, Python doesn't have this problem - it simply treats both types of line terminators as valid. So do all other modern languages that rely on whitespace.

And semicolons are optional in JavaScript, makes it whitespace sensitive I suppose.

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.

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?

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

ASI is defined in the spec here: https://www.ecma-international.org/ecma-262/#sec-automatic-s...

> JS is not particularly accessible to beginners and makes it easy to write bad/dangerous code

That describes just about every programming language ever.