ওয়েব ডেভেলপমেন্ট জগত প্রায় এক দশক ধরে নিজেকে এটা বোঝাতে ব্যস্ত ছিল যে ব্রাউজারকেই সব ভারী কাজ করতে হবে। আমরা ডকুমেন্ট এবং ফর্ম দিয়ে শুরু করেছিলাম, তারপর ধাপে ধাপে প্রতিটি সম্ভাব্য অপারেশন ক্লায়েন্টের কাছে স্থানান্তরিত করেছি। রাউটিং, স্টেট ম্যানেজমেন্ট, ডেটা ফেচিং, রেন্ডারিং লজিক, এমনকি GraphQL-এর মাধ্যমে ডেটাবেস কুয়েরি অর্কেস্ট্রেশন — সবকিছুই জাভাস্ক্রিপ্ট বান্ডেলের মধ্যে চলে এসেছে, যা প্রতিটি রিলিজের সাথে আরও ভারী হয়ে উঠছে। ফ্রেমওয়ার্কের সংখ্যা বাড়তে থাকল, বিল্ড পাইপলাইন আরও জটিল হলো, এবং যা অ্যাপগুলোকে দ্রুত করার উপায় হিসেবে শুরু হয়েছিল, তা এমন একটি আর্কিটেকচারে পরিণত হলো যেখানে মেগাবাইট পরিমাণ কোড ডাউনলোড, পার্স এবং এক্সিকিউট না হওয়া পর্যন্ত একটি পেজ একটি অর্থপূর্ণ পিক্সেলও রেন্ডার করতে পারে না।
এই পরিবর্তনটি বাস্তব সমস্যাগুলোর সমাধান করেছিল। jQuery-এর সামান্য ব্যবহারসহ সার্ভার-রেন্ডার করা পেজগুলো ব্যবহারকারীরা যে মসৃণ, অ্যাপ-এর মতো ট্রানজিশন আশা করেন তা দিতে হিমশিম খাচ্ছিল। Single Page Application আমাদের তাৎক্ষণিক নেভিগেশন, পারসিস্টেন্ট স্টেট এবং সমৃদ্ধ ইন্টারঅ্যাকশন দিয়েছে। কিন্তু এর একটি মূল্য দিতে হয়েছে। টিমগুলোকে এখন জটিল ক্লায়েন্ট-সাইড স্টেট স্টোর পরিচালনা করতে হয়, বিশাল জাভাস্ক্রিপ্ট বান্ডেল সামলাতে হয়, জটিল ডেটা সিনক্রোনাইজেশন লেয়ার বজায় রাখতে হয় এবং বিল্ড পাইপলাইন ডিবাগ করতে হয় যা মাঝে মাঝে তাদের জন্য একটি পূর্ণকালীন কাজের মতো মনে হয়। আমরা এক সেট সমস্যার বদলে অন্য সেট সমস্যা গ্রহণ করেছি, এবং অনেক ডেভেলপার এখন প্রশ্ন করছেন যে প্রতিটি অ্যাপ্লিকেশনের কি সত্যিই এই মূল্য দিতে হবে।
দুটি নতুন উন্নয়ন এই প্রশ্নের উত্তর দেওয়া সহজ করে তুলছে।
HTMX এবং হাইপারমিডিয়া-র প্রত্যাবর্তন
প্রথমটি হলো HTMX। ওপর থেকে দেখলে এটি একটি ছোট লাইব্রেরি মনে হতে পারে, কিন্তু এর আর্কিটেকচারাল প্রভাব অনেক বিশাল। HTMX HTML-কে একটি স্ট্যাটিক শেল হিসেবে না দেখে অ্যাপ্লিকেশন লজিকের জন্য নেটিভ ফরম্যাট হিসেবে বিবেচনা করে, যা জাভাস্ক্রিপ্ট দ্বারা পূর্ণ করতে হয়।
বাস্তবে যা পরিবর্তন হয় তা হলো: প্রথাগতভাবে, যখন একজন ব্যবহারকারী আরও কমেন্ট লোড করার জন্য একটি বাটনে ক্লিক করেন, তখন ফ্রন্টএন্ড একটি fetch রিকোয়েস্ট পাঠায়, একটি JSON পেলোড গ্রহণ করে, সেটিকে ক্লায়েন্ট-সাইড স্টোরে নরমালাইজ করে, একটি কম্পোনেন্ট টেমপ্লেটের মাধ্যমে চালনা করে, ভার্চুয়াল DOM ডিফ (diff) করে এবং অবশেষে পেজটি প্যাচ করে। HTMX এই চেইনটিকে সংক্ষিপ্ত করে দেয়। বাটনের মধ্যেই এমন কিছু অ্যাট্রিবিউট থাকে যা ব্রাউজারকে বলে দেয় রিকোয়েস্ট কোথায় পাঠাতে হবে এবং কোন পেজ এলিমেন্টটি প্রতিস্থাপন করতে হবে। সার্ভার একটি HTML ফ্র্যাগমেন্ট রিটার্ন করে — শুধুমাত্র নতুন কমেন্টগুলো, যা একটি div-এর মধ্যে মোড়ানো থাকে। ব্রাউজার সেটি পরিবর্তন করে বসিয়ে দেয়। এখানে কোনো JSON নেই, কোনো ফ্রন্টএন্ড স্টেট ট্রি নেই, কোনো রিকনসিলিয়েশন অ্যালগরিদম নেই এবং UI-কে সার্ভারের সাথে সিঙ্ক রাখার জন্য কোনো ইম্পারেটিভ জাভাস্ক্রিপ্ট নেই।
এটি আধুনিক ডেভেলপমেন্টের প্রত্যাখ্যান নয়। এটি অপ্রয়োজনীয় অ্যাবস্ট্রাকশনের প্রত্যাখ্যান। HTMX প্রমাণ করে যে হাইপারমিডিয়া, সেই আর্কিটেকচারাল স্টাইল যা শুরুর দিকের ওয়েবকে চালিত করেছিল, আধুনিক এরগনোমিক্সের সাথে যুক্ত হলে এখনও উন্নত ইন্টারফেস সমর্থন করতে পারে। শুধুমাত্র ফর্ম এবং লিঙ্ক নয়, যেকোনো এলিমেন্ট রিকোয়েস্ট পাঠাতে পারে। যেকোনো ইভেন্ট আপডেট ট্রিগার করতে পারে। ডেটা এবং প্রেজেন্টেশন উভয় ক্ষেত্রেই সার্ভারই সত্যের উৎস (source of truth) হিসেবে থাকে।
Chrome-এর Declarative Partial Updates
দ্বিতীয় পরিবর্তনটি আরও নতুন এবং এটি ব্রাউজারের ভেতরেই বিদ্যমান। Chrome প্রবর্তন করছে Declarative Partial Updates, বা DPU। এই ফিচারটি ব্রাউজারকে HTML স্ট্রিম করতে এবং বাইটগুলো আসার সাথে সাথে পেজের নির্দিষ্ট অংশে সরাসরি ইনসার্ট করতে দেয়।
DPU-এর আগে, আপনি যদি একটি ওয়েব পেজে লাইভ ডেটা স্ট্রিম করতে চাইতেন, তবে সাধারণত আপনাকে WebSockets, Server-Sent Events, অথবা ম্যানুয়াল DOM ম্যানিপুলেশনের সাথে long-polling ব্যবহার করতে হতো। ফ্রন্টএন্ডকে কানেকশন পরিচালনা করতে হতো, পেলোড পার্স করতে হতো এবং ঠিক কীভাবে এবং কোথায় মার্কআপ ইনজেক্ট করতে হবে তা সিদ্ধান্ত নিতে হতো। DPU এই প্রক্রিয়াটিকে ডিক্লেয়ারেটিভ (declarative) করে দিয়ে সমীকরণটি বদলে দেয়। ডেভেলপার একটি টার্গেট কন্টেইনার নির্দিষ্ট করেন এবং ব্রাউজার বাকি কাজগুলো সামলায়: স্ট্রিম গ্রহণ করা, ফ্র্যাগমেন্ট পার্স করা এবং সম্পূর্ণ রেসপন্স শেষ হওয়ার আগেই ঠিক যেখানে প্রয়োজন সেখানে এটি বসানো।
একটি মনিটরিং ড্যাশবোর্ডের কথা ভাবুন যা সার্ভার লগ দেখায় বা একটি সাপোর্ট কিউ (queue) যা রিয়েল টাইমে আপডেট হয়। DPU-এর মাধ্যমে, ব্যাকএন্ড যখনই HTML চাঙ্ক তৈরি করে তখনই তা পাঠায়। ক্লায়েন্ট-সাইড স্ট্রিমিং লজিকের একটি লাইনও না লিখে ব্রাউজার সেগুলোকে একটি টেবিল বডি বা ফিড কন্টেইনারে স্ট্রিম করে। অ্যাসেম্বলি বা সংযোজনটি নেটিভলি ঘটে।
সার্ভার-ফার্স্ট মডেল (The Server-First Model)
HTMX এবং DPU-কে একত্রে দেখলে আপনি একটি সুসংগত আর্কিটেকচার পাবেন যেখানে সার্ভার স্টেট নিয়ন্ত্রণ করে এবং UI তৈরি করে, আর ব্রাউজার ডিসপ্লে এবং ইউজার ইনপুট সামলায়। Rails, Laravel, Django, Go templates, বা ASP.NET-এর মতো ব্যাকএন্ড ফ্রেমওয়ার্কগুলো আবারও প্রাথমিক ইন্টারফেস লেয়ার হয়ে ওঠে। ফ্রন্টএন্ড কোনো আলাদা অ্যাপ্লিকেশন নয় যা একটি API ব্যবহার করে। এটি হলো সেই হাইপারমিডিয়া ইন্টারফেস যা সার্ভার তৈরি করে।
এই মডেলটি আশ্চর্যজনকভাবে বিস্তৃত পরিসরের সফটওয়্যারের ক্ষেত্রে প্রযোজ্য। একটি সাধারণ SaaS অ্যাপ্লিকেশনের কথা ভাবুন। এটি হলো সর্টেবল টেবিলসহ ড্যাশবোর্ড। এটি ফর্ম এবং ফিল্টারসহ অ্যাডমিন প্যানেল। এটি এমন ইন্টারনাল টুল যা রেকর্ডগুলোকে এক অবস্থা থেকে অন্য অবস্থায় নিয়ে যায়। এটি CRUD ওয়ার্কফ্লো যা একটি তালিকা দেখায়, ডিটেইল ভিউ প্রদান করে এবং ব্যবহারকারীকে ফিল্ড এডিট করার সুযোগ দেয়। এমনকি এটি AI ইন্টারফেসের ক্ষেত্রেও প্রযোজ্য যেখানে একটি ল্যাঙ্গুয়েজ মডেল ব্যবহারকারীর কাছে টোকেন স্ট্রিম করে, এবং প্রতিটি টোকেন বা অনুচ্ছেদ HTML-এ মুড়িয়ে কথোপকথনের থ্রেডের সাথে যুক্ত করা যেতে পারে। এই সবকিছুর জন্য একটি ভারী (thick) JavaScript ক্লায়েন্ট প্রায়শই অতিরিক্ত বা অপ্রয়োজনীয় (overkill)।
এর সুবিধাগুলো তাৎক্ষণিক এবং ব্যবহারিক। প্রাথমিক পেজ লোড দ্রুততর হয় কারণ প্রথম meaningful paint HTML হিসেবে আসে, কোনো hydration cycle সম্পন্ন হওয়ার পর নয়। JavaScript পেলোড কমে যায় কারণ এখানে কোনো virtual DOM, ক্লায়েন্ট-সাইড রাউটার বা শিপ করার জন্য কোনো স্টেট ম্যানেজমেন্ট লাইব্রেরি নেই। সার্চ ইঞ্জিনগুলো বান্ডেল এক্সিকিউট না করেই সম্পূর্ণ কন্টেন্ট দেখতে পায়, তাই ডিফল্টভাবেই SEO কাজ করে। জটিলতা কমে যায় কারণ একটি মাত্র কোডবেস রাউটিং, বিজনেস লজিক এবং রেন্ডারিং পরিচালনা করে। ডিবাগিং সহজ হয়ে যায়। যখন কিছু ভুল মনে হয়, আপনি Network ট্যাবটি ইন্সপেক্ট করে দেখতে পারেন সার্ভার ঠিক কী HTML পাঠিয়েছে। এখানে রিভার্স-ইঞ্জিনিয়ারিং করার জন্য কোনো অস্পষ্ট (opaque) ক্লায়েন্ট-সাইড স্টেট অবজেক্ট নেই।
React এবং ভারী ক্লায়েন্টের ক্ষেত্রে কী হবে?
এর মানে এই নয় যে React মৃত বা SPA একটি ভুল সিদ্ধান্ত। জটিল, এডিটর-গ্রেড অ্যাপ্লিকেশনগুলোর এখনও একটি ভারী ক্লায়েন্ট প্রয়োজন। Figma ব্রাউজারের ভেতরে WebAssembly-তে কম্পাইল করা একটি C++ ইঞ্জিন চালায়, কারণ সার্ভার রাউন্ড-ট্রিপ ড্রয়িং করা অসম্ভব করে তুলত। Canva ক্লায়েন্ট-সাইড জিওমেট্রির মাধ্যমে প্রতি সেকেন্ডে ষাট ফ্রেমের গতিতে ক্যানভাস ম্যানিপুলেট করে। Google Docs মিলিসেকেন্ডের মধ্যে এডিটিং কনফ্লিক্ট সমাধান করতে operational transforms ব্যবহার করে। এই টুলগুলো মূলত ব্রাউজার ট্যাবের মাধ্যমে সরবরাহ করা ডেস্কটপ অ্যাপ্লিকেশন। এগুলো আবার সার্ভার-রেন্ডারড ফর্মে ফিরে যাবে না।
কিন্তু বেশিরভাগ সফটওয়্যার Figma নয়। বেশিরভাগ সফটওয়্যার রিয়েল-টাইম গ্রাফিক্স এডিটর নয়। বেশিরভাগ সফটওয়্যার হলো একটি রিপোর্টিং স্ক্রিন, কনফিগারেশন প্যানেল, বুকিং ফ্লো বা কন্টেন্ট ম্যানেজমেন্ট ফর্ম। সেই বিশাল সংখ্যক অ্যাপ্লিকেশনের ক্ষেত্রে, শুধুমাত্র একটি মোডাল টগল করতে বা রেকর্ডের তালিকা আনতে শত শত কিলোবাইট JavaScript ফ্রেমওয়ার্ক পাঠানো কখনোই খুব একটা যুক্তিসঙ্গত ছিল না। স্ট্যাকের অর্থনীতি পরিবর্তিত হচ্ছে। আমরা নতুন করে আবিষ্কার করছি যে edge-এর কল্যাণে সার্ভার ব্যবহারকারীর খুব কাছে থাকতে পারে, এবং ব্রাউজার নিজেই প্রতিটি বাইটের জন্য কোনো ফ্রেমওয়ার্কের মধ্যস্থতা ছাড়াই ফ্র্যাগমেন্ট আপডেট করার মতো যথেষ্ট সক্ষম হয়ে উঠেছে।
পেন্ডুলাম ভারসাম্য খুঁজে পাচ্ছে
ওয়েব আর্কিটেকচারের গতিপথ সরলতার দিকে ফিরে যাচ্ছে, তবে এটি নব্বইয়ের দশকে ফিরে যাওয়ার কোনো আনাড়ি পদক্ষেপ নয়। ব্রাউজার আরও বুদ্ধিমান হয়ে উঠছে। DPU-এর মতো ফিচারগুলো ডেভেলপারের উদ্ভাবনী ক্ষমতাকে প্রতিস্থাপন করে না; বরং এগুলো আমাদের হাতে করা প্যাটার্নগুলোকে — যেমন streaming, partial updates, targeted DOM insertion — সরাসরি প্ল্যাটফর্মের অন্তর্ভুক্ত করে ফেলে। HTMX আমাদের ফ্রন্টএন্ডে একটি ক্ষুদ্র অপারেটিং সিস্টেম পুনর্গঠন না করেই সেই আচরণগুলো প্রকাশ করার ভাষা প্রদান করে।
আপনাকে আর একটি সাধারণ আর্কিটেকচার এবং একটি রেসপন্সিভ ইউজার এক্সপেরিয়েন্সের মধ্যে যেকোনো একটি বেছে নিতে হবে না। আপনি উভয়ই পেতে পারেন। সার্ভার ইন্টারফেস পরিচালনা করতে পারে, ব্রাউজার এটি অ্যাসেম্বল করতে পারে, এবং আপনার লেখা JavaScript কেবল পাইপলাইনিং বা অবকাঠামো তৈরির পরিবর্তে প্রকৃত ইন্টারঅ্যাক্টিভিটির ওপর মনোনিবেশ করতে পারে।
পরবর্তী প্রজন্মের ড্যাশবোর্ড, অ্যাডমিন টুল এবং AI-চালিত ইন্টারফেসের জন্য, সবচেয়ে বুদ্ধিমান ক্লায়েন্ট হতে পারে সেটি যা কম কাজ করে।