Django в 2026 році: норм чи стрьом?
Як ви всі напевно знаєте, Django — це класика Python-розробки. На ньому досі крутиться купа серйозних проєктів.
Але перша версія фреймворку вийшла аж у 2005 році. Звісно, він постійно оновлюється, проте його монолітний підхід не завжди вписується в сучасні тренди, де всі сфокусовані мікросервісах. Та і вакансій з ним не так багато. На DOU знайшов лише 63 штуки, де він згадується.
То як думаєте, чи є сенс у 2026 році вчити Django і брати його як базу для старту нового продукту з нуля, чи краще одразу дивитися в бік чогось новішого, більш сучасного?
28 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівПорсмотри на Jinja2. FastAPI его поддерживает из коробки. Наследование страниц даже есть. Мне зашло. Потом смотрел на Django не захотел передить в новой версии сайта, которую делаю с нуля.
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 )
А яку свободу дій хочеться мати?
...