การกำเนิดและความตายของ JavaScript (2014)

 (destroyallsoftware.com)
1 คะแนน โดย GN⁺ 6 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ติดตามประวัติของ JavaScript และการเขียนโปรแกรมตั้งแต่ปี 1995 ถึง 2035 ในรูปแบบ ไซไฟ·คอเมดี้·การบรรยายจริงจัง
  • ขอบเขตไม่ได้มีแค่ JavaScript แต่ขยายไปถึงประวัติของการเขียนโปรแกรมโดยรวม
  • ใช้มุมมองแบบ เป็นกลาง โดยไม่เข้าข้างฝ่ายสนับสนุนหรือคัดค้าน JavaScript
  • พูดถึง ข้อบกพร่อง ของภาษาอย่างตรงไปตรงมา แต่ประเมินผลกระทบสุดท้ายที่มีต่ออุตสาหกรรมในแง่บวกอย่างมาก
  • ข้อความสำคัญคือ แม้ JavaScript จะมีข้อบกพร่อง แต่ก็ได้ทิ้งอิทธิพลเชิงบวกอย่างมากไว้กับ อุตสาหกรรมการเขียนโปรแกรม

ภาพรวมการบรรยาย

  • เป็นการติดตามประวัติของ JavaScript และการเขียนโปรแกรมโดยรวมตั้งแต่ปี 1995 ถึง 2035
  • ลักษณะของการบรรยายเป็นการผสมกันของ ไซไฟ คอเมดี้ และการบรรยายที่จริงจังอย่างเต็มที่
  • ไม่ใช่การบรรยายที่สนับสนุนหรือคัดค้าน JavaScript และไม่ได้สรุปไปอยู่ฝั่งใดฝั่งหนึ่ง
  • แม้จะพูดถึงข้อบกพร่องของ JavaScript อย่างตรงไปตรงมา แต่ก็ประเมินผลกระทบสุดท้ายที่มีต่ออุตสาหกรรมในแง่บวกอย่างมาก

บทความที่เกี่ยวข้อง

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

 
GN⁺ 6 시간 전
ความคิดเห็นจาก Hacker News

  • แม้จะทำนายได้อย่างแม่นยำว่าจะเกิด ภัยพิบัติระดับโลก ในช่วงปี 2020~2025 แต่ดันพลาดแค่ชนิดของภัยพิบัติเท่านั้น ดีจัง(?)
    ช่างเป็น JavaScript เสียจริง

    • จะว่าไปก็เรียกได้ว่าแม่นยำประมาณ NaN%

  • น่าแปลกที่ยังไม่มีใครพูดว่าเขาได้ทิ้งผลงานชิ้นเอกนี้ไว้ให้พวกเรา
    ถ้ายังไม่เคยดู ขอแนะนำให้หยุดทุกอย่างแล้วไปดู รับรองว่าเป็น 5 นาทีที่ดีที่สุดของวันนี้
    https://www.destroyallsoftware.com/talks/wat

    • งานบรรยายของเขายอดเยี่ยมทั้งหมด
      Boundaries เป็นวิดีโอเกี่ยวกับสถาปัตยกรรมซอฟต์แวร์ที่ให้มุมมองลึกซึ้งที่สุดชิ้นหนึ่งเท่าที่เคยดูมา และจนถึงทุกวันนี้ก็ยังนึกถึงบทเรียนจากมันเวลาออกแบบแอปพลิเคชันที่ซับซ้อน
      มันยังเป็นสื่อเริ่มต้นที่ดีสำหรับสอนคนที่คุ้นกับตรรกะเชิงคำสั่งซึ่งมีสถานะกระจัดกระจายไปทั่ว ให้รู้จักคิดแบบโปรแกรมเมอร์สายฟังก์ชันด้วย
      https://www.destroyallsoftware.com/talks/boundaries
    • ในงานบรรยายนี้มีข้อผิดพลาดอยู่บ้าง และจะยกแค่สองจุดที่ฉันเห็น
      เขาเรียก Array(16) แล้วบอกว่ามีตัวคั่น 16 ตัว แต่จริง ๆ มีแค่ 15 ตัว เลยมุก Batman สะดุดไปนิดหน่อย
      อีกจุดคือเขาใช้ {}+[] แล้วอธิบายว่าเป็นการเอาออบเจ็กต์ไปบวกลิสต์ ก่อนจะล้อว่าผลลัพธ์ต่างจาก []+{} ที่ให้ [object Object] แต่จริง ๆ ถ้าเขียนเป็น ({}+[]) ก็จะได้ [object Object] เหมือนกัน
      ว่าทำไม {}+[] ถึงต่างออกไปนั้น ขอทิ้งไว้เป็นปริศนา คำใบ้: Gurer vf ab bowrpg gurer.

  • ในความเป็นจริง JavaScript ได้กลายเป็น เป้าหมายของการคอมไพล์ ไปแล้ว ตอนที่วิดีโอนั้นออกมามันคือ asm.js แต่ตอนนี้มี WebAssembly แล้ว
    พอมันถูกนำไปสร้างใช้งานจริงและรันได้ใกล้เคียงเนทีฟ ก็ถือว่าคำทำนายนี้แม่นพอสมควร
    ฉันใช้ TypeScript เป็นหลัก และด้วย Electron เทคโนโลยีเว็บก็ถูกห่อเป็นเดสก์ท็อปแอป ทำให้ไวยากรณ์ของเว็บหลุดเข้าไปอยู่ในโปรแกรมทั่วไปด้วย
    ถึงจะมีคนบอกว่า Electron หนักและไม่ค่อยดี แต่ก็เป็นวิธีที่เร็วที่สุดในการรองรับ Mac, Windows และ Linux พร้อมกัน
    “ความตาย” ที่พูดถึงตรงนี้คือสภาวะที่เราเลิกเขียน JavaScript ตรง ๆ แต่ให้มันกลายเป็น ชั้นฐานราก ที่มีอยู่ทุกที่ ซึ่งฉันคิดว่าสุดท้ายมันก็เป็นแบบนั้นจริง

    • ยังมี Flutter ด้วย และมันรองรับไม่ใช่แค่เดสก์ท็อป แต่รวมถึง iOS และ Android ด้วย
      ฉันคิดว่าความเร็วในการพัฒนาก็ค่อนข้างดี
      แต่ก็ไม่แน่ใจว่าเมื่อเทียบกับ Electron หรือแอปเนทีฟแล้วประสิทธิภาพเป็นอย่างไร
      ถ้าเป็นทีมเล็ก การโฟกัสที่ ปล่อยของให้ได้จริง มักดีกว่าการหมกมุ่นกับการปรับแต่งความเร็วมาก
    • พูดได้ว่า JavaScript คือ ชั้นแอสเซมบลี แบบใหม่
      โดยนิยามแล้ว คอมไพเลอร์คือสิ่งที่แปลงโค้ดที่มนุษย์อ่านได้ให้เป็นภาษาเครื่อง
      จุดแข็งของ JavaScript คือ Google ผลักดัน V8 ไปจนสุดทาง และ NodeJS ก็สร้างสภาพแวดล้อมฝั่งแบ็กเอนด์ที่น่าสนใจขึ้นมา จากนั้นมันก็กลายเป็นสิ่งที่มีอยู่ทุกที่แบบ PDF และเขียนครั้งเดียวใช้ได้แทบทุกที่
      เหตุผลที่มันยังได้เปรียบ WebAssembly จนถึงตอนนี้ก็เพราะความอเนกประสงค์นี่เอง และ WebAssembly ก็ยังไม่ได้ถูกติดตั้งแพร่หลายเท่า JavaScript
      ทุกวันนี้ JavaScript แทบจะกลายเป็นคำพ้องกับ TypeScript ไปแล้ว ซึ่งนี่เป็นก้าวกระโดดครั้งใหญ่ และฉันคิดว่าฮีโร่ที่ถูกมองข้ามตรงนี้คือ Angular 2
      Angular เลือก TypeScript ตั้งแต่แรก แม้จะมีเวอร์ชัน native JavaScript ให้ด้วย แต่พูดตามตรงเวอร์ชันนั้นแทบใช้งานไม่ได้ และตอนนั้นก็โดนวิจารณ์หนักมาก
      ที่น่าสนใจก็คือที่หลบภัยสุดท้ายที่ยังไม่ยก TypeScript ขึ้นเป็นตัวเลือกหลักคือ React แต่เมื่อโปรเจ็กต์ใหญ่ ๆ อย่าง NextJS พึ่งพา TypeScript เป็นค่าเริ่มต้นอยู่แล้ว ReactJS ก็คงต้านไม่อยู่ในที่สุด
      นี่ไม่ใช่ครั้งแรกที่นวัตกรรมเกิดจากโปรเจ็กต์อื่นก่อนแล้ว ReactJS ค่อยตามมา และในเรื่องนี้ฉันมองว่า Angular นำอยู่
      ถ้าคุณเลือก JavaScript กับ Python ก็มักจะไม่ได้เลือกผิดไปไกลนัก
    • ถ้า “ความตาย” นั้นหมายถึงการที่ JavaScript กลายเป็นชั้นฐานที่ไม่ต้องเขียนกันโดยตรงอีกต่อไป มันก็ดูเหมือนเป็นคนละเส้นเวลากับที่ฉันอยู่
      ผู้คนยังคงเขียน JS กันตรง ๆ เป็นจำนวนมหาศาล และ WebAssembly ก็ยังไม่ได้ครองความเป็นสภาพแวดล้อมรันไทม์ทั่วไปของเว็บแอปพลิเคชัน
      คุณอาจหาเจอบริษัทที่สร้างบางอย่างบน WebAssembly ได้ แต่ไม่ควรเอาไปปะปนกับ การเปลี่ยนผ่านครั้งใหญ่ แบบที่ Gary พูดถึง
    • ในเรื่องเล่าในวิดีโอนั้น JIT พัฒนาไปดีพอจน หน่วยความจำเสมือนและการป้องกันหน่วยความจำ ถูกกำจัดทิ้ง
      ซึ่งมันไม่ได้เกิดขึ้นเลยแม้แต่น้อย
    • ถ้าเว็บไซต์ก็พอแล้ว จะสร้างแอปไปทำไม?
      ไม่จำเป็นต้องเปิดเว็บเบราว์เซอร์หลายตัวเพื่อทำแบบนั้น

  • ทุก ๆ ไม่กี่ปีก็มีคนประดิษฐ์ JavaScript ที่ดีกว่าเดิมขึ้นมา แล้วสุดท้ายก็ ทรานส์ไพล์กลับมาเป็น JavaScript อีกที

    • การยอมรับในวงกว้างชนะการออกแบบที่ดีเสมอ
    • สุดท้ายแล้วมันก็เป็น โค้ดแอสเซมบลี ทั้งนั้น
      การคอมไพล์มาเป็น JavaScript เองก็ไม่ได้มีอะไรผิดโดยเนื้อแท้ และภาษาระดับสูงสามารถมอบการรับประกันหลายอย่างที่ JavaScript ล้วน ๆ ให้ไม่ได้โดยตรง
      การรับประกันจากภาษาที่เราใช้กันมาแทบทั้งหมดก็สามารถถูกทำลายได้เมื่ออยู่บนแอสเซมบลีดิบเช่นกัน

  • ปัญหาคือ พัฒนาการของ Wasm ไม่ได้เร็วเท่าที่คาดการณ์ไว้ในนี้
    เพราะมันไม่มีการจัดการ DOM เลย ทำให้ยังต้องใช้ JS เป็นโค้ดกาวอยู่ดี ไม่อย่างนั้นก็ต้องทิ้ง HTML กับ CSS ไปเลย แล้วเรนเดอร์ทุกอย่างลงแคนวาสแบบ Flutter หรือ Rust GUI บางตัว
    แต่การสูญเสียชุดความสามารถของเว็บไปก็น่าเสียดาย

    • คนที่เลือก Flutter อาจมองว่า ความสม่ำเสมอ ที่ได้จากแคนวาสในทุกเบราว์เซอร์ มีค่ามากกว่าการได้ชุดความสามารถเว็บที่แต่ละที่ทำงานกันไม่เหมือนกัน
    • DOM กับ JS แยกจากกันไม่ได้
      DOM API ถูกออกแบบมาโดยตั้งสมมติฐานว่าจะถูกเข้าถึงผ่าน JS และการออกแบบของ JS รวมถึงคุณลักษณะ “แปลก ๆ” บางอย่างก็มีที่มาบางส่วนจากการถูกสร้างมาให้ใช้ร่วมกับ DOM
    • JS เข้าถึงได้ง่ายกว่า WASM มาก
      คุณดีบักมันสด ๆ ได้ เอาไปให้ LLM ดูได้ และมันไม่มี wrapper มาขวาง จึงจับต้อง ทดลอง และทำงานกับมันได้ง่ายกว่ามาก

  • ในปี 2014 เคยดู Gary Bernhardt พูดไลฟ์ที่งาน Canadian Undergraduate Software Engineering Conference (CUSEC)
    PNaCl เพิ่งออกมาในปีก่อนหน้านั้น และ Google ก็กำลังใช้มันเพื่อ cross-compile, execute และ sandbox OpenSSH กับไคลเอนต์ RDP ภายใน Chrome และ ChromeOS ส่วนฝั่ง Mozilla/Firefox ก็เสนอ asm.js เป็นการตอบโต้
    ตอนนั้นก็แค่รู้สึกว่าตลกดี แต่พอมาดูตอนนี้ก็น่าทึ่งที่หลายส่วนของไอเดียนั้นยังอยู่รอดมาได้

  • Wat lightning talk ของ Gary Bernhardt เป็นหนึ่งในงานพูดที่ฉันชอบที่สุด
    มันมาก่อนงานพูดตามชื่อบทความนี้เพียง 2 ปีเท่านั้น
    [1]: https://www.destroyallsoftware.com/talks/wat

  • แทบทุกอย่างเกิดขึ้นไปตามบท
    ตอนนี้ก็เหลือแค่รอระบบปฏิบัติการอีกตัวที่สร้างบนเทคโนโลยีเบราว์เซอร์ทั้งหมด หรือ WASM OS
    อย่างน้อย webOS กับ Firefox OS ก็ล้ำยุคไปก่อนเวลาถึง 20 ปี

    • ไม่ใช่เลย
      WASM ไม่ได้ยืนยันข้อเสนอนั้น แต่เป็นการหักล้างมัน
      ข้อเสนอนั้นคือซอร์สที่เข้ากันได้กับ JavaScript จะกลายเป็นรากฐานของอนาคต และแม้ JavaScript ทั่วไปจะเป็นรากฐานที่แย่มาก แต่เอนจิน JavaScript ที่ถูกปรับแต่งอย่างหนักเพื่อแปลความชุดย่อยที่เข้ากันได้อย่างมีประสิทธิภาพ อาจกลายเป็นแพลตฟอร์มอเนกประสงค์แห่งอนาคตได้
      WASM ปฏิเสธแนวคิดนี้ตั้งแต่ราก โดยสร้างรากฐานใหม่ที่ไม่เข้ากันกับ JavaScript และออกแบบมาเพื่อเป็นเป้าหมายระดับล่าง
      การบอกว่า WASM เป็นการยืนยันข้อเสนอนั้น แปลกพอๆ กับการบอกว่าอนาคตที่ทุกคนมี Rust interpreter อยู่ในเบราว์เซอร์เป็นการยืนยันข้อเสนอนั้น
      ถ้าจะอ้างแบบนั้น ท้ายที่สุดก็แค่กำลังบอกว่าเว็บเบราว์เซอร์จะรันโค้ดบางรูปแบบจากภาษาใดก็ได้ ซึ่งตอนนี้ก็เป็นแบบนั้นอยู่แล้ว
      วิดีโอนี้พูดถึงความเป็นไปได้ที่ชัดเจนว่าน่า "ทึ่ง" ดังนั้นจะตีความว่ามันสอดคล้องกับทุกอนาคตที่เป็นไปได้แบบธรรมดาทั่วไปตามตัวอักษร ก็ไม่สมเหตุสมผล
    • มีเหตุผลทางเทคนิคอะไรไหมที่ไม่พูดถึง ChromeOS?
      ถามด้วยความสงสัยล้วนๆ
      แล้วสกรีนช็อตของ webOS ที่ฉันเคยเห็นก็ทำให้อยากให้มันกลับมา ไม่ใช่แค่บนสมาร์ตทีวี แต่รวมถึงที่อื่นด้วย

  • ตอนนี้เราเดินมาเกินครึ่งทางของไทม์ไลน์ปี 2035 ของ Bernhardt แล้ว
    JavaScript ยังไม่ตาย แต่ดูเหมือนว่ามันกำลังเขียนคำไว้อาลัยให้ตัวเองอยู่ใน WebAssembly

    • มีโอกาสสูงที่คำสั่ง JS สุดท้ายจะยังคงถูกรันอยู่ แม้คนในตระกูลของคุณหลายรุ่นจะตายไปหมดแล้ว
      เว้นแต่จะเกิดสงครามนิวเคลียร์ทั่วโลก ฉันยอมเดิมพันว่า JS จะอยู่ยาวกว่ามนุษย์ส่วนใหญ่
    • ฉันตรวจเว็บของลูกค้าหลายเจ้าทุกเดือน และทุกเว็บก็ใช้ JavaScript ไม่ทางใดก็ทางหนึ่ง
      มันจะไม่มีวันตาย เหมือน PHP

  • JavaScript คือ ภาษาโปรแกรมที่ยอดเยี่ยมที่สุดตลอดกาล