javascript

• web ile birlikte değişen gelişen bir dildir. bu vesile ile webin doksanlar sonundan günümüze değişimini ve bunun javascripte etkisini anlatayım. ne oldu da bu javascript ekrandaki kayan yazı oluşturan bir dilden angular, react, vue gibi frameworklere, ya da server side rendering, micro frontend, node.js e evrildi ?
  
  90 li yıllar sonu, dünya milenyum diye kasıp kavrulurken yavaş yavaş türkiye'de de internet diye bir kelime halk arasında duyulmaya başlandı. dünyada. akademik cevrede, ya da belli bir küçük grup arasında biliniyordu ama o yıllarda ilk defa televizyonlarda internet paketi reklamalar dönmeye başlamıştı. o zamanlar internet mirc, mail ve tek taraflı içerik sunan web siteleriydi. e-ticaret yoktu, zaten o zamanlar e-ticarete geleceğini gören web siteleri simdi dünyanın en büyük web siteleri oldu.
  
  web de genellikle statik web sayfalarıydı. url ile giriş yapılır, sayfada da yine bir url ye referans olan linklere tıklanır, bunun sonucunda sayfa en bastan yeniden yüklenirdi. her link tıklamada televizyonda kanal değiştirir gibi olurdu, tarayıcı üzerinde her şey birkaç saniye yok olur, tarayıcının bir yerlerinde “yükleniyor…” yazardı. bu donemde javascript dili ile birçok şey yapılsa da genelde web sitelerine bilgi girdiğimiz form validasyonlari yapılırdı. ekranda kocaman bir pop-up diyalog penceresi çıkar “girdiğiniz mail adresini tekrar kontrol edin” derdi. bunun dışında bu isin uzmanları ekranda kayan yazı, yıl başında ise kar yağma efektleri yaparlardı. javascript sunucuya veri gönderirken ya da alırken pek kullanılmazdı. sunucudan veri çekme url ile baslar, veri gönderme ise form içindeki submit butonu ile başlardı. tüm bu islerin çoğu browserlar tarafından halledilirdi. web sitesi yapmanın çok fazla bir ameleliği yoktu. javascript üzerine düşen en büyük amelelik sayfalardaki frameler arasındaki parametrelerin yönetimiydi. birinden bir verinin alıp diğerini gönderme gibi isler dönerdi. eksisozlukteki sol frame de o donemden kalma bir tasarım aslında, o dönemlerde nispeten yoğun içerik sunan sayfaların sol taraflarında hep bir frame olurdu.
  
  daha sonra inanlar ekranda hareketli birseyler görmek istedi, web sitelerinin televizyon gibi animasyonlu akan içerikler sunması isteniyordu. küçük hareketli gif animasyonlar vardı o zamanlar, ilginç bir şekilde nerdeyse her sayfada ucan güvercin ve dans eden bebek animasyonları vardı. hava durumu ve sayfayı kaç kişinin ziyaret ettiğini gösteren sayaç her sayfanın olmazsa olmazıydı. hatta “sayfamızı ziyaret ettiğiniz için teşekkür ederiz” yazardı sayfanın bir yerinde, o kadar kibardı o zamanın web developerlari.
  
  iste o zamanlar devrim niteliğinde bir şey oldu ve hayatimiz flash denilen şey girdi. flash ile yapılmış sayfaları görmek için bilgisayara yazılım yüklemek gerekirdi ve bu yazılım browserlara kendini eklerdi. böylece bol animasyonlu, film gibi akan sayfalar görmeye başladık. bir web sitesine girerdik, ekranda güzel animasyonlu bir “loading…” yazısı çıkar, bir müzik baslar, sakince sayfanın yüklenmesini beklerdik. flash sayfalarda tüm içerik en basta yüklendiği için bu sayfaların açılması çok uzun sürerdi, ama sabırla bekleyen durağan bir sayfa yerine bol hareketli bir web sitesi ile karşılaşırdı. ayni zamanda o zamanlarda internetten küçük flash filmler izlediğimiz zamanlardı. “noel dayi”, “grafi2000” çok popülerdi. bir çeşit youtube du o zamanın internet alemi için. flash döneminde de javascript çok etkin değildi web siteleri için, flash animasyonları sayfaya eklemek için kullanılırdı. tüm scripting isleri flash içinde actionscript ile yapılırdı. o zamanlar hatırladığım bir flash sayfa yapmıştım görenler “aşmış bunu yapanlar” derdi havaya girerdim. aslında sadece yaptığım bir film karesi gibi frame düzeni kurmak ve küçük actionscript dokunuşları yapmaktı. o zamanlar web sitesi ile insanları etkilemek kolaydı.
  
  2000 yılından sonra internet hayatimiz daha çok girdikçe web sayfaları da tek taraflı statik sayfalar olmaktan çıktı, insanların içerik girdiği, sayfayla etkileşim içinde olduğu donem başladı. iste bu donem javascriptin patlama yaptığı donem diyebilirim. çünkü artık bu donemde web sitelerinde kullanılan “event” denilen kullanıcı etkileşimi sunan hareketler arttı. daha çok buton tıklaması, fare ile bir içeriğin üzerine gelince açılan bilgi popuplari, kullanıcının bilgi girişi yaptığı formlar üzerindeki validasyonlar hep javascript ile yapılmalıydı. çünkü artık web sitelerine içeriği web geliştiriciler değil kullanıcılar sağlıyordu ve bu sunulan içerik hem kullanıcının bilgisayarında yönetilmeli ve denetlenmeli hem de uygun şekilde sunucuya gönderilmeliydi. ayni zamanda sayfaya yeni gelen kullanıcının içerik sağlamasını teşvik etmek için çok basit olmalı, kullanıcıya nasıl içerik girebilir diye de bilgi vermeliydi. o nedenle bu donemin sayfalarında pop-up lar, tab seklinde düzenlenmiş menüler sunuluyordu. tüm bu komponentlerin yükünü de javascript çekiyordu.
  
  kullanıcı ile etkileşim de bu kadar büyük olduğunda her “event” yani kullanıcı aksiyonu sonunda sayfanın bastan yüklenmesi çok büyük sorundu. ve hayatimiz “ajax” girdi. o zaman ajax denilince erkeklerin aklına futbol takımı ve kadınların aklına bir temizlik urunu geliyordu. neyse ki gelişen teknoloji hayatımızdan bu cinsiyet ayrımını çıkardı ve artık kadın-erkek, yasli-genc herkesin aklına “asynchronous javascript and xml” in kısaltması olan “ajax” kelimesi geliyor. burada “asynchronous” kelimesi devrim niteliğinde, çünkü o güne kadar webde her şey senkrondu, yani her şey ayni anda baslar ayni anda biterdi. sayfaya url girilir ve sayfa hayata gelir, yükleme tamamlandığında ise sayfa ölü gibi yatardı. ama ajax ile ne oldu, sayfanın içinde çalışan javascript kod parçaları ve sonundaki http istekleri birbirinden bağımsız zamanlarda asenkron olarak çalışır oldu. iste bu noktada web siteleri ve javascript kodları karmaşıklaşmaya başladı. o güne kadar css de bir sanatçı edasıyla renk uyumu tartışmaları yapan front-end developerlar artık developerligin hakkini verircesine “asynchronous thread” , “lazy loading”, “data exchange formats” konuşmaya başladılar.
  
  web sayfaları aslında basit yapılar, temelde bir web sayfası veri almak ve göndermek için http request/response yapar. daha sonra bu veriyi html formatında gösterir ve css ile süsler. ama ayni zamanda javascript eventleri vasıtası ile kullanıcıyla etkileşime girer. iste bu etkileşim kısmının artması ve arkasında donen olaylar asenkron olarak yapılmaya başlandığı an her şey karmaşıklaşmaya başladı. örneğin bu entry altında “fav”, “sukela”, ve “çok kotu” butonları siz bu yazıyı okurken javascript tarafından sağlanan bu eventler sayesinde devamlı dinleme halinde. “acaba fareyi üzerimize getirecek mi?”, “acaba üstümüze tıklayacak mi?” diye devamlı bekliyor. bu eventler yazılımcı tarafından bu ikonlar üzerine dinleme modunda eklenmişler. ayni şekilde asenkron çalışacak fonksiyonlara ve bu fonksiyonların sonucunda da gerçeklesek ajax request/response işlemlerine bağlanmış durumdalar. örneğin aşağıda fav ikonuna tıkladığınızda (hazır konu gelmişken bir tıklayıverin) bir javascript kodu sizin session bilgilerinizi, girilen entrinin bilgilerinizi toplayıp düzenleyip asenkron olarak sunucuya iletecek, sonunda da başarılı bir şekilde iletildi ve sunucuda database kaydedildi mesajın alınınca da ikon yeşile dondurulur ve bu asenkron işlem başarıyla tamamlanır. ya da bir futbol maçının skorlarını takip ettiğiniz sayfada asenkron olarak sayfa arka planda sunucuya devamlı “bursadan gol haberi var mi?” diye sorar, siz hiçbir şey yapmasanız da arkada bu isler javascript tarafından yönetilir.
  
  iste bu asenkron isler ve bu isler sonucunda sayfanın on yüzü html/css üzerindeki anlık müdahale ihtiyacı artması javascript de hali hazırda bulunan “dom” yani sayfada bulunan elemanlara müdahale etmeye yarayan fonksiyonlara ihtiyacı arttırdı. ama “vanilla javascript” denilen standart javascriptte bu isler çok pratik değildi ve o günlerde hayatimiz jquery ve mootools gibi javascript kütüphane framework arası araçlar girmeye başladı. bu araçlar temelde bu eventlerin yani kullanıcı etkileşimlerinin düzenlenmesini kolaylaştırıyor, bunu yaparken çeşitli animasyon opsiyonları sunuyor, arka planda asenkron http request/response yapmayı kolaylaştırıyor, bu asenkron verinin beklenmesini yönetiyor, ve sonunda da bu gelen veriye göre de “dom” üzerinde yani html üzerinde sadece gereken yerleri güncelliyor.
  
  tabi ben o zamanlar mootools cuyum, bir taraftan da jqueryciler vardı bol bol tartışırdık o mu daha iyi bu mu. ben hep “mootools” daha iyi derdim kendimce, “live event” var derdim. asenkron http requesti sonunda gelen bir html içeriğine alakalı eventleri otomatik olarak eklerdi. yani sayfanın bir bolumu güncellendiğinde o bölümdeki butonlara tıklama eventlerini falan daha sonradan manual olarak tekrar eklemek durumunda kalmazdık. o yüzden mootools daha iyi derdim, ama daha sonra bu özellik jquerye de geldi. daha sonra jquery aldı yürüdü. ben de o gün kütüphane, framework, dil fanatizmini bıraktım.
  
  jquery uzun yıllar piyasayı domine etti, ama hep mvc konusunda bir eksik vardı ve herkes kendi yöntemini uyguluyordu. mvc denilen şey “model-view-controller”. aslında daha önceden bahsettiğim yapının aynisi. web için konuşursak model http ile gelen datayı yöneten kısım, view dom elemanlarını, controller ise bu ikisi arasında eventler sonucu başlatılan ikisi arasında bağlantıyı sağlayan kısım. jquery zamanında bu kısımda herkesin kendi yoğurt yiyişi vardı, bu da büyük ekiplerde kodun yönetilmesini zorlaştırıyordu. kod çok kolay şekilde spagetti kıvama geliyor, asenkron eventlerin arasında bug aramak zorlaşıyordu.
  
  ayni zamanda gelen datanın yani model üzerindeki datanın arayuzdeki yani view üzerinde karşılığı var çoğu durumda. yani model üzerindeki bu yazıyı favlayan kişi sayısı bilgisi sayfa üzerinde bir yerde de kullanıcının görebileceği yerde duruyor. simdi siz fav butonuna basınca bu önce databasede sonra da donen sonuca göre model üzerinde güncelleniyor. ama bir de ek olarak geliştirici bu model üzerindeki bilgiyi sayfanın görünen elemanını güncelleyerek değiştirmesi gerekiyor. diğer taraftan da ekranda bir kutuya yazı yazınca o kutudaki yazının da model tarafında karşılığı var. siz yazıyı yazarken, ya da yazma işlemi tamamlandıktan sonra bu model üzerindeki o kutudaki bilginin eşitlenmesi gerekiyor.
  
  iste bu gibi durumlar da web isini karıştırmaya başlayınca bunlara çözüm getiren angular.js daha sonra angular, react ve vue gibi framewokler çıktı. bu frameworkler elbette sadece bu isleri yapmıyor. url, history, komponent, komponent hiyerarşisi, komponentler arası bilgi aktarımı, komponentlerin datasi, web sitesinin global datasinin yonetilmesi gibi birçok is yapıyor. yani çözdükleri sadece mvc yapısı veya “two way binding” değil ayni zamanda web için olmazsa olmaz birçok şeyi de kendi içlerinde farklı anlayışlarla ve paradigmalarla çözüyorlar.
  
  yani artık web geliştirme statik sayfalardan bu güne bu şekilde geldi, artık bu frameworklerin bize sunduğu “cli-command line interface” ile bir web sitesi templatini birkaç komutla çözüyoruz, kodumuzu farklı browserların özelliklerine göre transpile diyoruz, sayfada kullandığımız elemanları uygun şekilde sıkıştırıp paketliyoruz.
  sayfalar da büyüdükçe gidişat bir taraftan microfront-end ve server side rendering tarafında gidiyor. bu frameworkler bu konuda da birçok çözüm sunuyor. bir yanda da online oyunlar, browser tabanlı video konferans araçları ile birlikte kod üzerinde performans baskısı artıyor. bu da javascript geliştiricileri daha iyi olmaya, javascript dışında birçok araç gerece hakim olmaya, hem daha performanslı hem de daha temiz kod yazmaya, yazdığı kodu hızla deploy edip sunucu üzerine alabilecek araçlara hakim olmaya zorluyor.
  
  hatta tek bir dil değil typescript gibi farklı supersetleri öğrenmek gerekiyor. bunun yanında microfrontend ile birlikte geliştirici takımları sadece client tabanlı değil full-stack çalışmak durumunda, node.js veya başka back-end dili ile çalışmak durumunda kalıyor. json bilmek yetmiyor yaml da yazmak gerekiyor. sadece browserları bilmek yetmiyor, aws gibi cloud sistemleri de öğrenip kodun deploy edildiği tarafı da bilmek gerekiyor. mobil web ile birlikte farklı ekran boyutlarına uygun çalışabilmek hatta electron gibi araçlarla masaüstü yazılımlar da üretmek gerekebiliyor.
  
  yani artık geliştiricinin tek bir dil ve teknoloji öğrenmesi yetmiyor. çünkü mevcut yazılım mimarilerinde yazılım dilleri birbiri içine geçmiş durumda. bu ise girişen biri dilleri ve bu dillerin birbirine dokunduğu noktaları da öğrenmesi gerekiyor. ne demişler “dil dile değerek öğrenilir”. çok doğru söylemişler ya da ben bu sözü çok yanlış anlamışım.
  
  elbette çok daha öncesi de var ama javascriptin son 25 yılını anlattım ve çok şey değişti web ve javascript konusunda, çok ilerleme oldu. bu vesile ile sayın cumhurbaşkanımız, ve devlet büyüklerimize teşekkürü borç bili… ne diyorum ben ! teknoloji ve internet türkiye’deki halka bir hizmet olarak sunulmadı, bu teknoloji tüm engellemelere rağmen ülkeye istemeseler de sızdı. wikipedia bile engellendi bu ülkede, o yüzden tüm gençlik sırf bilgiye erişme amacıyla vpn teknolojisini öğrendi. aslinda istemediler, ama dünya degistikce biz de internete eristik. bangledesden bu yazıyı okuyan doslar alınmasın, internet bangledes'e bile ulasti. o nedenle "biz yaptık" diyenlere inanmamak gerekir, asil dogru olan "onlara ragmen internete ulastık" olmasi lazim
  
  wikipedia demişken sunu da söyleyeyim gecen wikipedia da “nacl” yani “sodium chloride” araması yaptım wiki ye düştüm. türkçesi var mi diye baktım bu içeriğin ama su sayfada https://en.wikipedia.org/wiki/sodium_chloride sol tarafa 75 farklı dilin içinde türkçeyi göremedim. madem nostalji yapıyoruz 2000 li yıllar başında wikipediada türkçe içerik diğer dillerle yarışırdı, yasaklardan sonra çok çok geride kaldı türkçe içerik.
  
  gecen bir yerde okudum, doğru yanlış bilmiyorum, internette dolasan bir bilgi; “world wide web” kavramını bulan kişi “tim berners-lee” kendini tanıtırken kendi için “web developer” tabirini kullanıyormuş. adam web in kendisini bulmuş, web olayının developmentını yapmış. ama o da web developer, ben de. dünya ne garip.
  
  edit: @gavin harrison hatirlatmasi uzerine yanlislikla yazilan tum"modal" kelimeleri "model" olarak duzeltildi.
• ilk entryimde jon duckett kitabini onermistim. hala guzel kitap ancak programlamaya yeniyseniz ve her seyi nedeniyle, nasiliyla anlamaya merakliysaniz benim gibi, su an onerdigim kitap:
  
  javascript: the definitive guide
  
  ucretsiz bir kitap istiyorsaniz ve daha sevimli bir anlatim ariyorsaniz da eloquent javasript
  
  full-stack js developer olma planiniz varsa benim gibi, ogrenmeniz gerekenler mean stack dedigimiz: mongodb, express.js, angular.js ve node.js'tir. js sevenler icin artik pazarin backbone'dan angular.js'e dondugunu 2015'te ogrenmeye zaman ayiracaginiz tek sey varsa bunun angular.js olmasi gerektigini soyleyip kaciyorum.
  
  ogrenmek isteyenler icin codecademy, khan academy, codewars, coderbyte, treehouse, code free camp gibi sitelerde gezinmelerini oneriyorum.
  
  python'la kiyaslanmis yukarida. cok ilginc birisi back end birisi hem back hem front end is yapabiliyor. object oriented programlamaya ozlem duyulmus, denmek isteneni anliyorum ancak browser icin baska bir dil secenegi olmadigindan disimizi sikip oop gibi kullanabiliriz. es6 de zaten bu ihtiyaca cevap vermeye calisiyor.
  
  2015'in yarisina geldik editi:
  piyasaya 2 haftada bir yeni framework/library cikiyor. simdilerde angular yerine react'e dondu piyasa. facebook'un urunu olan react/flux ikilisine bakmakta fayda var. angular eski populerligini kaybediyor. gerci back-end'e ulasma cabasinda ama bakip gorelim 2 hafta sonra neler olur. optum seker.
  
  2016'nin yarisina geldik editi:
  2 yil once meslegimi degistirmeye karar verdim ve kendi kendime evde programlama ogrenip (gozunu sevdigim javascript ile) - ki hic mi hic bir programlama gecmis yoktu - abuk sabuk app'ler yaziyordum. su an xbox'da muhendisim. hayata bak vay hacim ya :)
  
  2017 bitmek uzere editi:
  cadilar bayraminda xbox'cigimdaki ilk yilimi kutladik :) neler ogrendim neler. her gecen yil da daha cok sey ogrenicem. daha once de 6 aylik stajim vardi xbox'da. yani bu kendi kendine ogrenme isinin pesini birakmayinca hayat kapilar aciyor. bilgisayar diplomasi olmayan tek muhendisim sanirim takimda (xbox muhendislik) ve de tek hatun ve de tek turk :) seneye gorusuruz kiz!
  
  2018 yari yil editi:
  ilk terfi :) herkes cok memnun benden :) iyi tutundum heralde bu endustriye haaa :) birakmam artik. :) kazirlar beni burdan.
• kimileri tarafindan java ile javascript arasindaki farki bilmeden python ile karsilastirilan dil.
  
  butun dunyanin java'yi birakip python'a donmesi yalani disinda, konuyla alakali olarak javascript hala socket, transaction, transmission gibi islemler python'in asyncio'suna, uvloop'una ragmen daha yuksek performans gostermeye devam ediyor.
  
  sevgili ogrenciler; ogrenin de gelin.
• html5'le birlikte bu kadar entegre çalışacakken ve hemen hemen her tarayıcının desteklediği, istemci tarafında çalışan en güçlü ve kullanım oranı en yüksek olan dil olmasından ziyade; google kendisinin kökünü yarak yazıyacaktır, afedersiniz.
• bu dil hakkında bu entry altında kaynakları düzenleyeceğim. umarım güzel bir kaynak listesi entry'si oluşacak.
  
  - impatient js
  
  birinci kitabımız, dr. axel rauschmayer'e ait. kendisi 2ality isimli bir blog sitesinin de yazarı. js konusunda fazlasıyla bilgilidir ve detaylı anlatır. html formatında okuyacaksanız hepsi ücretsiz, yok ben pdf isterim derseniz paralı ancak, türkiye gibi ülkelerde yaşayan okuyuculara %90 kadar indirim yapıyor.
  
  - modern javascript
  
  bu site zaten fazlasıyla bilindik ancak koymaktan zarar gelmez, her türlü js hakkındaki konuları ele alır, beginner'den advanced'e kadar gider. tavsiyedir.
  
  - deep javascript: theory and techniques
  
  bu kitap da, javascript hakkında daha derine inmek isteyenler için yine dr. axel rauschmayer'e ait. proxy,reflect api gibi derin konuları işliyor.
  
  - wes bos'un js kursları
  
  wes bos da son derece güzel anlatan bir abimizdir. es6 for everyone, beginner javascript gibi kursları var ancak paralı hatırladığım kadarıyla. fakat türkiye'ye %75 indirim yapmakta.
  
  - frontendmasters
  
  diğer paralı kurs sitesi, netlify, netflix gibi bilindik şirketlerin senior developerlerini çağırıp konferans formatında ders anlattırıyorlar. js kursları güzel baya, kyle simpsons( you don't know js) ve codesmith gibi öğretmenleri var, çok şey katacak bir websitesi. öğrenciler için ayrıca github students aracılığıyla 6 ay bedava üyelik veriyorlar. ve mail üzerinden ulaşırsanız parity power discount da yapıyorlar (alım gücü düşüklüğü)
  
  - codesmith
  
  codesmith'de ayrıca çok güzel bir youtube kanalıdır. öğretmenleri yaza çize anlatır. çok şey katar.
  
  - mdn docs
  
  ve tabi ki olmazsa olmazımız, mdn docs :) her js developer'inin başucu kaynağı, bible'ı.
  
  - scrimba
  
  bu sitenin diğerlerinden farkı, interaktif videolardan oluşması, ancak free'de çok fazla video yok ve aşırı derin değil. daha çok beginnerden intermediate'e doğru gibi
  
  - ui.dev
  
  bir başka kurs sitesi ancak paralı, türkiyeye özel %70 indirim yapıyor. açıklamaları vs güzel bir site. özellikle advanced js kursu güzel ve detaylı
  
  şimdilik kaynaklar bu kadar, aklıma geldikçe editleyeceğim.
  
  tanım: web için olmazsa olmaz bir numaralı dil.
• bana göre piyasadaki en iyi ve kapsamlı anlatımı şu udemy kursunda yapılmış programlama dilidir.
  
  yukarıda bir arkadaş güzel ve kapsamlı kaynaklar vermiş fakat ben kitap ile ilerlemeyi pek önermiyorum. yazılım işi bilgisayar üzerinde pratik ile yapılır. variable yaratmayı mı öğrendiniz? hemen bunu pratiğe döküp ellerinizle o kodu yazmalısınız. ufak bir bilgi + anında pratik. yukarıdaki kursta da sürekli kod yazarak ilerliyorsunuz. zaten kursun sahibi jonas reis yazmazsanız hiçbir şey öğrenemezsiniz diyerek uyarıyor.
  
  döküman okuma konusunda düzenli bir ilerleme katetmek isteyen arkadaşlar için de the odin project'i tavsiye edebilirim. burada daha derinlemesine okumalar yapıyorsunuz fakat kendinizi çok kaptırıp pratikten uzaklaşmayın.
  
  ufak code challengelar için kullandığım codewars 'a da bir göz atın. biraz daha eğlenceli hale getiriyor olayı.
  
  bazı quick tipler için şu tarz youtube kanallarını takip edebilirsiniz;
  freecodecamp
  traversy media
  web dev simplifed
  fireship
  
  farklı farklı yerlerden kaynaklar gösteriyorum ki çevreniz programlama konularıyla dolu olsun. ne kadar çok terimlere, konseptlere maruz kalırsanız o kadar iyi hakim olursunuz. emin olun günde yarım saat, bir saat şöyle bakıp geçerseniz aklınızdan kesinlikle uçup gider.
  
  yukarıda da belirtildiği gibi mdn kutsal kaynağınız olacak. ara ara gidip hatırlamadığınız ya da derinlemesine öğrenmek istediğiniz konuları okuyabilirsiniz fakat sırf döküman okuyarak da çok ilerleme sağlanamaz yukarıda belirttiğim gibi.
  
  ama birçok kişinin pek söylemediği bir gerçek var ki o da bütün bu kaynakların, videoların birer rehber olduğu. günün sonunda boş kod editörüyle baş başa kaldığınızda, elinizden tutacak bir rehber olmadığında da bir şeyler yazabilecek seviyeye gelmelisiniz. bu noktada eğer kafanızda ufak tefek proje fikirleriniz varsa -- ki bunlar aşırı orijinal şeyler olmak zorunda değil -- onları hayata geçirmeyi deneyebilirsiniz. bu yolda takibi de dökümanları, videoları açıp bakabilirsiniz. fakat kendi fikriniz olan bir projeyi başlatıp, yolda karşılaştığınız problemleri bir şekilde çözüp projeyi bitiren siz olmalısınız. işte bu bi yazılımcının mesleğini icra ederken yaptığına çok benzer bir şey. ulaşmaya çalıştığınız hedef de bu olmalı zaten.
  
  buradan sonra da javascriptin aşırı geniş kullanım alanı sayesinde kendinize bir yol çizebilirsiniz. mesela ben react ve react native frameworklerini biliyorum. bu sayede modern bir web app ya da mobile app (hem ios hem android) yaratabiliyorum. bu gerçekten büyük bir olanak. react native ile apple tv'ye bile app yazabiliyorsunuz.
  
  yok ben server kurucam database ile falan uğraşıcam diyorsanız node.js ve express.js ile devam edebilirsiniz. hatta jonas'ın onun için de bir kursu var.
  
  çok genel olmayan, spesifik sorularınız olursa yeşillendirebilirsiniz.
• çok tartışma yaratan bir dildir. bir dilin eleştirilmesinin ve üzerinde tartışılmasının kendimce çok yararlı olduğunu düşünüyorum. ama bu tartışmanın körü körüne nefret veya dil fanatizmi üzerinden olunca insan okuduklarından pek bir şey kazanmıyor. ama en azından o konu üzerine düşünmek bile yararlı.
  
  javascript dili çok eleştirildiği için bu eleştiri noktalarını madde madde listeledim, ve kendi bakış açımla kimini sübjektif, kimini objektif cevaplamaya çalıştım.
  
  “1”+ 2 niye “12” oluyor”. ilk olarak sunu bilmek gerekir bu durum javascript diline özel bir durum değil, ayni kodu java dilinde de, c# dilinde de yazın, yine ayni sonuç çıkar. sebebi de basit. birçok programlama dilinde + işareti sadece toplama işareti değil ayni zamanda “string concatenation” denilen iki string birleştirilmesi için kullanılır. burada da elma ile armut toplanmak isteniyor ama aradaki + işareti toplama işareti değil bir string birleştirme fonksiyonunun ifadesi. tabi bu fonksiyonun amacı eleştirilir ise o zaman bu eleştiri sadece javascript ekseninde olmamalı, çünkü diğer birçok dilde de ayni durum söz konusu.
  
  peki o zaman +”1”+2 niye 3 oluyor? dedik ya her + toplama işareti değil burada da +“1” ifadesindeki + string den number tipine dönüştüren artı. yani +”1” string değeri önce 1 sayı değerine donuyor sonra da 1+2 deki + işareti toplama işareti olduğu için de 3 sonucunu alıyoruz. yani bu noktaya kadar gördüğümüz su + işaretinin 3 farklı belki daha fazla görevi var. tabi bu kafa karıştırıcı oluyor. özellikle + işaretinin bir veri tipini değiştirmesi konusundaki eleştirilere sonuna kadar katılıyorum, çok gereksiz bir özellik bence. yapılan isi kolaylaştırıyor ama ayni zamanda hataya açık ve kod okumayı zorlaştıran bir özellik. bu tip dönüşümlerinin java dilindeki gibi olmasını tercih ederdim.
  
  nedir bu eşitlik == ifadesinin saçmalıkları ? javascript saçmalıkları ile ilgili bir yazı yazılsa ilk bununla baslar eleştiriler. bu başlık altında da onlarca ayni eleştiri var ama onlarca kez de cevaplanmış. bu hatayı daha çok java, c# gibi dillerden javascripte gecenler yapıyor. ben de daha önceden java dilini öğrenip javascript öğrendiğimde bu konuda ilk sürprizimi yaşamıştım. bakin arkadaşlar a == b ifadesi java veya c# dillerinde eşitlik kontrolü yapıp a ve b birbirine eşit ise true dönebilir ama javascript de eşitlik ifadesi == değil === dur. yani “” == 0 gibi bir şey ya da türevlerini yazıp, bos bir string nasıl 0 değerine eşit olur ne bu saçmalık demeyin, çünkü siz eşitlik kontrolü yapmıyorsunuz, javascript de özdeşlik kontrolü yapıyorsunuz.
  
  “javascript de == özdeşlik kontrolüdür, eşitlik ise === ile kontrol edilir”
  
  peki özdeşliğin eşitlikten farkı nedir? == için ayni şekilde abstract eşitlik kontrolü de deniliyor çünkü bu bizim diğer dillerden bildiğimiz gibi direkt eşitlik kontrolü yapmıyor, ayni zamanda ifadenin iki tarafındaki tipler birbirine ayni değil ise tip donuşumu de yapıyor. yani sonuç olarak iki taraf birbirine özdeş mi diye bakılıyor. örneğin “” == 0 ifadesinde biri string diğeri sayı değeri, o nedenle önce iki tarafında da tipleri birbirine eşitlenmesi gerekiyor ve kontrol yapılmadan önce iki taraf da bir tip değişim fonksiyonuna giriyor. sonuç olarak “” bos string değeri önce boolean değere yani özdeşi olan “false” olarak dönüştürülüyor. 0 sayı değeri ise özdeşi olan “false” değerine dönüşüyor. sonuç olarak da “false == false” gibi bir noktaya geliyoruz ve bu durumda da sonuç “true” oluyor.
  
  yani javascript dilini bu noktadan tutup eleştirirken öncelikle == ve === ifadelerinin farkını, ve daha sonra == ifadesindeki tip değişimi yapıldığını, ve bunun nasıl yapıldığını bilir isek bir anda o bize komik gelen her durum mantıklı bir yapıya oturuyor.
  
  kardeşim “typesafe” denilen bir durum var, typesafe olmaz isen bunlar başına gelir? iste bu == meselesinin kontrasında gelen ilk eleştiri bu oluyor. iyi de javascript dili bilerek ve isteyerek typesafe değil. ve bu toplulukta kalabalık bir grup da javascript dilinin typesafe olmasını istemiyor. çünkü typesafe durumlar her ne kadar güvenli olsa da esnekliği bozan bir durum. örneğin tip dönüşümlerinin nispeten otomatik yapılmadığı, tiplerin belirli ve tanımlı olduğu dilleri, yani typesafe dilleri düşünelim, örneğin java dilini. bir değişken tanımladınız, örneğin “boolean status = false;” daha sonra bu değişkeni birçok classda birçok method da kullandınız. artık bu değişkenin etki alanı binlerce farklı noktaya erişti. gün geldi müşteriniz dedik ki “status” artık true veya false olmaz, ikisinin arasında bir üçüncü bir durum daha var. java geliştirici iseniz müşteriye sunu demeniz gerekir “java typesafe bir dil, o nedenle bu durumu sistemin mimarisini tasarlarken belirtmeniz gerekirdi, artık bunu yapmak için çok geç yoksa binlerce satir kod ve test dosyası değişmeli, kusura bakmayın”. dersiniz de müşteri bundan anlamaz, sonuç olarak “bir isi beceremedi” der. iste typesafe dillerde en büyük angarya müşteri istekleri geldiğinde bunun mimari bir karşılığını olmaması ve yapılmak zorunda kalındığında ise bu değişikliğin büyük bir refactoring olması. ama kullandığınız dil javascript gibi typesafe dil değil ise, “var status = false;” ifadesini “var status = 0;” “var status = 2;” şekillinde istediğiniz gibi değiştirir, bunun zincirleme etkisi ile direkt olarak değil de sadece unit test dosyalarında uğraşırsınız. komple bir refactoring gerekmez.
  
  tabi typesafe olmayan bir dil kullanır iseniz kullandığınız dilin dokümantasyonuna hakim olmanız gerekir. esneklik var ama istediğiniz fonksiyona istediğiniz tipi gönderme esnekliğiniz de var. bu da birçok yerde büyük problem. örneğin .sort() fonksiyonu dokümantasyonda da belirtildiği gibi string değerleri alfabetik sıralamak için, ve eğer siz o fonksiyona string değil bir sayı gönderirseniz önce string olarak değiştirilecek ve alfabetik olarak sıralanacaktır. yani “[5, 12, 9, 2, 18, 1, 25].sort();” da olan [1, 12, 18, 2, 25, 5, 9] yanlış sıralanması çok doğru, önemli, öğretici bir eleştiri. düşünün dokümantasyonda bir satir ama çok kritik uyarıyı kaçırıyorsunuz ve karşınızda çok farklı bir sonuç. typesafe dilden gelen biri için bir kabus. tamam esneklik var, güzel ama kardeşim sadece string sıralayan bir fonksiyon bu tip değişimini yapmasın ve hata donsun. tabi bu problem bir nebze es6 ile çözülmüş durumda, yani bu .sort() fonksiyonu ayni zamanda bir fonksiyonel programlama pratiği olarak “first class function” alabiliyor. ve bu problem çözülüyor. tabi bu sürprizle karşılaşınca insan bir dona kalıyor, elindeki dilin ne kadar kontrol dişi olduğu ile yüzleşiyor.
  
  tamam da ben typesafe dillerde daha rahat ediyorum? eğer bu şekilde düşünüyorsanız yalnız değilsiniz. javascript dünyasında da büyük bir grup özellikle oop anlayışına bağlı grup bunu istiyor. iste bu nokta da typescript doğdu, yani daha oop daha typesafe bir javascript. ama sen istiyorsan javascript de typesafe olsun diye, peki esnekliğin çok önemli olduğu, genel geçer isler için bu kadar kasmaya ne gerek var derim. örneğin web dünyasında kodlar çok fazla değişir, çünkü müşteri ile direkt muhatap olan kısım web alanıdır. back-end tarafının müşteri ile isi olmaz. bu durumda esneklik çok önemli bir ihtiyaç oluyor.
  
  ama benim geldiğim dilde örneğin javada bu durumu daha generic tipler ile çözüyoruz? iste bunu dersen derim ki her dil öğrendiğin bir önceki dile benzemek zorunda ise o zaman bir ikinci dile niye ihtiyaç var. ben java ve birçok farklı dil biliyorum, hepsi de typesafe diller. günün birinde daha riskli ama diğer taraftan da daha esnek bir dile ihtiyacım oldu javascript öğrendim. simdi javascript de java gibi type safe, kati bir oop olur ise ben o zaman javanin üzerine niye javascript öğrendim diye sorarım kendime. zaten burada söyle olsun, böyle olsun diye eleştirilerin çoğu da bu eksende ve sonuç olarak istedikleri hayal ettikleri javascript dili java veya c# dillerine çıkıyor. yani kısaca birçok kişinin istediği olayın asil nedenine bakmadan, sırf bir problem gördü diye javasciptin daha iyi bildiği dile benzemesi. elma yerken keşke elmanın tadı armuta benzeseydi, armut yerken de keşke armutun tadı elma gibi olsaydı demek gibi bir şey.
  
  yani bu noktada önce javascript dilinin felsefesine bakmak lazım, javascript front-end için evrimleşmiş ve bu noktaya gelmiş bir dil. o nedenle de birçok hatasının, probleminin arkasında yatan asil unsur esneklik. esnek olsun, hatası ile sevabı ile esnek olsun anlayışı. yoksa esneklikten kaybediyoruz.
  
  neden bu eleştiriler hep javascript de toplanıyor? çünkü ister java, ister c++, ister c#, ister python geliştirici olun javascript diline elinizi sürmeden bir omur geçirmeniz zor. mutlaka bir şekilde hayatta bir noktada kesişiyorsunuz. çünkü javascript web sitelerin dili, yani bir web sitesinde bir buton yapacaksanız bu dile elinizi sürmeniz lazım. tabi uzmanı olduğunuz dilden bu dile geçince de bir muhafazakârlık oluyor. bende de java dilinden sonra javascript ile tanışınca ayni durum oldu. çünkü bu dilde genel akim dillerden farklı bir bakış açısı var. diğer diller sağlam bir yapı ortaya koymaya çalışırken, örneğin genişlemeye açık, değişime kapalı bir yapı ortaya koymaya çalışırken (bkz: solid prensipleri), javascript esneklik ve değişim üzerine bir yapıda. doğal olarak bu da uzun sure bu dil ile çalışırken yabancılık çekmek demek. çünkü dili öğrenmenin dışında bir de bakış açisini değiştirmek gerekir. bu dildeki %90 tüm eleştirilerin çıkış noktası o konunun çok riskli ve hataya açık ama ayni zamanda esnek olmasına dayanıyor.
  
  yerine başka bir dil geçer mi peki? elbette geçer, hangi dil yok olmuyor ki. ama bir dili komple silmek gerçekten güç. örneğin esnekliği bırakıp web alanında kurallı diller ile geliştirme yapılmaya çalışılmadı mi sanıyorsunuz. bunun yine en büyük elebaşı google oldu. google web toolkit (gwt) ile bir web sitesi yazanlar bilecektir neden gwt nin basarisiz olduğunu. başarılı olamadı çünkü esnek değildi, benim de zamanında koru körüne savunduğum bir dil olan java dili ile çok kati kurallar ile geliştiriliyordu. ister google da çalısın ister küçük bir reklam ajansında, web alanında müşterinin isteklerine bir şekilde cevap vermeniz lazım. sonuçta o sanal dükkânınızın müşterinin gördüğü yüzü web sitesidir. web sitesi denilince de google her ne kadar arkasında büyük bir algoritma bir back-end çalışsa da on tarafındaki o basit front-end için ne kadar uğraştığına bakin. iste o nedenle nerdeyse her sene google ara yüzü küçük ama etkili değişiklikler yapıyor front-end tarafta. adamlar yılların emektar, asla rakip tanımaz excel programına google docs ya da microsoft office 360 ile web ara yüzünde, yazdılar. yani kısaca excel programının birçok fonksiyonunu javascript ile yazdılar. yani isin asli bir çok kez javascript yerine başka dil ya da başka dilden dönüştüren araçlar geçmeye çalıştı ama olmadı.
  
  peki yerine geçerse hangi dil geçer? bence su anda bu konuda en büyük aday tam olarak bir dil değil, bir javascript superseti olan typescript geçer. çünkü microsoft aynen c# dilinde de olduğu gibi typescript ile çok iyi is çıkartıyor. nasıl ki c# dili java dilinin en çok eleştirilen problemlerini hızla çözerek bu noktaya geldi, typescript de javascript dilinin eleştirilen noktalarını bir oop geliştirici bakış açısı ile çözüyor. ama is yine ayni noktaya geliyor. belki birkaç ay sonra değişecek kod için neden typescript de olduğu gibi bir tipin number mi string mi olduğuna niye kafa patlayım diyebiliyor insan. tabi elbette birçok geliştiricinin elini sürdüğü, uzun vadeli planlanan bir kodda typescript iyi bir seçenek.
  
  javascript dilinin oop olması gerekir? bu da bir eleştiri, ama javascript dili zaten oop. hatta birçok dilin aksine hem oop hem fonksiyonel bir dil. bu eleştirinin çıkış noktası da bir öncekine benzer, yani oop en iyisi, o nedenle her dil oop olsun. iyi de bu soruyu matematikçilere sormak lazım önce, oop mi tercih ederler fonksiyonel mi. ya da fonksiyonel programlama anlayışının oop ye avantajları, dezavantajları ne bilmek lazım. ben de java geliştirici olarak çalışırken oop nin en iyisi olduğunu düşünürdüm, ama bugün sunu biliyorum ki ikisinin de gerekli olduğu yerler farklı. özellikle “stateless” bir yapıda “microservices” geliştirmek istenir ise fonksiyonel programlama oop den daha avantajlı. hatta bu baskı nedeniyle java diline bile bir fonksiyonel programlama dili pratiği olan lambda fonksiyon özelliği geldi java 8 ile birlikte. yani özetle ne oop, ne fonksiyonel programlama, bence ikisi de gerekli.
  
  peki javascript de oop yazılamaz mi? yazılır ama java ve c# dan farklı olarak temelde prototype kullanarak yapılıyor. diğer dillerde bu class temelli bir oop söz konusu. ama sen dersen ki ben prototype ile bir obje tanımlamak, kalıtım yapmak amelelik, o zaman javascript de class temelli bir yazma sekli de mevcut. es6 versiyonu ile birlikte ayni java veya c# dilinde olduğu gibi class yazıyorsun, bunun constructor tanımlamasını yapıyorsun, extends ile kalıtım yapıyorsun. hatta bu yazım sekli java ve c# dan neredeyse farklı değil. özellikle es6 bilmeden javascript eleştirmemek lazım bence.
  
  es6, es5 nedir bu saçmalık? burada da birçok eleştiri javascript in es5 versiyonu ile ilgili eleştiriler, es5 diğer adi ile ecmascript 2009. yani 2019 yılındayız ve javascript 10 yıl önceki hali ile kod yazıp, sonra da eleştirmek biraz abes oluyor. es6 yani ecmascript 2015 bile yeterince eskiyken bile javascript için bir devrim diyebilirim.
  
  bu javascript dilinin fanboylari da çekilmiyor? ben de sadece java geliştirici iken ve yeni yeni javascript öğrenirken ayni şekilde düşünüyordum. simdi ise tüm dilleri iyi ya da kotu yönleri ile seviyorum. bunu derken javascript dilini kimin geliştirdiğine bir baksınlar bence. javascript dilini geliştiren, bu dilin bu şekilde olmasını isteyenler yani ecmascript kriterlerini geliştirenler tc39 denilen bir grup. buraya söyle bir link bırakayım, javascript dilini tasarlayan bu halde bu şekilde olmasını bilerek isteyen şirketler ve bu linkteki şirketlerin geliştiricileri, mimarlarla. https://www.ecma-international.org/…to/ordinary.htm
  
  simdi bu noktada kendimize sormamız gereken ilk soru su olmalı, niye google, microsoft, ibm, paypal da çalışan ve ayni zamanda tc39 topluluğunu oluşturan bu insanlar bu dilin bu problemlerini görmüyor mu? niye değiştirmiyorlar? bunun cevabini bir tc39 toplantısına gitseniz alırsınız mutlaka. bu toplantılar ve seminerler dünyanın birçok yerinde yapılıyor ve herkese açık toplantılar oluyor. buralarda bu dili tasarlayanlar, bir sonraki versiyonunu planlayan kişiler bizim gibi geliştiricilerden önerileri alıyor, tartışıyor, sorularına cevap veriyorlar. bu toplantılarda en çok dikkat ettikleri javascriptin programlamaya bakış açısı. o da esneklik, yani dile mümkün olduğunca az kural koyup mümkün olduğunca fazla özellik eklemek üzerine.
  
  işte bu bakış açısı + işaretinin neden bu dilde bu kadar çok farklı anlamı olgunun cevabini veriyor. ya da bu dilin neden hem fonksiyonel hem, object oriented, hatta hem protoype temelli bir object oriented, hem class temelli object oriented bir dil olduğunu. çünkü ihtiyaç doğdukça dil o yöne gelişiyor. zamanında oop büyük bir akim iken o yönde evrildi, simdi microservices ve serverless cloud akımı ile son katılan dil özellikleri hep bu noktadan yani fonksiyonel programlama noktasından gelişiyor.
  
  yani dile katılan özellikler, geride kalmış ve artık saçma olan özellikler, farklı geliştirme anlayışı hep ihtiyaca yönelik bu büyük şirketlerin ve çalışanlarının eseri. zaten bu dilin böyle olmasını google istemese, microsoft istemese o özelliği desteklemez, hatta javascript dili yerine kendi geliştirdikleri c#, golang dillerini native olarak browser dili olarak kullanırlar. sonuçta browser da onların dil de onların. ama herkesin atladığı bir nokta var javascript dili de bu şirketlerin “lingua franca” si. yani google in da microsoft’un da ortak konuştuğu, beraber geliştirdiği, ayni standartlar göre uyguladığı bir dilden bahsediyoruz. böyle bir birliktelik olabilir mi. hatta micorsoft durmuyor bir de typescript diye bir şey geliştiriyor. diğer taraftan da google durmuyor da node.js ortamının en çekirdek noktası v8 engine geliştiriyor.
  
  bakin burada bu dili kullanan şirketleri saymıyorum, kullanan şirketleri saysam zaten tüm dünyadaki şirketleri saymam lazım. hadi web alanında tartışmasız lider bir dil, web alanını çıkartalım, sırf back-end alanında yani node.js kullanan şirketleri saysam bile ciddi bir ağırlığı var bu dilin. sırf back-end alanına dahi netflix, paypal, uber gibi çok ağır bir yükün altındaki şirketler bu dili kullanıyor. dili geliştirenler ise google, microsoft, ibm gibi şirketlerin ortaklığı. yaygin olmasi iyi oldugu anlamina gelmez. elbette gelmez ama bu durum yayginliktan daha öte, aslinda kasıtlı bir tercih. örneğin paypal daha onceden back-end tarafta java kullanirken niye node.js ortamina gecti. ya da ayni sekilde netflix. bunlar ile ilgili çeşitli case-study ler mevcut internete, ve o sirketlerin gelistirme platformlarinda. javascript dilinde neyi tercih ettiler de mevcut saglam dilleri biraki javascript ve node.js e gectiler. cevabi yine ayni esneklik, ama ayni zamanda bu esnekligin yani node.js in cok iyi entegre oldugu c++ ve c++ tarafindan saglanan o performans. yani node.js demek javascriptin esnekligi ve c++ in performansi bir arada calisiyor demek.
  
  bu noktada eleştirirken insanın ilk kendine sorması gereken fanatizm yapıp, “ne boktan bir dil”, “bu devirde bu dili kullanana şaşarım” demeden önce o dilin felsefesini, bakış acısını anlayıp, sonra bu dili geliştirenler kimler, ne yollardan geçtiler de bu şekilde yaptılar anlamak lazım.
  
  bu şirketlerde çalışan insanlar eleştirmiyor mu bu dili? iste bu noktada çok önemli bir sosyolojik bir durum ortaya çıkıyor. muasır medeniyetlerde, ya da ilham alınacak kişilerde eleştiri bir fanatizm aracı, ya da komple yok etme, silme aracı değil. eleştiri bu toplumlarda gelişmenin, daha iyisini bulmanın, daha da iyi noktaya getirmenin bir aracı. gelişmiş toplumlara baktığınızda ya da iyi noktalara gelmiş kişilere baktığınızda zaten bir şey dikkate değer ise eleştirilir. ama bu eleştiri koru körüne, yok edici eleştiri değil, daha çok problemi öne sürme, ve bir öneri ile gelmekten geçer. ama bunun sağlıklı olması için de o konunun bakış acısını felsefesini bilmek gerekir. çünkü bize ilk planda saçma gelen bir şeyin belki önemli bir amacı, bir hikayesi vardır. belki bir zorunluluktan ordadır, belki ihtiyaç yoktur ama onu silmeye kimsenin gücü yetmiyordur. bu bir dil için de böyle, bir dildeki özellik için de ayni.
• java ile javascripti karıştıran bilgisayar teknolojileri 2. sınıf öğrencisi bulunduran başlık. daha ne demek lazım ki...
• yazılım geliştirmede herkesin veya her şirketin yaşadığı bir ayrım var, hızlıca yazılsın ama shit/spagetti code mu olsun yoksa, biraz daha geç yazılsın ama okunabilir, bakımı yapılabilir, daha sonradan kullanılabilir kod mu olsun ayrımı. şirketlerde deadline baskısı yüzünden birinci seçenek tercih ediliyor ve teknik borç bıraka bıraka, hedefe koşarken duvarların içinden geçerek, önüne çıkan engelleri yıkarak shit/spagetti code yazılarak ürün çıkılabiliyor. şirket değil, bireysel proje geliştiriyorsanız da hızlı olmak, ürünü acilen yayına almak, bir an önce projeyi monetize etmek, amaca bir an önce ulaşmak üzere iyi, güzel, verimli, temiz kod yazmaya dair tüm kuralların içinden geçebiliyoruz. gerçekten ne yapmalı ben de bilmiyorum.
  
  şu sıralar geçmişte bıraktığım teknik borç ile çok uğraştığım için varsın yavaş olsun, biraz daha maintainable, reusable ve advanced tekniklerle kod yazma taraftarıyım. çünkü "çalışsın yeter" kafasıyla, hedefe ulaşmak için süpermen gibi tüm duvarların içinden geçerek yazdığım kodlar, götümü tırmalıyor. tabii o zaman da bu gerekiyordu. gerçekten bilemiyorum dostlar. bu baskı ağzımıza sıçıyor. 35 mb'a işletim sistemi vardı mk. şu an gördüğüm bazı web projeleri bundan büyük boyutlarda. insanın "gerçekten mi? gerçekten mi bir os'tan daha büyük iş yapıyoruz?" diye sorası geliyor. ben de dahil, çoğu kişi bok gibi kod yazıyor. insanın geri dönüp baktığında gözü kanıyor, daha önceden yazdığı kodu(bkz: legacy code) yeniden kullanması gerektiğinde sıkıntı basıyor. (bkz: code smells)
  
  bunu neden javascript başlığına yazıyorum, çünkü javascript gibi diller, shit/spagetti code yazmaya bir tık daha elverişli. sizi iyi kod yazmaya zorlamıyor. ben de şu an üzerinde çalıştığı projeyi javascript ile yazan biri olarak daha önce yazdığım fonksiyonları/metodları yeniden kullanmak zorunda kalıyorum sık sık. cidden artık geçmişteki kendime küfürler edesim geliyor. "keşke biraz daha zaman ayırıp daha düzgün kod yazsaydım" diyorum. ama üretim baskısı bitmiyor. bugün bile bok gibi kod yazmaya devam ediyorum. duvarların içinden geçmeniz gerekiyorsa geçeceksiniz, yapacak bir şey yok. ama bıraktığınız teknik borcun hepsi götünüze girecek haberiniz olsun. eyyorlamam bu kadar. hadi eyvallah.
  
  not: yanlış anlaşılmasın, yazılım geliştirmeye yeni başlayan biri clean code gibi şeyleri umursamamalı. yeni başlayanları şuraya alayım: (bkz: #145240173)
  
  şu an okuduğunuz entry'ye mevzu bahis durum, üretim baskısı yüzünden kötü kod yazmak zorunda kalma durumudur.
• 1990 - 1996 seneleri arasında ajax'ta oynamış ve 12 gol atmıştır.
  
  (bkz: ben de konuşayim adamları)