Другата страна на интеграцията: защо "сглобяването" на технологиите е по-трудно от избора им

Всеки разработчик, който е опитвал да пусне сериозно уеб приложение, познава това усещане.

Избрал си си сървърния фреймуърк, ORM-а, библиотеката за валидация, фронтенда, билд инструмента. Всичко изглежда перфектно на хартия. После започваш да строиш реални функции и разбираш, че твоята валидационна библиотека не разбира формата, която ORM-а ти връща. Фронтенд фреймуъркът ти не се разбира добре с мидълуера на сървъра. Управлението на сесиите прави предположения, които се чупят когато пуснеш нещата на edge.

Всяко едно парче е страхотно. Съединенията между тях са кошмар.

Как стигнахме дотук

JavaScript общността винаги е ценяла гъвкавостта повече от цялостността. Това не е непременно грешно — UNIX философията ни служи десетилетия. Проблемът е, че уеб приложенията не са тръбопроводи за изолирани трансформации. Те са заплетени мрежи от споделени предположения: форми на заявки, граници на валидация, потоци на автентикация, контексти за рендиране, деплоймент цели.

Когато Django се появи през 2005, направи залог: разработчиците ще търгуват част от гъвкавостта си за една смислена система. Все още можеше да излезеш извън стека когато ти трябваше, но вътре всичко беше проектирано да работи заедно. Тази собственост означаваше по-малко изненади.

PHP фреймуърците също разбраха това. Laravel, Symfony, Yii — всички даваха това усещане за "една смислена система". Знаеше кое е официална територия и кое изисква да се впуснеш в дивата природа.

После JavaScript погълна сървъра и загубихме това.

Капанът на мета-фреймуърците

Съвременните мета-фреймуърци подобриха нещата в някои отношения. Next.js, Nuxt, SvelteKit — те ти дадоха смислен стек отново. Но го направиха като стесниха изборите ти, вместо да ги разширят.

Ето какво имам предвид: Next.js е страхотен React стек. Но ако се влюбиш в перформанса на Solid или простотата на Svelte, не можеш просто да подмениш view слоя. Приемаш различен мета-фреймуърк с различни конвенции, различни модели за рутиране, различни предположения за бекенда. Преоткриваш същите проблеми, които вече си решил, само с различен синтаксис.

Това създава абсурдна ситуация. Фронтенд общността продължава да иновира, но преминаването между подходи изисква почти да започнеш отначало. React разработчици и Svelte разработчици решават едни и същи бекенд проблеми независимо, по малко различни начини, завинаги.

Лотарията на runtime-овете

И после идва фрагментацията на runtime-овете. Node.js, Deno, Bun — всички са способни платформи, но повечето фреймуърци са ефективно специфични за един runtime. Когато даден фреймуърк твърди, че поддържа Deno, често това само означава "Deno може да пусне нашия Node код." Това не е същото като фреймуъркът да е проектиран около нативните API-та и моделът за изпълнение на Deno.

Това има значение повече, отколкото изглежда. Runtime-ът, който избереш, влияе на перформанса, деплоймент целите и моделите за сигурност. Да се заключиш във фреймуърк, който наистина работи само на един runtime, ограничава опциите ти докато екосистемата се развива.

Какво всъщност ни трябва

Ето нещото: уеб приложенията имат естествени слоеве, които не трябва да са свързани.

Фронтендът описва браузър UI. Бекендът обработва заявки, данни и логика на приложението. Runtimes са цели за изпълнение. Тези неща трябва да могат да варират независимо.

Представи си, че строиш един route с React, защото ти трябва неговата екосистема от компоненти. Друг route със Svelte, защото там перформансът е по-важен. Пускаш си Node.js routes-ите днес, но деплойваш TypeScript routes-ите си на Bun когато ти трябва скоростта. Всичко в едно приложение, с един и същ бекенд модел, една и съща валидация, едни и същи сесии.

Това не е магическо мислене. Това е третиране на нещата като отделни неща — а така винаги са се строили добрите софтуерни системи.

Фреймуъркът трябва да поеме шевовете

Не настоявам един фреймуърк да властва над всички. Настоявам фреймуъркът да поеме отговорността неговите парчета да работят заедно. Все още трябва да можеш да излезеш извън официалния стек когато ти трябва — никой не доставя перфектни настройки по подразбиране за всеки случай. Но когато оставаш вътре във фреймуърка, шевовете трябва да са негов проблем за решаване, не твой.

Фреймуърк, който те кара да мислиш за рутиране, валидация, достъп до данни и рендиране като за отделни проблеми, които трябва да залепиш заедно — не е фреймуърк. Това е предложение.

Най-добрите фреймуърци ти дават собственост върху бизнес логиката, докато поемат собствеността върху всичко останало.

В NameOcean сме виждали как хостинг сложността се умножава когато стекът ти е фрагментиран. Избирането на фреймуърк, който уважава разделянето на отговорностите — който ти позволява да сменяш парчета без да пренаписваш всичко — прави деплоймента, скалирането и поддръжката драматично по-прости.

Въпросът не е дали да използваш фреймуърк. Въпросът е дали твоят фреймуърк работи за теб или просто добавя още един слой от решения, които не ти трябваше да вземаш.

Какво би означавало да строиш следващото си приложение с инструмент, който поема шевовете? Струва си да помислиш, преди да си сглобил следващия проект.