0

JavaScript was designed specifically for browsers. It wasn't pulled off the shelf. So what were the reasons behind making it a scripting language rather than a compiled language?

With the introduction of WebAssembly, it's proof that compiled languages for the web is possible. But why wasn't it designed like that to begin with?

What benefits does a scripting language have over compiled languages in the domain of the web?

Proponents of compiled languages believe JavaScript is a terrible language that should never have been adopted, so I wonder, was the choice to make JavaScript scripted an arbitrary choice, or was it a choice to appeal to developers who can't handle a "real" language like C? Or some other reason?

What prevented a WebAssebly-like system from being implemented and adopted on the web to begin with?

user3743222
  • 18,345
  • 5
  • 69
  • 75
Croolsby
  • 1,416
  • 1
  • 14
  • 14
  • That is still a good question, I wonder if stackexchange would not be a better place to ask such – user3743222 Jun 13 '20 at 19:35
  • I've rephrased this question to be answerable with facts and citations. Can it be re-opened? – Croolsby Jun 19 '20 at 21:50
  • Honesty the question is somewhere in the middle. It may be answerable with facts, but there is hardly a definitive answer, meaning answers will still be opinion-based. I would suggest you move the question to stack exchange. For instance this is the kind of questions you can ask there: https://scifi.stackexchange.com/questions/233150/why-didnt-any-parents-complain-about-what-was-going-on-at-hogwarts – user3743222 Jun 23 '20 at 12:54

1 Answers1

1

JavaScript was developed to be

  • Light weight. A Windows 95 PC might have 0.002 gig of memory (2MB) and be running a fast Pentium processors at 0.06 GHz (60Mhz). Such a set up did not have the resources to load and execute Microsoft C++ while doing anything else. Memory paging worked overtime.
  • Faster than Java. Cranking up the Java engine in early Netscape browsers took forever, so visiting a web site using Java involved a long wait to load the plugin the first time a Java applet was encountered. For that reason alone use of Java client side never really took hold.
  • Easy to learn and use. This may have gone a bit overboard, but
    • Undeclared variables were supported (not the greatest idea),
    • All variables are like a Basic Variant variable - no need to declare or manage variables types.
    • No pointers. Well, there are and they're called "object" variables, but no need to deal with memory addresses, struct or union data types, or classes.
    • Used a syntax familiar to programmers familiar with the C family of languages.
    • Defined and introduced an environment with objects and built in access to global objects for programming within web pages.
    • Had a few mistakes, like returning "object" for the data type of null, and claiming objects were classes, but never mind.
Arguably JavaScript is a high level language, particularly in comparison to C ... known to many as a "high-level assembly language."

Finally there's cost effectiveness in learning and using some minimal JavaScript to affect a web page - which when introduced was all it was for.

Other choices could be ruled out fairly simply: a high level language such as Pascal was probably not considered, Java was too slow, C too low level and Visual Basic for Applications (vba) was a proprietary product of Microsoft Corporation.

TLDR;

It was designed to look like something developers already knew and wouldn't involve much effort in checking out. Netscape wanted developers using web page "programming" to encourage use of their browser. Alternative truths were told, including using "Java" as part of the language name.

More:

As covered on MDN WebAssembly is not a replacement for JavaScript, but in a browser context does support calls to JavaScript function wrappers.

A preliminary of JavaScript was introduced under the name of "Livescript" in version 2.02 beta of Netscape navigator in 1995. It introduced the <script> tag and exposed parts of Netsape's browser internals to page scripts - mostly to support injecting HTML into page source and dealing with mouse and keyboard events generated by form controls and page navigation.

At this time (the outset) there was neither demand nor a web eco-system for WebAssembly to fit into: interfaces for XMLHttpRequest's, the DOM, CSSOM, WebGL, IndexedDB, Web Audio API, etc. were years or decades away from being developed, implemented and standardized. Netscape was creating a demand for web scripting in the first place, using a scripting engine [initially] written by Brendan Eich in ten days.

traktor
  • 17,588
  • 4
  • 32
  • 53