-
Notifications
You must be signed in to change notification settings - Fork 0
JavaScript is not Asynchronous
Being synchronous/asynchronous is a matter of program behavior. It depends on the context & the environment.
What does the even mean?
Well, lets look at some things and revisit this.
JavaScript is a language.
It provides language constructs to build programs.
A set of building blocks.
It provides syntax and semantics.
Programs are instructions + data.
The nature of the programming languages is often described a few characteristics.
Whether they are
- Statically typed
- Dynamically typed
- Have strong typing vs weak/loose typing
- Object Oriented
- Object based
- Functional
- Imperative
They describe the mechanics of code execution, and operations.
A programming language is thus a tool that felicitates the building of programs.
JavaScript owing to history, had to be lightweight, and simple.
It had to execute in an Environment, the Netscape browser.
Brendan Eich, with his exposure to languages developed JavaScript in about 10 days.
Then JavaScript had been introduced to the world as the Browser's programming language.
It had not been taught as a pure language.
It has been taught contextually. That of the browser first, then Node next.
And everyone has learnt it in a context.
Whenever a language is learn inside a context, other players jump in.
We soon associate things of the environment as language characteristics & take them from granted.
Let us step away from JavaScript a little.
And talk about systems.
When a graphical user interface is built, we do not know how the user is going to use the system.
There is no do this, then that & that.
Every user is different.
They can use the system in a lot of different ways.
To build a system around unpredictability, we have to identify players of the system.
The system is always built around inputs.
Given this, do that -> is the common thought process.
Thus the players of the Graphical User interface become:
The actual human being, the input devices on the screen (buttons & others), Actions (how does the user interact with the system) and then reactions(what does the system do or how does it respond).
This whole system of thinking can be associated with "Event oriented systems".
Where an Event is "Oh the user did something".
Event oriented systems do not a single flow.
Event oriented systems, then have the concepts of
"Event", "Event Generators", "Event Consumers" & "Event Processing Engines".
Graphical user interfaces & systems need not be the only ones that think in this direction.
We could have other systems think like this too.
The OS for instance can think in terms of events.
A program has been run. The program is suspended. The program terminated with a failure. and so on.
The database system can think in terms of events also.
A new table has been created. Users have been assigned new permissions. A row has been inserted and so on.
A network program can also think in terms of events.
Oh i got a new connection. That client has sent me a new request message. Oops. We lost connection. and so on.
How does the system think about things happening in time.
That is the root philosophy.
Systems can be designed to think like this.
"Something happened" and "What should we do" -> is the way to think when building such systems.
The browser does a lot of things. One of things it does is it makes an application available to the user. A web application.
A web application is a graphical user interface system.
The best paradigm(thought process) available to such systems is "Events".
The execution environment for a web application thus is inherently Event Oriented.
JavaScript being the language of the web now has to be event oriented.
But it is not.
It is simply a language.
A system can be built that can account for events, how they are represented and how to process them.
The browser implements such a model & the system.
Now in the context of the browser, there are all the objects that are visual, that can be interacted with.
When interactions happen, events are created.
What should be done when events happen.
Well, event handlers should be executed.
What are event handlers? They are reactions to the actions happening in the system.
Technically, they are code blocks. 'Do Something' sorts.
Who provides the code?
The developer of the system does.
Oh! Cool.
What language?
In the context of the browser, JavaScript.
How can one write blocks of code to be executed.
JavaScript provides a construct called the function.
How are event handlers or blocks of code that do something upon something else happening specified.
Through "Event handler registration".
In the browser(and event oriented systems), an object can emit events.
Objects that emit events are called 'Event Emitters'.
Event Emitters have an interface description.
When something happens, they emit events.
Also they provide 'event handler registration' mechanisms.
These can be properties on the objects such as 'onclick'.
myButton.onclick = doSomething.
All event oriented systems have the same pattern.
The browser implements this paradigm. This thought process.
We learn JavaScript in the context of web applications.
In the context of the browser.
And that of Node.
So we think that JavaScript is 'Event Oriented'.
Also event oriented systems are inherently asynchronous.
Thus, we think that JavaScript is Asynchronous.
But it is not.
It is just a language. A tool to describe intent. It has a few building blocks to construct programs.
The language features. And how it thinks about its constructs. Nothing more. Nothing less.
The nature of a program and the behavior of the program is attributed to its execution environment.
Thus asynchronous/synchronous execution becomes a characteristic of the program's behavior and the environment and how it is modeled.
An 'Event oriented system' is a thought process.
It brings in the question -> How do we think about this system?
The browser, node are environments that force us to think in such terms.
They implement this thought process.
A language on the other hand is a tool. A utility. To express intent.
It is important to separate environments, paradigms & the tools to build programs.
So that we understand everything separately. And then everything working together.
This makes us learn other languages. And become polyglots.
This make us think about Systems. About Architecture. About Environments. About Responsibilities.
And we develop other systems. Better.
And use other languages. Better.
And think. Better.
Hope this makes you, dear developer, appreciative of many things. And helps you understand things.
With Love, JavaScript
PS: This is based on interactions with my friend. JavaScript. Whom i love so!