Does anyone know how we ended up with the hellish JavaScript when we had before FOX-toolkit, FXRuby and TCL? They're POSIX compliant and best of all, actually makes sense without losing context between html and js.

What is the context of your question? That is, how have you first encountered Javascript?

The history of Javascript is probably not relevant to your use, but you may be interested to see where this article leads you. What we know as Javascript is actually a superset of ECMAScript, and the current version as far as I am aware is ECMAScript-6.

I was not a fan of Javascript until recently, but I have come to like ECMAScript-6 even though my use of it is not broad.

Javascript (aka ECMAScript) is used primarily as the scripting language within web browsers. As you have compared it to FOX-Toolkit, FXRuby which is built on FOX-Toolkit, and TCL, I would guess you have encountered Javascript in a non-browser Node.js development environment (of which I am not a fan as yet). A description of your use case would help others provide more useful replies.

1 members found this post helpful.

The history of JavaScript is extremely well-known. The fact the it was made in ten days (for Netscape) is obviously a factor here.

You claim that those other languages are "POSIX-compliant". Are they? And how would that be relevant, considering that a web browser is not a POSIX-compliant platform?

you can find a lot of pages on the net about it, for example this one: https://buttondown.email/hillelwayne...pt-in-10-days/
or this: https://medium.com/javascript-non-gr...t-58f440d6b3d8

Do you have actually any problem to solve?

Thanks all!

I went from JS to Ruby and FXRuby with pleasure until I found out ERB can't spit out HTML styled FXRuby pages.

It's overall a lot easier to manage FXRuby than JS; especially updating contents. I felt cheated.

I don't know about the first two,
but I remember that tcl was an early candidate for web page scripting,
inside the browser,
as early as late 90's.

The "novel idea" of JavaScript was "prototypes." This gave an interpreted language great power at nominal cost – and "cost" was extremely important then. But it also made actual runtime behavior extremely runtime dependent ... which you see every day with so-called "ad blockers." You actually do not know, can be made unable to detect, and cannot change what the running code is actually doing on a particular computer.

It continues to baffle me why "JavaScript" won the race ... or, continues to do so. The various strange things that have been done to it, such as "just-in time machine code compiling which occurs on the client machine," continue to leave me shaking my head. "Why would any engineer ... engineer this?" And then, pour so much additional effort into it instead of replacing it?

By comparison, the truly p-compiled "Adobe Flash" was oh, so elegant. Where did "WASM" go?

WebAssembly? It didn't go anywhere. It's widely used.

Excellent. I'd lost touch with it lately.

However, it still mystifies me that people have poured effort into "just-in-time client-side compilers for JavaScript," when the obvious answer is and always has been to supply object code to the client rather than source. And, that "object code" could be anything that the situation required.

Likewise, why do we continue to build the back end of "web sites" using interpreted languages like PHP, Perl, Python, Ruby, and so-on? Why don't we just supply executable programs for the servers to run? The "at-run-time decisions" made by all of those interpreters, millions of times per second, do not change.