Ne smoosh oldu?
Array.prototype.flatten adlı bir JavaScript dili özelliği için öneri, Web ile uyumlu değil. Özelliğin Firefox Nightly'de kullanıma sunulması en az bir popüler web sitesinin çalışmamasına neden oldu. Sorunlu kodun yaygın MooTools kitaplığının bir parçası olması nedeniyle, daha birçok web sitesinin etkilenmiş olması muhtemeldir. (MooTools, 2018'de yeni web siteleri için yaygın olarak kullanılmasa da eskiden çok popülerdi ve birçok üretim web sitesinde hâlâ kullanılıyor.)
Teklif yazarı, uyumluluk sorununu önlemek için flatten değerini smoosh olarak yeniden adlandırmayı şakayla önerdi. Espri herkes tarafından anlaşılmadı. Bazı kullanıcılar yeni adın zaten belirlenmiş olduğunu yanlış bir şekilde düşünmeye başladı ve işler hızla büyüdü.
Array.prototype.flatten ne işe yarar?
Başlangıçta Array.prototype.flatten olarak önerilen Array.prototype.flat, dizileri belirtilen depth değerine kadar (varsayılan olarak 1) yinelemeli olarak düzleştirir.
// Flatten one level:
const array = [1, [2, [3]]];
array.flat();
// → [1, 2, [3]]
// Flatten recursively until the array contains no more nested arrays:
array.flat(Infinity);
// → [1, 2, 3]
Aynı teklifte Array.prototype.flatMap yer alır. Bu işlev, sonucu yeni bir dizi halinde düzleştirdiği dışında Array.prototype.map ile aynıdır.
[2, 3, 4].flatMap((x) => [x, x * 2]);
// → [2, 4, 3, 6, 4, 8]
MooTools'un bu soruna neden olan işlemi nedir?
MooTools, Array.prototype.flatten için standart olmayan kendi sürümünü tanımlar:
Array.prototype.flatten = /* non-standard implementation */;
MooTools'un flatten uygulaması, önerilen standarttan farklıdır.
Ancak sorun bu değil. Tarayıcılar Array.prototype.flatten'ü doğal olarak gönderdiğinde MooTools, doğal uygulamayı geçersiz kılar. Bu, yerel flatten'ün kullanılabilir olup olmadığına bakılmaksızın MooTools davranışına dayalı kodun amaçlandığı gibi çalışmasını sağlar.
Şu ana kadar her şey yolunda.
Maalesef daha sonra başka bir şey oluyor. MooTools, tüm özel dizi yöntemlerini Elements.prototype'e kopyalar (Elements, MooTools'a özgü bir API'dir):
for (var key in Array.prototype) {
Elements.prototype[key] = Array.prototype[key];
}
for-in, Array.prototype.sort gibi yerel yöntemleri içermeyen ancak Array.prototype.foo = whatever gibi düzenli olarak atanan özellikleri içeren "sayılabilir" özelliklerde iterasyon yapar. Ancak, sayılabilir olmayan bir mülkün (ör. Array.prototype.sort = whatever) üzerine yazarsanız bu mülk sayılabilir olmayan olarak kalır.
Şu anda Array.prototype.flatten = mooToolsFlattenImplementation, listelenebilir bir flatten mülkü oluşturur. Bu nedenle, daha sonra Elements'ye kopyalanır. Ancak tarayıcılar flatten'ün yerel bir sürümünü gönderirse bu öğe sayılabilir olmaz ve Elements'a kopyalanmaz. MooTools'ın Elements.prototype.flatten sınıfını kullanan tüm kodlar artık çalışmıyor.
Yerel Array.prototype.flatten öğesinin sayılabilir olarak değiştirilmesi sorunu çözecek gibi görünse de bu işlem muhtemelen daha da fazla uyumluluk sorununa neden olur. Bir dizi üzerinde iterasyon yapmak için for-in kullanan her web sitesi (kötü bir uygulama olsa da bu durumla karşılaşılabilir) aniden flatten mülkü için ek bir döngü iterasyonu alır.
Buradaki temel sorun, yerleşik nesnelerin değiştirilmesidir. Yerel prototipleri genişletmek, diğer kitaplıklar ve üçüncü taraf kodlarıyla iyi bir şekilde derlenmediği için günümüzde genellikle kötü bir uygulama olarak kabul edilir. Sahibi olmadığınız nesneleri değiştirmeyin.
Neden mevcut adı kullanmaya devam edip web'i bozmuyoruz?
1996'da, CSS yaygınlaşmadan ve "HTML5" ortaya çıkmadan çok önce Space Jam web sitesi kullanıma sunuldu. Web sitesi bugün hâlâ 22 yıl önceki gibi çalışıyor.
Bu nasıl oldu? Bu web sitesini tüm bu yıllar boyunca koruyan ve tarayıcı tedarikçileri yeni bir özellik yayınladığında güncelleyen biri var mı?
Görünüşe göre "Web'i bozmayın", HTML, CSS, JavaScript ve Web'de yaygın olarak kullanılan diğer tüm standartlar için birincil tasarım ilkesi. Yeni bir tarayıcı özelliğinin kullanıma sunulması, mevcut web sitelerinin çalışmamasına neden olursa bu durum herkes için kötü olur:
- Etkilenen web sitelerinin ziyaretçileri aniden bozuk bir kullanıcı deneyimi yaşar;
- Web sitesi sahipleri, hiçbir şey değiştirmeden mükemmel çalışan bir web sitesine sahipken işlevsiz bir siteye sahip olduysa;
- Yeni özelliği kullanıma sunan tarayıcı tedarikçileri, kullanıcıların "X tarayıcıda çalışıyor"u fark ettikten sonra tarayıcı değiştirmesiyle pazar payını kaybeder;
- Uyumluluk sorunu bilindikten sonra diğer tarayıcı tedarikçileri bu sürümü göndermeyi reddeder. Özellik spesifikasyonu gerçekle eşleşmiyor ("yalnızca bir kurgu eseri"). Bu durum, standartlaştırma süreci için kötüdür.
Elbette, geriye dönüp bakıldığında MooTools yanlış bir şey yaptı. Ancak web'in çalışmasını engellemek, onları değil kullanıcıları cezalandırır. Bu kullanıcılar moo aracının ne olduğunu bilmiyor. Alternatif olarak başka bir çözüm bulabilir ve kullanıcıların web'i kullanmaya devam etmesini sağlayabiliriz. Bu tercihi yapmak kolaydır.
Does that mean bad APIs can never be removed from the Web Platform?
Duruma göre değişir. Nadiren de olsa kötü özellikler web'den kaldırılabilir. Bir özelliğin kaldırılıp kaldırılamayacağını belirlemek bile çok zor bir işlemdir. Bu işlem, davranışı değişecek web sayfalarının sayısını ölçmek için kapsamlı telemetri gerektirir. Ancak özellik yeterince güvenli değilse, kullanıcılar için zararlıysa veya çok nadiren kullanılıyorsa bu işlem yapılabilir.
<applet>, <keygen> ve showModalDialog(), Web Platformu'ndan başarıyla kaldırılan kötü API'lere örnek olarak verilebilir.
Neden MooTools'u düzeltmiyoruz?
MooTools'u, yerleşik nesneleri artık genişletmeyecek şekilde düzeltmek iyi bir fikirdir. Ancak bu, mevcut sorunu çözmez. MooTools bir yama sürümü yayınlasa bile uyumluluk sorununun ortadan kalkması için bu sürümü kullanan tüm mevcut web sitelerinin güncellenmesi gerekir.
Kullanıcılar MooTools kopyalarını güncelleyemez mi?
İdeal bir dünyada MooTools bir yama yayınlar ve MooTools kullanan her web sitesi ertesi gün sihirli bir şekilde güncellenir. Sorun çözüldü, değil mi?
Maalesef bu mümkün değil. Bir şekilde etkilenen tüm web sitelerini tespit edip her birinin iletişim bilgilerini bulabilen, tüm web sitesi sahipleriyle iletişime geçebilen ve onları güncellemeyi yapmaya ikna edebilen (bu, tüm kod tabanlarının yeniden yapılandırılması anlamına gelebilir) bir kişi olsa bile tüm süreç en iyi ihtimalle yıllar sürer.
Bu web sitelerinin çoğunun eski ve muhtemelen bakımsız olduğunu unutmayın. Bakım uzmanı hâlâ aktif olsa bile sizin gibi yüksek vasıflı bir web geliştiricisi olmayabilir. Web uyumluluğu sorunu nedeniyle herkesin 8 yıllık web sitesini değiştirmesini bekleyemeyiz.
TC39 süreci nasıl işler?
TC39, ECMAScript standardı aracılığıyla JavaScript dilini geliştirmekten sorumlu komitedir.
#SmooshGate, bazı kullanıcıların "TC39, flatten'yi smoosh olarak yeniden adlandırmak istiyor" şeklinde düşünmesine neden oldu. Ancak bu, dışarıya iyi aktarılmayan bir şakaydı.
Tekliflerin adını değiştirmek gibi önemli kararlar kolayca alınmaz, tek bir kişi tarafından verilmez ve kesinlikle tek bir GitHub yorumuna dayalı olarak bir gecede verilmez.
TC39, özellik önerileri için net bir aşamalandırma süreci uygular.
ECMAScript önerileri ve bunlarda yapılan büyük değişiklikler (yöntem yeniden adlandırma dahil) TC39 toplantılarında tartışılır ve resmileşmeden önce komitenin tamamı tarafından onaylanması gerekir. Array.prototype.flatten durumunda, teklif 3. Aşama'ya kadar çeşitli anlaşma aşamalarından geçmiş durumda. Bu, özelliğin web tarayıcılarında uygulanmaya hazır olduğunu gösterir. Uygulama sırasında ek özellik sorunlarının ortaya çıkması yaygındır. Bu durumda, en önemli geri bildirim, özelliği kullanıma sunmaya çalıştıktan sonra geldi: Özellik, mevcut haliyle web'i bozuyor. Bu tür tahmin edilmesi zor sorunlar, TC39 sürecinin tarayıcılar bir özelliği kullanıma sunduğunda sona ermesinin nedenlerinden biridir.
TC39, fikir birliğine dayalı olarak çalışır. Yani komitenin yeni değişiklikler üzerinde anlaşmaya varması gerekir. smoosh ciddi bir öneri olsa bile bir komite üyesinin compact veya chain gibi daha yaygın bir ad tercih ederek buna itiraz etmesi muhtemeldir.
flatten olan adının smoosh olarak değiştirilmesi (şaka olsa bile) hiçbir zaman TC39 toplantısında görüşülmedi. Bu nedenle, TC39'un bu konudaki resmi tutumu şu anda bilinmemektedir. Bir sonraki toplantıda fikir birliğine varılana kadar TC39'un tamamı adına tek bir kişi konuşamaz.
TC39 toplantılarına genellikle çok farklı geçmişlere sahip kişiler katılır: Bazıları programlama dili tasarımı konusunda yıllara dayanan deneyime sahiptir, bazıları bir tarayıcı veya JavaScript motoru üzerinde çalışır ve artan sayıda katılımcı JavaScript geliştirici topluluğunu temsil eder.
SmooshGate sonunda nasıl çözüldü?
Mayıs 2018 TC39 toplantısında, #SmooshGate sorunu flatten'nin flat olarak yeniden adlandırılmasıyla resmi olarak çözüldü.
Array.prototype.flat ve Array.prototype.flatMap, V8 6.9 sürümünde ve Chrome 69'da kullanıma sunulmuştur.