Derleme Hedefleri Olarak Web Dilleri

0
24

Kısa bir süre önce Eric Bailey tarafından yazılan ve kütüphanelerin ve çerçevelerin, standartlaştırılmış eşdeğerlerinden farklı olan kendi kurallarını ve kalıplarını nasıl yarattıklarına dikkat çektiği bir makaleyi okudum.

Twitter’da birisinin kullanabileceğinizi belirttiği bir örneğe atıfta bulunuyor.

Birisinin yanıt verdiği “yerel bir HTML akordiyonu oluşturma” öğesi: “bu Bootstrap olmadan çalışır? 🤯 ”

Buradaki sorun nedir? Eric’ten:

Bu durumdan kaynaklanan sorun, insanlara önce çerçeve içinde düşünmeyi ve çalışmayı öğretmesidir. Bu gerçekleştiğinde, zor kazanılmış, pişirilmiş birlikte çalışabilirlik ve en önemlisi, erişilebilirlik [web] platform atıldı. Bu aynı zamanda birleşik bir problem: Bize sunulan unsurları ne kadar çok insan kullanmazsa, alakasız oldukları düşüncesi o kadar fazla olur.

Bu, daha fazlasını keşfetmek istediğim harika bir fikir.

Kitaplıklar ve çerçeveler, platform API’lerinin eksik olduğu boşlukları düzeltmeye veya en azından boşlukları doldurmaya çalışır. Boşlukları doldurdukları için, bu, yerel web API’lerinin yeterli olmadığına dair bir tür zımni kabul.

Modern tarayıcı API’lerine sahip olmak, modern kitaplıkların ve çerçevelerin gerisinde kalıyor, web için oluşturmayı seçtiğimiz yöntemdir. Bence bu yaklaşımın olumsuz yanlarını açıkça kabul etmeye değer, bunlardan biri: Web API’leri her zaman insanların ihtiyaç duyduğu şeyi sağlamadığından, bir çerçeve kullanma olasılıkları daha yüksektir. Bu, insanları oluştururken “çerçeveyi önce” düşünmeye yönlendirir, bu da “platform-son” düşünme eğiliminde oldukları anlamına gelir.

Eric devam ediyor:

Bu, web’de garip bir sürtüşme anıdır. Platform, belge tabanlı bir modelden uygulama tabanlı bir modele geçmeye devam ediyor …

HTML’yi bir derleme hedefi gibi ele alırken, HTML okuryazarlığı olan insanları Assembly’de programlayabilen mühendislerin eşdeğerine dönüştürüp dönüştürmediğimizi merak ediyorum.

Bu, HTML’den daha fazlası için yankılanıyor. Giderek artan bir şekilde tüm web dilleri (HTML, CSS ve JS) derleme hedefleri gibi geliyor.

HTML, WYSIWYG’lerde, Markdown’da veya şablon oluşturma yoluyla derlenen diğer bazı ham veri kaynaklarında yazmadan elde edilen bir derleme hedefidir.

CSS, Sass veya Less’te yazmadan elde edilen bir derleme hedefidir. Veya PostCSS veya Webpack gibi projenizde çalışmak için bazı derleme araçları veya işleme gerektirir. Veya basamaklı stil sayfalarını tamamen önleyebilir ve JavaScript’te stiller oluşturabilirsiniz.

JS, bugünlerde neredeyse her şey için bir derleme hedefi. Yeni nesil ECMAScript’te yazabilir ve derleyebilirsiniz. Veya TypeScript gibi bir JS üst kümesinde yazın ve derleyin. Veya tamamen Ruby gibi farklı bir dilde yazın ve derleyin. Ve henüz React için JSX veya Vue için SFC’ler (tek dosya bileşenleri) gibi çerçeveye özgü sözdizimini derlemem bile gerekmedi.

Ve henüz WASM’ye varmadık bile.

Web’de inşa etmenin ilk gurur ve zanaat sinyallerinden birinin “el yapımı” HTML ve CSS olması ironiktir, artık makinelerin şifreli çıktıları ile tamamen değiştirilen bir şey.

Christian Heilman, HTML ve CSS öğretimi hakkındaki makalesinde tüm bu konuyu ele alıyor:

Bilgi [about] bir HTML belgesinin tarayıcının işini yapmasına izin vermesi bile heyecan verici değildir.

Ama önemli. HTML’nin ne anlama geldiğini açıklayarak öğretmemek ve insanların onu yeniden icat etmesine neden oluyor.

Hepimiz özünde bir çapa olan DIV / SPAN yapılarını gördük. Ve klavyeden erişilebilir durumda değiller. Sonra insanlar onları erişilebilir kılmak için biraz ARIA ve bir sekme dizini ekler. Aslında değil. Otomatik erişilebilirlik testinin başarısız olduğunu işaretlememek, onu erişilebilir kılmaktan daha önemlidir.

Onun amacı şudur:

“Hızlı bir şekilde sonuca ulaşmak için ne gerekiyorsa onu ekleyin” moduna geri dönüyoruz. Web’de boyamak için bir teknoloji yığını olarak HTML / CSS ile tanıştığımızda öğrendiğimiz mod.

HTML genellikle bir işlemin parçası olarak yazılır: bir şey yazın, herhangi bir şey yazın ve bir sonucu görün. Kelimeleri gruplamak, stillere ve etkileşimlere bağlanmak veya belirli kullanıcı arayüzü parçaları oluşturmak için kullanın. Bunun anlam ve yapıyı iletmekle neredeyse hiçbir ilgisi yoktur.

HTML, içeriğin anlamını ve etkileşimini (birçok öğeye ihtiyaç duyulan) ana hatlarını çizmek için biçimlendirmek üzere tasarlandığında genellikle UI oluşturmak için yapı iskelesi haline gelir (bunun için birkaç öğeye ihtiyaç vardır). Yehuda Katz’ın Twitter’da belirttiği gibi:

HTML (özellikle ARIA ile geliştirildiğinde), bilgi işlemdeki etkileşim kalıpları için tek bir taşınabilir anlamlar kümesi oluşturmak için insanlığın en iyi çabasıdır.

Çerçeveler ve kitaplıklar, tarayıcı API adaylarını keşfetmek ve incelemek için tasarlanmış bir alanda yaşadıkları için – açıkça olmasa da dolaylı olarak – üzerine inşa edildikleri soyutlamalara (HTML, CSS ve JS) şeffaf dikişlere sahip olmak mantıklı olacaktır. Bu, insanların daha çok platform öncelikli ve çerçeve ikinci olarak düşünmelerine yardımcı olabilir.

CEVAP VER

Lütfen yorumunuzu giriniz!
Lütfen isminizi buraya giriniz