HTML öncelikli bir site kurarak kullanıcı sayısını bir gecede nasıl ikiye çıkardılar
(mohkohn.co.uk)- HTML öncelikli yaklaşım, kamu hizmeti başvuru formunun JavaScript olmadan da çalışmasını sağladı ve zayıf cihaz, tarayıcı ve ağ koşullarında bile kullanıcıların başvuruyu tamamlayabilmesine imkan verdi
- Mevcut React uygulaması müşteri şikayetleri nedeniyle 3 gün içinde kaldırıldı; yükleme spinner'ları, küresel JavaScript durumu, erişilebilirlik sorunları ve görselleri
localStorageiçindeki 5 MB sınırına takılan bir depolama yöntemi sorun yaratıyordu - Yeni uygulama Astro tabanlı olarak kuruldu; formun her adımı ayrı bir sayfa yapıldı ve gönderilen verilerle yüklemeler, girilen verilerin kaybolmasını önlemek için her adımda arka uç oturumunda saklandı
- Form doğrulaması, tarayıcının yerleşik HTML doğrulamasını saran bir web component ile ele alındı; başarısız olursa tarayıcının varsayılan doğrulamasına ve ardından arka uç API doğrulamasına geçen aşamalı iyileştirme yapısı kullanıldı
- Yayına alındıktan sonra formu tamamlayanların sayısı iki katına çıktı ve JavaScript hatası nedeniyle ayrılan kullanıcıların JavaScript tabanlı analiz paketlerinde görünmediği ortaya çıktı
Sorunun arka planı ve başarısız önceki deneme
- Müşteri bir utility şirketiydi ve hizmet başvurusu, web sitesindeki eski ASP formu ya da manuel süreçler üzerinden yapılabiliyordu
- Manuel süreç şirket için daha pahalıydı ve müşteri memnuniyeti %96'nın altına düşerse milyonlarca sterlin ceza doğurabilecek düzenlenmiş bir tekel durumu vardı
- Sorunu çözmeye yönelik önceki girişim iki kez başarısız oldu; en son denemede başka bir ülkedeki yükleniciler bir React uygulaması geliştirdi
- React uygulaması, internette yayına açıldıktan 3 gün sonra müşteri şikayetleri nedeniyle kaldırıldı
- Uygulama, yükleme spinner'ları ve küresel JavaScript durumunun birbirine karıştığı, erişilebilir olmayan bir yapıdaydı
- Görsel yükleme formun temel işlevlerinden biriydi, ancak görselleri ve tüm form verilerini 5 MB sınırı olan
localStorageiçinde saklamaya çalışıyordu
HTML öncelikli yaklaşım için belirlenen ölçütler
- Yeni site Astro ile oluşturuldu ve HTML öncelikli bir mimari benimsendi
- JavaScript yalnızca web component'lerin içinde kullanıldı ve JavaScript olmadan da düzgün çalışan web sitesini aşamalı olarak iyileştirme görevini üstlendi
- Kamu hizmetlerinin mümkün olan her cihazda çalışması gerektiği ölçütü benimsendi
- Bağlantı kötü olsa bile çalışması gerektiği ölçütü benimsendi
- Forma bir kez girilen verilerin asla kaybolmaması gerektiği ölçütü benimsendi
- Terence Eden'ın örneği, GOV.UK'nin basit HTML sayfalarının yavaş ve sık sık belleği tükenen PlayStation Portable tarayıcısında bile konut yardımı bilgilerini okunabilir kıldığını gösterdi
- GOV.UK sayfaları hafif olacak şekilde tasarlanmış basit HTML ile yazılmıştı ve çok kötü tarayıcılarda bile çalışmaları gerekiyordu
Form yapısı ve veriyi koruma yöntemi
- Formun her oturumunun benzersiz bir kimliği olmalıydı
- Form sihirbazının tüm adımlarında gönderilen veriler ve yüklenen dosyalar arka uçta saklanmalıydı
- JavaScript olmadan da form tamamlanabilmeliydi
- Eski ve düşük performanslı web tarayıcılarında da form tamamlanabilmeliydi
- Erişilebilirlik WCAG ölçütlerini karşılamalıydı ve ekip AAA yerine AA seviyesini hedefledi
- JavaScript ve modern CSS deneyimi iyileştirmek için kullanılmalıydı
- Nihai yapıda form sihirbazının her adımı ayrı bir sayfa oldu ve kullanıcı İleri'ye bastığında form gönderildi
- API veriyi geçerli sayarsa tarayıcı bir sonraki adıma yönlendirildi
- Form gönderimi ve yönlendirme, eski bir web uygulaması kalıbıdır ve Remix sayesinde küçük çaplı modern bir canlanma yaşadı
- Bu hizmet, gerçek zamanlı veri gösteren bir uygulama değil büyük bir formdu; render etmeden önce 20 MB JavaScript göndermek uygun değildi
Form doğrulaması ve aşamalı iyileştirme
- Form doğrulaması ve form hata gösterimi, React doğrulama kütüphaneleri nedeniyle ekiplerin uzun saatler harcadığı bir alan olarak ele alınıyor
- Oysa tarayıcılarda zaten bir doğrulama sistemi bulunuyor ve bunu kullanmak, ayrı kütüphane yönetimi gerektiren düşük kaliteli taklit uygulamalardan daha az emek istiyor
- Uygulanan HTML web component, mevcut HTML'yi saran basit bir custom element idi
- Bu web component shadow DOM kullanmıyordu ve JavaScript içinde neredeyse hiç HTML render etmiyordu
- Component, HTML formunu sarıyor ve HTML doğrulamasını alıp modern bir biçimde gösteriyordu
- HTML doğrulama popup tooltip'leri engellendi ve hatalar, alanla ilişkilendirilmiş
aria-describedbyöğesinin içine yerleştirildi - Bugün
aria-errormessagekullanımı öneriliyor - Girdi sırasında alan geçerli hale gelirse doğrulama temizleniyor,
bluranında ve gönderim sırasında yeniden değerlendiriliyordu - Bu kullanıcı deneyimi 1 KB'tan küçük bir boyutta sunuldu ve başarısız olursa tarayıcının varsayılan doğrulamasına geri dönüyordu
- Tarayıcının varsayılan doğrulaması da başarısız olursa doğrulamayı arka uç API'si üstleniyordu
- Doğrulama sorunları, kullanıcının tarayıcısının izin verdiği en erken anda bildirildi ve başarısız olsa bile her zaman kabul edilebilir bir deneyime fallback yapıldı
- Daha sonra genel kullanım için web component'in yeni bir sürümü baştan yazıldı; adı validation-enhancer
- Kullanım örneğinde
validation-enhancer, HTML formunu sarıyor veinput type="email",required,aria-errormessageyapılarını aynen kullanıyor
Email
Submit
Yayın sonucu ve sonuç
- Yayına alındıktan sonra formu tamamlayan kişi sayısı iki katına çıktı
- Analiz ekibi bu kullanıcıların nereden geldiğini bilmiyordu
- JavaScript tabanlı analiz paketleri, JavaScript hatası yüzünden ayrılan kullanıcıları göremiyor
- Arka uç oturumunu koruyan ve kullanıcı verisini asla kaybetmeyen yaklaşım işe yaradı
- Bir örnekte kullanıcı, forma başladıktan bir ay sonra tamamladı
- Sözleşmeli iş bittikten sonra görevi devralan kişi, JavaScript olmadan da her zaman çalışan yapının ekibe daha fazla iş çıkardığını söyledi
- Eski tarayıcı kullananları, kötü ağ bağlantısına sahip kullanıcıları ve yardımcı teknolojiler kullanan kişileri dışlamak, tekel durumundaki bir kamu hizmetinde kabul edilemez
- Yazılım sektörünün büyüme döneminde ortaya çıkan kaba ve olgunlaşmamış yaklaşımları sürdürme eğilimini geride bırakmak gerekiyor
- PlayStation Portable ve 3G bağlantıda da çalışan bir web uygulaması yaparsanız, hem tüm kullanıcılar için çalışır hem de 30 yıl sonra bile çalışabilir
2 yorum
Hacker News görüşleri
Web dışı bir geliştirici olarak merak ediyorum; bu yaklaşımın neden daha fazla iş çıkardığını anlamıyorum
Yazıda anlatılan yaklaşım oldukça basit görünüyor: form için standart bileşenler oluşturup alta bir gönder butonu koymak yeterli. Yıllar önce kişisel web sitemi yaparken ben de böyle yapmıştım ve o kadar da zor değildi. Belki bu alanı iyi bilmediğim içindir ama gösterişli bir frontend yapmak çok daha zor görünüyor
Aptal olduklarından değil. Doğrudan “React olmadan web sitesi yapılabilir mi?” diye sorsanız elbette “evet” derler. Ama onlara yeni bir web sitesi yapmaları söylendiğinde, alışkanlık ve işi bitirme isteğiyle fazla düşünmeden yeni bir React projesi başlatıyorlar
Bazıları gerçekten başka yol bilmiyor. Düz HTML dönen sıradan bir HTTP sunucusunun nasıl kurulacağını da, JavaScript olmadan doğrulanan/gönderilen form yapma deneyimini de bilmiyorlar. Bu insanlar HN'de yazı yazan tipler değil; yeni araçlar ve teknolojiler ya da eski araç ve teknolojiler hakkındaki çevrimiçi tartışmalara da katılmıyorlar. Bir bootcamp'te ya da üniversitede tek bir web uygulaması dersinde işe girecek kadarını öğrenip, sonra da işverenin istediği veya ekipten birinin seçtiği araçları ihtiyaç oldukça öğrenmiş kişiler
Daha yaşlı biri olarak bunu fark etmem biraz zaman aldı ama artık anlıyorum. Kariyer yoluna bağlı olarak bazı insanlar HTML, CSS ve düz JavaScript'in en temel kısımlarıyla, bu teknolojilerin karmaşık framework'e özgü kısımlarından daha sonra tanışıyor. Bu yüzden onlara göre bu yaklaşım daha az profesyonel değil; tersine daha anlaşılmaz, daha ileri seviye ya da ikincil bir bilgi gibi hissediliyor
“Bu bizim için çok daha fazla iş demek” sözü de ille de bilinçli olarak yanlış bir iddia olmayabilir. Alışık olmadığınız araçlarla iş yapmak, o araçlar daha az karmaşık olsa bile, gerçekten çok daha fazla iş gibi hissettirebilir
Uygulama hızlı ve basitti ama bunun bir bedeli vardı. Zengin UI öğelerini npm paketleri olarak doğrudan alıp kullanma imkânımız sınırlıydı ve iyi bir kullanıcı deneyimi sunmak için çok daha fazla emek gerekiyordu. Her şey daha uzun sürdü ve sonuçta kullanıcı deneyimi de daha kötü oldu. Özen gösterdik ama sonuna kadar ilgilenmeye zaman bulamadığınız durumlar da oluyor
Şirket başarısız oldu ve React'in bunu kurtaracağını düşünmüyorum. Ama “sadelik” konusundaki ahlaki takıntının da yardımcı olmadığını bizzat söyleyebilirim. Her zaman bir ödünleşim var
Birisi, çoğu insanın aklına gelecek çözümden daha basit ve daha mantıklı bir çözüm sunduğunu söylüyor ama devralan kişi bundan memnun kalmamış
Devredilen kodun kalitesinin yüksek olup olmadığını biliyor muyuz? O kişi sadece “React değil” olmasına mı tepki verdi? Şirkette uygulama geliştirmenin zorunlu kılındığı bir şablon olabilir miydi?
Bilmiyoruz
Bir süredir çok duymuyorum ama HTML Triptych önerisinin bir gün tarayıcılara gelmesini hâlâ umduğum şeylerden biri. HTML formlarının REST endpoint'leriyle konuşma biçimi iyi bir desen
Kullanıcıya yardımcı doğrulama input özellikleriyle ele alınıyor, asıl doğrulama isteğin diğer tarafında yapılıyor ve akış GET /form => POST /thing => GET /thing/1 şeklinde oluyor. Triptych özelliği uygulanırsa harika bir desen olur
[0] https://triptychproject.org/
React sitelerini hiç sevmiyorum ama anlamadığım şey şu: bu siteler lazy loading hiç mi yapmıyor?
Büyük bir tek sayfa uygulama bile, bileşenleri yalnızca ihtiyaç olduğunda yüklüyorsanız çok hızlı olabilir
Angular1 -> Vue2 -> Svelte2 üzerinden geçip shadow DOM'suz düz web component'lerinde karar kıldım; hem hızlı hem de üzerinde çalışması keyifli
Bu günlerde çoğu uygulamayı sadece HTMX + Go + SQLite ile yapıyorum
Çoğu proje için bunun yeterli olduğunu düşündüm
Sitelerimden biri çok fazla görsel içeriyor ve aylık 10TB trafik işliyor. Bu durumda kurulum şöyle: 1. Güvenilir veri depolaması gerektiği için S3 kullanıyorum 2. Önüne Cloudflare koyup Tiered Cache’i açıyorum. Böylece POP’lar origin yerine Cloudflare’dan çekmeyi tercih ediyor. Hem tarayıcıda hem de Cloudflare’da her şeyi 1 yıl önbelleğe alıyor, origin cache policy ve query string’i yok sayan kurallar tanımlıyor ve yalnızca revizyon gerektiren immutable nesneler kullanıyorum 3. Onun da önüne BunnyCDN koyuyorum
Sadece Cloudflare, görsel ağırlıklı bir siteyi işletmeme izin vermiyor; bu yöntemle maliyeti ciddi ölçüde düşürdüm. Politika gereği bunu esas olarak görseller için değil, HTML, CSS, JavaScript ve sitenin diğer içerikleri için kullanmak gerekiyor
Yalnızca S3 kullansam maliyet çok yükselirdi
Ama son zamanlarda mobil uygulama yapıyorum. PWA’nın sınırları var. İşletim sistemi IndexedDB depolamasını geri alabiliyor; bu yüzden üyelik ya da backend müdahalesi olmadan uygulama içinde güvenilir veri depolaması sunamıyorsunuz
Sonunda Android’de Flutter’a geçmek zorunda kaldım ama onun da başka acıları vardı. Bazen uygulama güncellemeleri uzun süre “incelemede” kalıyor ve bu çok sinir bozucu. Aynı uygulamanın web sürümüyle karşılaştırınca güncellemeler çok daha hızlı
JavaScript, HTML, CSS ile uygulama yapmaya izin verip büyük bir uğraş gerektirmeden kararlı depolama da sağlayan bir mobil işletim sistemi neden yok diye merak ediyorum. PWA uygulamalarını hızlı güncelleyebilmek güzel
Zaman yolculuğu kolay kısmı; asıl sonrası Palm’ın çöküşünü ve webOS’un akıllı telefon işletim sistemi olarak unutulmasını bir şekilde engellemek
2009 çok uzak geliyorsa 2012’deki Firefox OS’a da şans verebilirsiniz
Şakayı bir kenara bırakırsak, insanlar ve şirketler bunu denedi. Ama kötü zamanlama ve üst üste gelen olaylar yüzünden bizim zaman çizgimizde bu gerçeklik yaşanamadı
C’deki gereksiz yükler olmadan, Java’daki gibi iş mantığına odaklanmaya izin veren tam doğru tatlı noktada gibi hissettiriyor. Rust öyle değil
Her iş için iyi değil. Özellikle soyutlama kurma becerisinin sınırlı olması üzücü. Ama iş mantığı yoğun sunucu uygulamaları için harika. Her şeyi yapmaya çalışan bir dil değil, o alana özel bir dil gibi
SQL ve HTMX/web/OAuth kısımlarını soyutlamak için birkaç kütüphane de yaptım. Artık uygulamalarım birbirine çok benziyor; o yüzden özellikleri birinden alıp diğerine taşımak kolay
https://github.com/cattlecloud/webtools
https://github.com/cattlecloud/litesql
Karşı argüman olarak In Defence of the Single Page Application var
https://williamkennedy.ninja/javascript/2022/05/03/in-defenc...
In Defence of the Single Page Application - https://news.ycombinator.com/item?id=31275178 - Mayıs 2022, 32 yorum
Bu yazı güzel; problemi ele alıp uygun teknolojiyle ve doğru derinlikte çözen harika bir örnek. Müşterinin alan bilgisini eksiksiz taşımak gerçekten çok yardımcı oluyor
Ama “basit HTML, React’ten daha iyidir” şeklindeki çerçeveleme hoşuma gitmiyor. Çünkü aynı hikâye React geliştiricisi olarak da birebir anlatılabilir
Sunucu tabanlı oturum saklama ile tarayıcı tabanlı depolamanın karmaşıklığı ve incelikleri gibi, bu yazıda hızlı geçilmiş daha pek çok konu hakkında sayfalarca konuşulabilir ama çok uzar
HTML’de basit olan şeyler React’te de basit
Kelimenin tam anlamıyla aynı kod. React’te tarayıcı tabanlı HTML doğrulaması kullanmanızı engelleyen hiçbir şey yok. React’te karmaşıklaşan kod, örneğin gereğinden fazla karmaşık doğrulama mantığı, Astro’da da karmaşıklaşır. Astro’nun da şema doğrulama gibi konularda kendi yaklaşımı var ve bunu Astro sitesine entegre etmek için client router gibi şeyleri de entegre etmek gerekiyor; orada da gereksiz karmaşıklığa düşmek çok kolay
Karşılaştırılan taraf da muhtemelen eksik bilgiye sahip bir yurt dışı dış kaynak ekibi ve proje yapısı gereği çözümü olabildiğince hızlı, mümkün olan en az zamanda ve mümkün olan en yüksek karmaşıklıkla üretmeye teşvik ediliyorlar
Son nokta ince bir mesele. Dış kaynak şirketinin bunu kasıtlı yaptığı anlamına gelmiyor ama teşvik yapısı gereği aşırı karmaşıklık fiilen onların lehine çalışıyor; bu yüzden daha basit bir yola gitmeleri için doğrudan bir teşvik yok
Her hâlükârda, eldeki problemi doğrudan ele alan basit çözüm her zaman daha iyidir; hangi stack’i seçerseniz seçin durum aynı
Astro’nun form doğrulamasına karşı değilim; yalnızca konunun “native HTML browser validation”dan daha fazlası olduğunu vurgulamak istedim
Harika bir yazı, ama böyle ilham verici yazılar okuduğumda hep ikilemde kalıyorum. Söylenenler tamamen doğru ve basit bir site fikrini seviyorum: iyi çalışıyor, hızlı yükleniyor ve modern tarayıcılara bağımlı değil.
Sonra da bunun, React’i ya da o an moda olan havalı teknolojileri anlayacak kadar zeki olmadığım için hoşuma gidip gitmediğini düşünmeye başlıyorum.
Aşılamaz bir anlama sınırı varmış gibi geliyor. Bana Sublime gibi basit bir editör verip web sayfası yapmamı isteseniz, JavaScript olsa bile mutlu olurum. Ama VSCode ya da Zed, oraya buraya iliştirilmiş Claude/Copilot/ChatGPT eklentileri ve React eğitimleri verildiğinde beynim pelteye dönüyor.
Basit tutmak kötü bir şey değil; aksine, çoğu zaman gereksiz yere fazla karmaşıklaştırmayacak kadar zeki olmayı gerektiriyor.
Embrace Extend Extinguish gerçektir ve buna ayak uyduranların, daha hızlı yalan söyleyen ve daha hızlı çöp kod üreten LLM’lerle yer değiştirmesi de gayet yerinde olur.
Bu bana neredeyse 15 yıl öncesini hatırlattı. Grails’te arka uç oturum yönetimini kullanıyor, duyarlı CSS ve “biraz” JS ile geliştirilmiş HTML formları kullanıyorduk.
O zamandan farkı, tarayıcı teknolojilerinin bugünkü kadar gelişmemiş olmasıydı. Birden çok tarayıcıyı düşünmek gerekiyordu; IE7, hatta IE6 ile uğraşmak zordu ve kapsamlı QA şarttı. BrowserStack daha sonra çıktı.
JavaScript kütüphanelerinin evrilmesinin bir nedeni var. npm yoktu, bower bile yoktu. Sonra Backbone.js çıktı ve onu sevdim. AngularJS etkileyiciydi, sonraki Angular sürümünde büyük bir uyumluluk kırılması yaşandı, ardından React, Polymer ve diğerleri geldi.
Günümüzde yerel tarayıcılar çok şey yapabiliyor ve özellikleri kademeli olarak geliştirmek de kolay. Ama durum her zaman böyle değildi. O zamanlar React kullanma kararı birçok nedenle makuldü; burada da öyle olmuş olabilir.
10 yıldan da uzun süre önce Adalet Bakanlığı için GOV.UK üzerinde bunun gibi uygulamalar yaptım. Uzun formları adım adım doğrulayan ve birden çok sayfaya bölebilen kendi form sihirbazı kütüphanemizi yazdık. Çünkü Ruby on Rails bunu kutudan çıktığı haliyle desteklemiyordu.
O dönemde, kullanıcı hangi ortamdan erişirse erişsin herkesin dijital hizmetleri kullanabilmesi ilkesi çok önemliydi.
Her oturum kimliği için, çok sayfalı uygulamadaki sayfayı o oturum kimliğiyle eşleştirebilirsiniz; gerekirse kullanıcı bunu kendisi de girebilir. Ama IP adresi, yükleme tarihi, tarayıcı, işletim sistemi gibi yeterli bilgi varsa bunu ayırt edebilmeniz gerekir. Yine de en doğru oturum tarayıcının içinde olmalı; böylece tek bir başvurunun çerezi, PlayStation Portable kullanan bir akraba gibi başka başvuru sahipleriyle karışmaz.
Mobil uygulamalarında hangi teknolojiyi kullandıklarını merak ediyorum. Tam teşekküllü yerel bir mobil uygulama değil, bir webview kullanıyorlar diye tahmin ediyorum.
Buradaki mesele “React uygulamasını HTML formlarına çevirdik ve performans arttı” değil. Mesele “kötü bir web sayfasını iyi bir web sayfasına çevirdik ve performans arttı.”
Bunu tarayıcı deneyimini çalıştıran teknolojiye bağlamak saçma. React ile de harika bir kullanıcı deneyimi yapılabilir, saf HTML ile de berbat web siteleri yapılabilir.
İyileşme teknolojiden değil, tasarım değişikliğinden geldi.
Ama söylenen doğru: kullanıcı tarafındaki değişim, kullanılan teknolojiden değil tasarımın düzeltilmesinden geldi.
Bu, kötü özgeçmiş maddelerine çok benziyor. Birinin “siteyi HTML öncelikli olarak yeniden yazarak ziyaretçileri %100 artırdım” demesi gibi; sanki iş sonucu kod değişikliği sayesinde olmuş gibi. O madde sorulunca da sonunda, aslında tasarım sorunlarını düzeltmek veya özellik eklemek için tüm siteyi yeniden tasarladığını ve ziyaretçi artışını bunun sağladığını kabul eder.
Douglas Crockford’un JavaScript: The Good Parts kitabı komik derecede ince bir cilttir. React: The Good Parts ondan da ince olurdu.
İlginçtir ki özgün yazı, son 10 yılda neredeyse hiç görmediğim çok sayfalı sihirbaz tarzı formları anlatıyor. Ama ben böyle şeyler gördüğümde bunlar genelde korkunç kurumsal sistemler oluyordu. En son gördüğüm şey, masraf işlemleri için kullanılan bir Oracle ürünü gibiydi.
Bu tür şeylerin sorunu hep işlem sırasında yavaş olmalarıdır. Her düğmede birkaç saniye beklemeniz gerekir. Bir iki adım geri dönmeniz gerekirse sinir bozuculuk iki katına çıkar. Kötü yapılmış tek sayfalı uygulamalar ise başlangıçta yavaş olma eğilimindedir. Yüklenmeleri zaman alır, ama bir kez yüklendikten sonra performansları genelde iyidir.
Lobste.rs görüşleri
İnsanlar için düzgün çalışan bir şey yapmak elbette daha fazla emek gerektirir. Ama sonuçta bu, işin tamamının özüdür
Sonrakilerin aslında söylemek istediği şey, web platformunun temellerini pek bilmediklerine daha yakın görünüyor
Bunun arzu edilir olduğunu söylemiyorum, sadece mevcut gerçekliğin böyle olduğunu söylüyorum
“Form gönderimi ve yönlendirme”yi çalışma arkadaşlarına anlatmanın zaman aldığını söyleyen kısım buruk geldi. Bunun nedeni herkesin istemci merkezli web uygulamalarına alışmış olması
Web geliştirme şu anda gerçekten üzücü bir durumda ve yeniden öğretilmesi gereken çok şey var
Bu yaklaşımı gerekçelendirmek için o kadar yüksek düzeyde uyumluluğa ihtiyaç olduğunu düşünmüyorum. Yazıda da dendiği gibi, sonuçta sadece bir form
O yüzden ben olsam her durumda bunu böyle yapardım
Yazıda anlatıldığı gibi site kurma işi yapmak isterdim. Neredeyse tüm tarayıcılarda çalışmak zorunda olan ve erişilebilirliği de gözeten çok küçük bir indirme boyutu kısıtı, oldukça eğlenceli bir meydan okuma gibi geliyor
Bu alanda uzmanlaşmış şirketler var mı, işe alım yapıyorlar mı merak ediyorum. Belki de sadece eski, daha sade yöntemleri özleyen yaşlı biriyimdir
Özellikler yeterince iyi izole edilmiş durumda; yeniden kullanılabilir bir kütüphane olarak çıkarması çok kolay ve hâlâ yapılacak çok iş var. Böyle şeyleri web framework’lerinin varsayılanı haline getirmek istiyor insan. Gerçekten çok iyi bir yazı
Biraz ironik biçimde, Firefox’ta bazı stiller yüzünden ana metin ne tamamen görünüyordu ne de seçilebiliyordu; bu yüzden okuma moduna geçmem gerekti. Başlık, pembe alıntı işaretleri ve kod blokları görünüyordu ama geri kalanı görünmüyordu
Düzenleme: Aşağıdakilere bakınca bunun muhtemelen benim ortamımla ilgili bir sorun olduğunu anladım. Bağlam için bırakıyorum
Yazının kendisini iyi okudum. İster geliştirici ister son kullanıcı olalım, hepimiz React’in “çevikliğinin” bedelini ödüyoruz. İş yerinde başka bir stack kullanabilsek keşke diye birçok kez düşündüm
Ayrıca yazarın empati yeteneği ve bunu “herkesin kazandığı” bir yapı olarak tasarlamış olması etkileyiciydi. Özen göstermek eninde sonunda karşılığını veriyor
Buna çok katılıyorum. Eskiden JavaScript’i aşırı yoğun bir blog yapmıştım ve JS tabanlı özellikler yüzünden neredeyse isyan çıkacaktı
Henüz HTML öncelikli bir yaklaşıma geçirecek zamanım olmadı ama dışarıdan bakıldığında büyük ölçüde HTML öncelikli bir web sayfası gibi görünmesini sağlamıştım
Analitik verilerimde de benzer sonuçlar gördüm. Hemen çıkma oranı %80’den yaklaşık %50’ye indi ve sonraki yazıların yeni ziyaretçileri neredeyse iki katına çıktı
Başta JS ile yapılmış o berbat uygulama yüzünden ne kadar çok insanın alan adımı ömür boyu kaçınılacaklar listesine almış olabileceğini düşünmek bile ürkütücü. Web sayfası ya da blog için bu en önemli tavsiyelerden biri
Bu yöntem otomatik form doldurma için de yardımcı olur. Eskiden formun tamamı dinamikti ve her bölümü tanımlayacak nitelikler yoktu, bu yüzden otomatik doldurma yapılamıyordu
İşlevden çok güzel görünmeye aşırı odaklanmış bir tasarımdı; bu yüzden kullanıcı öncelikli tasarım üzerine bu yazıyı keyifle okudum
Buna SSE streaming ve bir morph kütüphanesi eklerseniz, dinamik, gerçek zamanlı ve çok oyunculu özellikler de oldukça şık biçimde yapılabilir