Hacker News veya Reddit’te yeterince zaman geçirirseniz sonunda aynı eleştiriyle karşılaşırsınız: Electron şişkindir, Electron çok fazla bellek kullanır ve ciddi masaüstü uygulamaları yerel olmalıdır.
Bu eleştirinin doğruluk payı var. Electron uygulamaları, Chromium ve Node.js ile birlikte dağıtıldıkları için genellikle daha yüksek bir temel kaynak tüketimine sahiptir. Özenle geliştirilmiş bir yerel uygulama daha az bellek kullanabilir, daha hızlı açılabilir ve işletim sistemiyle daha derinlemesine bütünleşebilir.
Ancak bu tartışma bilgisayara fazla, yazılımı geliştiren şirkete ise yeterince odaklanmıyor.
Çoğu kullanıcı için bir uygulamanın arkasındaki teknoloji pek önemli değildir. Uygulamanın çalışıp çalışmadığına, hızlı tepki verip vermediğine, hataların düzeltilip düzeltilmediğine ve kullanışlı özelliklerin eklenmeye devam edip etmediğine bakarlar. Dolayısıyla bir yazılım şirketi için teknoloji yığınının en önemli özelliklerinden biri, performans karşılaştırma tablolarında nadiren görülen bir şeydir: Ekip ürünü ne kadar hızlı geliştirebilir, kullanıma sunabilir, öğrenebilir ve iyileştirebilir?
Electron, birçok modern masaüstü uygulaması için bu konuda son derece başarılıdır.
Kıt kaynak, mühendislerin zamanıdır
İdealize edilmiş bir yerel masaüstü yazılım şirketinin mükemmel bir macOS ekibi, Windows uygulamasını geliştiren başka bir ekibi ve belki de Linux’u destekleyen bir başka ekibi vardır. Her uygulama kendi platformu için özenle optimize edilir ve her mühendis üzerinde çalıştığı işletim sistemini derinlemesine tanır.
Çoğu şirketin böyle bir lüksü yoktur.
Bir masaüstü ürününün beş mühendisi olabilir. İki mühendisi de olabilir. Aynı mühendislerin özellik geliştirmesi, hataları düzeltmesi, performansı iyileştirmesi, müşterilere yanıt vermesi, altyapının bakımını yapması, işletim sistemi değişiklikleriyle ilgilenmesi ve ürünü ileriye taşıması gerekir.
Yerel geliştirme bunu zorlaştırır; çünkü macOS, Windows ve Linux gerçekten farklı platformlardır. Farklı kullanıcı arayüzü çatılarına, API’lere, izin sistemlerine, yaşam döngüsü davranışlarına, kurulum programlarına, güncelleme mekanizmalarına, bildirim sistemlerine, pencere yönetimine, erişilebilirlik API’lerine ve yıllar içinde birikmiş platforma özgü tuhaflıklara sahiptirler.
Electron bu denklemi değiştirir. Chromium, Node.js ve masaüstü API’lerini macOS, Windows ve Linux genelinde ortak bir uygulama modelinde birleştirir. Aynı TypeScript mühendisi çoğu zaman bir özelliği arayüzden uygulama mantığına kadar geliştirebilir ve tüm masaüstü platformlarında kullanıma sunabilir. Gerçekten ihtiyaç duyulduğunda yerel kod hâlâ kullanılabilir, ancak ürünün temeli olmaktan çıkıp istisna hâline gelir. Electron da bunu temel avantajlarından biri olarak tanımlar: üç büyük masaüstü platformunun tamamında tek bir JavaScript kod tabanı.
Bu fark yıllar içinde katlanarak büyür. Her önemli özellik ayrı Mac ve Windows uygulamaları gerektiriyorsa şirket bu platform yükünün bedelini tekrar tekrar öder: her özellikte, yeniden tasarımda, denemede, hata düzeltmesinde, erişilebilirlik iyileştirmesinde ve performans optimizasyonunda.
Electron ile bu işlerin büyük bir kısmı bir kez yapılır.
Electron, yineleme hızını optimize eder
Ürünler nadiren ilk uygulamaları kusursuz olduğu için harika hâle gelir. Tekrarlanan geliştirme döngüleri sayesinde harika olurlar.
Bir ekip bir şey geliştirip kullanıma sunar. Müşteriler onu kullanır. Ekip öğrenir. Özelliği değiştirir. Daha fazla kişi kullanır. Başka bir sorun görünür hâle gelir. Ekip onu yeniden iyileştirir.
Fikir, uygulama, geri bildirim ve iyileştirme arasındaki döngü ne kadar kısa olursa ürün o kadar hızlı gelişir.
Electron bu döngüyü kısaltmakta özellikle başarılıdır; çünkü yazılım şirketlerinin zaten her yerde kullandığı teknolojiler üzerine kuruludur: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js ve npm.
Bu, şirketlerin kaynak kodundan çok daha fazlasını paylaşabileceği anlamına gelir. Web ve masaüstü ürünleri arasında mühendisleri, arayüz bileşenlerini, geliştirme araçlarını, kütüphaneleri, altyapıyı, test yaklaşımlarını ve kurumsal bilgi birikimini paylaşabilirler.
Şirketin Windows istemcisi için yardıma ihtiyacı var diye bir ön yüz mühendisi bir anda işe yaramaz hâle gelmez. Bir masaüstü mühendisi web uygulamasına katkıda bulunabilir. Tam yığın bir TypeScript mühendisi, öncelikler değiştikçe ürünler arasında geçiş yapabilir.
Küçük veya orta ölçekli bir şirket için bu esneklik, 100 MB RAM tasarruf etmekten çok daha değerli olabilir.
Electron’u gerçekte kimlerin kullandığına bakın
Electron bazen “düzgün” bir masaüstü uygulamasına yatırım yapmak istemeyen şirketlerin başvurduğu bir kestirme yol olarak tanımlanır. Onunla geliştirilen ürünler bu iddiayı savunmayı giderek zorlaştırıyor.
Electron projesinin kendisi Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom ve Canva gibi ürünleri öne çıkarıyor. Bunlar basit yardımcı araçlar değil. Birçoğu dünyanın en gelişmiş ve en yaygın kullanılan üretkenlik uygulamaları arasında yer alıyor.
Visual Studio Code özellikle yararlı bir örnek. Microsoft, amiral gemisi kod düzenleyicisini istediği hemen hemen her Windows teknolojisiyle geliştirebilirdi; buna rağmen VS Code, Windows, macOS ve Linux’ta Electron kullanıyor. Terminaller, hata ayıklama, dil sunucuları, Git entegrasyonu, uzaktan geliştirme, not defterleri, eklentiler ve son derece özelleştirilmiş düzenleyiciler içeriyor.
İlginç olan soru, Microsoft’un üç ayrı yerel sürüm geliştirerek bellek tasarrufu yapıp yapamayacağı değil. Elbette yapabilirdi.
Daha iyi soru şu: Her önemli yetenek birkaç ayrı uygulama gerektirseydi VS Code bu kadar hızlı gelişebilir, platformlar arasında bu kadar tutarlı kalabilir ve böylesine büyük bir ekosistem oluşturabilir miydi?
ChatGPT ve Claude, yaklaşım farkını gösteriyor
ChatGPT ile Claude arasındaki karşıtlık da öğretici.
OpenAI başlangıçta ChatGPT için özel bir yerel macOS uygulaması geliştirdi. Anthropic ise Claude Desktop’ı Electron üzerine kurdu ve en başından itibaren platformlar arasında ortak bir masaüstü temeline sahip oldu.
Ürünler genişledikçe bu fark daha önemli hâle geldi. Claude Desktop, MCP entegrasyonları, eklentiler ve Claude Code gibi yetenekleri aynı platformlar arası uygulamaya eklemeye devam edebildi. Anthropic artık birden fazla yerel ve uzak oturum da dâhil olmak üzere Claude Code’u doğrudan masaüstü deneyimi içinde destekliyor.
OpenAI de daha sonra yeni platformlar arası masaüstü yaklaşımını Electron’a yöneltti ve Electron artık hem ChatGPT’yi hem de Claude’u önde gelen Electron uygulamaları arasında listeliyor.
Ürün geliştirme hızındaki farkı tek başına Electron’un açıkladığını iddia etmek fazla ileri gitmek olur. Ekip büyüklüğü, öncelikler, ürün stratejisi ve iç organizasyonun hepsi önemlidir. Ancak mimari avantaj açıktır: Platformlar arasında ortak bir temel, ayrı uygulamalar sürdürmeden özellikleri farklı işletim sistemlerinde kullanıma sunmayı kolaylaştırır.
Bu, bir masaüstü ürünü büyüdükçe daha değerli hâle gelen türden bir avantajdır.
Evernote, ayrı istemciler sürdürmenin maliyetini öğrendi
Evernote, bu sorunun en açık tarihsel örneklerinden biridir.
Evernote yıllarca Mac, Windows, mobil ve web için farklı uygulamalar sürdürdü. Zaman içinde bu ürünlerde farklı davranışlar, görüntüleme farklılıkları, geçmişten kalan varsayımlar ve senkronizasyon sorunları birikti.
2020’de Evernote, Windows ve Mac uygulamalarını ortak bir kod tabanı etrafında yeniden geliştirdi. Şirket, yeni temelin uygulamaları daha kararlı hâle getireceğini, hataların daha hızlı düzeltilmesini sağlayacağını, özelliklerin daha sık kullanıma sunulmasına olanak tanıyacağını ve platformlar arası senkronizasyonu iyileştireceğini söyledi.
Bu geçiş sancısız değildi ve bazı uzun süreli kullanıcılar, başlangıçta platforma özgü özelliklerin kaybolmasından hoşlanmadı. Ancak Evernote’un neden böylesine maliyetli bir yeniden yazıma giriştiği, geçiş sorunlarının kendisinden daha ilginçtir.
Bir ürün zengin bir düzenleyiciye, çevrimdışı depolamaya, aramaya, eklere, iş birliğine, görevlere, takvimlere ve karmaşık senkronizasyona sahip olduğunda, birkaç bağımsız uygulamayı sürdürmek giderek daha pahalı hâle gelir. Hatalar farklı davranır. Görüntüleme farklılaşır. Senkronizasyon mantığı farklı yerel mimarilerle etkileşime girer. Her önemli ürün değişikliğinin birkaç istemciye aktarılması gerekir.
Ortak bir mimari, zor sorunları ortadan kaldırmaz. Şirketin bu sorunların daha fazlasını tek seferde çözmesini sağlar.
Linux, Electron’un en az takdir edilen avantajı olabilir
Linux, Electron lehindeki gerekçeleri daha da güçlendiriyor.
Linux’u gerektiği gibi desteklemek zordur. macOS veya Windows’un aksine “Linux masaüstü”, sıkı biçimde kontrol edilen tek bir platform değildir. Geliştiricilerin farklı dağıtımlarla, paket biçimleriyle, masaüstü ortamlarıyla, grafik yığınlarıyla, sistem kütüphaneleriyle ve görüntüleme protokolleriyle uğraşması gerekir.
Birçok yazılım şirketi için ticari açıdan mantıklı karar, Linux’u hiç desteklememek olurdu.
Electron bu ekonomik dengeyi değiştirir.
Electron, macOS, Windows ve Linux genelinde ortak bir çalışma zamanı sağladığı için Linux desteği eklemek, ayrı bir yerel Linux uygulamasını sürdürmekten çok daha kolay olabilir. Bugün Linux kullanıcılarının, geçmişte belki de hiçbir zaman resmî bir Linux istemcisine kavuşmayacak birçok büyük masaüstü uygulamasına erişebilmesinin nedenlerinden biri budur.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian ve daha birçok araç, tamamen ayrı bir GTK veya Qt uygulamasını sürdürmeden Linux’u destekleyebiliyor.
Electron ayrıca uygulama geliştiricileri adına Linux’a özgü karmaşıklığın büyük bir kısmını üstleniyor. X11’den Wayland’e geçiş bunun iyi bir örneği. Electron’un bakımını üstlenen geliştiriciler, Chromium’un Wayland’e geçişinin Electron uygulamalarını da fiilen beraberinde taşıdığını ve her uygulama ekibinin bağımsız olarak yapması gereken görüntüleme yığını çalışmalarını azalttığını anlattılar.
Electron gibi çatılar olmadan birçok şirket yerel Linux istemcileri geliştirmezdi. Yalnızca macOS ve Windows’u destekler, Linux kullanıcılarını bir tarayıcı sekmesiyle baş başa bırakırdı.
Electron, ticari Linux masaüstü yazılımları için muhtemelen kendisine atfedilenden çok daha fazlasını yaptı.
Microsoft bile giderek daha fazla web teknolojisini seçiyor
Microsoft, ciddi Windows yazılımlarının her zaman yerel Windows arayüz çatılarını kullanması gerektiği fikrine karşı belki de en güçlü örnek.
Microsoft, Windows’u kontrol ediyor. Win32, .NET, WinUI, WebView2 ve geliştiricilerin üzerine yazılım kurduğu platformun büyük bir kısmı onun kontrolünde. Tamamen yerel Windows geliştirme her zaman bariz cevap olsaydı, bunu her yerde kullanabilecek en iyi konumda Microsoft olurdu.
Ama öyle yapmıyor.
Visual Studio Code, Electron kullanıyor. Microsoft, Electron’u daha optimize edilmiş bir WebView2 barındırıcıyla değiştirdikten sonra bile Teams, React, TypeScript ve Chromium üzerine kurulu olmaya devam ediyor. Yeni Windows Outlook da büyük ölçüde web teknolojisine dayanıyor ve Microsoft bu mimariyi açıkça çevikliği artırmanın, daha hızlı özellik sunmanın ve daha tutarlı bir deneyim oluşturmanın bir yolu olarak tanımlıyor.
Teams özellikle öğretici. Microsoft performansı artırmak ve kaynak tüketimini azaltmak istediği için mimariyi değiştirdi. Ancak arayüzü geleneksel bir yerel Windows uygulaması olarak yeniden yazmadı.
Web yığınını korudu ve optimizasyonlarını onun etrafında yaptı.
Bu ayrım önemli. Microsoft, performansı yoğun biçimde iyileştirirken bile React, TypeScript ve Chromium’un organizasyonel avantajlarının korunmaya değer olduğuna karar verdi.
Burada başka bir ders daha var. Microsoft yıllar içinde Windows uygulama teknolojisinin birçok neslini bizzat sundu: Win32, WPF, UWP, WinUI ve diğerleri. “Yerel Windows”u seçen bir şirket, mutlaka zamana meydan okuyan bir platform seçmiş olmaz. Çoğu zaman Microsoft’un tercih ettiği çatının belirli bir nesline yatırım yapmış olur.
Web platformu, biraz ironik biçimde, mevcut en istikrarlı uygulama hedeflerinden biri hâline geldi.
İşe alım, mimarinin bir parçasıdır
Çatı seçimleri, kimleri işe alabileceğinizi de belirler.
JavaScript ve TypeScript geliştiricileri, sektördeki en büyük mühendislik yetenek havuzlarından birini oluşturur. Electron ile geliştirme yapan bir şirket, deneyimli macOS, Windows ve Linux uzmanlarından oluşan ayrı ekiplere ihtiyaç duymak yerine bu havuzdan işe alım yapabilir.
Yerel platform uzmanları değerli olmaya devam eder. Ciddi masaüstü ürünleri hâlâ işletim sistemlerini derinlemesine anlayan mühendislere ihtiyaç duyar. Ancak Electron, kaç uzmana ihtiyaç duyduğunuzu değiştirir.
Uygulamanın büyük bölümünün platform uzmanları tarafından geliştirilmesini gerektirmek yerine, nispeten az miktarda yerel entegrasyon kodu tutabilir ve ekibin çoğunluğunun ortak ürün üzerinde çalışmasını sağlayabilirsiniz.
Bir şirketin zaten bir web uygulaması varsa bu daha da önem kazanır. React bileşenleri bazen paylaşılabilir. TypeScript kütüphaneleri yeniden kullanılabilir. Ürün mantığı web ile masaüstü arasında taşınabilir. Mühendisler tamamen farklı bir ekosistem öğrenmeden ekip değiştirebilir.
İşe alım da daha az kırılgan hâle gelir. Yerel Windows istemcinizi derinlemesine anlayan tek mühendis ayrılırsa, bu uzmanlığın yerini doldurmak zor olabilir. Electron ile kod tabanının çok daha büyük bir kısmı, organizasyonun geri kalanının aşina olduğu teknolojileri kullanır.
Dolayısıyla bir çatı yalnızca bir arayüzün nasıl görüntüleneceğini belirlemez. Mühendislik organizasyonunun nasıl yapılandırılabileceğini de etkiler.
Yerel olması, otomatik olarak daha iyi yazılım olduğu anlamına gelmez
Geliştiriciler “yerel” sözcüğünü çoğu zaman neredeyse “hızlı” ile eş anlamlı kullanır.
Öyle değildir.
Yerel API’ler, geliştiricilere çok verimli bir uygulama oluşturma fırsatı verir. Nihai ürünün bunu gerçekten başarıp başaramayacağı mimariye, ekibe, bütçeye ve şirketin karşılayabileceği optimizasyon çalışmasının miktarına bağlıdır.
Yerel bir uygulama yine de yavaş, hatalı, bellek tüketimi yüksek, tutarsız veya bakımı yetersiz olabilir.
Daha da önemlisi, sınırlı bir ekibi birkaç yerel uygulama arasında bölmek, her uygulamaya daha az mühendislik zamanı ayrılması anlamına gelir.
Bir şirketin masaüstü ürünü için altı mühendisi olduğunu düşünün. Bir seçenek, onları Mac ve Windows arasında bölmek ve belki Linux’u desteksiz bırakmaktır. Diğer seçenek ise altı mühendisin neredeyse tamamını, üç platformun hepsine hizmet veren ortak bir Electron uygulamasında çalıştırmaktır.
Hangi yaklaşım şirkete açılış süresini iyileştirmek, bellek sızıntılarını düzeltmek, etkileşimleri kusursuzlaştırmak, erişilebilirliği artırmak, çökmeleri azaltmak ve kullanıcılara yanıt vermek için daha fazla mühendislik kapasitesi sağlar?
Yerel uygulamaların daha iyi bir ürün ortaya çıkaracağı hiç de kesin değildir.
Bu, ilginç bir paradoks yaratır: Biraz daha fazla makine kaynağı tüketen bir çatı, çok daha az mühendislik kaynağı tükettiği için şirketin daha iyi optimize edilmiş bir ürün geliştirmesini sağlayabilir.
Electron, kontrollü bir platform sunar
Electron’un gözden kaçması kolay bir başka avantajı daha vardır: Uygulamanın geliştirildiği ve test edildiği Chromium çalışma zamanını uygulamayla birlikte dağıtır.
Bu, platformlar arası geliştirmeden önemli bir değişkeni çıkarır.
İşletim sisteminin web görünümlerine dayanan çatılar daha küçük uygulamalar üretebilir; ancak bunun karşılığında aynı ön yüz Windows’ta WebView2, macOS’ta WKWebView ve Linux’ta WebKitGTK üzerinde çalışabilir. Bu motorların yetenekleri, hataları, sürüm takvimleri ve görüntüleme davranışları farklıdır.
Electron farklı bir tercih yapar: Çalışma zamanını paketler ve uygulamanın bir parçası hâline getirir.
Evet, bunun disk alanı açısından bir bedeli vardır.
Ama geliştiricilere birbirinden çok farklı üç işletim sistemi genelinde çok daha tutarlı bir hedef sağlar.
Tutarlılığın mühendislik açısından çok büyük bir değeri vardır.
Electron yetmediğinde, yine yerel koda başvurabilirsiniz
Electron’u seçmek, yerel yeteneklere erişimden vazgeçmek anlamına gelmez.
Electron uygulamaları, gerektiğinde yerel modülleri ve platforma özgü kodu kullanabilir. Bu da mimari seçimin aslında şu olmadığı anlamına gelir:
%100 yerel veya %100 JavaScript.
Birçok ürün için daha iyi bir model şudur:
Uygulamanın büyük bölümünün ortak olması, işletim sisteminin gerçekten gerektirdiği yerlerde ise az miktarda yerel kod kullanılması.
Yerel kod, tüm ürünün temeli olmak yerine gerektiğinde başvurulacak bir çıkış yolu hâline gelir.
Birçok şirket için bu, mühendislik çabasını çok daha iyi dağıtmanın bir yoludur.
Kullanıcılar çatılarla değil, ürünlerle ilgilenir
Etkinlik Monitörü’nü açıp birkaç Chromium sürecini fark eden ve bir uygulamanın Electron kullanmasından hemen şikâyet eden, teknik açıdan bilgili küçük bir kullanıcı grubu vardır.
Çoğu kullanıcı böyle yapmaz.
Slack’in Electron kullanmasını önemsemezler. VS Code’un web teknolojileriyle geliştirilmesini önemsemezler. Claude’un hangi çatıyı kullandığını bilmezler. Yazılımın işlerini yapmalarına yardımcı olup olmadığına bakarlar.
Bir uygulama yeterince hızlı açılıyor, hızlı tepki veriyor, nadiren çöküyor ve kullanıcının sorununu çözüyorsa, kullanılan teknoloji büyük ölçüde görünmezdir.
Bunun tersi de aynı ölçüde doğrudur. Yerel bir uygulama, Swift veya WinUI kullandığı için otomatik olarak iyi bir ürün olmaz.
Yazılımlar çatı düzeyinde değil, ürün düzeyinde rekabet eder.
Yalnızca ikili dosyayı değil, şirketi optimize edin
Electron’un gerçek maliyetleri vardır. Daha fazla disk alanı kullanır. Temel bellek tüketimi genellikle küçük bir yerel uygulamanınkinden daha yüksektir. Bu maliyetlerin Electron’u yanlış bir seçim hâline getirdiği ürünler kesinlikle vardır.
Küçücük bir menü çubuğu aracının muhtemelen Chromium’a ihtiyacı yoktur. Bir aygıt sürücüsünün kesinlikle yoktur. Oyunların, profesyonel ses yazılımlarının ve gecikmeye son derece duyarlı uygulamaların farklı gereksinimleri vardır. Ayrıca ürününüz yalnızca tek bir işletim sisteminde çalışacaksa, yerel geliştirmeyi gerekçelendirmek çok daha kolaydır.
Ancak modern masaüstü yazılımlarının çok büyük bir bölümü bu kategorilerde yer almaz.
Bulut hizmetlerine bağlı karmaşık arayüzlerden oluşurlar. Windows ve macOS’ta çalışmaları gerekir ve kullanıcılar giderek daha fazla Linux desteği de bekler. Sürekli gelişmeleri gerekir. Her hafta değişiklik sunan ürünlerle rekabet ederler. Ve genellikle sınırlı sayıda mühendisi olan bir şirket tarafından geliştirilirler.
Bu ürünler için geliştirici verimliliği, uygulama performansının bir parçasıdır.
Electron, bir şirketin çok daha büyük bir yetenek havuzundan işe alım yapmasını, mühendisleri web ile masaüstü arasında paylaşmasını, birkaç uygulama yerine tek bir ana uygulamanın bakımını yapmasını, JavaScript ekosistemini yeniden kullanmasını, özellikleri işletim sistemleri genelinde daha tutarlı biçimde sunmasını, aksi hâlde çoğu zaman gerekçelendirmesi zor olacak bir maliyetle Linux’u desteklemesini ve paralel uygulamaların bakımını yapmak yerine ürünü iyileştirmeye daha fazla mühendislik zamanı ayırmasını sağlar.
Electron’un maliyetini megabayt cinsinden kolayca ölçebilirsiniz.
Alternatifin maliyetlerini görmek daha zordur. Bunlar ek mühendisler, yinelenen uygulamalar, daha uzun sürüm döngüleri, platforma özgü hatalar, işe alım güçlükleri, organizasyonel silolar, desteklenmeyen Linux kullanıcıları ve herkese ulaşması aylar daha uzun süren özellikler olarak ortaya çıkar.
Bu maliyetler Etkinlik Monitörü’nde görünmez.
Ancak yazılımı geliştiren şirket için çok daha büyük olabilirler.
Yazılım geliştirmenin amacı en küçük ikili dosyayı üretmek değildir.
Amaç, organizasyonunuzun kullanıma sunabileceği, bakımını yapabileceği ve sürekli iyileştirebileceği en iyi ürünü geliştirmektir.
Şaşırtıcı derecede geniş bir masaüstü uygulaması grubu için Electron, tam da bunu yapmanın en verimli yollarından biri olmaya devam ediyor.