6 คะแนน โดย GN⁺ 2025-12-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เว็บเฟรมเวิร์ก Django เวอร์ชัน 6.0 เปิดตัว โดยรองรับ Python 3.12 ขึ้นไป และเพิ่มความสามารถด้านความปลอดภัย เทมเพลต และงานแบบอะซิงโครนัสอย่างมาก
  • Content Security Policy(CSP) ถูกฝังมาในตัว ทำให้สามารถตั้งค่านโยบายเพื่อป้องกันการโจมตีแบบอินเจกต์เนื้อหา เช่น XSS ได้
  • เพิ่มฟีเจอร์ Template Partials เพื่อกำหนดส่วนที่สามารถนำกลับมาใช้ซ้ำได้ในเทมเพลต ทำให้การทำโมดูลาร์ของโค้ดดีขึ้น
  • เพิ่ม Background Tasks Framework ซึ่งช่วยให้รันงานแบบอะซิงโครนัสนอกเหนือจากวงจร request-response ได้
  • นำ Python Modern Email API มาใช้ ปรับความเข้ากันได้ด้วยการเลิกสนับสนุน MariaDB 10.5 และเปลี่ยนค่าเริ่มต้น DEFAULT_AUTO_FIELD เป็นต้น ทำให้เกิดการปรับปรุงสภาพร่วมสมัยของเฟรมเวิร์ก

ความเข้ากันได้ของ Python

  • Django 6.0 รองรับ Python 3.12, 3.13, 3.14 และจะรองรับเฉพาะการปล่อยล่าสุดของแต่ละซีรีส์อย่างเป็นทางการเท่านั้น
  • Django 5.2.x เป็นเวอร์ชันสุดท้ายที่ยังรองรับ Python 3.10 และ 3.11
  • หลังจาก Django 6.0 แนะนำให้แอปแบบ third-party เลิกรองรับเวอร์ชันก่อนหน้า Django 5.2

คุณสมบัติใหม่สำคัญ

การรองรับ Content Security Policy(CSP)

  • CSP มาตรฐาน ถูกเพิ่มเข้ามาใน Django เพื่อเสริมการป้องกันการโจมตีแบบ XSS และการฉีดเนื้อหาอื่นๆ
    • สามารถกำหนดนโยบายผ่าน ContentSecurityPolicyMiddleware, context processor csp(), และการตั้งค่า SECURE_CSP
    • รองรับการกำหนดนโยบายอย่างชัดเจนและปลอดภัยด้วยการตั้งค่าที่อิงจาก Python dict
  • ตั้งค่าได้ด้วย SECURE_CSP_REPORT_ONLY เพื่อใช้งานในโหมดตรวจสอบ
  • มี decorator สำหรับกำหนดทับนโยบายหรือปิดการใช้งานได้ในระดับ view

Template Partials

  • เพิ่ม tag partialdef และ partial เพื่อกำหนดและนำกลับมาใช้ซ้ำได้สำหรับ ชิ้นส่วนเทมเพลต (fragment)
  • อนุญาตให้อ้างอิงได้โดยตรงใน get_template(), render(), {% include %} ด้วยไวยากรณ์ template_name#partial_name
  • มีคู่มือย้ายระบบสำหรับผู้ใช้แพ็กเกจ third-party django-template-partials

Background Tasks Framework

  • เพิ่มเฟรมเวิร์กภายใน Django สำหรับรันงานแบบอะซิงโครนัส
    • สามารถใช้งานงานนอกวงจร HTTP request-response เช่นการส่งอีเมล การประมวลผลข้อมูล
    • กำหนดงานด้วย decorator @task และลงทะเบียนคิวด้วย enqueue()
  • backend กำหนดผ่านการตั้งค่า TASKS โดยมี backend เริ่มต้น 2 ตัวสำหรับการพัฒนา/ทดสอบ
  • Django ทำหน้าที่สร้างและคิวงานเท่านั้น ขณะที่ worker process ภายนอก จะรับผิดชอบการรันงานจริง

การนำ Python Modern Email API มาใช้

  • ตรรกะการจัดการอีเมลของ Django ย้ายมาพึ่ง API อีเมลสมัยใหม่ของ Python 3.6+ (email.message.EmailMessage)
  • คลาส SafeMIMEText และ SafeMIMEMultipart จะไม่ถูกใช้ต่อ (deprecated)
  • ค่าที่ EmailMessage.message() คืนกลับเปลี่ยนเป็น instance ของ EmailMessage ของ Python

รายละเอียดการปรับปรุง

Admin

  • ใช้ icon set Font Awesome Free 6.7.2
  • สามารถปรับแต่งฟอร์มเปลี่ยนรหัสผ่านในแอดมินได้ผ่าน AdminSite.password_change_form
  • มีการเพิ่มไอคอนและสไตล์ CSS แยกสำหรับ messages.DEBUG และ messages.INFO

Auth

  • จำนวนรอบการแฮช PBKDF2 เพิ่มจาก 1,000,000 เป็น 1,200,000

GIS

  • สามารถตรวจสอบว่า Geometry มีแกน M หรือไม่ผ่าน GEOSGeometry.hasm
  • Rotate รองรับการหมุนตามมุมที่กำหนด
  • สามารถปรับแต่งผู้ให้บริการแผนที่ (map tile provider) ได้ผ่าน BaseGeometryWidget.base_layer
  • เริ่มรองรับ coveredby, isvalid, GeoHash, IsValid และฟีเจอร์อื่นๆ บน MariaDB 12.0.1+
  • ลบ JavaScript แบบ inline ออกจากการ render วิดเจ็ต ต้องแก้ไขเทมเพลตเพิ่มเมื่อมีการปรับแต่ง

PostgreSQL

  • เพิ่ม Lexeme expression เพื่อควบคุมการค้นหาข้อความแบบเต็ม (full-text search) ได้ละเอียดขึ้น
  • เพิ่มพารามิเตอร์ hints ในการดำเนินงานที่เกี่ยวกับ extension เช่น CreateExtension
  • เพิ่มระบบตรวจสอบอัตโนมัติสำหรับ field, index และข้อจำกัด (constraints) ที่เกี่ยวข้องกับ django.contrib.postgres

Staticfiles

  • ManifestStaticFilesStorage ช่วยรับประกันความสม่ำเสมอของการเรียงเส้นทางเพื่อลด diff ที่ไม่จำเป็น
  • คำสั่ง collectstatic จะแสดงผลสรุปเท่านั้นเป็นค่าเริ่มต้น รายละเอียดจะแสดงเมื่อใช้ --verbosity 2 ขึ้นไป

อื่นๆ

  • เพิ่มการรองรับภาษา Haitian Creole
  • คำสั่ง startproject และ startapp จะสร้างโฟลเดอร์ที่ไม่มีอยู่ให้อัตโนมัติ
  • คำสั่ง shell จะ import util พื้นฐาน เช่น django.conf.settings โดยอัตโนมัติ
  • รองรับการ serialization ของ zoneinfo.ZoneInfo ในไฟล์ migration
  • เพิ่ม aggregate ใหม่ เช่น StringAgg, AnyValue
  • รองรับการแบ่งหน้าข้อมูลแบบอะซิงโครนัสด้วย AsyncPaginator, AsyncPage
  • รองรับหลาย Cookie header ในสภาพแวดล้อม ASGI สำหรับ HTTP/2
  • เพิ่มตัวแปร forloop.length ในเทมเพลต และปรับปรุง tag querystring
  • DiscoverRunner รองรับการทดสอบแบบขนานด้วยโหมด forkserver

การเปลี่ยนแปลงที่ไม่เข้ากันได้

Database Backend API

  • BaseDatabaseSchemaEditor และ backend ของ PostgreSQL หยุดใช้ CASCADE เมื่อทำการลบคอลัมน์
  • เปลี่ยนชื่อเมธอดจาก return_insert_columns() เป็น returning_columns()
  • เมื่อรองรับ UPDATE … RETURNING สามารถตั้งค่า DatabaseFeatures.can_return_rows_from_update=True ได้

สิ้นสุดการสนับสนุน

  • เลิกรองรับ MariaDB 10.5 (ต้องใช้ 10.6 ขึ้นไป)
  • เลิกรองรับ Python ต่ำกว่า 3.12
    • เวอร์ชันขั้นต่ำของไลบรารีที่สำคัญ: aiosmtpd 1.4.5, bcrypt 4.1.1, Pillow 10.1.0, psycopg 3.1.12 ฯลฯ

Email

  • ลบคุณสมบัติ mixed_subtype, alternative_subtype, encoding
  • เนื่องจากการเปลี่ยนแปลงภายใน ต้องตรวจสอบ subclass ของ EmailMessage ที่ปรับแต่งเองอีกครั้ง

การเปลี่ยนแปลงค่าเริ่มต้น DEFAULT_AUTO_FIELD

  • ค่าเริ่มต้นเปลี่ยนจาก AutoField เป็น BigAutoField
  • โปรเจกต์ที่ยังไม่จัดการคำเตือน models.W042 ตั้งแต่ Django 3.2 ต้องเพิ่มการตั้งค่าเพื่อให้งานได้ครบถ้วน

ORM Expression

  • ค่าที่คืนจากเมธอด as_sql() ต้องเป็น tuple

อื่นๆ

  • ในการ JSON serialization จะมีการเพิ่ม newline เสมอ
  • เพิ่มเวอร์ชันขั้นต่ำของ asgiref เป็น 3.9.1

ฟีเจอร์ที่จะเลิกใช้ในอนาคต

django.core.mail API

  • ใน get_connection(), send_mail() และ APIs ที่เกี่ยวข้อง การส่ง argument แบบเลือกได้ต้องส่งเป็น keyword-only
  • เมื่อสร้าง EmailMessage, EmailMultiAlternatives อนุญาต positional arguments ได้เฉพาะ 4 ตัวแรก ส่วนที่เหลือต้องเป็น keyword-only

อื่นๆ

  • เลิกใช้ BaseDatabaseCreation.create_test_db(serialize) และใช้ serialize_db_to_string() แทน
  • เลิกใช้ StringAgg, OrderableAggMixin ที่เป็นของ PostgreSQL
  • โปรโตคอลเริ่มต้นของ urlize, urlizetrunc จะเปลี่ยนเป็น HTTPS ใน Django 7.0
  • กำหนด ADMINS, MANAGERS ด้วยรายชื่อสตริงอีเมลเท่านั้น (ไม่ใช่ tuple ของ ชื่อและที่อยู่)
  • เลิกใช้คลาสอีเมล SafeMIMEText, SafeMIMEMultipart, BadHeaderError

ฟีเจอร์ที่ถูกลบออก

  • ลบการรองรับ positional arguments ของ BaseConstraint
  • ลบ DjangoDivFormRenderer, Jinja2DivFormRenderer
  • ลบการรองรับไดรเวอร์ฐานข้อมูล cx_Oracle
  • เปลี่ยนค่า scheme เริ่มต้นของ forms.URLField จาก "http" เป็น "https"
  • ลบการรับ positional arguments ของ Model.save() และ Model.asave()
  • ลบ ModelAdmin.log_deletion(), LogEntryManager.log_action()
  • ลบโมดูล django.utils.itercompat
  • ลบเมธอด GeoIP2.coords(), GeoIP2.open()
  • ลบ ForeignObject.get_joining_columns() และเมธอดที่เกี่ยวข้อง

Django 6.0 ยกระดับความมั่นคงเสถียรและความสามารถในการขยายตัวของเฟรมเวิร์กผ่านการเสริมความปลอดภัย การประมวลผลแบบอะซิงโครนัส และการนำ API อีเมลสมัยใหม่มาใช้ โดยกำหนดภาพชัดเจนสำหรับการย้ายไปสู่สภาพแวดล้อม Python 3.12 ขึ้นไป

1 ความคิดเห็น

 
GN⁺ 2025-12-05
ความคิดเห็นจาก Hacker News
  • ในองค์กรที่เคยทำงานมาก่อน มีทั้งโค้ดเบส ‘สมัยใหม่’ ที่ทำด้วย NodeJS+React และ แอป Django แบบ legacy บน Python 2.7 ที่มีอายุเกือบ 15 ปี
    ตอนแรกกังวลว่าโค้ดเก่าจะเป็นงานที่น่าปวดหัว แต่กลับตรงกันข้ามโดยสิ้นเชิง
    แอป Django ใช้งานได้อย่างรื่นรมย์และการค่อยๆ จัดระเบียบมันก็สนุกมาก พอถึงวันที่มันจะถูกแทนที่ด้วย การรีไรต์ใหม่ด้วย Go/React ก็คงรู้สึกเสียดาย

    • ไม่เข้าใจว่าทำไมต้องเปลี่ยนด้วย ถ้า มันยังไม่พัง ก็ไม่จำเป็นต้องแก้
  • ขอแสดงความยินดีกับทีม Django
    ฉันดูแล แอปตั้งต้น Django + Celery + Postgres + Redis + esbuild + Tailwind บน Docker Compose มานาน และเพิ่งอัปเดตให้เข้ากับ Django 6.0 ได้ไม่นานนี้
    ดูได้ที่ GitHub repository
    ตอนนี้ยังไม่ได้ใส่ การตั้งค่า CSP เป็นค่าเริ่มต้น แต่ตั้งใจจะเพิ่มหลังจากทบทวนอีกหน่อย

    • ตั้งใจจะบุ๊กมาร์กไว้ แต่พบว่าเคยเซฟไว้แล้วตั้งแต่เดือนธันวาคม 2023
    • repository ของ Nick คุณภาพระดับท็อป เสมอ ฉันก็อ้างอิงจากของเขาในเอกสารของตัวเองบ่อยมาก ขอบคุณที่แชร์แบบสาธารณะ
    • เคยใช้เทมเพลตนี้กับโปรเจ็กต์เมื่อหลายปีก่อน ยอดเยี่ยมจริงๆ
    • พอเห็นว่าเพิ่ง เพิ่ม uv เข้าไป ก็รู้เลยว่ายังดูแลต่อเนื่องอยู่
  • ปรัชญา "batteries included" ของ Django เข้ากับการสร้างโค้ดด้วย AI ได้อย่างสมบูรณ์แบบ
    ทั้งแอดมินพาเนล ระบบล็อกอิน การรีเซ็ตรหัสผ่าน และฟังก์ชันพื้นฐานอื่นๆ มีมาให้อย่างพร้อมสรรพ ทำให้ AI สามารถสร้างเว็บที่สมบูรณ์ได้ด้วยโค้ดเบสขนาดเล็ก
    โค้ดก็เล็กและชัดเจน จึงเหมาะกับการให้ AI ปรับปรุงแบบวนซ้ำ

    • จุดแข็งของ Django คือ โครงสร้างโค้ดที่มนุษย์อ่านง่าย
      แทนที่จะเป็นคอมโพเนนต์ขนาดมหึมา มันมีโมเดลและเทมเพลตที่ชัดเจน ทำให้รีวิวโค้ดที่ AI สร้างมาก็ง่าย
      อีกทั้ง Django admin ยังเป็น ground truth ที่แยกอิสระอยู่ด้วย ดังนั้นแม้ฝั่งฟรอนต์เอนด์จะพัง ก็ยังจัดการข้อมูลได้
      แต่ก็เสียดายที่ ecosystem ของ Python ไม่ได้เลือกใช้ โมเดล gevent ไม่อย่างนั้นการเปลี่ยนผ่านไปสู่ async คงลื่นไหลกว่านี้มาก
    • ด้วยโครงสร้าง INSTALLED_APPS ของ Django จึงเพิ่มหรือลบฟังก์ชันเป็นรายแอปได้ง่าย
      มันบูรณาการมากกว่ากรอบงานที่เชื่อมกันหลวมๆ อย่าง Flask หรือ FastAPI มาก
      ความต่างแบบนี้ช่วยลด ความจุกจิกเล็กๆ น้อยๆ (papercuts) ได้มากในที่สุด
    • เคยใช้ทั้ง Django และ Rails พอมาทดสอบกับ Claude Code แล้ว Rails ทำงานได้ดีกว่ามาก
      ฉันรีไรต์แอป .NET เก่าและ Rails แปลงได้แทบสมบูรณ์แบบ แต่ Django กลับทำได้ยากกว่า
    • จริงๆ แล้ว Ruby on Rails มีฟีเจอร์อย่าง CSP, background worker และความสามารถอีกหลายอย่างมาให้เป็นค่าเริ่มต้นมานานกว่าแล้ว
    • Django ถูกใช้ในโปรเจ็กต์โอเพนซอร์สมายาวนานมาก ทำให้ AI มี ข้อมูลโค้ด สำหรับเรียนรู้จำนวนมหาศาล
  • ฟีเจอร์ template partials ในรีลีสนี้ดูดีทีเดียว
    แต่สถานะของ type annotations ก็ยังน่าอึดอัดอยู่ดี
    django-stubs ต้องใช้ mypy plugin, django-types เป็นฟอร์กสำหรับ pyright แต่ซิงก์กันได้ไม่ดี
    ส่วน pylance ก็ใช้ฟอร์กของตัวเองอีก
    หวังว่าเวอร์ชันหน้าจะใส่ type พื้นฐานอย่าง HttpRequest, HttpResponse, View, Model มาให้อย่างเป็นทางการอย่างน้อยก็ยังดี

  • Django ทำให้การพัฒนาเว็บเป็นเรื่องสนุกมากจริงๆ
    ต่อให้ลองเปลี่ยนไปใช้เฟรมเวิร์กอื่น สุดท้ายก็มักจะกลับมาหา Django อยู่ดี เป็น ตัวเลือกที่ไม่เคยเสียใจ

    • ฉันมีประสบการณ์แบบเดียวกันกับ Ruby on Rails
      ต่อให้ลองเฟรมเวิร์กอื่น สุดท้ายก็กลับมาเพราะความสะดวกของ Rails
      แค่น่าเสียดายที่ Rails ไม่มี Admin UI พื้นฐานมาให้
    • ถ้ามองแค่ฝั่งแบ็กเอนด์ Django นั้นยอดเยี่ยม แต่ในมุมของ ฟรอนต์เอนด์ ยังเหมือนอยู่ในยุคหิน
      ถ้าอยากได้ full-stack แบบครบจริงๆ ไปดู Laravel หรือ Rails จะดีกว่า
    • พูดตรงๆ คือฉันไม่ค่อยเข้าใจเสน่ห์ของ Django เท่าไร
      ทำเว็บมาตั้งแต่ยุค PHP แต่ Django ก็ให้ความรู้สึกว่า กลางๆ มาโดยตลอด
  • Django คือ โปรเจ็กต์ฟรีแลนซ์ขนาดใหญ่ชิ้นแรก ของฉัน และจนถึงตอนนี้ก็ยังรู้สึกคุ้นมือและสบายใจอยู่
    ลองทำอะไรเชิงทดลองมาหลายแบบ แต่มันก็ทำงานได้ดีเสมอ ขอบคุณ Django

  • ใช้ Django แทบจะผูกขาดอยู่คนเดียวมาเกือบ 15 ปีแล้ว
    ลองเฟรมเวิร์กอื่นมาก็เยอะ แต่ไม่มีตัวไหน เข้ามือ เท่า Django
    รีลีสนี้เพิ่ม task framework เข้ามาแล้ว แต่ก็เสียดายที่ยังไม่มีทั้ง backend และ worker รวมมาให้
    อยากให้เวอร์ชันถัดไปรวมมาแบบสมบูรณ์ไปเลยมากกว่า

    • สงสัยเหมือนกันว่า Django มีแผนจะข้ามเส้นนั้นไหม เพราะตามปรัชญาของเฟรมเวิร์กแล้วน่าจะให้ความสำคัญกับ การรักษาขอบเขต
    • อย่าให้ความสมบูรณ์แบบกลายเป็นศัตรูของสิ่งที่ดี Django เป็นเฟรมเวิร์กสำหรับ "พวกสมบูรณ์แบบนิยมที่มีเดดไลน์" ในท้ายที่สุด
  • ความเป็น batteries included ของ Django ทำให้มันเหมาะกับโปรเจ็กต์ทุกแบบไม่ว่าจะขนาดไหน
    ขอชื่นชมทีมงานและผู้ร่วมพัฒนาทุกคน

  • ฉันสงสัยว่าเราเข้ามาสู่ ยุค SPA กันได้อย่างไร เพราะแค่อยากกำจัด loading spinner หรือมีเหตุผลที่ลึกกว่านั้น

    • หนึ่งในเหตุผลสำคัญคือการมาของ แอปมือถือ
      เมื่อเว็บ, iOS และ Android ต้องใช้แบ็กเอนด์ร่วมกัน รูปแบบ SPA ก็แพร่หลายขึ้นอย่างเป็นธรรมชาติ
      ฉันเองก็ยังทำ SPA อยู่ แต่สักวันก็อยากลองทำโปรเจ็กต์ใหญ่ด้วย Django + htmx
    • เมื่อก่อนฉันเปลี่ยนไปใช้ SPA ตอนทำ data visualization ด้วย Angular
      ความสามารถในการทำงานเหมือนแอปโดยไม่ต้องรีโหลดหน้ามันน่าสนใจมาก แต่ในทางปฏิบัติก็ยังมีหลายกรณีที่ต้อง บังคับรีเฟรช
      ถึงอย่างนั้นฉันก็ยังคิดว่าโครงสร้างที่แยกข้อมูลออกจากการแสดงผลนั้นดูสง่างาม
    • เดิมทีเว็บถูกสร้างมาเพื่อ เรนเดอร์เอกสาร แต่ผู้ใช้ต้องการแอป
      จึงเกิดความพยายามที่จะใช้ JS เปลี่ยนเอกสารให้ทำงานเหมือนแอป
    • ในยุคที่อินเทอร์เน็ตช้า และการตรวจสอบฝั่งแบ็กเอนด์ก็ช้า เราเริ่มจากเพิ่ม JS เพื่อทำ form validation แล้วมันก็ค่อยๆ ซับซ้อนขึ้น
      สุดท้ายก็แยกฟรอนต์เอนด์กับแบ็กเอนด์ออกจากกัน และเกิด API contract กับกระบวนการตรวจสอบตามมา
      ต่อมาจึงเกิดกระแสจะรวมกลับด้วย server components และตอนนี้เราก็อยู่ที่จุดนั้น
      อนึ่ง ตัวอย่างเว็บฟอร์มแบบเก่าสามารถดูได้ที่ลิงก์นี้
    • เทมเพลตอย่าง Django หรือ Rails ขาด type safety
      เพราะอย่างนั้นฉันจึงชอบ กระบวนการ build ที่อิง TypeScript มากกว่า
  • ทุกครั้งที่ใช้ Django ก็รู้สึกแค่ สนุก นั่นแหละทั้งหมด