موشن، اسکرول، سه‌بعدی و PWA در کدام لایه‌ی وب ساخته می‌شوند؟

قابلیت را به اسم framework نسبت ندهید

یک product brief می‌گوید: «motion روان، scroll effect، 3D viewer و PWA می‌خواهیم؛ کدام framework همه را می‌دهد؟» این سؤال boundaryهای واقعی را مخفی می‌کند. motion می‌تواند با CSS یا JavaScript ساخته شود. scroll behavior می‌تواند به CSS feature، Browser API یا application logic متکی باشد. 3D می‌تواند از WebGL یا WebGPU استفاده کند. installability یک web-app capability با manifest و browser requirementهای خودش است؛ service worker برای offline رایج است اما طبق guidance فعلی MDN شرط مطلق installability نیست.

در این درس Experience Capability Placement Record v1 را می‌سازید تا قبل از انتخاب framework/library، هر capability را در boundary درست web platform یا application قرار دهید.

ابتدا Browser responsibility را پیدا کنید، بعد ابزار را اضافه کنید

WEBF-001 مدل Browser/resource را می‌دهد و WEBF-007 کمک می‌کند framework را با platform capability یکی نگیرید. برای هر feature بپرسید: primitive اصلی چیست؟ application code چه چیزی را coordinate می‌کند؟ compatibility constraint کجاست؟ fallback چگونه user outcome را حفظ می‌کند؟

این درس animation choreography، GPU programming، service-worker caching strategy یا pluginهای framework-specific PWA را آموزش نمی‌دهد. مالکیت آن capability placement و reasoning درباره compatibility/fallback است.

چهار لایه capability را جدا کنید

Presentation — CSS. CSS presentation document را تعریف می‌کند و moduleهایی برای transition، animation، transform، scroll snap، scroll-driven animation، overflow و رفتارهای rendering دارد. [S-MDN-CSS]

Browser behavior — JavaScript + Web APIs. application code می‌تواند به input، scroll state، DOM، timer، media و capabilityهای expose‌شده توسط Browser واکنش نشان دهد. framework ممکن است این code را سازمان دهد، اما platform boundary همان Browser API باقی می‌ماند.

Graphics — WebGL / WebGPU. WebGL یک JavaScript API برای 2D/3D accelerated در browser سازگار است. WebGPU architecture جدیدتری برای graphics/compute دارد اما MDN فعلاً آن را Limited availability نشان می‌دهد؛ پس universal availability ادعای مجازی نیست. [S-MDN-WEBGL] [S-MDN-WEBGPU]

Installable web app — manifest + browser criteria. guidance فعلی MDN برای installability روی web app manifest و requirementهای browser تأکید می‌کند و صریحاً می‌گوید service worker شرط installable بودن PWA نیست، هرچند بسیاری از PWAها برای offline از آن استفاده می‌کنند. [S-MDN-PWA]

Record را بر اساس user outcome بسازید

برای هر capability این fieldها را جدا ثبت کنید:

• user_outcome
• platform_boundary
• implementation_mechanism
• application_or_framework_role
• browser_requirement
• compatibility_evidence
• fallback
• uncertainty
• next_evidence
• bounded_decision

این fieldها Experience Capability Placement Record v1 را می‌سازند. اگر 3D با WebGL/WebGPU پیاده می‌شود و framework فقط component/canvas lifecycle را coordinate می‌کند، ننویسید «framework 3D را می‌سازد».

User outcome را از mechanism جدا نگه دارید

outcome «کاربر مدل محصول را از چند زاویه ببیند» می‌تواند چند mechanism داشته باشد: WebGPU برای مسیر enhanced، WebGL برای compatibility، و static image gallery برای deviceای که 3D قابل‌استفاده ندارد. outcome ثابت می‌ماند حتی اگر mechanism تغییر کند.

برای motion هم همین است. transition ساده ممکن است کاملاً CSS باشد. sequence وابسته به application state می‌تواند JavaScript coordination بخواهد. framework lifecycle یا state abstraction می‌دهد، اما CSS animation یا WebGL را به لایه‌ای جدید منتقل نمی‌کند.

در PWA نیز installable، offline-capable، background behavior و cached یک claim نیستند. service worker می‌تواند offline/request interception را پشتیبانی کند، اما نباید تعریف یگانه PWA یا installability شود. هر capability یک row مستقل می‌خواهد.

مثال حل‌شده: مقاله تعاملی بدون فرض framework

article page نیاز به reveal ملایم figureها و یک molecular diagram سه‌بعدی ساده دارد.

placement محدود:

• reveal motion: اگر state declarative است از CSS transition/animation شروع کنید؛ JavaScript فقط state class را تغییر دهد؛
• 3D diagram: WebGL به‌عنوان graphics primitive در canvas؛ application code data و control را مدیریت کند؛
• fallback: اگر graphics initialization شکست خورد یا device مناسب نبود، annotated static image نمایش داده شود.

این record بدون نام framework کامل است. اگر بعداً framework اضافه شد، فقط coordination role آن را ثبت کنید و platform boundary را تغییر ندهید.

خطاهای رایج boundary

«framework ما animation دارد، پس animation متعلق به framework است.» helper framework ممکن است وجود داشته باشد، اما CSS و Browser API همچنان platform capability مستقل‌اند.

«WebGPU جدیدتر است، پس همه جا استفاده می‌کنیم.» compatibility فعلی چنین universal claimی را پشتیبانی نمی‌کند. fallback یا capability check بخشی از design است. [S-MDN-WEBGPU]

«PWA یعنی service worker + offline cache.» چند capability متفاوت را collapse می‌کند و با guidance فعلی installability بیش‌ازحد قوی است. [S-MDN-PWA]

«اگر 3D اجرا نشد کل product page بی‌فایده است.» enhancement نباید single point of failure باشد؛ fallback باید core outcome را حفظ کند.

برای برنامه‌نویس باتجربه: enhancement را contract ببینید

featureهای advanced را progressive capability contract ببینید. baseline بدون enhancement هم باید مفید باشد. enhanced path فقط تحت conditionهای مشخص فعال شود. browser feature detection، secure context، device capability، input mode، reduced-motion preference و asset availability می‌توانند مسیر را عوض کنند بدون اینکه کل architecture عوض شود.

همچنین بدون evidence درباره portability framework ادعای کلی نکنید. WebGL renderer می‌تواند داخل component systemهای مختلف قرار بگیرد، ولی lifecycle، cleanup، event handling و SSR integration هنوز framework-specific work می‌خواهند.

Mechanism را با constraint انتخاب کنید، نه با جدید بودن

CSS motion معمولاً برای state declarative ساده‌تر است. JavaScript coordination وقتی مفید است که motion به application state یا measurement پیچیده وابسته باشد. WebGL پشتیبانی گسترده‌تری در browserهای مدرن دارد، درحالی‌که WebGPU capabilityهای جدیدتری دارد اما نیازمند compatibility planning است. static/video representation هم اگر 3D essential نیست fallback مشروعی است.

در PWA installability، offline strategy، update strategy، notification و background behavior را جدا کنید. اضافه کردن همه capabilityها complexity و permission surface را بالا می‌برد. فقط feature مرتبط با user requirement را انتخاب کنید.

قبل از library، capability را place کنید

Guided: dashboard دارای CSS hover transition، scroll position indicator با JavaScript و canvas chart است. سه row بسازید و platform boundary، application role، compatibility evidence و fallback را ثبت کنید.

Independent: marketing site می‌گوید «cinematic scroll، immersive 3D و app-like behavior». هر phrase را به user outcome قابل‌بررسی تبدیل کنید و بدون انتخاب framework rowها را کامل کنید. هرجا compatibility/device evidence ندارید UNKNOWN ثبت کنید.

Evidence bar

reviewer باید ببیند که:

• user outcome از implementation mechanism جداست؛
• CSS، Browser API، graphics API، framework/application code و installability collapse نشده‌اند؛
• WebGPU universal availability ندارد؛
• وجود service worker تعریف installability نشده است؛
• fallback core outcome را نگه می‌دارد؛
• compatibility/device uncertainty صریح است؛
• هیچ row ادعا نمی‌کند 3D به UI framework خاصی نیاز دارد.

Transfer به product page

transfer نهایی product pageای است با CSS motion، 3D viewer که مسیر enhanced آن WebGPU است و WebGL fallback دارد، و requirement مربوط به installability. record را بدون coupling به یک UI framework خاص بسازید. installability را از offline behavior جدا کنید، compatibility evidence لازم را بنویسید و non-3D fallback مفید حفظ کنید.

Source boundary و review date

claimهای CSS، WebGL، WebGPU و PWA/installability فقط به MDNهای اعلام‌شده متکی‌اند. compatibility به‌خصوص برای WebGPU و installability time-sensitive است. در review date یا تغییر محسوس browser support دوباره بررسی شود. هیچ sourceای در این درس ادعا نمی‌کند یک framework مالک motion/3D/PWA است یا برای همه پروژه‌ها بهترین stack وجود دارد.