Django в 2026 році: норм чи стрьом?
Як ви всі напевно знаєте, Django — це класика Python-розробки. На ньому досі крутиться купа серйозних проєктів.
Але перша версія фреймворку вийшла аж у 2005 році. Звісно, він постійно оновлюється, проте його монолітний підхід не завжди вписується в сучасні тренди, де всі сфокусовані мікросервісах. Та і вакансій з ним не так багато. На DOU знайшов лише 63 штуки, де він згадується.
То як думаєте, чи є сенс у 2026 році вчити Django і брати його як базу для старту нового продукту з нуля, чи краще одразу дивитися в бік чогось новішого, більш сучасного?
27 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів1. Почнемо з простого DOU та Djinni написані на Django і чудово працюють.
2. Хто сказав, що Django монолітний і на ньому не можна мікросервіси? Тут мабуть хтось плутає тепле з м’яким.
3. Якщо вам не треба керувати event-loop та використовувати asyncio — він чудово підійде для більшості задач. Якщо не одразу, то за кілька місяців проекту це окупиться. Навіть бачив проекти, де зробили його повністю асинхронним: django-ninja.dev та github.com/em1208/adrf (але не тестував)
4. У Django є купа готових ліб для більшості ваших задач та інтеграцій. REST/RPC/SOAP/WS, платежі, аналітика, логування, розсилки, воркери, адмінка, і т.д.
5. Досі велика спільнота розробників, яка працює з цим і може порадити чи розробляє якусь лібу
P.S. таке є FastAPI і купа інших, але кожен вирішує свою задачу
Джанго цвіте і пахне... Це база веб розробника на пітоні і його потрібно знати.
Я намагався відшукати якісь готові рішення по LLM на Go або щось подібне, але в цій темі Python виявився більш дорослішим. А звичайні сайти можна і на HTML клепати. Нічого не можу сказати за Django, але суто моє бачення, це Vue.js
Пригадую багато хто казав що PHP вмирає, а виявилось його довбнею не добʼєш. Такі рушії як Wordpress, OpenCart, Joomla досі актуальні, ще й підтримуються з коробки на дешевих серверах майже з праски.
Проте погоджуюсь з тим що довготривалість та зрілість подібних проектів визначається гарним багаторічним досвідом спільноти, яка робить вклад в підтримку та розвиток свого продукту. А зібрати однодумців навколо себе ще й залучити до цього спеціалістів з гарним досвідом які готові вкладати частку своєї душі ще й безоплатно, — мені здається ще той життєвий квест...
Цікаво було б дослідити питання з Django на аудиторії що пише на Python.
Погоджусь з тим, що вакансій на нього зараз менше ніж на FastAPI, але не розумію ось цього
Вам треба робити продукт чи аби було круто? Який ваш продукт, яку нагрузку ви прогнозуєте і т.д. і т.п.?
Якщо для портфоліо окей, але із 100% вакансій що я бачив, в 90% FastAPI це просто «стильно модно молодьожно», а не тому що там дійсно треба мікросервіси.
Тільки на одному проекті, на який у мене була співбесіда, у мене було питання — чому вибрали джанго, бо це дійсно був хайлоад, мікросервіси і таке інше.
На всіх інших, коли бачиш сайт на 1.5 користувача зато на мікросервісах на FastAPI, асинхроність і всі діла то це тільки дивує :)
Fast API ніби же, новий стандарт — не ? Django не зробив те саме що Spring Framework у Java, тому його чекає те саме що Apache Struts.
Якщо робити продукти — це Django.
Якщо гратися в гурток програмування — мікросервіси.
У продукту Python зазвичай взагалі допоміжний інструмент, щоб щось не цільове робити значно швидше ніж на : C++, Go lang, Java, C# або Rust. Gil робить так, що якщо є навантаження рано пізно як і у випадку із PHP — доведеться це переписати, бо це буде дешевше ніж платити за хард, коли рахунки будуть мати по 5 а то і 6 нулів.
Не усі як Google та Meta — можуть по факту змінити керівнмй склад комюніті, щоб міняти сам тех стек ідеологічно під потреби свого бізнесу.
Для швидкого протипування і TTM — так одні з найкращіх інструментів що Python Django, що PHP із купою своїх фреймверків типу : WordPress, Drupal чи Joomla.
Це «навантаження» — воно тут з нами, в цій кімнаті?
Ви все ще на AWS? Боїтеся або не вмієте адмініструвати сервер з Лінуксом за 45$ на Хецнері?
Воно зазвичай навпаки, з хостінгу чи приватного датацентру — в клауди, і давно так вже. В приватних датацентрах — так само або Kubernetes або OpenShift та контейнери в будь якому випадку.
Бізнеси мають різні маштаби, при старті дрібних проектів доки не ясно чи взагалі працює бізнес модель і чи є сенс вкладатись, дійсно треба брати LAMP стек і не випендрюватись. Масштабувати має сенс, коли для цього існує необхідність, якісь може сервіси чи скрипти тести і т.д. написати і на Python чи на чому вмієш швидко.
Дрібний проектт в клаудах, справді не окупний.
Джанго це веб, ви стикалися з обмеженнями GIL в вебі? Цікаво почути про такі задачі і причини чому вони не були винесені в окремі сервіси
Щоб не спекулювати в пусту, бо це холівар апріорі : TechEmpower Web Framework Benchmark де міряють Request per second
Берем тільки JSON serialization API:
Java Spring WebFlux — 210 000 RPS latency 2.5 ms.
Java Spring Framework MVC — 160 000 RPS, latency 8ms
Python Fast API — 25 000 RPS, latency 35 ms.
Python Django — 8000 PRS, latency 45 ms.
PHP Laravel — 7000 RPS, latency 12 ms.
PHP Symfony — 8000 RPS, latency 22 ms.
Лідером бенчмарку є Rust may-mini — із 1327000 RPS.
Так там є і більш реалістичні бенчмарки, із запитами до баз данних — коли різниця в 3 рази.
Далі щоб по холіварити функціоналу з коробки у Django до 5 крат більше, ніж в конструктора зроби сам типу Spring Boot і тим більше фреймверків на Rust чи С++.
Були зіміри швидкості розробки, The Web Framework Shutout — де абсолютний чемпіон якраз Djano — із середніми 2 годинами на завданя у груп розробників, далі Laravel із 2.5 годинами. Fast API — 5 годин. Spring boot 12 годин. Rust Axum — понад 40 годин.
Ну я і не збирався холіварити щодо швидкості мов бо це і так всім відомо, але дякую що також привели швидкість розробки, це важливо :)
Мій коментар був більше про те що мову і фреймворк треба вибирати згідно завдань, і будь які критичні моменти можна завжди винести в окремий сервіс на якій забажаєте мові :)
Якщо ж звісно у вас сайт на сотні тисяч rps то дійсно можливо треба вибрати високошвідкісну мову
Чекаю треду «jQuery в 2026: норм чи стрьом»))
Все там вписується. Та все ж, я не фанат DRF, бо я бачив до чого призводить сліпе використання вбудованого функціоналу звідти... Ті хто давно і якісно пише на django і має досвід з популярними «батарейками» можуть дуже швидко зробити готовий прототип. Тому я б тут від наявного досвіду команд більш відштовхувався ніж від переваг якогось з фреймворків, хоч мені більше імпонує FastAPI.
Залежить від прокладки між кріслом та клавіатурою.
Прошу надати креслення правильної прокладки.
Залежить від контексту
норм
А можу поцікавитися чому? Особисто моя думка про Django — це те, що, якщо є можливість, то від нього краще відмовлятися на користь чогось більш гнучкого, зручного та кращого
бо на ньому можна дуже швидко зробити робочий продукт, на відміну від Реакт
А можу поцікавитись чому навпаки така негативна думка щодо Джанго? :)
Та не те щоб негативна, скоріше я б сказав не позитивна) Колись давно бавився з ним деякий час, і він здався мені зовсім негнучким та занадто масивним.
Але з коментарем вище я згоден. Якщо треба швидко зібрати MVP — Django для цього підходить. Проте в інших випадках він не дуже задовольняє потреби. Умовний FastAPI дає набагато більше свободи дій і не тягне за собою зайвого багажу.
Дивлячись де та як разгортати, та скільки на це є грошей. Django — старий фреймверк 2005 року з іншої ери, коли говним методом формування динаміки DOM був server side rendering. Spring і Java EE загалом та ASP.NET — теж і усе це прямим чином намагалось робити аналогію — PHP/ LAMP стекам.
Та усі вони зараз стали використовуватись для розробки RESTful web service API для SPA Frontend-у, на React, Vue чи Angular.
FastAPI — зроблений якраз під це, під Claud Native підхід та SPA frontend.
Як там справи з FastAPI + SQLAlchemy + Alembic у порівнянні з Django? Достатньо гнучкості? 😄
Після Django ORM неможливо спокійно дивитись в бік Alchemy + Alembic )
А яку свободу дій хочеться мати?
...