EcmaScript ve Javascript farklı şeyler mi? JavaScript nasıl ortaya çıktı?

Bilge Demirkaya
6 min readSep 7, 2020

--

JavaScript, sürekli olarak yeni özellikler ekleyen, ilerleyen bir dildir. Bir JavaScript geliştiricisi olmayı planlıyorsanız, yeni bir özelliği basit bir fikirden resmi dil spesifikasyonunun bir parçası haline dönüştürmek için gerekli olan temel süreci anlamak önemlidir. Bunu yapmak için üç konuyu ele alacağız — Ecma, EcmaScript ve TC39.

Photo by Clint Patterson on Unsplash

JavaScript

İlk olarak, 1995'e bakalım.Dünyanın en büyük şirketlerinin web siteleri şu şekilde görünüyordu.

Merkezi Omaha, Nebraska olan Berkshire Hathaway dünya’nın en büyük 2. holding şirketi

Bu şirketin hala aynı websitesini kullandığına inanmayanlar olabilir. Linki hemen burada.

O zamanlar bu websitesini açabilmeniz için Netscape Navigator kullanmanız gerekliydi. Netscape Navigator, neredeyse %80 pazar payıyla en popüler web tarayıcısıydı.

Netscape Navigator’ın arkasındaki şirket olan Netscape’in kurucusu ise Marc Andreessen.

Andreesen’ın web sitelerinin geleceği için bir hayali vardi. Sadece dosyaların ve bilgilerin paylaşıldığı bir platform olmasını istemiyordu. Daha dinamik, kullanıcı aktivitesi olan platformlarin mümkün olabileceğine inaniyordu.

Bunun için hem kullanıcıların hem yazılımcıların rahatça kullanabileceği bir glue language yaratmak gerekirdi. Bu noktada ise devreye Brendan Eich girmiştir.

Aslında ilk ismi Mocha olan Javascript böyle ortaya çıkıyor.

Brendan, Scheme programlama dilini Netscape Navigator’a yerleştirmek amacıyla Netscape tarafından işe alındı. Ancak tam işe koyulacakken, Netscape, tarayıcının içinde programlama dili Java’yı kullanıma sunmak için Sun Microsystems ile işbirliği yaptı. Şimdi, akla şöyle bir soru geliyor; Java zaten uygun bir dilse ve tarayıcılarına koyuyorsa, Netscape neden başka bir dil oluşturması için Brendan’ı işe aldı?

Çünkü Netscape tasarımcı ve hatta amatörlerin bile kolaylıkla kullanılabileceği basit bir dil betik dil (script language) istiyordu. Java buna uygun bir dil değildi.

Betik dillerinin en önemli farkı, derleme adımına (compiler) ihtiyaç duymamasıdır. Bu diller, yorumlanarak çalışır. (interpreter) Örneğin, normalde, bir C ya da Java programının çalıştırmadan önce derlenmesi gerekirken (kodun makine diline çevirilmesi) JavaScript veya Python gibi bir betik dili derlenmeden çalışabilir. Çünkü bu diller başka dillerle işbirliği yaparak Internet Browser gibi web tarayıcıları tarafından yorumlanır. Örneğin JavaScript yorumlama için Htmli kullanarak çalışır.

Çok fazla dağılmadan ilerlemek adına fazla ayrıntıya girmiyorum. Programlama dili ile Betik dilinin farklarına buradan bakabilirsiniz.

Bu noktadan sonra, Java’nın “profesyoneller” tarafından kullanılabileceği ve bu yeni dil “Mocha” nın (JavaScript’in ilk adı) herkes tarafından kullanılacağı fikri ortaya çıktı. Diller arasındaki bu işbirliği nedeniyle Netscape, Mocha’nın Java’yı tamamlaması gerektiğine ve nispeten benzer bir sözdizimine (syntax) sahip olması gerektiğine karar verdi.

Efsanenin duyulduğu gibi, Brendan sadece 10 günde Mocha’nın ilk versiyonunu çıkarttı. Bu sürüm Scheme’den bir çok özelliğe, SmallTalk’un object-orientation özelliğine ve işbirliği nedeniyle Java’nın sözdizimine (syntax) sahipti.

Sonrasında Mocha’nın adı LiveScript olarak değiştirildi ve ardından LiveScript, Java’nın reklam değerinden faydalanması için bir pazarlama hilesi olarak JavaScript olarak değiştirildi. Netscape Navigator, tarihte ilk defa iki ayrı dili beraber çalıştırarak, hem profesyonellere hem de kullanıcılara yönelik bir deneyim sunmaya sunmaya başlamıştı.

Bu olayların ne zaman gerçekleştiğinin bağlamını anlamak önemlidir. Çünkü bu sıralarda Microsoft, Internet Explorer üzerinde çalışıyordu.

Let the Browser Wars begin

JavaScript, web’deki kullanıcı deneyimini temelden değiştirdiği için, rakip bir tarayıcı olarak Internet Explore’ın, JavaScript benzeri, kendi uygulamasını oluşturmaktan başka seçeneği yoktu.Microsoft’un yaptığı da tam olarak buydu ve JScript adında bir script yazılım dili geliştirdiler.

JScript mi JavaScript mi?

Bu ikili durum daha sonra internet tarihinde oldukça yankı uyandıran bir soruna yol açıyor. JScript, JavaScript ile aynı işlevi görüyor, ancak uygulaması farklı. Bu, herhangi biriyle yazılmış bir web sitesinin hem Internet Explorer hem de Netscape Navigator’da çalışmasını bekleyemeyeceğiniz anlamına geliyordu.

Bir çok şirket, web sitesini hem Netscape’de hem de Internet Explore’da çalışması için iki kere yazdırmak zorunda kaldı. Geri kalan çoğunluk ise bunun maliyetli olması sebebiyle birisini tercih etmek zorunda kaldı. “Netscape’te en iyi görüntülenme” ve “Internet Explorer’da en iyi görüntülenme” rozetleri, her iki uygulama için de geliştirme gücü olmayan çoğu şirket için yaygın hale geldi.

İşte burada Ecma devreye giriyor.

ECMA International

Ecma International, “1961'de kurulmuş, kendini bilgi ve iletişim sistemlerinin standardizasyonuna adamış bir endüstri birliğidir”. Kasım 1996'da Netscape, standart bir spesifikasyon oluşturmak için Ecma’ya JavaScripti gönderdi. Bunu yaparak, ideal olarak, bütün uygulamaların tarayıcılar arasında tutarlı kalmasına ve bütün tarayıcılarda aynı şekilde görüntülenebilmesine yardımcı olacaktı.

ECMA nasıl çalışıyor?

Ecma kapsamında, her yeni spesifikasyon bir standart ve bir komite ile birlikte gelir.

JavaScript’in standartı — ECMA-262

ECMA-262 standardı üzerinde çalışan kominite — TC39 (Technical Committee 39)

ECMA-262 standardında JavaScriptin söyleniş biçimi — EcmaScript

EcmaScript mi JavaScript mi?

Açıklamak gerekirse, ECMA262 standardında “JavaScript” teriminin hiçbir zaman adı geçmez. Bunun yerine, bu resmi dil hakkında konuşmak için “EcmaScript” terimini kullanırlar. ES5, ES6 sürümleri de EcmaScript isminden türemiştir.

Bunun nedeni, Oracle’ın “JavaScript” teriminin ticari markasına sahip olmasıdır. Yasal sorunları önlemek için de Ecma, Javascript yerine EcmaScript terimini kullanmaya karar verdi. Sonuç olarak, ECMAScript genellikle resmi standart olan ECMA-262'ye atıfta bulunmak için kullanılırken, JavaScript pratikte dil hakkında konuşurken kullanılır.

Technical Committee 39

TC39 , tipik olarak tarayıcı satıcıları ve web’e yoğun bir şekilde yatırım yapan büyük şirketler olan “üyelerden” oluşur. (Facebook ve PayPal gibi.) Toplantılara katılmak için “üyeler” (yine büyük şirketler ve tarayıcı satıcıları) kuruma kendilerini temsil etmesi için “delegeler” göndermektedir. Bu delegeler, yeni Javascript özelliklerini onaylamak, geliştirmek ya da reddetmek için oylama yöntemi ile karar varırlar. Yani aslında JavaScriptin bütün ilerleyişini onlar kontrol ederler. Her yılın Haziran ayında da yeni sürümü yayınlamak için karar kılmışlardır.

Yani Javascript yeni bir özellik güncellemesi getirmek istediğinde kurula bir öneri sunar. Bu önerinin gerçekleştirilmesi için önce 5 farklı aşamadan geçmesi gerekir.

İlgisini çekenler için burada güzel bir blog buldum.

Interesting ECMAScript 2017 proposals that weren’t adopted

Kabul edilmeden önceki 5 Aşama

Aşama 0 — Gösterim

Her yeni teklif Aşama 0'da başlar. Bu aşamaya “Straw man” aşaması denir. Aşama 0 teklifleri, “bir TC39 üyesi tarafından komiteye sunulması planlanan veya komiteye sunulmuş ama kesin olarak reddedilmemiş, ancak 1. aşamaya geçme kriterlerinden herhangi birine henüz ulaşmamış tekliflerdir.”

Dolayısıyla, Aşama 0 teklifi olmanın tek şartı, belgenin bir TC39 toplantısında gözden geçirilmesi gerektiğidir. Herkes bu aşamaya teklif verebilir.

Aşama 1 — Teklif

Aşama 1'e ilerlemek için, TC39'un bir parçası olan ve tekliften sorumlu olan resmi bir “şampiyon” belirlenmelidir. Ek olarak,

  • teklifin çözdüğü sorunu tanımlaması,
  • açıklayıcı kullanım örneklerine, yüksek düzeyde bir API’ye sahip olması
  • olası endişeleri ve uygulama zorluklarını tanımlaması

gerekir. Komite, 1. aşama için teklifi kabul ederek, teklifi daha derinlemesine analiz etmek için kaynakları incelemeye istekli olduklarını belirtirse 2. aşamaya ilerlenebilir.

Aşama 2 — Taslak

Bu noktada, bu özelliğin eninde sonunda resmi şartnamenin bir parçası olması muhtemeldir. 2. aşamada resmi şartnamede olacakların bir taslağı veya ilk versiyonu yazılır. Bu, özelliğin tüm yönlerini ortaya serilmesi aşamasıdır. Yani ana taslak ortaya çıkmış olmalıdır. Gelecekte yine değişikler yapılabilir, ancak bunlar yalnızca küçük, artımlı değişiklikler olmalıdır.

Aşama 3 — Aday

Bu aşamada teklif çoğunlukla bitmiştir ve sonraki aşamaya geçmek için uygulayıcılardan ve kullanıcılardan geri bildirime ihtiyacı vardır. Aşama 3'e ilerlemek için, şartname metni bitirilmeli ve en az iki spesifikasyona uygun uygulama yaratılmalıdır.

Aşama 4 — Onaylanma

Bu noktada teklif, resmi şartnameye dahil edilmeye hazırdır. Aşama 4'e ulaşmak için testler yazılmalı, spesifikasyonla uyumlu iki uygulama bu testleri geçmeli, üyeler yeni özellikle önemli pratik deneyime sahip olmalı ve EcmaScript özellik düzenleyicisinin spesifikasyon metnini imzalaması gerekir.

Temel olarak bir teklif 4. aşamaya ulaştığında, teklif olmayı bırakıp resmi şartnameye girmeye hazırdır.

Daha önce de belirttiğim gibi, 2016 itibariyle, her yıl o sırada hazır olan özellikler ile birlikte yeni bir ECMAScript sürümü yayınlanmaktadır. Yani, yeni bir sürüm yayınlanırken, var olan 4. Aşama teklifleri o yılki sürüme dahil edilecektir. Bu yıllık sürüm sirkülasyonu nedeniyle, yeni özelliklerin benimsenmesi kolay olması çok önemlidir.

--

--