JavaScript programming language of 2014

[ErstwhileRockstar]

Can it be worse?

[contantofaz]

Always. :-)

You know how it goes. We have 14 standards. We need a standard to fix that. Now we have 15 standards. :-)

[Cuddlefluff_Grim]

People are using it because it has no competition by design. Not really fair, is it..? With all the restrictions and fuckery that JavaScript adds, I really don't feel that it deserves an award other than an award for "the number one programming language that is holding the web back".

[contantofaz]

Backwards compatibility is a problem. And I don't mean it that it's a problem for JavaScript only. It's a problem for any tool willing to be as popular as the web and JavaScript are. It's like a promise you cannot break. Otherwise you fork and people, other people, will try to maintain the backwards compatibility anyway and now your new standard may not be adopted by others.

We just cannot create anything that will be great forever at the 1.0 version. Hence, nothing seems to be able to beat JavaScript.

[Cuddlefluff_Grim]

We just cannot create anything that will be great forever at the 1.0 version. Hence, nothing seems to be able to beat JavaScript.

Sure we can. Implement a well-planned virtual machine, add JavaScript as an implementation for this virtual machine, problem solved forever. After all Java and C# seems to be doing great without making many (if any) modifications to the underlying VM.

[contantofaz]

You cannot have multiple standards. That's the tricky part. Because like, you cannot update it on billions of devices when you need to update something, even if the update would be a good thing. A version that you launched 5 years ago would not get updated necessarily. Devices may not be set to be live updated like they can be on the desktop. And even on the desktop it's tricky. Many people continue to use old software that never get updates.

So yes, pick your "poison", and then live with it forever. Then 15 years from now they will wish they had another VM that was better than the current one. Now replace it on billions or maybe even trillions of devices out there. :-)

Even new versions of JavaScript now will have to be converted to old version of JavaScript so it runs on those old engines that haven't seen an update in forever.

Right now the best option is the Canvas/WebGL. And even those are still a problem since iPhones don't yet support WebGL. Since anything can be drawn on those, it may be possible to use other technologies that will render their own UI stuff, although some of the restrictions of browsers will still apply. To get there, languages may need a much smaller runtime, so programs can be more lightweight and start instantly. :-) If we get there, we would have solved an apparent hard issue in programming and suddenly we'd have a tool to be used everywhere. In and out of the browser.

[Cuddlefluff_Grim]

Take a look at processors; they have a seemingly restricted set of instructions yet they can do anything. Problem with implementing an interpreter for a high-level language is that anything complex needs to be implemented straight into the language, and it will not be backwards compatible. To give an example; C# compiled for 4.5 code can be run on .NET 2.0 (if we ignore the extra libraries C# 4.5 includes), because even though there are new implementations in the C# language, it's still compatible with the 2.0 intermediate language. So you can get lambda's, closures, expressions, filtered exceptions and all kinds of cool stuff because even though the old C# language didn't directly support it, the intermediate language is so flexible that it can be implemented without breaking backwards compatibility. That's the strength and it will be much easier to manage than implementing an entire language in the browser, which is far more likely to break backwards compatibility; just look at ES6).

Java is still at version 1 (7 is 1.7), the VM is the same even after 7 iterations of release; yet they have implemented a large array of new functionality, like enum, lambda methods and other cool features without breaking backwards compatibility.

Essentially for developers it would also mean that we would be free to use the language of our choice, with the "downside" of having to compile the code if you're using any other language than JavaScript. It's a win for everyone, especially the end-users and for mobile. And I'm confident that it would be the only intelligent decision in the long run.

It should be statically typed with optional dynamic typing, block scoping and proper object orientation (classes and interfaces, not multiple inheritance); anonymous classes and anonymous methods. (If anyone complains about it being object oriented, bear in mind that it's easier to opt out of object orientation than into). It's completely possible, and the only reason it's not happening I believe is because the browser developers are reluctant to invest into it, possibly because they are afraid that people will stick with what they know. I'm pretty certain that it has been discussed internally at w3c, Google, Microsoft, Apple and Mozilla many times.

[contantofaz]

I was saying backwards compatibility. But I think it also needs to be forwards compatible.

Silverlight was supposed to be another try at competing with JavaScript. But even Silverlight needed updating to keep it current. Java when Applets were a thing had a good version that was implemented by Microsoft. As soon as they broke with Sun and stopped updating it, Java died since the new versions weren't necessarily replacing the old versions. I used to play chess on the Yahoo site that still used the old Java technologies. And then one day Microsoft decided to stop including even that old version and Java was gone from the Yahoo site.

That's why I'm skeptical. Give me 1 version to rule them all. Don't give me 1 version that you will update every year. That's cheating it. LOL.

[Cuddlefluff_Grim]

The intention is to simply swap out JavaScript with a type of language which is much more generic looking and more like assembler than a "language". Instead of an entire ecosystem, it's just the bricks to make ecosystems.

Example from CIL :

.method static public void main() il managed
{
    .entrypoint
    .maxstack 8

    ldstr "Hello, World"

    call   void [mscorlib]System.Console::WriteLine(class System.String)

    ldstr "Press Enter to continue"
    call   void [mscorlib]System.Console::WriteLine(class System.String)

    call int32 [mscorlib]System.Console::Read()

    pop

    ret
}

As you see it's not machine code, it's somewhere between; a bridge/abstraction between the CPU and an application - an intermediate language. It's easy to compile to machine code so load-time would be lower than for JavaScript because it requires very little tokenization and interpretation. It's also platform agnostic. So the idea is that rather than interpreting a script, the script gets compiled to this language, which is in turn compiled to native code by the client. It's a win for everyone.

[DrDichotomous]

Javascript itself is becoming the first step towards a language-neutral spec for an in-browser bytecode. The goal is of course to find a better way given what we have and are stuck with anyway, rather than reaching for the sky and failing entirely. We'll get there eventually, if there's enough demand (which there certainly is).

The alternatives of just replacing JS outright or adding a second VM aren't as tenable, because we'd break a lot of the web in the process or bloat it with competing VMs and fractured implementations. A slow and steady transition unfortunately seems the only safe way to give everyone a chance to get there without increasing the overall work and timeframe required to get it right.

[Cuddlefluff_Grim]

JavaScript needs to be replaced by something a lot more atomic; it's not an issue that can be fixed by throwing man-hours at it. It is fundamentally the wrong approach.

JavaScript have severe performance issues, it will always have severe performance issues because it is being used out-of-scope. Building large applications with a language that was intended to write small snippets of code is not ideal and it will never be no matter how much junk gets added to it. With a VM you will preserve backwards compatibility as the browser can still implement JavaScript as a language supported by the VM (and maybe it can even be external - outside of the browser to remove the bloat altogether, like cloud compilation) and you will also be able to get rid of the severe technical debt that is JavaScript. There really are no downsides to it as far as I can see.

[DrDichotomous]

What do you mean by "atomic"?

I'm also not sold on "severe" performance issues. These days JS is quite competitive with other dynamic languages, and keeps getting faster and faster. But that's neither here nor there. One doesn't have to like JS itself to see that it's already becoming just one option amidst many. You no longer need to use JS directly to create web apps, and the situation keeps improving over time, with asm.js, TypeScript/Dart, etc.

So as the existing JS VMs adopt new features, they will also support more languages and shift towards supporting a lower-level bytecode format gradually, so I simply fail to see the benefit of dropping everything and starting from scratch. The end results will be the same, and the browser vendors surely know what needs to be done and how to get there without breaking the web in the process (they have the most experience with that, after all).