Frontend Treadmill
(polotek.net)- Bir ürün ne kadar uzun ömürlü olursa, frontend framework seçiminden çok yeniden yazım tartışmalarına harcanan zaman ve enerji daha büyük bir maliyet haline gelir
- Bir ürün 5 yıl sonra hâlâ yaşıyorsa bu başarıdır; ancak bu süre içinde seçilen framework'ün eskimiş hale gelmesi ya da aynı ad altında çıkan yeni bir sürümle büyük ölçüde değişmesi çok olasıdır
- Daha iyi ürün ekipleri, yeni araçlara geçmek yerine mevcut framework'ü derinlemesine anlayarak, aracın iş ilerleyişini engellemeyecek kadar uzmanlık geliştirir
- Uzun vadeli maliyeti düşürmek için, karmaşık soyutlamalardan ziyade web platformuna ve temel web teknolojilerine yakın kalmayı seçmek gerçekçi bir iş tavizi olabilir
- Frontend ekosisteminin karmaşıklığı hem yeni geliştiriciler hem de işe alım ekipleri için zorluk yaratır; web temelleri zayıf olan geliştiriciler bir sonraki stack değişimine karşı daha savunmasız olur
Yeniden yazımla treadmill'den çıkmak zor
- Pek çok frontend ekibi yeniden yazımın daha iyi bir duruma götüreceğine inanır, ancak uzun ömürlü ürünlerde framework seçimi başlı başına en önemli teknik karar değildir
- Bir ürün 5 yıldan uzun sürerse bu başarı sayılabilir, fakat bu süre boyunca seçilen framework eskiyebilir
- Frontend topluluğu sürekli değişim etrafında hareket etti ve bunun yakın zamanda değişmesi de pek olası değil
- Hayatta kalan popüler framework'lerin bile iç yapısı tamamen farklılaşabilir ve yeni sürüm numaraları altında fiilen yeniden yazılmış olabilir
- Ekiplerin odaklanması gereken şey yeni ve göz alıcı araçların peşinden koşmak değil, şu anda kullandıkları framework'ü yeterince iyi öğrenmektir
- Aracın işin ilerlemesi önünde engel olmayacağı düzeyde anlayış ve uzmanlık gerekir
- Alternatif bir araca geçince sorunların çözüleceği beklentisi neredeyse bir tuzaktır
Web platformuna ne kadar yakınsanız, uzun vadeli maliyet o kadar düşer
- Frontend teknolojilerinin sık sık eskimesinin maliyetini azaltmak isteyen şirketler, web platformuna daha yakın bir yönü değerlendirebilir
- Karmaşık soyutlamaları azaltmak ve web'in gerçekte neler yapabildiğini yeniden öğrenmek gerekir
- Bu, her sorunun cevabı olduğu ya da koşulsuz olarak daha iyi olduğu anlamına gelmez
- Uzun vadede daha fazla değer sunup maliyeti düşürebilecek bir iş tavizi olabilir
- Temel web teknolojilerine yakın olmak, gelecekte yetkin mühendisler işe alınırken ancak milyonlarca satır kod yeniden yazılırsa çalışılabileceği iddialarından daha az etkilenmeyi sağlar
- Mühendisler için de belirli bir framework'ü sürekli takip etmektense temel web teknolojilerini derinlemesine anlamak uzun vadeli piyasa değeri açısından daha faydalıdır
- Kısa vadede işe alım piyasasındaki çekiciliğin bir kısmından vazgeçmek gerekebilir
- Popüler teknolojilerin hepsini öğrenmeye çalışmaktan daha sürdürülebilir bir kariyer sağlar
- Belirli bir teknolojiyi bilmek, piyasanın kötüleşmesi gibi gerçeklere karşı koruma sağlamaz
Framework tercihleri ve ekip maliyeti
- Framework tercihleri güçlü olan mühendisler, bu ölçütü iş arama koşullarına yansıtmalıdır
- Hâlihazırda belirli bir framework kullanan bir ekibe katıldıktan sonra onu kendi tercih ettiği framework'e geçirmeye çalışmak ekibi sarsar ve maliyeti ciddi ölçüde artırır
- Mevcut frontend ekosisteminin karmaşıklığı hem yeni geliştiriciler hem de şirketler için yük oluşturur
- Yeni geliştiriciler işe girecek kadar yetkinlik kazanmakta zorlanır ve karmaşık araçlar karşısında bunalır
- Şirketler sıradan geliştirici alımını bile daha zor görür ve tam zamanlı geliştirici rolleri için giriş eşiği yükselir
- Bugünkü teknoloji ekosistemini öğrenen biri web temellerini öğrenmezse, stack yeniden değiştiğinde ciddi bir dezavantaj yaşayabilir
- Web, yazılım sunmak için güçlü ve benzersiz bir platformdur; zamanla daha iyi hale gelmiş ve yüksek düzeyde geriye dönük uyumluluk korumuştur
- Bugünün temel araçları yeterince iyidir, ancak framework katmanı platformu benimsemek yerine çoğu zaman ona karşı çalışır
1 yorum
Hacker News yorumları
Kısa süre önce frontend kodunun build sistemini yarn’dan pnpm’e taşıma işi yaptım; normalde backend mühendisiyim ama JS tarafında da epey deneyimim var.
Frontend’e girince en sinir bozucu şey, gerçekten her şeyin deprecated gibi görünmesi. 2022’de apollo CLI kullandıysanız, hemen deprecated olmuş oluyor ve graphql-client gibi tamamen farklı ayarları ve seçenekleri olan bir aracı öğrenmeniz gerekiyor. Sonunda eski olanı koruyup pnpm’in Node engine kontrolünü kapattım ki şikâyet etmesin. Herhangi bir bağımlılığı patch seviyesinde yükseltmeye kalkınca type signature’lar bozulabiliyor; onu da sabitleyip, bir gün birilerinin düzeltmesini umduğum bir TODO’yu codebase’e bıraktım.
Zor bela çalışır hâle getirince kurulum sırasında yüzlerce deprecated uyarısı akıp gidiyor ve build biter bitmez oradan kaçmak istiyorsunuz.
Frontend geliştirme dünyasının genel olarak breaking change ve deprecated kavramlarını bu kadar kabullenmiş olması bana gerçekten tuhaf geliyor. Neredeyse 4 yıldır büyük bir Rust projesinde çalışıyorum; bu süre boyunca üçüncü taraf kütüphanelerde birkaç küçük breaking change oldu ama uygulamayı ciddi biçimde değiştirmemi gerektiren büyük değişiklik yalnızca bir kez yaşandı. Buna karşılık JS’te sanki 6 ay bile geçmeden bir şeyleri yeniden yazmak gerekiyor gibi görünüyor.
Frontend dünyası, sosyal medyayı, YouTube’u, hatta Twitch’i diğer alanlara göre çok daha aktif benimsedi. Bu influencer’ların relevance’larını korumak için sürekli yeni malzemeye ihtiyacı var; bu yüzden içerik yapılabilecek yeni şeyleri durmadan öne itiyorlar.
Buna canlı bir konferans kültürü de ekleniyor. Frontend ve JS konferansları, yükselen yeni konuları sunmak için büyük bir rekabet gibi hissettiriyor.
Frontend kursları satılan pazar da büyük. Kurs üreticilerinin, yeni trendi öğrenmeye yönelik 700 dolarlık sınırlı süreli video kursunu patrona onaylatmaları gerekiyor; bunun için de sektörün zaten bildiği eski şeylerden uzaklaşmasını sağlamaları şart. Bu yüzden yeniyi güçlü biçimde itip eskiyi deprecated hâline getiriyorlar.
15 yıl önce yazdığım küçük, 5 KLOC’luk saf JS web uygulaması, tek satırı bile değişmeden bugün hâlâ yaklaşık 10 kişi tarafından her gün kullanılıyor. Hatta Win32 uygulamalarından daha iyi dayanıyor.
Frontend’deki churn’ün büyük kısmının basitçe siyasi ve kurumsal bir başarısızlığa yakın olduğunu düşünüyorum.
Saf JS/jQuery döneminde başladığımda bağımlılık yönetimi fiilen
.jsdosyalarınıvendor/dizinine kopyalamaktan ibaretti. Sonra nodejs/npm çıktı; frontend’de npm’den önce bower da kullanıldı ve birden “kendin yazma, modül indir” tavsiyesi standart hâline geldi.Ama daha o zaman bile binlerce satırlık görünmez kodu bizzat sahiplenmeyip, eğlencesine açık kaynak yapan gönüllülere bırakmanın doğru olup olmadığını sorgulayan çok kişi vardı.
Bugün de bir projeyi uzun süre yaşatmak istiyorsanız görünmeyen kısmı fazla şişirmemek mümkün. “Bu kütüphaneden yalnızca bir fonksiyona ihtiyacımız var; tüm kütüphaneye bağımlı olmak yerine o fonksiyonu codebase’e kopyalayıp test ekleyelim” yaklaşımıyla küçük sorunlar çözülebilir.
Bu yüzden bunun JavaScript’in kendisine ait bir sorun değil, insan ve süreç sorunu olduğunu düşünüyorum. Bu sorunları yaşamayan birçok JS geliştiricisi de var, ama ekosistemin büyük bir kısmı böyle değil.
“MultiselectDropdown’u MultiSelectButtonDropdown yapsak nasıl olur? API’yi de tamamen yeni bir şeye çevirelim!” gibi ‘çok önemli’™ breaking change’lerin sonuçlarını düzeltmek için her gün binlerce insan-saat harcanıyor.
Breaking API’lerin muazzam maliyetini anlayan bir kültür neredeyse yok. 10 yıl Go ile çalıştıktan sonra bu özellikle can sıkıcı geliyor. Go’nun geriye dönük uyumluluk vaadi var ve bu, Go kütüphane geliştiricilerinin uyumluluk ve breaking change konusundaki tutumunu da etkiliyor gibi görünüyor. 10 yıl önce yazılmış kodun güncel Go’da olduğu gibi derlenip çalışması gerçekten güzel bir deneyim.
Bu JS/web cehenneminden çıkmak için bir ara Flutter’a geçmiştim; bana epey uygun gelmişti ve web stack’inin tesadüfi karmaşıklığının çoğunu unutturmuştu. Ama “paketi bozmak sorun değil” kültürünün Dart ekosistemine de sızıyor olması çok sinir bozucu.
Açıkçası frontend’den çok daha kötü olduğunu düşünüyorum. Frontend’de en azından TypeScript ve dil özellikleri sayesinde hasar alanı nispeten sane bir seviyede sınırlanıyor. Python’da ise gerçekten kelimenin tam anlamıyla her şeyi yapabilirsiniz; bu yüzden kütüphane yazarları da kelimenin tam anlamıyla her şeyi yapıyor. Modüllerin import edilme biçimini değiştirmek istiyorsanız değiştirirsiniz; metaclass’larla sınıf davranışına dair tüm varsayımları yıkmak istiyorsanız mümkündür. Statik tiplerin yardımcı olacağını düşünseniz bile
Partialgibi basit şeyler bile yoktur; iki nesnenin aynı tipte olduğunu statik olarak ileri sürmek de olmaz.Kütüphaneler değişiyor diye söylenildiğini görmek komik. Python 2’den 3’e geçiş o kadar korkunçtu ki, önceki iş yerimde Python 3’e yükseltme planı hiç olmayan 100 milyon satırlık bir Python monolith vardı. SqlAlchemy 1’den 2’ye geçmek 8 aşamalı bir migration ve fiilen tam bir yeniden yazım; tek bir şey bile bozulsa site kapanıyor. Buna karşılık React’in opsiyonel olarak hooks eklemesinden şikâyet ediliyor.
Tuhaf olan şu: İnternette “frontend treadmill” yazılarıyla dolu, ama bunun karşı tarafı hakkında söylenen yazılar pek görünmüyor.
“Bir mühendisseniz, temel web teknolojilerini ne kadar derin anlarsanız zaman geçse de piyasa değerinizi o kadar yüksek koruyabilirsiniz” sözü hakkında; neredeyse 20 yıldır frontend yapıyorum ve birkaç büyük paradigma değişimi yaşadım, dolayısıyla fikir belirtmeye hakkım olduğunu düşünüyorum.
Temel web teknolojilerinin hepsini bilmenin sizi daha dengeli bir mühendis yaptığı kesinlikle doğru. Ama bunun işe alım piyasasında sizi daha cazip gösterip göstermediği konusunda şüpheliyim. Bu bilginin önemsiz olmasından değil; işe alım kararını verenlerin genelde kalıp eşleştirmesi yapmasından.
“Piyasa değerini” en üst düzeye çıkarmak istiyorsanız hâlâ React’i çok iyi bilmeniz gerekiyor. Bu neredeyse temel giriş bileti gibi; diğerleri harika ama bu temel yoksa seçenekleriniz azalıyor. Belki yazar bunu kastetmişti de ben yanlış okumuş olabilirim.
Ancak danışmanlık veya sözleşmeli roller için orijinal yoruma katılıyorum. Büyük danışmanlık şirketlerinde işe alım yapan ya da kimin mülakata çağrılacağına karar veren insanlarla çalıştığınızda, tercih ettikleri stack’i veya mevcut müşterinin kullandığı stack’i zaten bilmeyenleri neredeyse otomatik olarak elediklerini görüyorsunuz. Bunu teknik mimarlar da yapıyor; yani sorun sadece teknik olmayan işe alımcılarla sınırlı değil. Yetkinlikten bağımsız olarak, teknolojinin kendisine uyum sağlama süresi istemiyorlar.
Bu tür rollerde güncel kalmak çok önemli. Aksi halde işe alım yöneticisi, bir mühendisin beceriyi değerlendirmesine fırsat kalmadan, buzzword eksik diye özgeçmişi çöpe atıyor.
İstisnai bir durum olabilir, ama React bilmemek hiç sorun olmadı. “Temel giriş bileti” ifadesi fazla güçlü.
Frontend’de ücret açısından oldukça sağlam bir üst sınır var. Belli bir seviyenin üzerine çıktığınızda bir daha UI yapmanız gerekmiyor.
Çoğu şirket, hatta büyük şirketler bile temel prensiplere pek önem vermiyor, bunları doğrulamıyor ya da buna göre işe almıyor. “React’i iyi biliyor” veya “Next.js deneyimi çok” gibi kriterlerle işe alıyorlar.
Temeller, sıfırdan bir şey inşa ederken harikadır; ama gerçek şirketler bunu neredeyse hiç yapmaz. Genelde ekosistemi büyük ve dokümantasyonu iyi olan hazır çözümleri alıp kullanırlar. Bunlarda iyiyseniz işe alınmanız çok daha kolay olur; temelleri de bu süreçte öğrenebilirsiniz.
“Hangi framework’ü seçersen seç, 5 yıl sonra obsolete olur” sözü biraz eskimiş bir argüman gibi görünüyor.
Asıl olarak frontend geliştiricisi değilim ama frontend yapmam gerektiğinde kaçınmam; son 10 yıl kadar React kullandım. Svelte tarafına doğru bir miktar hava değişimi var, ama Svelte React’i geçtiğinde muhtemelen Svelte de o kadar uzun süre production’da kullanılmış olacak. Angular da bir gün güç kaybedebilir; ama Angular1 ve Angular2+ dönemlerini birlikte düşünürsek React’ten daha eski.
Frontend geliştirme hızlı ilerliyor, bu doğru; ama o kadar da kötü değil. Sıkıcı seçimler yaparsanız sıkıcı sonuçlar alırsınız.
Angular1 ve 2, adı dışında neredeyse karşılaştırılamayacak kadar farklıydı ve birçok geliştirici burada yandı. Angular’ın kendisi de epey büyük ölçüde değişiyor. v1’den Angular2’ye geçiş kadar sert değil, ama yine de ciddi bir yeniden alışma gerektirecek kadar büyük. Her şey standalone component’lere, yeni template sözdizimine, signals’a vb. kayıyor.
React’te de benzer. Fonksiyonel component’ler ve hooks’un gelişiyle büyük bir paradigma değişimi yaşandı. Uyumlu kaldılar, ama birbirlerinden çok farklıydılar.
Daha genel paradigmada da aynı şey geçerli. Başta her şey server-side rendering idi; sonra single-page app’lere tam gaz koşuldu; ardından yeniden server-side rendering’e dönüldü, ama bu kez hydration içeren kısmi server-side rendering olarak.
Başka bir framework denebilecek kadar farklı; dolayısıyla nüansları olsa da o argüman tamamen ölmüş değil.
Çalışması gerçekten çok basit. Basit bir hisse dağılım uygulaması yaptım; beni en çok şaşırtan şey bundle boyutuydu. gzip ile 9KB idi ve bildiğim tüm framework’lerden küçük. Bir ölçüde “anti-JS”e yakın olan htmx’ten bile küçük.
Eski framework’ler de çok uzun süre çalışabilir. O stack’i bilen insanlar var olduğu ve gerektiğinde işe alınıp üzerinde çalışabildiği sürece o stack obsolete değildir. “Eski” ya da “legacy” denebilir. Ama onu yönetecek hiç kimsenin kalmadığı gün gelene kadar obsolete değildir.
Buna frontend sorunu denmesi ilginç. Frontend sorunu değil, devasa bir ekosisteme sürekli yeni katılımcıların girmesi sorunu
15 yıl önce Java inovasyonun en ön safındayken de aynı şeyi gördüm. Birkaç yıl içinde onlarca framework ve çeşitli build sistemleri çıktı. React 17’den 18’e geçiş, Perl 5’ten 6’ya ya da Python 2’den 3’e geçişten çok daha küçük bir değişim
Backend tarafında “yeni bir framework kullanalım” yerine “yeni bir dil kullanalım” deniyor. Son moda, bir şeyleri Rust ile yeniden yazmak; ondan önce Go, Haskell, Scala, F# da vardı
Frontend kodunu React’ten Svelte gibi bir şeye taşımayı can sıkıcı buluyorsanız, bir de VB 6 uygulamasını yeniden yazmayı deneyin. Verinin kodun içinde olduğu RPC benzeri şeylerden bahsetmiyorum bile
Mühendislik pratiklerindeki istikrarsızlık sorun değil demek istemiyorum. Büyük bir sorun. Sadece frontend’e özgü bir sorun değil
webpack de 13 yıllık, ama son birkaç yıl içinde bile yapılandırma biçimi dramatik şekilde değişti
Apache yapılandırması bu sistemler kadar sık değişseydi kimse Apache kullanmazdı
Önceki işimde 2 yıl içinde iki veritabanı migrasyonu yapıldı ve toplam 1 yıllık mühendislik zamanı harcandı. Hedef bazı kritik olmayan tablolar değil, tüm tablolardı. Bir şey bozulduğunda ya da üst yönetim neden bu kadar yavaş olduğunu sorduğunda, deneyimsiz oldukları gerekçesiyle frontend öğrenen mühendisleri suçladılar
25 yılı aşkın süredir Java geliştiricisi olarak çalışıyorum; ilk 10 yıldan biraz fazlasında full-stack geliştirme yaptım ve o dönemde şirketlerde yaygın model buydu. Artık ayrı bir frontend ekibinin olması normal, hatta web·iOS·Android diye üç ekibin olduğu durumlar da çok. Bana göre bu değişim AngularJS’den Angular’a geçiş dönemleri civarında yaşandı
Java da ilk 10 yıl kadar hızlı değişti, özellikle ilk 3 yıl çok hızlıydı. Ama o dönem bitti. Java 5 büyük bir değişimdi, Java 8’de de önemli özellikler vardı; ama Java 8 2014’te çıktı. Ekibimiz ancak yakın zamanda Java 11’e geçti, şimdi ise Java 24 çıktı. Ben Java 11 özelliklerini hiç kullanmadım, ne olduklarını da bilmiyorum. 10 yıldır tek bir yeni dil özelliği bile öğrenmedim
Build aracı son 15 yıldır aynı, IDE son 20 yıldır aynı. Başlıca kullandığımız framework de 10 yıldır aynı. Son işime geçtiğimde codebase yapısı önceki ekibimle tamamen aynıydı
Java ile web servisi yapmak çözülmüş bir problem. İyi anlamda tamamen sıkıcı; COBOL gibi
Frontend 90’ların sonu ve 2000’lerin başında da hızlı değişiyordu, ama sonrasında da sürekli hızlı değişmeye devam etti. Birkaç yıl önce yaptığım kişisel UI projesi tamamen eskimiş durumda
EJB sonrası dönemde üzerinde çalıştığım bir Java projesi olsaydı, bugün bir Java geliştiricisini bulup projeye katsanız hemen üretken olabilir. O geliştirici proje oluşturulduktan sonra doğmuş olsa bile mümkün. Öğrenmesi gereken sadece birkaç eski kütüphane olur
Koşu bandından inmenin yolu frontend framework’lerini hiç kullanmamaktır. Rastgele başka bir framework seçip sonra tekrar yeniden yazmak değil
Sunucu tarafı render, yalnızca gerektiğinde JavaScript ve şirket içinde backend ile frontend personelini ayırmayan bir yaklaşım gerekiyor
Bir mühendis SSR web görünümü için gereken tam sütunları getirecek SQL’i yazabiliyor ve o web görünümünden de sorumlu olabiliyorsa, API ya da ORM gibi şeyleri bir saniye bile düşünmeye gerek kalmaz. SQL ve modern, saf HTML/CSS/JS bilmek yeterli. Yapılan işin çoğu, iş alanına ait view’ları (SQL) DOM’a (HTML) dönüştürmek haline gelirken sunucu tarafı programlama ekosistemi geri plana çekilir
Nihai biçimin, web içeriğini RDBMS içinde SSR etmek olduğunu düşünüyorum. Oracle APEX gibi bir yaklaşım. Ama çoğu mühendis henüz bu konuşmaya hazır değil. Ben de gerçek sahada ilk gördüğümde öyleydim. Acı çekme biçimlerimize fazla bağlanmışız
Frontend’in aşırı karmaşıklaşması sorununu daha da kötüleştirdi. Frontend ekibinde insanlar olunca sürekli kendilerine iş yaratıyor ve karmaşıklık ekliyorlar. Sadece web geliştirme bilen, başka bir şey bilmeyen çok fazla insanın ortaya çıkması da sorun
Yan projemde başlangıç kısıtlarından birini, JavaScript kapatılsa bile tüm sitenin zarif biçimde işlev kaybederek çalışması olarak belirledim. Böyle olunca normalde JavaScript ile yapılacak bir özellik eklemek istediğim her seferinde “bunu JavaScript olmadan yapabilir miyim?” diye sormaya başladım; şimdiye kadar şaşırtıcı şekilde cevap hep evet oldu
Temel HTML kontrollerine yönelik CSS seçicileri ile bile bugün gerçekten çok şey yapılabiliyor. O codebase’de hâlâ tek satır JS yok
Ürün/tasarım ekipleri kullanılabilirlik, performans, erişilebilirlik ve iyi mühendisliği hiç dikkate almadan mümkün olduğunca çok JavaScript süsü eklenmesi için baskı yapabilir
Ben frontend’de iyi değilim, tasarımcım da yok. Backend’de çok daha iyiyim ama ekipteki diğer insanlar frontend tasarımı konusunda benden daha yetenekli
İlk web sitemi yaparken “Svelte, React’ten daha iyi”, “solid-js bir sonraki büyük dalga olacak” gibi yazılar okuyup bunun web geliştirmenin önemli bir parçası olduğunu düşünmüştüm.
Yeni başlayanlar için MDN okumak ve geri kalanını görmezden gelmek daha iyi.
İnsanların öğreticilere ve adım adım walkthrough’lara ihtiyacı var; tüm bunların nasıl çalıştığına dair içsel bir anlayış geliştirmeleri gerekiyor.
Framework’ler bu kısımları soyutlamaya yardımcı olur.
Ama son dönemdeki Next.js ve SSR takıntısı için aynı şey geçerli olmayabilir. Şahsen bunun React tarafının çöküş nedenlerinden biri olabileceğini düşünüyorum.
Son birkaç yılda saf JS ve CSS’in nasıl geliştiğini, ayrıca
display: noneanimasyonu gibi ilginç özelliklerin neredeyse benimsenme aşamasına geldiğini düşününce, sunucuda şablon HTML üretip JS’i yalnızca gerektiği yerlerde kullanmak her zamankinden daha makul görünüyor.Bunu geçimini büyük ölçüde React’ten sağlayan biri olarak söylüyorum.
Yazı sahibi gibi ben de şu ya da bu şekilde 20 yıldır frontend yapıyorum. Ekosistem, churn ve frontend ile backend arasında state’i senkronize etme cambazlığı gerçekten akıl almaz seviyede.
Yakın zamanda Go templates ve HTMX ile bir kavram kanıtı projesine başladım; React’teki gibi UI’ı “bileşenler” ile oluşturma hissini yaklaştırmaya çalışıyorum. Hâlâ çok pürüzlü yanları var ama potansiyel mevcut. Dürüst olmak gerekirse HTMX’e gerçekten ihtiyaç olup olmadığından da henüz emin değilim. Event listener’ları doğrudan yönetmeye başladım ve sanırım bu taraf daha çok hoşuma gidiyor.
İlginç şekilde, kullanıcı rolleri ve yetkilerine dayalı karmaşık UI state yönetimi sunucuda çok daha kolay. Kullanıcının görebileceği HTML’i göndermek yeterli.
Ancak React, Vue vb. için muazzam bir ivme var. Düşünme biçiminde kolektif bir dönüşümün nasıl başlayabileceğini bilmiyorum. Özellikle de UI oluşturma yolu olarak frontend framework’lerinden başka bir şey bilmeyen çok sayıda geliştirici olduğu düşünülünce.
“Hangi framework’ü seçerseniz seçin 5 yıl sonra obsolete olur” sözüne pek emin değilim.
10 yılı aşkın süredir profesyonel olarak React kullanıyorum.
package.jsoniçinde kaç bağımlılık tanımlı? Ekip hangi node/npm sürümünü kullanıyor?Yeterince güncel sürümler kullanıyor ve popüler kütüphanelerden yararlanıyorsanız,
npm installsırasında alt bağımlılıklar için deprecated uyarılarının biriktiğini görmüşsünüzdür.Adil olmak gerekirse React kodunun kendisinin geriye dönük uyumluluğu oldukça iyi koruduğunu düşünüyorum. Bu React’in suçu değil. Ama 5 yıl önce kullanılan build sistemlerinin hepsi değişti ve geriye dönük uyumluluğu bozdu. Bileşen lifecycle metotlarını da unutmuştum.
React kadar iyi yönetilen bir proje bile ekosisteminin dağınıklığından kaçamıyor.
Her zaman seçme şansı olmuyor ama bugünlerde genelde saf JS’i build sistemi olmadan import etmeyi, mümkün olduğunca Python/Django backend’de halletmeyi ve JavaScript ekosisteminden tamamen çıkmayı tercih ediyorum. Hiç pişman olmadım.
Uygulamanızı hâlâ React 15’te mi tutuyorsunuz?
React 16’da çalışan tüm WYSIWYG editörleri artık desteklenmiyor. Bir güvenlik sorunu bulunursa durum “şansa kalmış” oluyor. Ya da hiç kullanmamak gerekiyor.
React 16 hâlâ destekleniyor ama kesinlikle obsolete.
Karşı argüman şu: Bir framework benimsemezseniz, sonunda ekip dışındaki insanların anlayamadığı, dokümantasyonu da genelde zayıf olan ve mevcut framework’lerde zaten bulunan özellikleri eklemek için sürekli uğraşmanız gereken kendi framework’ünüzü yaratmış olursunuz.
Frontend’de ortak ihtiyaç duyulan özellikler ve çözülmesi gereken ortak problemler var. Hiçbir şey olmadan başlamak yerine en azından bir şeyin üzerine kurarak başlamak daha iyi değil mi?
İç framework’ü hiç görmemiş birinin hemen üretken olmasını beklemek imkânsız. Dokümantasyon çok iyi olsa bile öğrenmek ve içselleştirmek zaman alıyor. Uzun vadeli işe alımlarda en kötüsü olmayabilir ama geçici olarak daha fazla geliştiriciye ihtiyaç duyulursa cevap yok.
Başka yerlerde de yazdığım gibi, neredeyse herkes web uygulaması istiyor ya da bir web uygulamasına sahip olduğunu düşünüyor; ama gerçekte çoğu zaman bu sadece dinamik bir web sitesi. Dinamik bir web sitesi yapmak için framework’leri üst üste yığmaya gerek yok.
Bu bir frontend sorunu değil, JS ekosistemi sorunu. Backend’de de oluyor.
JS ortamı, onlarca hatta yüzlerce başka bağımlılığa sahip bağımlılıklardan oluşan tam bir karmaşa. Örneğin Fastify tabanlı Node framework’ü Platformatic’in bağımlılık grafiği şöyle:
https://npmgraph.js.org/?q=platformatic#zoom=h
Bu bağımlılıklar herhangi bir anda terk edilebilir. Axios veya Express gibi dev bağımlılıklar bile bir dönem terk edilmiş gibi görünmüştü.
Ayrıca her bağımlılık, bakımcısının doğru olduğunu düşündüğü yaklaşıma tabidir. Birkaç gün önce prodüksiyonda kullandığımız bir bağımlılık; haftada yaklaşık 25 milyon indirme almasına, React’in yaklaşık 26 milyon seviyesinde olmasına ve 10 milyon GitHub deposunda kullanılmasına rağmen, yaklaşık 3 yıl önceki Safari sürümlerini desteklemeyi bırakabileceğine karar verdi. Safari’nin ABD mobil pazar payının %50’den fazla olduğu düşünülürse bu gerçekten çılgınca.