Harika. Bu tür bir yaklaşımı gerçekten çok seviyorum.

ML tabanlı olmayan, sevindirici bir optimizasyon yaklaşımı.

Sanırım bu kişi IDE abonelik ücretinden bahsediyor. FLCC ücretsiz sürümde sunulmuyor.
Ama insanlar yalnızca bunu bekleyerek para ödemiyor zaten.

Yazının zayıf kalan noktaları

1. SPA'nin asıl amacını daraltarak yorumluyor
   View Transitions API gerçekten çok etkileyici, ancak bu tek başına SPA'ye artık ihtiyaç olmadığı anlamına gelmez.

2. Tüm web sitelerine aynı ölçütle bakıyor
   Pazarlama sitesi ≠ dashboard ≠ e-ticaret uygulaması ≠ gerçek zamanlı iş birliği aracı
   Her birinin farklı yapısal gereksinimleri vardır.

3. Pratikte SPA + SSR + MPA birlikte var olmaya devam ediyor
   Next.js gibi hibrit framework'ler bunu iyi gösteriyor.
   Statik varlıklar için SSG, giriş sonrası dashboard için CSR/SPA, arama motoru uyumluluğu için SSR gibi esnek kombinasyonlara ihtiyaç var.

Bence SPA, sadece kullanıcı deneyiminin değil, aynı zamanda yapısal iyileştirmenin de bir ürününe daha yakın.
SPA'nin gereksiz olduğu sayfalarda MPA + modern CSS iyi bir seçim olabilir, ancak SPA; yapı, durum, ölçeklenebilirlik ve bakım açısından hâlâ gereklidir. Modern CSS, SPA'yi "tamamlayabilir" ama "yerine geçemez" diye düşünüyorum.

Açıkçası, daha elini bile sürmediğin Rust ya da Haskell için “ona gerek yok, artık modern C++ ile hepsi yapılıyor” demek gibi görünüyor.

Mevcut SPA framework'lerinin ve bunlara dayalı frontend trendinin standart dışılaşmaya karşı sürekli tetikte olmayı gerektirdiği, ayrıca aşırı mühendisliğe ve gereksiz kaynak tüketimine yol açmaya elverişli olduğu doğru ama…

SPA kavramına da fazla dar bakılıyor ama bundan da öte, SPA framework'lerinin genel olarak geliştirme sürecinin tamamı üzerinde nasıl bir etki yarattığının anlaşılıp anlaşılmadığından şüphe duyuyorum.

Sadece View Transition API ile, CSS varsa her şeyin çözüldüğünü söylemek, başka bir ifadeyle bununla ilgisiz tüm işlevlerin ve bunu başarmaya yönelik tüm paradigma anlayışının bütünüyle anlamsız olduğunu söylemek demek; bu bana biraz fazla kibirli bir bakış açısı gibi geliyor.

Broşür sitesi yerine geçen düzeyde bir siteyi React ile yaptığınızda ortaya çıkan aşırı mühendislik ise bambaşka bir mesele.

Çoğu küçük ölçekli projede illa bir SPA framework'üne ihtiyaç olmadığına katılıyorum; ancak karmaşık etkileşimler, süreklilik taşıyan bir kullanıcı deneyimi ve buna bağlı bakım ile sürekli iyileştirmeyi gereksinim olarak taşıyan servislerde, CSS gelişmiş olsa da durumun böyle olmadığını düşünüyorum.

Vektör aramayı ele alırken üzerinde düşünülmüş çok sayıda nokta olması güzel.

Kotlin'de kullanmaya çalıştığınızda, primitive'lerin wrapper'larla sarılması nedeniyle stack yerine heap'te saklanmasından kaynaklanan bir performans sorunu olabileceğini biliyorum. Elbette çoğu kullanım senaryosunda bakım kolaylığı önceliklidir. Ayrıca, performans sorununu en aza indirmek için value class kullanılabilir.

Bu arada rust destek bileti: https://github.com/android/ndk/issues/1742

Keşke C++ için de böyle bir şey olsa!

Hmm, emin değilim. SPA framework'lerini kullanmanın amacı, akıcı geçişlerden ziyade kullanıcıyla karmaşık etkileşimler kurmak değil mi?

Yerelde çalıştığı için ücret gerekmeyecek gibi görünüyor

Bunu yapmak için ayda $20 ~ $200 harcamak biraz...

Bu arada Pass:

Hmm...^^;;; Hata yaptım.. Bir dahaki sefere biraz daha gözden geçirip paylaşacağım..

LLM'lerin dezavantajları olmadığı söylenemez ama tüm AI hizmetlerinin kârlı olmadığı görüşüne katılmak zor. Önümüzdeki 5 yıl içinde mevcut platform hizmetlerinin neredeyse tamamının AI ajanlarıyla değiştirileceğini düşünüyorum.

> Bu özet metnini PDF özet raporu formatında (özet taslağı-giriş-gelişme-sonuç) ayrı bir belge olarak da hazırlayayım mı?

Zaten normalde de sık sık yazı paylaşan biri olduğu için bunu bilerek eklemiş gibi görünüyor lol
Eğlenceli bir yazıydı. Sanırım önce kendi kafamızı çalıştırıp sonra llm kullanmak daha iyi olur.

Doğruluk ve sahiplenme duygusunun düşük olması gerçekten doğruymuş.

Özet bile llm..

Anladım, teşekkürler