การเขียนโค้ดสำหรับเว็บ

 (mrmr.io)
1 คะแนน โดย GN⁺ 2024-02-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Apple มอบอุปกรณ์ที่ปลอดภัยและมีภาระการดูแลต่ำให้ลูกค้า แต่จากประสบการณ์ได้ข้อสรุปว่าไม่ได้สร้าง ความพึ่งพาซึ่งกันและกัน ในระดับเดียวกันกับนักพัฒนาอิสระ
  • บั๊กโหมดมืด/สว่างของ Google Search ถูกใช้เป็นตัวอย่างที่แสดงว่า ความไม่สะดวกที่ไม่กระทบรายได้ อาจถูกปล่อยทิ้งไว้นาน ไม่ใช่เพราะขาดความสามารถทางเทคนิค
  • คุณค่าหลักของ Apple อยู่ที่คอมพิวเตอร์และอุปกรณ์ที่ผู้ใช้ใช้งานได้โดยไม่ต้องดูแลจัดการเอง มากกว่าระบบนิเวศของแอป และมองว่า iPhone หรือ iPad ยังมีเหตุผลให้ซื้อแม้ไม่มีแอป
  • Apple Music API ที่เคยคาดหวังไว้ในปี 2016 แม้ผ่านไป 8 ปีแล้วยังมีบั๊กและข้อจำกัดการเข้าถึง และแม้จะทดลองใช้ง่าย ๆ ก็ต้องมี บัญชีนักพัฒนาปีละ 100 ดอลลาร์
  • แพลตฟอร์มเว็บ ที่ไม่มีบริษัทเดียวเป็นเจ้าของนั้นไม่สมบูรณ์และเปราะบาง แต่ยังเป็นตัวเลือกที่เป็นจริงสำหรับนักพัฒนาที่ต้องการผูกติดกับโครงสร้างเกมผลรวมศูนย์ของบริษัทใดบริษัทหนึ่งให้น้อยลง

Apple แข็งแกร่งต่อหน้าลูกค้า แต่ไม่ได้พึ่งพานักพัฒนา

  • แกนหลักของมุมมองนี้คือ Apple มอบคุณค่าที่ชัดเจนให้บุคคลทั่วไปซึ่งเป็นลูกค้า แต่มีเหตุผลเชิงโครงสร้างน้อยกว่ามากที่จะใส่ใจ นักพัฒนาอิสระ ในแบบเดียวกัน
  • ความสัมพันธ์แบบพึ่งพาไหลจาก Developer -> Apple, Apple -> Consumer และแทบไม่มีการพึ่งพาย้อนกลับจาก Apple ไปยังนักพัฒนาอิสระ
  • แม้นักพัฒนาทั้งหมดจะหยุดพัฒนาบนแพลตฟอร์ม Apple โดยรวมแล้ว Apple ก็น่าจะอยู่รอดได้ เพราะข้อเสนอคุณค่าหลักของ Apple ไม่ได้ขึ้นอยู่กับนักพัฒนาแต่ละราย
  • ความร่วมมือกับ “พาร์ทเนอร์” ที่เป็นนักพัฒนาระดับองค์กรอาจจำเป็น แต่เป็นคนละประเด็นกับการพึ่งพานักพัฒนาอิสระ
  • บริษัทข้ามชาติบางแห่งวางนักพัฒนาไว้เป็นแกนกลางของกลยุทธ์ แต่เห็นว่า Apple ไม่ใช่บริษัทประเภทนั้น
  • เมื่อยอมรับการแบ่งแยกนี้แล้ว ก็สามารถแยกความรู้สึกชอบผลิตภัณฑ์ Apple ออกจากความอยากพัฒนาสำหรับ Apple ได้

กรณี Google: บั๊กที่ไม่กระทบรายได้อาจคงอยู่นาน

  • Google Search มีปัญหาในสภาพแวดล้อมที่ระบบเปลี่ยนโหมดสว่าง/มืดแบบไดนามิก โดยหน้าผลการค้นหาหน้าแรกแสดงเป็นธีมตรงข้าม
    • ตอนกลางคืน ทั้งระบบอยู่ในโหมดมืด แต่หน้าผลลัพธ์แรกกลับสว่างจนแสบตา
    • ตอนเช้า หลังแล็ปท็อปกลับเป็นโหมดสว่าง ผลการค้นหากลับแสดงเป็นพื้นหลังสีดำที่อ่านยาก
  • บั๊กนี้ดำเนินมาหลายปี และมองว่ามีโอกาสแก้ไขต่ำ เว้นแต่จะถูกแก้โดยบังเอิญระหว่างการปรับปรุงครั้งใหญ่
  • สาเหตุไม่ได้ถูกตีความว่า Google ไม่มีความสามารถจะแก้ แต่เป็นเพราะ มันไม่กระทบรายได้
  • คนที่ใช้เสิร์ชเอนจินทางเลือกอย่าง DDG ก็ออกไปแล้ว และผู้ใช้ส่วนใหญ่ท่วมท้นยังผูกติดกับ Google
  • DDG ชูจุดขายเรื่องความเป็นมิตรต่อความเป็นส่วนตัว แต่เหตุผลที่ใช้จริงคือ UX ที่เรียบง่ายชวนให้นึกถึง Google ยุคแรก ผลการค้นหาแบบตรงตัวที่คุณภาพดี และโฆษณาที่ไม่รบกวน
  • Google ไม่ได้มองผู้ใช้เป็นเป้าหมายเชิงทฤษฎีเกม และการปฏิสัมพันธ์ที่เป็นปฏิปักษ์ต่อผู้ใช้เมื่อจำเป็นต้องใช้ผลิตภัณฑ์ Google ก็ถูกยอมรับว่าเป็นผลลัพธ์ของโครงสร้างเช่นนั้น

คุณค่าหลักของ Apple: คอมพิวเตอร์ที่ปลอดภัยและไม่ต้องดูแลมาก

  • ราวปี 2009 ขณะเลือกคอมพิวเตอร์สำหรับครอบครัว ได้ตัดสินว่า Windows ในเวลานั้นมีความปลอดภัยอ่อนแอเกินไป ส่วน Linux ต้องการการสนับสนุนทางเทคนิคอย่างต่อเนื่อง
  • ท้ายที่สุดจึงเตรียมคอมพิวเตอร์ที่ติดตั้ง OpenBSD, Firefox และเกมพื้นฐานไว้ แต่เพื่อแลกกับความปลอดภัย ความเป็นส่วนตัว และภาระซัพพอร์ตต่ำ ความสามารถในการใช้งานกลับถูกจำกัดอย่างมาก
  • หลังได้ใช้ Mac สำหรับงานที่บริษัทแอป iOS ก็สรุปว่า “นี่คือคอมพิวเตอร์ที่อยากให้แม่ใช้”
  • จึงเก็บเงินซื้อ MacBook และเมื่อเวลาผ่านไป ฟอร์มแฟกเตอร์ที่ครอบครัวใช้เปลี่ยนจากโน้ตบุ๊กเป็น iPad แต่คุณค่าหลักเดิมยังคงได้รับการตอบสนอง
  • แม้เป็น iPhone ที่ไม่มีแอป สำหรับตนเองก็ยังมีความเป็นไปได้ที่จะซื้อ และสำหรับครอบครัวมองว่าแทบจะแน่นอนว่าเป็นอุปกรณ์ที่จะซื้อ
  • ในโมเดลธุรกิจของ Apple นักพัฒนาไม่ใช่องค์ประกอบที่ขาดไม่ได้ และตีความว่าแม้นักพัฒนาจะมีความสุขก็ไม่เป็นไร แต่โครงสร้างไม่ได้บังคับว่าต้องทำให้นักพัฒนามีความสุข
  • ภายใน Apple มีบุคคลที่ใส่ใจนักพัฒนาและพยายามปรับปรุงอยู่ แต่การกระทำในระดับบริษัทอาจไม่สม่ำเสมอ

ความคาดหวังและความผิดหวังต่อ Apple Music API

  • ราวปี 2016 เมื่อ Apple Music API ถูกประกาศที่ WWDC ก็มีความคาดหวังสูง แต่ในความเป็นจริง “ทุกอย่างเปลี่ยนไป” ไม่ได้เกิดขึ้น
  • ยังรู้สึกว่าเครื่องเล่นเพลงของ Apple เองใช้งานยาก และเครื่องเล่นทางเลือกที่ลองใช้โดยมากก็เดินตามแนวทางแบบ Spotify
  • เคยคาดหวังว่าจะสร้างประสบการณ์เครื่องเล่นเพลงส่วนตัวที่รวดเร็ว ลื่นไหล ต่อเนื่องไม่สิ้นสุด เหมือนยุค Justin Frankel ของ Winamp ขึ้นมาใหม่ได้
  • มองว่าหากมีแค็ตตาล็อกเพลงของ Apple ก็สามารถสร้างประสบการณ์นั้นขึ้นใหม่ได้โดยไม่ต้องพึ่งพาการละเมิดลิขสิทธิ์เหมือนในอดีต
  • เมื่อมีเวลาว่าง จึงสร้างเครื่องเล่นเพลงชื่อ Flowers และตั้งใจจะเขียนทูทอเรียลเพื่อให้คนอื่นสร้างเครื่องเล่นเพลงของตนเองได้
  • ระหว่างการพัฒนา หลังผ่านไป 8 ปี ก็สรุปว่า API นั้น มีบั๊กและไม่ได้เปิดเผยต่อสาธารณะอย่างแท้จริง
    • แค่ทดสอบ API ก็ต้องจ่ายให้ Apple ปีละ 100 ดอลลาร์
    • ค่าใช้จ่ายนี้ไม่ได้เป็นค่าการใช้งานจำนวนมาก แต่จำเป็นแม้เพียงเพื่อเข้าถึงสำหรับทดลองใช้งาน
    • แม้ใช้บัญชีนักพัฒนาแบบเสียเงิน ก็ได้รับ API ที่ถูกจำกัดเท่านั้น
  • เมื่อพิมพ์ MusicKit.getInstance().developerToken ในคอนโซลของเบราว์เซอร์บนเว็บเพลเยอร์เพลงของ Apple จะได้รับ root token แบบไม่จำกัดฟรี จึงมองว่าขั้นตอนสำหรับนักพัฒนานั้นไม่สมเหตุสมผล

เว็บคือแพลตฟอร์มร่วมที่ไม่มีเจ้าของรายเดียว

  • ข้อสรุปนำไปสู่ทิศทางว่าให้เขียน โค้ดที่รันบนเว็บ
  • เว็บเป็นแพลตฟอร์มร่วมที่ไม่มีหน่วยงานเดียวเป็นเจ้าของ และแตกต่างจากแพลตฟอร์มของบริษัทใดบริษัทหนึ่งตรงที่แม้แต่เจตนาดีก็อาจถูกทำลายด้วยความไร้ประสิทธิภาพได้
  • แพลตฟอร์มเว็บอยู่ในสภาพเปราะบางเพราะปัจจัยต่อไปนี้
    • รัฐบาลที่แทรกแซงมากเกินไป
    • โครงสร้างตลาดเบราว์เซอร์ที่มีสองขั้วใหญ่
    • ระบบนิเวศนักพัฒนาที่ซับซ้อน
  • ไม่มีหลักประกันว่าเว็บจะรุ่งเรืองต่อไป แต่จนถึงตอนนี้มันอยู่รอดมาได้ และยิ่งอยู่รอดนานเท่าไร โอกาสที่จะรุ่งเรืองต่อไปในอนาคตก็ยิ่งมากขึ้น
  • ระบุว่าโค้ด workaround ล่าสุดที่ต้องเขียนเกี่ยวกับเว็บนั้นเกิดจากพฤติกรรมเฉพาะตัวของ Safari
  • ขณะเดียวกัน Google ก็กำลังทำสิ่งยอดเยี่ยมเพื่อเว็บ จึงประเมินว่าในบริบทนี้ Google มีบทบาทที่ดี

ความสัมพันธ์กับบริษัทแบ่งเป็นดีชั่วแบบตายตัวได้ยาก

  • เช่นเดียวกับที่การแบ่งคนเป็นคนดีและคนเลวแบบตายตัวไม่ค่อยมีประโยชน์ บริษัทก็ยากจะแบ่งถาวรเป็นบริษัทดีหรือบริษัทเลว
  • บริษัทมีคุณสมบัติคล้ายมนุษย์ตรงที่มีสติปัญญา บุคลิกภาพ การถือกำเนิด การเติบโต การดับสูญ และสถานะนิติบุคคล
  • เช่นเดียวกับที่เราอยู่ไม่ได้โดยไม่มีผู้คน ก็อยู่ไม่ได้โดยไม่มีบริษัท และแม้จะมีลักษณะที่ไม่ใช่มนุษย์ รูปแบบเชิงแฟร็กทัลขององค์กรมนุษย์ก็ยังคงดำรงอยู่
  • หากไม่จัดบริษัทไว้ในหมวดดีชั่วแบบตายตัว ก็จะสร้างความสัมพันธ์ได้อย่างยืดหยุ่นมากขึ้น
    • เมื่อบริษัทผลักเราเข้าไปในเกมผลรวมศูนย์ ก็ลดระดับการพึ่งพา
    • เมื่อบริษัทเปิดให้มีความสัมพันธ์แบบเกื้อกูลกันมากขึ้น ก็กลับเข้าไปมีส่วนร่วม
  • Steve Jobs กล่าวไว้ในปี 1996 ว่าบริษัทขนาดใหญ่ กลาง และเล็ก ต่างเริ่มมองเว็บเป็นช่องทางกระจายสินค้าสู่ลูกค้าโดยตรงขั้นสุดท้าย และเป็นเส้นทางจากผู้จัดหาไปยังผู้บริโภคโดยตรงโดยข้ามคนกลาง

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

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

 
GN⁺ 2024-02-05
ความเห็นจาก Hacker News

  • ตอนแรกตัดสินใจว่าจะไม่เรียน การพัฒนาแอปมือถือแบบเนทีฟ และทุ่มเวลาที่มีจำกัดทั้งหมดไปกับเว็บ ซึ่งมองว่าครั้งนี้เป็นการตัดสินใจที่ถูกต้อง
    ตอนนี้เราสร้างสิ่งน่าทึ่งบนเบราว์เซอร์ได้ และในความเห็นส่วนตัวมาก ๆ นอกจาก Uber, Google Drive และเกมแล้ว แอปส่วนใหญ่น่าจะควรเป็น เว็บแอป
    ฉันเคยทำงานในวงการสื่อ ซึ่งช่วงต้นทศวรรษ 2010 ในประเทศของเราคือยุคที่สำนักข่าวซึ่งแทบไม่มีเงินต่างทุ่มงบไปกับการทำแอปมือถือ และฉันเป็นคนแหกคอกที่ปฏิเสธกระแสนั้น
    ฉันรู้อยู่แล้วว่าแอปส่วนใหญ่คงไม่มีคุณภาพดี และบริษัทต่าง ๆ ก็จะไม่อัปเดตฝั่งมือถืออย่างต่อเนื่อง ซึ่งสุดท้ายก็เป็นแบบนั้นจริง ๆ
    ตอนนี้เราถูกขังอยู่กับแอปที่แทบไม่ได้รับการบำรุงรักษา และส่วนใหญ่ก็ดูเหมือนซากจากยุคที่ผ่านมา ซึ่งจริง ๆ ก็เป็นแบบนั้นแหละ

    • เข้าใจได้ว่า Google Drive ทำงานได้ดีกว่าบนแอปเนทีฟ เพราะต้องให้ ระบบไฟล์เสมือน กับระบบปฏิบัติการ และต้องทำพวกการซิงก์เบื้องหลัง
      แต่ไม่เข้าใจว่าทำไมถึงเป็น Uber Uber มีหรือเคยมีเว็บไซต์มือถือที่รองรับการเรียกรถและแทบทุกอย่างที่แอปทำได้ดีอยู่แล้ว และมองไม่ค่อยออกว่าแอปเนทีฟเพิ่มคุณค่าอะไรให้ผู้ใช้
      เกมมือถือส่วนใหญ่ก็เหมือนกัน มักเป็นกราฟิกเรียบง่ายที่เบราว์เซอร์เรนเดอร์ได้แรงพออยู่แล้ว และหลายครั้งก็ทำคอมโพเนนต์ UI ทั่วไปขึ้นมาใหม่เอง ดังนั้นการใช้ปุ่มระบบแบบเนทีฟไม่ได้ก็แทบไม่ต่างมาก
      PWA ก็ให้พื้นที่เก็บข้อมูลเพียงพอสำหรับไฟล์ในเครื่องและข้อมูลเกมได้เช่นกัน แน่นอนว่าเกมที่รีดขีดจำกัดของระบบเป็นข้อยกเว้น
      ฉันไม่ได้คาดหวังว่าเกมอย่าง Death Stranding หรือ RE4 รีเมกจะรันได้ดีโดยไม่เข้าถึงการเร่งกราฟิกแบบเนทีฟโดยตรง และมันก็ใหญ่เกินกว่าจะโหลดเป็นเว็บหน้าเดียว
      แต่แอปมือถือส่วนใหญ่ รวมถึงเกมเล่นฟรีทำเงินสูงที่ถ้าไปอยู่บนเว็บก็เก็บรายได้เพิ่มได้อีก 30% ไม่ได้อยู่ในกลุ่มนั้น
      แล้วทำไมถึงไม่ทำเว็บเป็นเป้าหมายล่ะ? โดยสัญชาตญาณแล้ว ผู้ใช้มือถือถูกฝึกให้หาแอปและเกมจากแอปสโตร์ ขณะที่ผู้ใช้เดสก์ท็อปคาดหวังว่าแอปจะให้บริการผ่านเบราว์เซอร์ ยกเว้นเครื่องมือเฉพาะทางบางอย่างและเกมสเปกสูง
      สุดท้ายแล้วส่วนใหญ่เป็น ปัญหาทางวัฒนธรรม และการรองรับ PWA ที่ไม่ดีของ Apple ก็ไม่ได้ช่วยอะไร
    • อยากให้ประสบการณ์การพัฒนาเว็บไม่อึดอัดแบบนี้ แม้ 10 ปีที่ผ่านมาจะดีขึ้นมาก แต่ก็ยังรู้สึกว่าไม่ลงตัวเท่าสภาพแวดล้อมการพัฒนาแบบเนทีฟ
      ความอึดอัดส่วนใหญ่มาจากเครื่องมือ โดยเฉพาะ TypeScript อธิบายสั้น ๆ ยาก แต่ฉันต้องไปปล้ำกับระบบ type ของ TypeScript มากกว่าฝั่งเนทีฟเยอะมาก
    • โดยเฉพาะ PWA ที่สร้างแบบ offline-first ทุกวันนี้ใกล้เคียงประสบการณ์แบบเนทีฟมากกว่าเมื่อ 5 ปีก่อนมาก
      เพียงแต่กังวลว่า Google กับ Apple จะมีแรงจูงใจให้ช่วยพัฒนา PWA จนแข่งขันกับแอปเนทีฟได้จริงหรือไม่ เพราะถ้าไปถึงจุดนั้นก็อาจกระทบรายได้ของพวกเขา
    • ทำไมต้องเอาเวลาไปลงกับเทคโนโลยีกระแสที่เปลี่ยนทุกเดือน?
      เอาเวลาไปลงทุนกับ องค์ประกอบพื้นฐาน ของเทคโนโลยีน่าจะดีกว่า
    • เหนื่อยมากกับการที่โทรศัพท์และแท็บเล็ตเต็มไปด้วยแอปจุกจิก สถานีจอดรถใกล้บ้านก็มีแอป เครื่องถ่ายเอกสารในห้องสมุดก็มีแอป
      ทั้งหมดนี้ทำผ่านเว็บได้ทั้งนั้น

  • เหตุผลที่ Apple ไม่ใส่ใจนักพัฒนาก็เพราะอย่างที่เจ้าตัวอธิบายไว้ พวกเขาสร้างฐานผู้ใช้ที่เกือบเป็นลัทธิแบบ สวนปิด เอาไว้แล้ว
    ถ้านักพัฒนาไม่ทำผลิตภัณฑ์ลงแพลตฟอร์มนั้น ก็จะเสียตลาดไปครึ่งหนึ่งหรือมากกว่านั้น
    ในงานหลักของฉันที่ทำเกมมือถืออยู่ในสตูดิโอเล็ก ๆ ภายใต้บริษัทยักษ์ใหญ่ เราต้องสู้กับ Apple ตลอด ไม่ใช่แค่เรื่องเทคนิค แต่รวมถึงนโยบายและการอนุมัติด้วย
    แต่ก็ยากจะจินตนาการถึงการออกเกมมือถือที่เล่นบน iOS ไม่ได้ เลยจำเป็นต้องทำตาม
    ในหลายด้าน กลยุทธ์พีซียุคดั้งเดิมของ Microsoft เป็นภาพตรงกันข้ามอย่างสิ้นเชิง พวกเขาดูแลนักพัฒนาและให้ทั้งเอกสาร ตัวอย่าง และเครื่องมือจำนวนมหาศาล
    บริษัทที่มีนักพัฒนาเหล่านั้นอยู่ก็มีแรงจูงใจที่จะสร้าง โปรโมต และขายซอฟต์แวร์สำหรับ Microsoft และคลื่นของนักพัฒนาอิสระที่ปล่อยซอฟต์แวร์ Windows จำนวนมาก ก็ทำให้เกิดระบบปฏิบัติการเดสก์ท็อปที่ครองตลาดมาจนถึงทุกวันนี้

    • ฉันเขียนซอฟต์แวร์เป็นอาชีพมา 15 ปี แต่ไม่เคยเขียน โค้ดสำหรับอุปกรณ์ Apple แม้แต่บรรทัดเดียว และต่อไปก็จะไม่ทำ
      การมีส่วนร่วมกับระบบนิเวศของ Apple เป็นทางเลือก ไม่ใช่การบังคับ นักพัฒนาที่มีส่วนร่วมกับระบบนิเวศของ Apple ก็กำลังมีส่วนร่วมกับสภาพที่เป็นอยู่ในตอนนี้อย่างแข็งขัน
    • มองว่าเป็นเพราะ Apple คือ บริษัทฮาร์ดแวร์ และใช้ซอฟต์แวร์เพื่อดึงดูดผู้บริโภค ขณะที่ Microsoft คือ บริษัทซอฟต์แวร์ และใช้ฮาร์ดแวร์เพื่อดึงดูดผู้บริโภค
    • Apple ไม่ได้บังคับให้นักพัฒนาต้องทำอะไร นักพัฒนาทำแอปลงแพลตฟอร์มนั้นเพราะผู้บริโภคอยากใช้เงินที่นั่น
      Apple ทำสิ่งนี้ได้ด้วยการปฏิบัติกับนักพัฒนาอย่างไม่ค่อยดี หรือให้แม่นกว่านั้นคือไม่ยอมให้นักพัฒนาปฏิบัติกับลูกค้าอย่างไม่ค่อยดี
      มันคล้ายกับวิธีที่กดดันซัพพลายเออร์อย่างหนัก แต่สุดท้ายก็เกิดระบบนิเวศที่แข็งแรงและมั่งคั่ง และนักพัฒนากับซัพพลายเออร์ก็ยังคงส่งแอปเข้าไปอยู่ดี
    • เรื่องนี้ให้ความรู้สึกต่างจากสถานการณ์ที่ผู้เขียนพูดถึงอยู่พอสมควร ผู้เขียนดูเหมือนจะมองว่ามือถือเป็นเพียงหนึ่งในหลายช่องทางเข้าถึง และมุ่งเน้นไปที่บริการที่มีความหมายไม่ว่าอยู่ในบริบทไหน
      เช่นโซเชียลเน็ตเวิร์ก แอปหาคู่ Reddit และ Stack Overflow ไม่ใช่บริการที่พึ่งพาประสบการณ์บนมือถืออย่าง Uber ที่ต้องติดตามตำแหน่ง หรือเกมมือถือที่ออกแบบมาให้เล่นระหว่างเดินทาง
      ถ้าธุรกิจไม่ได้พึ่งพาประสบการณ์บนมือถือ ก็สามารถให้บริการได้โดยไม่มีแอปเนทีฟ
      ผู้ใช้มือถือก็ยังเข้าผ่านเบราว์เซอร์มือถือได้ และแม้อาจไม่ใช่ประสบการณ์ในอุดมคติ แต่ก็ยังเป็นทางเลือก
      ประเด็นสำคัญคือ ถ้าแพลตฟอร์มมือถือไม่ใช่สิ่งจำเป็นหรือไม่ได้เป็นสิ่งที่ธุรกิจพึ่งพา ก็ไม่ควรสร้างสำหรับแพลตฟอร์มนั้น
    • สงสัยว่า Apple เคยสกัดกั้นอะไรบ้างในฝั่งเกมมือถือ

  • เมื่อหลายปีก่อนฉันเคยพยายามเรียนรู้ Swift และการพัฒนา iOS แบบเนทีฟอย่างจริงจัง แต่สุดท้ายก็ไม่อาจคุ้นเคยกับการใช้ Xcode ได้เลย
    UI/UX ของ Xcode แย่มากจนแทบหาคำบรรยายไม่ได้ และต้องคอยเปิดปิดพาเนลอยู่ตลอดเพื่อกดไอคอนที่ไม่ได้จัดกลุ่มอย่างเป็นธรรมชาติ
    พอเปิดพาเนลหนึ่ง อีกพาเนลก็มักถูกย่อโดยบังคับ และรู้สึกเหมือนหนึ่งในสิบของเวลาทั้งหมดหมดไปกับการ “ขับพาเนล”
    ดูเหมือนว่านักออกแบบของ Apple อยากสร้าง IDE ที่สวย มินิมอล มากกว่า IDE ที่ทำให้นักพัฒนาทำงานได้ลื่นไหลโดยมีแรงเสียดทานต่ำ
    แต่ IDE ไม่จำเป็นต้องมินิมอล และควรปล่อยให้นักพัฒนาแต่ละคนปรับแต่งหรือจัดวางให้รกได้เท่าที่ต้องการตามสิ่งที่กำลังสร้าง
    ถ้าลองนึกถึงโต๊ะทำงานในโรงรถจริง ๆ Visual Studio จะให้คุณทำพื้นที่ทำงานให้รกและปรับแต่งได้ตามใจ แต่ Apple ให้ความรู้สึกเหมือนบังคับให้เก็บเครื่องมือชิ้นก่อนหน้าใส่กล่องทุกครั้งก่อนจะหยิบชิ้นถัดไป
    นี่แหละคือความหมายของคำว่า “ขับพาเนล” ที่ฉันพูดถึง และก็สงสัยว่านักพัฒนาคนอื่นรู้สึกแบบนี้เหมือนกันไหม

    • คำอธิบายนี้โดนใจมาก และเหตุผลที่ฉันพยายามเริ่มพัฒนา Mac/iOS แบบเนทีฟหลายครั้งแล้วเลิกไป ก็เพราะ IDE นี่แหละ
      คำว่าให้ความสำคัญกับรูปลักษณ์มากกว่าการใช้งาน ช่วยให้ฉันอธิบายได้เสียทีว่าฉันไม่ชอบอะไรใน Xcode
      ฉันอยู่ใน ecosystem ของ JetBrains มานานกว่าสิบปี มันก็มีข้อเสียอยู่บ้าง แต่ไม่เคยรู้สึกเลยว่า JetBrains ไม่พยายามทำให้ IDE ทำงานในแบบที่ฉันต้องการ
    • เห็นด้วยว่า การใช้งานของ Xcode แย่มาก ทั้งช้าจนน่าเหลือเชื่อและแครชบ่อยเกินไป จนถ้าเป็นการรีวิวบน App Store ก็คงไม่ผ่าน
      แต่สิ่งที่ทำให้ฉันถอยห่างจากการพัฒนาแอปเนทีฟบนแพลตฟอร์ม Apple จริง ๆ คือการผสมกันของบั๊กกับเอกสารที่ไม่เพียงพอ
      ตอนที่ใช้ครั้งล่าสุดเมื่อปีก่อน SwiftUI ยังไม่อยู่ในสภาพที่เหมาะกับจุดประสงค์ และแม้แต่ไลบรารีที่โตเต็มที่กว่าก็มักมีเอกสารน้อยมาก
      ยังยากเลยที่จะรู้ว่าอะไรถูกเลิกใช้ไปแล้ว
      สำหรับงานของฉัน ข้อดีของแอปเนทีฟจากมุมผู้ใช้เดิมทีก็มีน้อยอยู่แล้ว ส่วนใหญ่ก็แค่ที่เก็บข้อมูลภายในเครื่องที่เสถียรกว่า
      ถ้าประสิทธิภาพการผลิตต่ำกว่าการทำเว็บแอปมาก ก็ยากจะหาเหตุผลมารองรับต้นทุนและความเสี่ยงเพิ่มเติมจากการต้องพึ่งความเมตตาของผู้ผูกขาดดั่งเจ้าผู้ครองอาณาจักร
    • ฉันคิดว่ามันขึ้นอยู่กับสไตล์การพัฒนาและสภาพแวดล้อมที่คุ้นเคยพอสมควร
      Xcode ไม่ได้กวนใจฉันเลย แต่ Android Studio ที่สร้างบน IntelliJ ซึ่งใคร ๆ ก็ชื่นชม กลับทำให้หงุดหงิดอยู่เรื่อย
      Visual Studio ก็คล้ายกัน คืออึดอัดและมีข้อจำกัดแปลก ๆ เช่นฉันไม่เข้าใจว่าทำไมถึงใช้ตัวเอียงกับการเน้นไวยากรณ์ไม่ได้
      ตัวแก้ไขข้อความก็เหมือนกัน VS Code มีจุดเล็ก ๆ ที่น่ารำคาญต่างจาก Sublime Text หรือ TextMate
    • เห็นด้วย ทุกครั้งที่พยายามหาอะไรอย่าง Build Output หรือ Project Settings ที่ใน IDE อื่นหาได้ง่าย ฉันมักหลงทางได้อย่างง่ายดาย และต้องไปค้น Google ว่าจะเปิดพาเนลนั้นอย่างไร
    • สำหรับฉัน Xcode ทั้งยอดเยี่ยมและแย่มากในเวลาเดียวกัน ตอนอยู่ใน VS Code จะคิดถึงมัน แต่พออยู่ใน Xcode กลับเกลียดมันเอง ไม่รู้ว่าฟังดูสมเหตุสมผลไหม
      มันให้ความรู้สึกเหมือน IDE หนัก ๆ แบบสมัยก่อน ยิ่งยอมทำตามแนวทางของมันก็ยิ่งใช้ง่ายขึ้น แต่ขณะเดียวกันก็ยังรู้สึกว่าฉันไม่ได้เป็นฝ่ายควบคุม
      ถ้า Apple ใส่ใจจริง ๆ ก็น่าจะทำให้มันลื่นขึ้นได้อย่างน้อยสักครึ่งหนึ่งของ VS Code ต่อให้ไม่ถึงระดับเดียวกันก็ตาม ซึ่งก็คงดีกว่าตอนนี้มาก
      แค่การรองรับปุ่มลัดแบบ Vim ที่แย่มากก็ทำให้ฉันหงุดหงิดแล้ว เช่นแทบจะสั่งทำซ้ำการกระทำส่วนใหญ่ อย่าง c หรือ r ไม่ได้
      ฉันไม่แน่ใจว่าตอนนั้นคุณใช้ SwiftUI หรือกำลังต่อสู้กับ storyboard ของ UIKit แต่แบบหลังนี่คือประสบการณ์ที่เลวร้ายที่สุดจนไม่อยากแนะนำให้แม้แต่ศัตรู
      SwiftUI ยังอยู่ในช่วงเริ่มต้นและยังต้องขัดเกลาอีกมาก แต่เมื่อเทียบกันแล้วมันยังให้ความรู้สึกเหมือนอนาคต

  • ครั้งหนึ่งเมื่อก่อน เราจำเป็นต้องตั้งค่า บัญชีนักพัฒนา Apple เพื่อแสดงว่าแอปหนึ่งของเทศบาลเรานั้นเป็นของเรา
    แอปอื่นไม่ต้องทำแบบนั้น ฉันก็ไม่รู้ว่าทำไม แต่ยังไงก็ต้องทำ และมันเป็นประสบการณ์ที่ค่อนข้างแย่มาก
    ก่อนอื่นต้องมีบัญชี Apple และเพราะไม่อยากใช้บัญชีส่วนตัว ฉันเลยต้องสร้างบัญชีสำหรับงานขึ้นมาใหม่
    ไม่สามารถสร้าง “บัญชีองค์กร” ได้ เลยถูกผูกกับตัวฉันในฐานะบุคคล และโชคดีที่มี iPhone เก่าที่กำลังจะปลดระวางอยู่เครื่องหนึ่งเลยใช้เครื่องนั้นได้
    จากนั้นก็ต้องรอหลายวันให้ Apple ตรวจสอบตัวตนของฉัน ซึ่งในทางปฏิบัติก็คือ Apple โทรหาคนที่ฉันระบุว่าเป็นหัวหน้า แล้วให้คนนั้นยืนยันว่าฉันเป็นฉันจริง
    ฉันอยากเชื่อว่าพวกเขาตรวจสอบอย่างอื่นมากกว่านั้น แต่ก็ไม่มั่นใจ และคนที่โทรมาก็พูดอังกฤษได้แย่กว่าเราเสียอีก อย่างน้อยก็เลยออกแนวขำ ๆ
    ต่อมาก็ต้องตั้งค่าการชำระเงิน ซึ่งไม่รู้เหมือนกันว่าทำไมการมีบัญชีนักพัฒนา Apple ถึงต้องเสียเงิน
    สำหรับงบรวมของเมืองที่มีประชากร 60,000 คน มันอาจเป็นเงินที่แทบมองไม่เห็น แต่เพราะเป็นค่าสมัครจากต่างประเทศ และ Apple ก็ไม่มีวิธีจัดการให้เป็นการซื้อแบบ B2B ที่ลงทะเบียนกับหน่วยงานภาษีท้องถิ่นได้ง่าย จึงถูกหยิบขึ้นมาทบทวนทุกปี
    การจ่ายเงินก็ทำได้ด้วยบัตรเครดิตเท่านั้น และบัตรองค์กรก็ยังผูกกับบุคคลจริงอยู่ดี จึงต้องมีคนรับผิดชอบเรื่องการต่ออายุ
    คนเราก็ย้ายงานกันได้ และถ้าจะเปลี่ยนเจ้าของก็ต้องให้ Apple ติดต่อกับคนจริง ๆ โดยตรง คุณคงเดาได้ว่ามัน “สนุก” แค่ไหน
    แม้จะเป็นเรื่องเมื่อหลายปีก่อนและอาจเปลี่ยนไปแล้ว แต่จากโซลูชัน IT สำหรับองค์กรกว่า 300 รายการที่ฉันเคยแตะต้องมา ก็ไม่มีอะไรแย่เท่า Apple อีกแล้ว
    เพื่อความเป็นธรรม ฉันเป็นนักพัฒนา เลยไม่รู้เหมือนกันว่าทำไมถึงได้มาทำเรื่องนี้ และในฝั่ง IT operations เรื่องแบบนี้อาจปกติกว่านี้ก็ได้

    • ตอนนี้น่าจะยิ่งแย่ลงด้วยซ้ำ พวกเขายังคงเพิ่ม อุปสรรค เพื่อกันไม่ให้คนเผยแพร่แอปลงใน “ecosystem” ของตัวเองได้
      ยกเว้นเสียแต่ว่าคุณเป็นบริษัทยักษ์ใหญ่ในสหรัฐฯ ที่จัดการงานเอกสารพวกนี้ได้ง่าย
    • ตอนนี้ก็ยังเหมือนเดิม ตอนตั้งค่าบัญชีนักพัฒนา ฉันติดลูป error บน iPhone แล้วทีมซัพพอร์ตก็ไม่เข้าใจว่าเกิดอะไรขึ้น ก่อนที่อยู่ ๆ มันจะใช้ได้เองหลังผ่านไปราว 6 เดือน
      มันยังคงสุ่มอยู่ อาจผ่านได้ทันที หรือถ้าดวงซวยไปเจอบั๊กสุ่มในกระบวนการนี้ ก็อาจล้มเหลวอยู่เป็นเวลานาน
    • เท่าที่รู้ หน่วยงานรัฐและองค์กรไม่แสวงหากำไรสามารถขอยกเว้นค่าธรรมเนียมสมาชิก $99 Developer Program ได้
      ไม่แน่ใจว่าเริ่มเมื่อไร แต่ไม่ใช่เรื่องที่เพิ่งเกิดขึ้นไม่นานนี้
    • ถ้าทำตอนนี้ ในมุมของการจัดซื้อสำหรับองค์กรอาจง่ายขึ้นมาก ทุกวันนี้มักออก หมายเลขบัตรเสมือน แบบใช้ครั้งเดียวแยกตามบริการกันบ่อย

  • บางครั้งก็ลืมไปว่าเดิมทีเว็บ/www เปิดกว้างแค่ไหน และเมื่อเทียบกับ “ระบบนิเวศของแอป” ที่ Apple และ Google ผูกขาดอยู่ในตอนนี้ มันยังเปิดกว้างกว่ามากโดยรวม
    แน่นอนว่ามี “คลาวด์” อยู่ แต่ก็ไม่มีอะไรขวางไม่ให้คุณเช่าเซิร์ฟเวอร์แล้วโฮสต์ของของตัวเองโดยตรง
    ถ้ามันไม่เวิร์ก ก็ย้ายออกแล้วไปเช่าเซิร์ฟเวอร์อื่นได้
    มันอาจมีผลของการล็อกอินและอาจไม่ง่าย แต่ก็ไม่ใช่ว่าเป็นไปไม่ได้
    แต่ถ้ามองทั้งระบบนิเวศของแอป ทางเลือกมีแค่ 2 ทาง และพูดตามตรงก็ขึ้นอยู่กับความเมตตาของพวกเขา
    สำหรับผมคงไม่มีวันเอาธุรกิจทั้งหมดไปฝากไว้กับ “แอป” เพียงตัวเดียวแน่ ๆ
    ถ้าผู้ใช้ต้องการจริง ๆ ก็อาจมีแอปเป็นช่องทางเสริมเล็ก ๆ ได้ แต่ก็แค่นั้น
    ผมไม่ชอบสินค้าที่บังคับให้ต้องใช้แอปบนอุปกรณ์พกพา
    แบบ m.website.com กลับมาจะดีกว่า และผมอยากเลี่ยงทั้งระบบนิเวศของแอปไปเลย

    • ถ้า 2 เจ้านั้นคือสิ่งที่ผมกำลังนึกถึง หนึ่งในนั้นก็คือที่ที่ถือค้อนเนรเทศไปสู่ หลุมดำฝ่ายบริการลูกค้า
      คุณอาจตกอยู่ในสภาพที่ต้อง “ไปอ้อนวอนขอความช่วยเหลือบนหน้าแรกของ HN” ข้ามคืน ด้วยเหตุผลใดก็ตามหรือไม่มีเหตุผลเลยก็ได้
      ผมหวังว่ากระแส sideloading ใหม่ของ EU จะจุดให้เกิดข้อเรียกร้องแบบเดียวกันในสหรัฐฯ ด้วย แต่ก็รู้ดีเหมือนกันว่ามันจะเกิดขึ้นได้ก็ต่อเมื่อมีคนจำนวนมากพอที่รู้และสนใจว่าคำว่า “สวนปิด” หรือ “sideloading” หมายถึงอะไร

  • เว็บนั้นยอดเยี่ยมในทางทฤษฎี แต่สภาพแวดล้อมของเบราว์เซอร์ให้มาแค่ ขั้นต่ำพื้นฐาน เลยไม่ค่อยน่าดึงดูดในฐานะแพลตฟอร์มแอป ถ้าคุณคุ้นกับประสบการณ์พัฒนาแบบรวมทุกอย่างพร้อมใช้เหมือนบนแพลตฟอร์มของ Apple
    บน macOS คุณสามารถพัฒนาแอปที่ทรงพลังและขัดเกลาอย่างดีได้ โดยมี dependency และ subdependency แค่นับนิ้วได้ หรือถ้าพยายามหน่อยก็อาจไม่ต้องมีเลย
    แต่เว็บแอปที่เทียบกันได้กลับมี dependency เป็นหลักสิบถึงหลักร้อยเพื่ออุดช่องว่างของฟีเจอร์
    ตัวอย่างเช่น ผมไม่เห็นเหตุผลเลยว่าทำไมเบราว์เซอร์ถึงไม่ควรมี list/table view พื้นฐานที่รีไซเคิลเซลล์ได้อย่างมีประสิทธิภาพ โดยไม่ต้องใช้ JavaScript เลยหรือใช้น้อยมาก
    งานที่ต้องเลื่อนดูรายการหลักร้อยถึงหลักพันโดยไม่ให้เครื่องกระตุกหรือหน่วยความจำหมด ไม่ใช่เรื่องแปลกอะไร
    AppKit, UIKit, SwiftUI, Android Framework, Compose และน่าจะรวมถึง Flutter ก็จัดการเรื่องนี้ได้ดีเป็นพื้นฐานอยู่แล้ว แต่บนเบราว์เซอร์กลับต้องดึงไลบรารีเข้ามาหรือเขียนโค้ดเองเพียงเพื่อฟีเจอร์พื้นฐานมาก ๆ แบบนี้
    พอรวมเรื่องการจัดการแพ็กเกจและปัญหาเครื่องมือโดยรวมเข้าไปด้วย ปัญหารากเดิมก็ยังคงอยู่แบบดื้อด้าน แม้โซลูชันจะผลัดกันมาแล้วก็ไป

    • ผมรู้สึกว่าประสบการณ์การพัฒนาด้วย Electron ดีกว่าการพัฒนาสำหรับ Apple UI มาก
      ผมก็เคยทำแอป iOS/iPad มาพอสมควรตั้งแต่ 15 ปีก่อน
      ข้อดีของเว็บคือมักจะมีไลบรารีหรือเฟรมเวิร์กที่ตรงกับความต้องการอยู่แล้ว เช่น Electron
      ฝั่ง Apple มักไม่มีไลบรารีดี ๆ และ SwiftUI ก็มีบั๊กเยอะเกินไป
      React แค่ใช้งานได้ดี และในเชิงแนวคิดก็เรียบง่ายกว่า การทำ data binding สองทางเป็นความคิดที่ไม่ดี
      Apple ดูเหมือนจะเชื่อว่าตัวเองกำลังทำให้ทุกอย่างง่ายขึ้น แต่ในความเป็นจริงบ่อยครั้งกลับทำให้ยุ่งยากและยากขึ้น
    • เว็บถูกสร้างขึ้นมาโดยคิดถึงเอกสารเป็นหลัก จึงตั้งอยู่บนสมมติฐานว่าในไฟล์ HTML มีข้อมูลทั้งหมดที่ต้องแสดงอยู่แล้ว
      ตารางถูกเติมข้อมูลที่ต้องใช้และเรียงลำดับที่ถูกต้องมาจากเซิร์ฟเวอร์เรียบร้อยแล้ว
      ดังนั้นจึงไม่จำเป็นต้องรีไซเคิลเซลล์และแถว และถึงจะมีหลายพันแถว ข้อมูลก็มีขนาดแค่ระดับ KB เลยทำงานได้ลื่น
    • Flutter มีเอนจินเรนเดอร์ของตัวเอง จึงมี API พื้นฐานที่ค่อนข้างแข็งแรง
      เมื่อพิจารณาทางเลือกอย่าง WebAssembly และ Flutter ด้วยแล้ว การที่เบราว์เซอร์มีความสามารถพื้นฐานไม่พอไม่น่าจะเป็นปัญหาอีกต่อไป
    • ผมไม่เข้าใจว่า JavaScript มีปัญหาอะไร

  • ผมไม่คิดว่าคำพูดที่ว่านักพัฒนาไม่ได้ทำอะไรให้ Apple เลยจะเป็นเรื่องจริง
    ถ้าไม่มีแอปจาก third-party บน iPhone Apple ก็คงขายโทรศัพท์ได้น้อยกว่านี้มาก
    ในทางทฤษฎี แอปจำนวนมากอาจย้ายไปอยู่บนเว็บได้ แต่ถึงอย่างนั้นแอปจาก third-party ก็ยังทำให้ iPhone น่าครอบครองมากขึ้นอย่างชัดเจน
    ถ้ามีการแข่งขันที่แท้จริง ผู้ผลิตระบบปฏิบัติการก็จะพยายามอย่างหนักเพื่อดึงดูดนักพัฒนา ลองนึกถึงวิดีโอ “developers developers developers” ของ Ballmer ในอดีตก็ได้
    เพราะพวกเขารู้ว่านักพัฒนาเพิ่มคุณค่าให้แพลตฟอร์มและมีอิทธิพลต่อการเลือกของผู้บริโภค
    ปัญหาในทุกวันนี้คือไม่มีการแข่งขันที่มีความหมาย
    ไม่ว่ากฎของ Apple จะเป็นอย่างไร นักพัฒนาก็ต้องมีอะไรสักอย่างสำหรับ iPhone และ Apple ก็วางใจได้ว่าแทบไม่มีโอกาสที่แพลตฟอร์มมือถือรายที่สามจะตั้งหลักได้
    Apple รู้เรื่องนี้ และก็พลิกสถานการณ์อย่างโหดร้ายด้วยนโยบายที่เข้มงวด
    ทั้งที่นักพัฒนามีบทบาทอย่างมากในการทำให้ iPhone น่าครอบครอง Apple กลับเก็บภาษีจากรายได้ทั้งหมด โดยทำเหมือนว่าตัวเองกำลังมีพระคุณที่อนุญาตให้พวกเขาเข้าถึงลูกค้า iPhone ได้
    นี่คือ การใช้อำนาจเหนือตลาดในทางที่ผิด และอย่างที่บล็อกนั้นบอกไว้ สิ่งที่พอจะทำได้มีไม่มากนอกจากแจกจ่ายผ่านเว็บ
    มันไม่สมบูรณ์แบบ แต่ถ้าไม่นับการกำกับดูแล ก็แทบไม่มีทางเลือกอื่นที่มีความหมาย และ Apple ก็ไม่มีเหตุผลจะยอมปล่อยรายได้หลายพันล้านดอลลาร์จากการเก็บภาษีนักพัฒนาแอปไปเอง จึงจะใช้ทุกวิถีทางเพื่อหลีกเลี่ยงการกำกับดูแล
    ผมหวังว่าเว็บจะมีพลังมากขึ้นในฐานะวิธีหลีกเลี่ยงกฎการแจกจ่ายแอปที่เอาเปรียบ

  • ทุกวันผมคิดถึงว่าเว็บยอดเยี่ยมแค่ไหน และน่าเสียดายเพียงใดที่ Apple พยายามทำลายเว็บให้ได้มากที่สุดเท่าที่จะทำได้ โดยผลักให้นักพัฒนาสร้างแอป iOS แทนเว็บแอป
    ถ้าไม่มี App Store เว็บคงดีกว่านี้มาก
    คงมีความหลากหลายมากกว่านี้ทั้งในการเสพคอนเทนต์ แหล่งที่มาของโซเชียลมีเดีย คำแนะนำจากอัลกอริทึม และประสบการณ์ดิจิทัล
    เว็บทำงานได้ทุกที่ และยังมี API ที่ยอดเยี่ยมมากมายสำหรับสร้างแอปแบบ immersive/next-gen อย่าง WebXR
    แต่ถ้ามีคนสร้าง แอป WebXR บนเว็บไซต์ของตัวเองแล้วขายแบบเสียเงิน Apple ก็ไม่ได้อะไรจากมัน ดังนั้น Apple จึงไม่มีวันโปรโมตเว็บแอปแบบนี้
    ในระยะยาว เว็บจะไม่ตาย บริษัทต่าง ๆ เข้ามา ตักตวงผลประโยชน์ แล้วก็จากไป แต่เว็บจะไม่ตาย

  • Apple มี API หลายพันตัวที่ช่วยให้พัฒนาแพลตฟอร์มได้ง่ายขึ้น สร้างภาษาการเขียนโปรแกรมของตัวเองที่ผสานกับแพลตฟอร์มได้ดี และยังมี IDE แบบบูรณาการเต็มรูปแบบที่ทำงานร่วมกับทั้งสองอย่างนั้นด้วย
    ใช่แล้ว “เพื่อน” พวกเขาไม่สนใจคุณหรอก เว้นแต่ว่าคุณจะพัฒนาเพื่อแพลตฟอร์มของพวกเขา
    แล้วจะไปโทษใครได้ล่ะ? สิ่งที่กล่าวมาข้างต้นล้วนเป็นการลงทุนที่แพงมากและใช้เวลานาน

    • ยังขาดประเด็นที่ว่าพวกเขาล็อกทุกอย่างที่ไม่ใช่เครื่องมือเหล่านั้นไว้
      ฉันเคยพยายามพัฒนาแอปบน macOS โดยไม่ใช้ Swift และเครื่องมือของ Apple แล้ว มันทรมานมาก
      พวกเขาเลิกใช้และตรึงเวอร์ชัน OpenGL แบบที่แทบอธิบายอย่างอื่นไม่ได้นอกจากต้องการดันเครื่องมือของตัวเอง
      แค่จะโหลด external DLL สักตัวก็แทบเป็นไปไม่ได้
      อะไรก็ตามที่เป็น cross-platform ต้องถูกดึงลงมาอยู่ในระบบเครื่องมือของ Apple เช่นการแปลง Vulkan เป็น Metal
      macOS เป็นกรณีที่แปลกและเฉพาะทางยิ่งกว่าดิสโทร Linux ทั้งหมดเสียอีก
      พอเห็นว่า Windows พัฒนาง่ายแค่ไหนแล้วก็น่าประหลาดใจ ฝั่ง Microsoft แทบทั้งหมดเป็น cross-platform
      ในสิ่งที่พูดถึงเกี่ยวกับ Apple ไม่มีอะไรที่ช่วยให้ทำงานแบบไม่ยึดติดกับแพลตฟอร์มได้เลย
      ตรงกันข้าม Windows แม้จะรองรับเทคโนโลยีของตัวเองอย่าง DirectX แต่ก็ยังยอมให้รัน Vulkan, OpenGL ฯลฯ ได้โดยตรง
    • ฉันเองก็มองการพัฒนาบน Apple ในแง่ค่อนข้างบวกและก็ชอบ Xcode อย่างน้อยก็ตั้งแต่มี SwiftUI ส่วน Interface Builder นั้นฉันไม่มีทางใช้จนคล่องได้เลย
      แต่การที่ผู้เขียนเข้าไปทำงานกับแอปเพลงนี่มีนัยสำคัญ API ด้านเสียงของ Apple นั้นยุ่งเหยิงสุดๆ
      ทั้ง Media Player, AVPlayer, Core Audio, AVFoundation, AVAudioEngine และอีกมากมาย ดูเหมือนเป็นไลบรารีจากทีมที่แข่งกันเองซึ่งย้อนไปได้ถึงยุค NeXT และบังเอิญว่าทั้งหมดรอดมาถึงยุค iPhone
      ช่วงล็อกดาวน์ COVID ฉันใช้เวลาไปราวสามเดือนพยายามทำ Shoutcast/Icecast player แล้วมันทรมานจริงๆ
    • Apple ไม่ได้พัฒนา API พวกนั้นด้วยความหวังดี นี่คือ กลยุทธ์การล็อกผู้ใช้
      พวกเขาทำให้การเขียนโค้ด native แบบ cross-platform ที่รันบน iOS กลายเป็นสิ่งที่แทบเป็นไปไม่ได้ และทำทุกอย่างเท่าที่จะทำได้ภายใต้ข้อจำกัดทางการเมืองเพื่อไม่ให้เว็บแอปมาแข่งกับ native app ได้
    • ถ้าวัดกันตามเกณฑ์นั้น ฉันคงกังวลว่า Oracle จะชนะได้ง่ายๆ ในฐานะบริษัทที่ใส่ใจนักพัฒนามากที่สุด เพราะพวกเขาก็ลงทุนที่แพงมากและใช้เวลานานเหมือนกัน
    • ไม่เห็นจำเป็นต้องสร้างภาษาของตัวเองขึ้นมาเลย นั่นก็เป็นส่วนหนึ่งของ ผลของการล็อกอิน

  • ชอบท่าทีที่ผู้เขียนมีต่อบริษัทใหญ่แบบมีสุขภาวะดี นี่คือทักษะการเอาตัวรอดพื้นฐานในยุคนี้
    ถ้าเลือกได้เอง ฉันก็อยากไม่ต้องติดตั้งแอปอะไรเลยบน iPhone หรือ iPad แต่ข้อจำกัดของแพลตฟอร์มทำให้ในทางปฏิบัติมันจำเป็น
    ฉันเห็นเว็บแอป X/Twitter บน Safari เล่นวิดีโอไม่ได้ ทั้งที่ปิด Lockdown Mode สำหรับ X ไปแล้วก็ยังเป็นอยู่
    อยากรู้ว่านี่เป็นความผิดของ Apple ที่ทำให้แพลตฟอร์มไม่สอดคล้องกัน หรือเป็นความตั้งใจของ X ที่อยากบังคับให้ผู้ใช้ติดตั้งแอป
    ฉันเชี่ยวชาญด้าน deep learning และ LLM แต่ก็สนุกกับการพัฒนาเว็บมาโดยตลอด
    สิ่งที่ฉุดไว้คือเครื่องมือมันซับซ้อนเกินไป
    แต่ก็มีคนที่ฉันรู้จักเขียนถึง ClojureScript + Dart เยอะมาก เลยคิดว่าอาจจะลองดู
    อยากหาเว็บแอปสแตกที่เรียบง่าย เรียนได้ภายในไม่กี่วัน และมีการซัพพอร์ตที่ดี ถ้ามีคำแนะนำก็คงดี

    • ปกติควรมองข้ามโพสต์ที่ตามหา “สแตกที่สมบูรณ์แบบ” ไปได้เลย เพราะ สแตกที่สมบูรณ์แบบ ไม่มีอยู่จริง และก็ไม่ใช่สิ่งจำเป็นต่อการปล่อยซอฟต์แวร์ที่ยอดเยี่ยมซึ่งผู้ใช้จริงเห็นคุณค่า
      ส่วนสำคัญมากของการพัฒนาเว็บคือการรู้จักเบราว์เซอร์ให้ดี และ web.dev เป็นแหล่งข้อมูลที่ยอดเยี่ยม
      จากนั้นก็ไปเรียน React + TypeScript ได้เลย ส่วน react.dev เวอร์ชันใหม่ก็ทำได้ดี
      React ไม่ได้สมบูรณ์แบบ แต่ในฐานะกระบวนทัศน์สำหรับสร้าง UI มันดีมากเสียจน Apple ยังเอาไปเป็นแบบอย่างตอนสร้าง SwiftUI
      หยิบ Vite ขึ้นมาแล้วเริ่มเขียนโค้ดได้เลย
      สิ่งที่อยากแนะนำที่สุดคือศึกษาข้อมูลเหล่านั้นให้จริงจัง ต้องเริ่มจากหน้าแรกของเอกสารแล้วค่อยๆ ตามไปจนจบ
      แต่สิ่งที่เรียนได้ภายในไม่กี่วันนั้นมีไม่มาก งานฝั่งฟรอนต์เอนด์มันยากด้วยเหตุผลที่สมควรแล้ว