Web’i fork etmek üzerine

• Alternatif belirtimin hedefi, tüm Web değil, 6 Mayıs 2026 itibarıyla sıkıştırılmış hali açıldığında 18.3MiB olan HTML belirtimini öncelikli hedef olarak alıp Web’in avantajlarını korurken dezavantajlarından kaçınmaktır
• Belirtim kısa ve basit olmalı; tüm belirtimi içeren sıkıştırılmış tar.gz dosyasını 1.44MiB ile sınırlamak gibi bir yolla uygulama yükünü azaltıp çeşitli tarayıcılar ve istemcilerin ortaya çıkmasına imkan vermelidir
• Belirtim, bugünkü Web specification gibi sürekli değişen bir belge değil, 1.2.3 gibi semantik sürümler taşımalıdır ve yayımlanmış standart sürümleri asla değiştirilmemelidir
• Belirtim, kolayca ayrıştırılabilen belirsiz olmayan biçimsel dil bilgisi içermelidir; ayrıca standarda uymayan sayfalar render edilmemeli, böylece ayrıştırıcı ve içerik araçları geliştirme maliyeti düşürülmelidir
• Alternatif belirtim, Web’i özellik özellik kopyalamayı değil, yazılmış metin merkezli bilgi alışverişini hedefler; scripting yerine Geo link veya tiled web map standardında olduğu gibi standartlaştırılmış dosya ve URL’lerin yerel programlarda açılmasını tercih eder

---

Web için alternatif bir belirtimin hedefleri

• HTML belirtimi, 6 Mayıs 2026 itibarıyla sıkıştırılmış hali açıldığında 18.3MiB boyutundadır ve ilk inceleme konusu tüm Web değil, HTML belirtimiyle sınırlıdır
• Amaç, Web’in avantajlarını mümkün olduğunca korurken dezavantajlarından kaçınan bir alternatif belirtim oluşturmaktır
• Bu henüz resmî bir belirtim değil; zaman içinde değişebilecek gayriresmî notlara daha yakındır

Basitlik ve uygulama çeşitliliği

• Tüm belirtim kısa ve basit olmalı, düşük çabayla çeşitli tarayıcılar ve istemciler yapılabilmelidir
• On yıllar boyunca basitliği korumak çok zor olduğundan, belirtim uzunluğunu bayt düzeyinde sınırlayan bir kural bir yöntem olabilir
• Dillo, sürümlerini tek bir disket içine sığdırmak için aynı yaklaşımı kullanıyor; alternatif belirtim de tüm belirtimi içeren sıkıştırılmış tar.gz için 1.44MiB sınırı koyabilir

Semantik sürümleme

• Mevcut Web specification kabaca her hafta değişen bir sayfa olduğundan, istemcilerin belirtime uyması için değişiklikleri sürekli takip etmesi gerekir
• Alternatif belirtim, 1.2.3 gibi kesin semantik sürümler taşımalıdır
• 1.2.3 belgesi, 1.2.3, 1.2.0 ve 1.3.0 destekleyen tarayıcılarda doğru render edilebilir; ancak yalnızca 1.1.0 veya 2.0.0 destekleyen tarayıcılarda edilemez türünden bir uyumluluk ölçütü gereklidir
• Belgeler, tarayıcı bazlı uygulama durumuna göre değil standart sürümüne göre yazılmalıdır; örneğin tarayıcıların %90’ının 1.2.0 standardını desteklediği varsayımıyla bu sürüm hedeflenebilir
• Bir kez yayımlanan standart sürümü asla değiştirilmemelidir
  • Yazım hataları, patch sürüm artışıyla ele alınır
  • Geriye dönük uyumlu yeni özellikler, minor sürüm artışıyla ele alınır
  • Uyumluluğu bozan değişiklikler, major sürüm artışı gerektirir
• Yalıtılmış bir ortamda yalnızca 1.2.0 standardının basılı kopyası bulunsa bile, tamamen uyumlu bir tarayıcı yapılabilmeli ve bu tarayıcı 1.2.X belgelerini kalıcı olarak doğru ayrıştırabilmelidir

Katı dil bilgisi

• Belirtim, kolayca ayrıştırılabilen belirsiz olmayan biçimsel dil bilgisi içermelidir
• Sayfalar standarda karşı test edilip uyumlu olup olmadıkları belirlenmeli, uyumsuz sayfalar render edilmemelidir
• İstemcilerin belirtime uymayan sayfaları kabul etmesi açıkça yasaklanmalıdır
• Bozuk sayfaları düzeltmek için karmaşık standart kuralları uygulama gereğini ortadan kaldırır ve belirtimdeki hataların sonraki sürümlerde düzeltilmesini zorunlu kılar
• Katı dil bilgisi, insanın yazması daha kolay ve daha hoşgörülü dillere, örneğin Markdown’a geçişi teşvik edebilir; bu da amaçlanan bir etkidir
• Hedef, ayrıştırıcıları basitleştirmek ve içeriği işleyen araçların geliştirme maliyetini düşürmektir
• Patch sürüm değişiklikleri yalnızca ifadeyi değiştirir, dil bilgisi aynı kalır

HTML’yi yeniden kullanma olasılığı

• Mevcut yazılımlarda en az çabayla çalışabilecek bir HTML alt kümesi oluşturulabilirse bu arzu edilir olur
• Ancak HTML ayrıştırmasının karmaşıklığı nedeniyle bu mümkün olmayabilir
• XML belgeleri için biçimsel bir dil bilgisi oluşturmak da basit olmadığından, HTML/XML’in basit ayrıştırma için uygun bir biçim olup olmadığı değerlendirilmelidir

Standart ele geçirilmesine karşı direnç

• Web’in sorunlarından biri, tekelci aktörlerin gelir çıkarma mekanizmaları kurabildiğinde standartları kendi lehlerine çevirmek üzere ele geçirmeye teşvik edilmeleridir
• Web’de bunun sonucunda standart karmaşıklığının kontrol edilemez biçimde büyüdüğü, yeni tarayıcılar için giriş engelinin yükseldiği ve rekabetin azaldığı düşünülmektedir
• Bunu önlemeye yönelik ilk fikirler vardır, ancak oyun teorisi açısından daha dikkatli değerlendirme gerekir

Metin önceliği ilkesi

• Belirtimin amacı, basılı bir kitap veya yazı gibi insanlar arasında bilgi iletmek için yeterli ayrıntıları ele almaktır
• Yazılmış metin, bilgiyi kodlamanın en çok yönlü aracı olarak öncelenmelidir
• Metin çevrilebilir, bilgisayar tarafından sesli okunabilir ve az depolama alanında saklanabilir
• Belgeler ekran boyutuna göre satır kırmalıdır; aynı belge hem küçük hem büyük ekranlarda okunabilmelidir

Scripting’in dışlanması

• Scripting özelliği eklemek bir hataydı; bu nedenle alternatif belirtimde bundan kaçınılabilir
• Bu, kullanıcının etkileşimli programlar kullanmasını sınırlamak anlamına gelmez
• Örneğin bugün JavaScript ile tarayıcı içinde ilgi noktalarının konumunu gösteren etkileşimli bir harita yükleniyor; bunun yerine, bu protokolü destekleyen herhangi bir istemcide konumu açabilen bir Geo link verilebilir
• Benzer şekilde, açık bir belirtim varsa herhangi bir istemci sunucunun harita döşemelerini kullanabilir; ilgili bir örnek olarak tiled web map standardı gösterilir
• Standartlaştırılmış dosya veya URL’leri yerel programlarda açma yaklaşımı, kullanılan cihaza göre optimize edilebilir ve birçok etkileşimli web sayfasındaki tek tip yaklaşımtan kaçınabilir

Hedef olmayanlar

• Amaç, Web’i özellik özellik yeniden üretmek değildir
• Amaç, insanların bilgi, not ve başka tür içerikleri paylaşabilmesini sağlayan ama bunları okumak için tam bir VM çalıştırma gereğini ortadan kaldıran bir belirtim oluşturmaktır

[GN⁺]

Lobste.rs görüşleri

• Yani yine her şey için uygulama mı gerekecek? Script yeteneklerinin baştan eklenmesinin bir hata olduğu fikrine katılmıyorum
  web'in işletim sistemi sınırlarını aşan genel amaçlı bir platform olması bana iyi geliyor

  • Aynı fikirdeyim. Standartlaştırılmış dosya ya da URL'leri yerel programlarla açmanın avantajının cihaza göre optimize edilmesi ve “herkese tek beden” web sayfası yaklaşımından kaçınması olduğu söylenebilir, ama Linux kullanıcılarının ikinci sınıf vatandaş olduğu günlere geri dönmek istemiyorum
    Yalnızca Windows'un desteklendiği ve bazen Mac'in sonradan eklendiği dönemlerden söz ediyorum
  • Web uygulamaları hakkında şikayet edilecek çok şey var, ama mobil platformlarda uygulama dağıtırken Apple vergisinden ve gelecekteki Google vergisinden kaçınmanın neredeyse tek yolu da bu
    Ayrıca yerel masaüstü geliştirme durumu da hiç basit değil; bu yüzden masaüstünde web uygulaması ya da Electron seçenleri fazlasıyla anlayabiliyorum
  • Neden her şey için uygulama gereksin? Bu spesifikasyon normal web tarayıcısında çalışmayı engellemiyor ki, bugünkü web de ortadan kalkmıyor
  • Asıl doğru noktanın, standartlaştırılmış işaretleme ile nereye kadar gidilebildiğini bulmak olduğunu düşünüyorum
    Modern web'in sorunu, kavramları durmadan yeniden icat etmesi; bunların önemli bir kısmı bildirime dayalı işaretleme olmalı. Bir web sitesini görüntüleme yoluna JavaScript'in girmesi gerekmemeli. Script yazımı, sunucuda yapılan işi istemciye taşıyan belirli istemci tarafı programlama için kullanılmalı; örneğin sunucunun döndürdüğü veri kümesini işlemek gibi
  • Aslında zaten her şey için bir uygulama var. Sadece ona uygulama yerine URL ya da alan adı diyoruz
    BT sektörü, Java ve Swing, Flash gibi sandbox alternatiflerinin can sıkacak kadar yetersiz olduğu ortaya çıkınca web tarayıcısını fiili sanal makineye dönüştürmüş gibi geliyor. Artık tek bir uygulama olan Google Chrome, kullanıcıların genel amaçlı hesaplama işlerinin çoğu için sanal makine işlevi görüyor; üstelik bunu gözetim kapitalizmi tekelinde bir şirket sahiplenip geliştiriyor. Bunun gerçekten daha güvenli mi olduğunu, yoksa gerçek zero-day açıklarının sadece aşırı pahalı hale geldiği için mi kamuya yansımadığını bilmiyorum
    Script eklenmesinin hata olduğunu düşünüyorum. En azından sonradan eklenmiş bir özellikti ve Dillo'nun hipermetin belge okuyucusunun kapsamını belge okumayla sınırlayıp okuyucunun içinde belge yazma/düzenleme işine girmemesine katılıyorum
    Amaç, web'i işlev işlev kopyalamak değil; bilgi, not ve enformasyon alışverişi için tam boy bir sanal makine çalıştırma zorunluluğu olmadan okunabilecek bir spesifikasyon oluşturmak
    Daha iyi bir sandbox içinde, çoğu “etkileşim” ihtiyacını karşılayan küçültülmüş bir genel amaçlı uygulama görmek isterdim. Reddit benzeri sosyal medya akışlarında hipermetin alışverişi için gerçekten tam bir sanal makine mi gerekiyor? Alışveriş sepeti ve ödeme bilgilerini işlemek için de tam sanal makine mi gerekiyor?
    Yine de “genel amaçlı” olan şeyin sonunda “uygulamaları” yutması ve o noktada web'i yeniden icat etmemiz çok olası. Buna rağmen, temelinde Google değil de başka bir aktörün, C++ değil de başka bir dilin olduğu bir fırsat varsa daha iyi olabilir. Dillo galiba C ve C++ kullanıyor; o halde ikisinden en az birinde ilerleme sayılır sanırım

• Ek olarak iyileştirilse iyi olacak şeyler: küçültülmüş bir HTTP kullanmak ama çerezlerde yalnızca istemcinin denetlediği oturum çerezlerini desteklemek, üçüncü taraf kaynakları yasaklamak ve tüm kaynakları belgeyle aynı web sunucusunda tutmak, text/markdown gibi biçimlerin tarayıcı içi dönüştürücüyle işlenmesini zorunlu kılmak

  • Üçüncü taraf kaynakların yasaklanması bile tek başına birçok ciddi sorunu engelleyebilir
  • İdeal olarak taşıma yönteminden bağımsız olmasını isterdim. Muhtemelen önce yerelden başlayıp herhangi bir uzak dosya sistemi bağlama noktasında çalışmasını denerdim
    Bu kez yaklaşım, diyeti düzelterek çerezlerden kaçınıp kaçınamayacağımıza bakmak olurdu. Bu, belgenin makine temsili; insanın okuyabilmesi için tasarlanmış ama insanın doğrudan yazması için değil. Bunun yerine Markdown gibi bir ön yüz dili kullanıp bunu taşınabilir, sıkı bir belgeye derlemek daha iyi olur
  • Önerim şu olurdu: çerezler gerçekten gerekliyse yalnızca ilgili site alan adına uygulanmalı. example.net çerezi sub.example.net'e gönderilmemeli, sub.example.net çerezi de example.net üzerinde ayarlanmamalı
    HTTP/2 ve HTTP/3 uygulama web'inde kalsın, HTTP/1 ise belge web'inde kalsın daha iyi. JavaScript'i nasıl kısıtlamak gerekir ki “içeriğimi görmek için özel tarayıcı lazım” sorunundan kaçınılsın, bilmiyorum; o yüzden JavaScript hiç olmamalı
    text/markdown işleme zorunlu olursa hangi sürümden söz edildiği de sorun olur. Desteklenmesi gereken yaklaşık yarım düzine varyant var

• Sıkı sözdizimi pek işe yaramaz. XHTML'in başarısız olmasının nedeni de buydu, HTML5'in yaygın “bozuklukları” ele alan kurallar eklemesinin nedeni de bu
  Yazarın istediği gibi HTML5'i daha biçimsel bir sözdizimiyle yeniden tanımlayabilirsiniz, ama sayfaları katı biçimde reddetmek bir fork'un iyi kullanımı gibi görünmüyor. Diğer alternatif de bir tane daha gopher/gemini türevi olmak; tutkulu bir hayran kitlesi olsa da neden popüler olmadığının sebepleri var. Geriye dönük uyumluluğun gücü çok büyük

  • XHTML'in başarısız olmasının sebebinin katılık olduğu görüşüne katılmıyorum. IE'nin 2011'e kadar XHTML'i desteklememesi çok geç kaldı; insanlar bu yüzden gerçek XHTML kullanmadı ve avantajlarını elde edemedi
    Katılık çok iyi olabilir, ama işlemesi için destek gerekir

• “Script özelliğinin eklenmesi hataydı” fikri, eğlenceye izin vermeyen kasvetli programcı tipleri arasında eski bir meme olmuştu; ama bana daha çok hayal gücü eksikliği gibi geliyor
  Dikkatle uygulanmış etkileşimli multimedya, iletişimi ve anlatımı büyük ölçüde geliştirebilir. Örneğin Red Blob Games Hex-Grid tutorial içindeki etkileşimli diyagramlara ya da Bartosz Ciechanowski's fantastic explanation of mechanical watch movement yazısına bakın. Web'in etkileşimli medyası sayesinde Canon Cat gibi tarihsel olarak önemli nadir bilgisayarları, yerel emülatör derleyip çalıştırmanın kâbus gibi süreci olmadan, bir bağlantıya tıkladıktan birkaç saniye sonra deneyebiliyorsunuz. Form gönderimi ve image map'ler, multimedyanın son derece soluk bir gölgesi; ayrıca etkileşim desteğinin yükünü özünde sunucu merkezli ve potansiyel olarak bant genişliği tüketen bir modele taşıyor
  Sorun script çalıştırma fikrinin kendisi değil, bugünkü tarayıcılarda script'lerin yapmasına izin verilen şeyler. HTTP ve HTML nasıl daha küçük, daha basit ve kullanıcı özerkliğine saygılı bir sisteme indirgenebilirse, web JavaScript'inin olumlu yanlarının çoğu korunurken API yüzeyi ve kötüye kullanım potansiyeli de ciddi biçimde azaltılabilir. Örneğin sayfa içinde Flash benzeri etkileşimli bir kutunun olduğu, etkileşimin kullanıcının erişip inceleyebileceği Lua script'leri ve Love2D benzeri grafik/girdi yetenekleriyle sağlandığı; uzak sunucularla konuşmak ya da web kameraya erişmek gibi mahremiyeti ihlal eden işlerin ise güçlü bir sandbox ve kullanıcının açık ön onayının arkasına konduğu bir web hayal edebilirsiniz
  Bugün de bu şekilde saygılı web uygulamaları yapmak mümkün, ama temel çok pürüzlü ve tutarsız; kullanışlı özelliklerde bariz eksikler ve kullanıcı güvenliği/mahremiyeti için gereksiz tehditler her yerde
  Erişilebilirlik açısından bir vizyon olarak; buton, alan, onay kutusu, kaydırıcı gibi bildirime dayalı UI girdilerini sıkı biçimde ele alan ve görüntü ile işaretlemeyi statik sayfa gibi <iframe> içinde işleyen, fakat uzak sunucuya gidiş geliş olmadan çalışan istemci tarafı formlar düşünülebilir. Birçok hesap makinesi, araç ve etkileşimli görselleştirme bu modele sığabilir; gecikme ve kullanıcı güvenliği açısından da arka uç odaklı modele göre daha iyi olur

• “Metin öncelikli” ise CSS'den de vazgeçmek gerekir. CSS çoğunlukla kullanıcı için değil, şirketler için var. Stili sayfa değil tarayıcı kontrol etmeli
  Kullanıcı ham sayfa yükünü okumayı seçmişse, onun büyük kısmı tarayıcının okunur diye gösterdiği bilgiyle aynı olmalı. Bugün okunabilir içerik buzdağının sadece görünen kısmı
  “Script yok” konusunda, stil ve şişkin sayfalar kaldırılırsa görüntülemeyi etkileyen script ihtiyacının da ciddi biçimde azalacağını tahmin ediyorum. Görüntülemeyi etkilemeyen script'ler ise çoğu zaman kullanıcının yararına aykırı amaçlarla kullanıldı

  • Bu zaten CSS cascade'in asıl fikriydi. Kitap ve makale biçimlendirmesi için kullanılabilecek makul bir CSS alt kümesi vardı ve kullanıcı stilleriyle birleşecek şekilde tasarlanmıştı
    Ama CSS ve biçimlendirme aşırı karmaşık hale geldi; kullanıcı stilleri artık ya tam bir CSS reset ile başlamak ya da siteye özel çok ayrıntılı olmak zorunda
  • Okuyucunun saat dilimine göre zaman damgası göstermek istiyorsanız, bugün bunu istemci tarafı script olmadan yapmanın yolu yok
    İstemcide JS olmadan kişisel araçlar yaparken bu sorunla karşılaştım; sunucuda “benim saat dilimi ayarım” tutmak ya da küçük bir yardımcı script eklemek gerektiğini fark ettim
    Stili tarayıcının kontrol etmesine bırakırsanız, “sayfam X ve Y tarayıcılarda okunuyor ama Z'de okunmuyor” gibi sorunlar bugünkünden daha da kötüleşebilir gibi görünüyor
  • CSS dolu, renkli ve gösterişli arka planları, iyi yazı tipleri, flexbox ve grid düzenleri olan bir dünyada mutlu yaşarım
    Yazarın sesini beyaz zemin üstünde siyah metne indirgenmiş sönük belgeler görmekten daha iyi buluyorum. CSS, web'de yazarın ifade biçimi ve gerçekten yok olmasını istemem. Karmaşık ama daha fazla insanın kendi web sitesinde eğlenceli şeyler yapabilmesini sağladığı için bence bu iyi bir şey
  • Katılıyorum. İsteğe bağlı yazar stili yasaklanmadan önce daha fazla araştırmak gerekir
    Stil ve şişkin sayfalar kalkarsa görüntüyü değiştiren script ihtiyacının azalacağı hissine ben de yakınım. Basit bir sözdizimi olursa etkileşimli yerel programların içine “belge” gömülebilir; tersi olmak zorunda kalmaz

• Başkalarının dediği gibi Gemini bakmak için iyi bir örnek bence. Yine de Gemini bir tür performans sanatı gibi, ama ondan öğrenilecek gerçekten çok şey var
  Gemini'de yeterince bilinmeyen dikkat çekici bir özellik, abone olunabilir sayfalar. Sayfa içinde metni YYYY-MM-DD ile başlayan bağlantılar örtük bir akış oluşturuyor. Çok sınırlı ve aptalca görünebilir ama bence Gemini'nin en etkileyici özelliklerinden biri bu. Spec here
  Geleneksel HTML'de blogu elle yazmak mümkün. Sıkıcı olsa da gayet yapılabilir. Ama RSS/ATOM akışını sürdürmek için neredeyse kesinlikle akış üreten bir araca ihtiyaç var
  Sonraki nesil “içerik odaklı” bir HTML'de buna benzer bir özellik olması iyi olur. Belki h-feed in microformats doğru yaklaşımdır, ama Gemini'deki abone olunabilir sayfaların sadeliğini gerçekten seviyorum. Ve her yerde akış olması iyi bir şey
  Gemini'nin satır tabanlı ve ayrıştırması kolay olması büyük avantaj, ama fazla sınırlı ve erişilebilirlik açısından olumsuz etkileri olabilir gibi geliyor. Yine de Gemini gibi görünen bir HTML-lite fena olmazdı
  Web fork'unun sağlayabileceği bir başka fayda da HTML'e sonradan eklenen şeyleri temizlemek olurdu. <meta name="viewport" content="width=device-width, initial-scale=1.0"/> oldukça sinir bozucu. Bugün bildiklerimizle yeni bir sürüm yapılsa gayet iyi olabilir
  Diğer kısımlarda o kadar emin değilim. İlke olarak JS olmamasını tamamen destekliyorum. Ama web'in en iyi kullanım alanlarından biri, devlet ve banka gibi temel hizmetlere genel erişim sağlaması. İyi kullanılabilirliği koruyarak gerçekten her şeyi JS olmadan yapıp yapamayacağımızdan henüz tamamen emin değilim, ama belki mümkündür
  another comment içindeki “bu spesifikasyon normal web tarayıcılarının çalışmasını engellemiyor, bugünkü web de yok olmuyor” kısmını da vurgulamak isterim
  “İçerik web tarayıcısı” ile “uygulama tarayıcısı”nı ayrı çalıştırabilsek iyi olurdu. Birçok amaç için uygulama platformu olarak web kadar iyi alternatif pek yok; web çok gelişti ve geliştiriciler de diğer seçeneklerden çok web'i tercih ediyor gibi görünüyor
  Böyle bir dünyada Google Maps içerik web tarayıcımda çalışmaz, uygulama tarayıcısında açılırdı. GMail'i uygulama tarayıcısında çalıştırınca e-postadaki bağlantılar içerik web tarayıcısında açılırdı
  İçerik web tarayıcısının ideal olarak uygulanması çok daha kolay olmalı; bu da rekabeti ve yeniliği teşvik ederdi. Ama bunun hayata geçme yolu pek görünmüyor, bu da üzücü. Tüm içerik gezintisini böyle bir içerik tarayıcısıyla yapabilsem çok daha mutlu olurdum. Saldırı yüzeyi çok daha küçük olacağı için güvenlik açısından içim daha rahat olurdu. Ama artık kimsenin umurunda değil gibi

  • Web sayfalarında JS'nin meşru kullanım örneklerinin neredeyse tamamı, tarayıcıda önemli işlevler eksik olduğu için ortaya çıkıyor. Bunu onlarca yıl boyunca öğrendik ve script'ler sayesinde tarayıcılar bu işlevleri eklemek zorunda kalmadı
    O zaman bunları doğrudan tarayıcı özelliği olarak eklemek gerekir

• Gemini'ye biraz benziyor ama bu fork biraz daha fazlasına izin verecek gibi duruyor
  Web siteleri Markdown türevi ya da benzeri bir şeyle yazılabilir diye düşünüyorum. Ham haliyle de kolay okunabilen belgeler olmalı. Gemtext'e satır içi medya gibi birkaç özellik eklenmiş hali gibi
  Ve biraz stil yeteneğine de izin verilmeli. Web, yaratıcılığı ortaya koymak için harika bir yerdi ve hâlâ öyle. Basit ve tutarlı bir stil kümesi korunursa yaratıcı insanlar daha ilginç siteler üretebilir

• HTMX'in temel unsurlarını da ele almak iyi olurdu

  • Ben şahsen yalnızca Triptych ilkel işlevlerinin gömülü olmasını isterdim. İstemciyi aşırı karmaşıklaştırmadan sunucu tarafında oluşturmak için yeterince olanak sağlıyor

• Bu fikir, açık bir motivasyon olursa daha iyi çalışır. “Basitleştirelim” fazla soyut kalıyor. İnsanların basitlik anlayışı farklı olduğu için, web'in neden daha basit olması gerektiğine ve bunun hangi somut ihtiyacı karşılayacağına dair daha açık hedefler gerekli
  Örneğin Gemini projesi, belirli bir iletişim biçimini önemseyen bir topluluk oluşturmaya odaklanıyor. Web'i o iletişim biçimine göre sınırlayıp basitleştirmesinin nedeni, o topluluğun hedefleriyle uyumlu olması; hatta görüntüleri bile teknik olarak desteklemediğini hatırlıyorum
  Buna karşılık Sciter ya da Blitz gibi araçlar, başka uygulamalara tarayıcı benzeri bir render motorunu daha kolay gömmeyi hedefliyor. Bunlar gereksiz tuhaf davranışları kaldırarak ya da HTML ayrıştırma ve JS çalıştırmayı isteğe bağlı hale getirerek sadeleşiyor. Böylece hem uygulanacak hem de gömülecek şey azalıyor
  İkisi de basitliği hedefliyor ama temel amaçları çok farklı olduğu için ortaya çıkan sonuçlar da çok farklı oluyor. Buradaki temel amaç ne?