Was ist JavaScript?

Bereits in meinem Eingangspost habe ich erwähnt, dass man für die Entwicklung moderner Web-Applikationen immer häufiger auf den MEAN-Stack zurückgreift und dieser wohl den LAMP-Stack in nicht allzu ferner Zukunft komplett ablösen wird. In diesem Zusammenhang lohnt es sich noch einmal kurz auf die namensgebenden Bestandteile des MEAN-Stacks einzugehen:

  • MongoDB
  • Express.js
  • AngularJS
  • Node.js

Dem aufmerksamen Leser wird nicht entgangen sein, dass bei drei von vier Bestandteilen die Abkürzung js – JavaScript enthalten ist. Das MongoDB nicht auch etwas mit JavaScript zu tun hat ist wohl der Tatsache geschuldet, dass MongoDB eine NOSQL Datenbank ist. Somit ist Javascript sowohl im Frontend als auch im Backend zu finden. Mit Frontend bezeichnet man alles, was für den Aufbau einer Benutzeroberfläche und deren Interaktion nötig ist, sodass der Benutzer eine Applikation benutzen kann. Mit Backend bezeichnet man alle Prozesse, die nichts mit der Benutzeroberfläche zu tun haben und die Programmlogik bereitstellen. In den meisten Fällen wird die Applikation die Benutzereingaben validieren/verarbeiten und an die Datenbank (MongoDB) weitergeben.

Im Jahr 1995 wurde das heutige JavaScript zuerst unter dem Namen „Mocha“ von Brendon Eich (zu dieser Zeit tätig bei Netscape) für den Netscape Navigator entwickelt. Nachdem Sun im Dezember 1995 Netscape die Markenrechte für JavaScript einräumte nutzte Netscape dies fortan um seinen Browser besser unter dem zu dieser Zeit stattfindenden Java Hype zu vermarkten. Dabei darf JavaScript nicht mit Java verwechselt werden! Während Javascript als Skriptsprache konzipiert wurde um Inhalte im Browserfenster dynamischer zu machen wurde Java von Beginn an mit einem universelleren Anspruch einer objektorientierten klassenbasierten Programmiersprache vorgestellt – mithilfe einer sogenannten Java Virtual Machine  (JVM) sollte es möglich sein den einmal entworfenen und kompilierten Programmcode auf einem beliebigen Geräten auszuführen. Eine Gegenüberstellung findet sich in Tabelle unter diesem Textblock.

JavaScript Java
Objektorientiert. Keine Unterscheidung zwischen Typen von Objekten. Vererbung mittels des Prototypen-Mechanismus, jedes beliebige Objekt kann dynamisch um Eigenschaften und Methoden erweitert werden. Klassenbasiert. Objekte werden in Klassen und Instanzen unterteilt, Vererbung erfolgt vollständig über die Klassenhierarchie. Klassen und Instanzen können keine Eigenschaften und Methoden dynamisch hinzugefügt werden.
Datentypen von Variablen werden nicht deklariert (dynamische Typisierung) Datentypen von Variablen müssen deklariert werden (statische Typisierung)
Kein automatischer Schreibzugriff auf die Festplatte. Kein automatischer Schreibzugriff auf die Festplatte.

Quelle: https://developer.mozilla.org/de/docs/Web/JavaScript/Guide/Einf%C3%BChrung

Um die Sprache JavScript plattformübergreifend verfügbar zu machen hat die Ecma International im Jahr 1997 die ECMA-262 Spezifikation veröffentlicht, die von Browserherstellern genutzt werden konnten. Leider wurden diese Spezifikationen damals nicht von allen Browserherstellern vollständig umgesetzt, was dazu führte, dass sich der Programmcode unterschiedlich verhielt, je nachdem in welchem Browser er ausgeführt wurde.

Insbesondere Microsoft’s Internet Explorer ist hier zu nennen, der in dieser Zeit mit zu den populärsten Browsern gehörte. Dadurch sprach sich unter den Entwicklern herum, dass JavaScript nicht unbedingt eine ideale Programmiersprache sei und man so gut es geht auf die Sprache verzichten sollte. Seit dem Jahr 1997 wurde die ECMA-262 Spezifikation weiterentwickelt und mehrere Aktualisierungen dieser Spezifikation veröffentlicht. Von momentaner Bedeutung für Web-Applikationen sind die momentan weit verbreitete stabile Version 5 (veröffentlicht 2009) und die in Umsetzung befindliche Version 6 (veröffentlicht 2015). Mit Umsetzung ist dabei gemeint, dass die ECMA-262 Version 6 im letzten Juli 2015 finalisiert wurde, aber von den Browserherstellern nur teilweise implementiert wurde.

Die Implementierung in den Browsern geschieht über Javascript Interpreter (auch „Engines“ genannt). Im Firefox werkelt die Spidermonkey Engine, während im Google Chrome die V8 Engine den Javascript Code interpretiert. Im Regelfall merkt der Anwender natürlich nichts von der Javascript Engine, welche die Web-Seiten insgesamt dynamischer macht. Dennoch ist in den letzten Jahren ein Wetttbewerb bzgl. der performantesten Engine ausgebrochen. Die Seite arewefastyet.com stellt eine Übersicht zu Ergebnissen der Browser in unterschiedlichen Standardtest’s dar.

arewefastyet

Dabei fällt auf, dass Chrome im „Turbofan“ Modus deutlich über den Kandidaten Chrome V8 und Mozilla Spidermonkey liegt. Eine kurze Recherche zum „Turbofan“ Modus von Chrome zeigt, dass dieser Modus auf einem Projekt von Google beruht die V8-Engine durch komplettes Code Refactoring von bestimmten Funktionen noch schneller zu machen. Da noch nicht die komplette V8 Engine in allen Funktionen neu geschrieben wurde, bzw. die neu geschriebenen Teile noch nicht performanter sind als die alten wurden der „Turbofan“ Modus nur bei bestimmten Funktionen ab Chrome 41 aktiviert.

Quelle: http://blog.chromium.org/2015/07/revving-up-javascript-performance-with.html

An diesem Punkt möchte ich den Beitrag zur Javascript Einführung nun beenden. Ich denke es ist eine gute, kurze Zusammenfassung zur Entstehungsgeschichte von Javascript und seiner Bedeutung auf Clients in modernen Web-Applikationen. Der nächste Beitrag wird das Thema der serverseitigen Javascript Nutzung behandeln.

Startschuss dieses Blogs

Herzlich willkommen auf meinem Blog. Ich möchte auf diesem Blog in Zukunft über den „nächsten Stack“ bloggen und lade Sie recht herzlich ein mein Blog zu Ihrem RSS-Reader hinzuzufügen und regelmäßig für die neuesten Einträge vorbeizuschauen. Ich möchte zunächst noch einmal grob umschreiben, was überhaupt der „nächste Stack“ ist.

In der IT-Entwicklung spricht man von einem Stack, wenn man die benötigten Komponenten beschreibt die zum Betrieb einer (Web)Applikation benötigt werden. Hierin liegt auch der Grund für dieses Blog: Ich interessiere mich für alles, was mit der Entwicklung moderner Applikationen zu tun hat – zunächst war ich rein privat daran interessiert. Doch seit meinem Berufseinstieg interessiert mich dieses Thema auch aus beruflicher Hinsicht, da ich als SAP Berater UI5 und Fiori Applikationen erstelle. Da die Grenzen zwischen Web- und Nicht-Web Applikationen zunehmend verschwimmen  (worauf ich ebenfalls im Laufe dieses Blogs eingehen möchte) werde ich im weiteren Verlauf des Blogs keine Unterscheidung diesbezüglich mehr machen. Hat man erst einmal alle Komponenten auf einem System vorhanden so bilden Sie eine Plattform auf der die gewünschte Applikation ohne weitere Einschränkungen lauffähig ist. Wikipedia beschreibt den (Solution) Stack folgendermaßen:

In the traditional sense, computing, a solution stack is a set of software subsystems or components needed to create a complete platform such that no additional software is needed to support applications. Applications are said to „run on“ or „run on top of“ the resulting platform. Some definitions of a platform overlap with what is known as system software.
https://en.wikipedia.org/wiki/Solution_stack

Um die Jahrtausendwende war der LAMP Stack sehr populär (und ist es wahrscheinlich nach wie vor). LAMP steht dabei für:

  • Linux
  • Apache
  • MySQL
  • PHP

Der WAMP Stack, bei dem Windows anstatt Linux als Betriebssystem verwendet wird, sei hier nur der Vollständigkeit halber erwähnt.  Diese WordPress Installation läuft übrigens auf einem LAMP Stack bei uberspace.de. Uberspace ist ein deutscher Hosting Anbieter mit dem Fokus auf größtmögliche technische Tiefe (durch Terminalzugriff auf einen Shared-CentOS Server) bei gleichzeitig sehr innovativem Preismodell (pay-what-you-want). Die Kombination aus Uberspace und WordPress habe ich gewählt, da Sie es jemandem mit wenig Zeit erlaubt sich auf das wesentliche zu konzentrieren – Bloggen auf einer stabilen Plattform. Gleichzeitig hat man bei dieser Kombination vielfältige Ansatzpunkte, falls man doch einmal ins Detail gehen möchte.  Zurück zu den Stacks. In den letzten Jahren wurde der MEAN-Stack immer populärer und erweckte damit auch mein Interesse – er besteht aus:

  • MongoDB
  • Express.js
  • AngularJS
  • Node.js

Auffallend dabei ist, dass in drei von vier Komponenten JS, was für Javascript steht, enthalten ist. Die Bedeutung und das Interesse am MEAN Stacks gegenüber dem klassischen LAMP Stack fällt im Jahr 2015 eindeutig zu Gunsten des MEAN-Stacks aus. Diese Aussage leite ich aus einer Google Trends Analyse ab:

Da ich auch beruflich viel mit Javascript zu tun habe werde ich in den kommenden Beiträge Ihnen zunächst die Sprache JavaScript als auch diesen Stack näher bringen, bevor ich zu einigen praktischen Vorstellungen komme. Ich will dieses Blog letztendlich aber nicht auf diesen einen Stack konzentrieren, denn ich habe in den letzten Jahren vermehrt das Gefühl, dass der Stack (also die Grundlage der Applikationen) permanent in Frage gestellt wird vom nächsten „großen Ding“. Sei es ob Apps für die mobilen Betriebssysteme iOS oder Android mit HTML5 und einem nativ laufenden „Browser“ wie z.B. Cordova ausgeführt werden oder aber dem Aufstieg von Node.js, einer serverseitigen JavaScript Implementierung welche nicht nur Grundlage für viele professionelle API’s ist sondern zunehmend auch Desktop Software wie z.B. der von github in Community Arbeit programmierte Atom-Editor. Auch grundsätzlichere Debatten um die Client/Server Architektur kommen mit der Entwicklung von Cloud Computing erstarken in letzter Zeit. So wirft ein Artikel auf der Webseite Techcrunch die Frage auf, ob wir in Zukunft überhaupt noch Server für die Applikatitonen brauchen oder ob Server gänzlich durch Cloud Computing obsolet werden:

Most companies today develop applications and deploy them on servers — whether on-premises or in the cloud. That means figuring out how much server, storage and database power they need ahead of time, and deploying all of the hardware and software it takes to run the application. Suppose you didn’t want to deal with all of that and were looking for a new model that handled all of the underlying infrastructure deployment for you?Amazon Web Services’ Lambda Service offers a way to do just that today. With Lambda, instead of deploying these massively large applications, you deploy an application with some single-action triggers and you only pay for the compute power you use, priced in 100 millisecond increments of usage. You can have as many triggers as you like running in tandem or separately. When the conditions are met, it triggers the programmed actions.Welcome to the world of the serverless app

http://techcrunch.com/2015/11/24/aws-lamda-makes-serverless-applications-a-reality/

Genauere Erläuterungen zu diesen Punkten werden noch in diesem Blog folgen. Der nächste Stack für moderne Applikationen ist also immer nur einen Steinwurf weit entfernt und unterliegt permanentem Wandel. Dies scheint mir ein guter Ausgangspunkt für mein Blog zu sein. Darüber hinaus werde ich mir interessant erscheinende Themen einstreuen wie z.B. IoT (Internet of Things) Projekte oder aber Neuigkeiten zu SAP Entwicklungen wie z.B. die Hana Cloud Platform.