ทำไม code-base ในการพัฒนาระดับ n มีจำนวนเท่ากันถ้าไม่มากกว่านั้นโค้ด JavaScript ในตอนนี้?

ฉันทำโปรแกรมเว็บมานานแล้วและที่ไหนสักแห่งฉันก็ไม่รู้ว่าทำไมเราถึงทำสิ่งที่เราทำในวันนี้ (หรือเรามาทำสิ่งต่าง ๆ แบบนี้)?

ฉันเริ่มต้นด้วยการพัฒนาเว็บ ASP ขั้นพื้นฐานและในช่วงแรกตรรกะการแสดงผลและตรรกะทางธุรกิจได้ปะปนกันบนหน้าเว็บ การพัฒนาฝั่งไคลเอ็นต์มีความแตกต่างกันอย่างมาก (VBScript, รสชาติที่แตกต่างกันของ JavaScript) และเรามีคำเตือนมากมายเกี่ยวกับการตรวจสอบความถูกต้องของฝั่งเซิร์ฟเวอร์ (ดังนั้นฉันจึงอยู่ห่างจากตรรกะฝั่งไคลเอ็นต์)

จากนั้นฉันย้ายไปที่ ColdFusion ชั่วครู่หนึ่ง ColdFusion อาจเป็นกรอบการพัฒนาเว็บแรกที่แยกการแสดงผลและตรรกะทางธุรกิจโดยใช้แท็ก ดูเหมือนจะชัดเจนสำหรับฉัน แต่ verbose มากและ ColdFusion ไม่ได้เป็นที่ต้องการของตลาดสูงและดังนั้นฉันจึงเดินหน้าต่อไป

จากนั้นฉันก็กระโดดขึ้นไปบนเกวียน ASP.NET และเริ่มใช้วิธี MVC ของพวกเขา ฉันก็รู้ว่า Java ดูเหมือนจะเป็นภาษาหอคอยงาช้างของระบบองค์กรและยังลองใช้วิธี MVC ของพวกเขา ต่อมา ASP.NET พัฒนารูปแบบการออกแบบ MVVM นี้และ Java (แม่นยำ J2EE หรือ JEE) ก็ดิ้นรนและออกมาด้วยวิธีการ MVC2

แต่วันนี้สิ่งที่ฉันได้ค้นพบคือการเขียนโปรแกรมแบ็คเอนด์ไม่ได้อยู่ที่ความตื่นเต้นและความก้าวหน้าอีกต่อไป นอกจากนี้แนวปฏิบัติ MVC บนฝั่งเซิร์ฟเวอร์ดูเหมือนจะล้าสมัยแล้ว (ผู้คนใช้ JSTL จริง ๆ อีกหรือไม่?) ทุกวันนี้ในโครงการส่วนใหญ่ที่ฉันเปิดอยู่ฉันพบว่าเฟรมเวิร์ก JavaScript และการพัฒนาฝั่งไคลเอ็นต์เป็นสิ่งที่ความก้าวหน้าและนวัตกรรมที่น่าตื่นเต้นกำลังดำเนินไป

ทำไมการเคลื่อนไหวนี้จากเซิร์ฟเวอร์ถึงการพัฒนาฝั่งไคลเอ็นต์เกิดขึ้น? ฉันนับจำนวนบรรทัดอย่างง่ายของหนึ่งในโครงการ JEE ของฉันและมีรหัสบรรทัดใน JavaScript มากกว่าจาวา (ยกเว้นห้องสมุดบุคคลที่สาม) ฉันพบว่าการพัฒนาแบ็กเอนด์ส่วนใหญ่โดยใช้ภาษาการเขียนโปรแกรมเช่น Java หรือ C # เป็นเพียงการสร้างส่วนที่คล้ายกับส่วนที่เหลือและความพยายามอย่างหนักในการแสดงภาพข้อมูลภาพอินพุต / เอาท์พุตปฏิสัมพันธ์ของผู้ใช้ ฯลฯ ... ผ่านทางฝั่งไคลเอ็นต์เช่น Angular, Backbone, Ember, Knockout, ฯลฯ ...

ในช่วงก่อนยุค jQuery ฉันเห็นไดอะแกรมมากมายที่มีเส้นแบ่งที่ชัดเจนและเป็นแนวคิดระหว่าง M, V และ C ใน MVC ในการพัฒนาระดับ n Post-jQuery เส้นเหล่านี้ถูกวาดที่ไหน? ดูเหมือนว่า MVC และ MVVM อยู่ที่นั่นในโค้ด JavaScript ฝั่งไคลเอ็นต์

สิ่งที่ฉันต้องการรู้ก็คือทำไมเราถึงทำการเปลี่ยนแปลงเช่นนี้ (จากการเน้นการเขียนโปรแกรมฝั่งเซิร์ฟเวอร์ไปจนถึงฝั่งไคลเอ็นต์จากภาษาคอมไพล์ไปจนถึงภาษาสคริปต์จากความจำเป็นไปจนถึงการเขียนโปรแกรมเชิงปฏิบัติการทั้งหมดนี้ดูเหมือนจะเกิดขึ้นพร้อมกัน ) และการเปลี่ยนแปลง / การเปลี่ยนแปลงนี้แก้ปัญหาอะไรได้บ้าง?

การเปลี่ยนภาระการประมวลผลระหว่างเซิร์ฟเวอร์และไคลเอนต์เป็นปรากฏการณ์ที่เกิดขึ้นตามวงจรและค่อนข้างนาน

เมื่อฉันอยู่ในวิทยาลัยชุมชนคอมพิวเตอร์ส่วนบุคคลเพิ่งได้รับแรงบันดาลใจ แต่อีเธอร์เน็ตยังไม่ได้ใช้อย่างกว้างขวางและไม่มีใครมีเครือข่ายท้องถิ่น ย้อนกลับไปตอนนั้นวิทยาลัยมีเมนเฟรมที่จัดการบันทึกนักเรียนและทำหน้าที่เป็นแพลตฟอร์มสำหรับชั้นเรียนการเขียนโปรแกรม การบริหารมีเครื่องเทอร์มินัลที่เชื่อมต่อกับเมนเฟรมบนพื้นฐานการแบ่งปันเวลา แต่นักเรียนจะต้องต่อยไพ่เพื่อให้งานเขียนโปรแกรมเสร็จสิ้นซึ่งเป็นกระบวนการที่ยากลำบาก ในที่สุดพวกเขาวางในห้องแล็บที่นักเรียนสามารถลงทะเบียนเวลาบนเทอร์มินัล แต่มันอาจใช้เวลาครึ่งชั่วโมงหรือมากกว่านั้นเพื่อให้ได้ข้อผิดพลาดหนาครึ่งนิ้วของคุณ การประมวลผลทั้งหมดทำบนเมนเฟรม (เซิร์ฟเวอร์)

แต่เมนเฟรมมีราคาแพงดังนั้น บริษัท จึงเริ่มติดตั้งเครือข่ายในพื้นที่และโหลดการประมวลผลเปลี่ยนจากเซิร์ฟเวอร์ไปยังเครื่องไคลเอนต์แต่ละเครื่องซึ่งมีประสิทธิภาพมากพอที่จะเรียกใช้การประมวลผลคำสเปรดชีตและแอปพลิเคชั่นทางธุรกิจ แบ่งปันพลังการประมวลผลของพวกเขากับคนอื่น ๆ เซิร์ฟเวอร์เป็นเครื่องที่คล้ายกันที่มีความสามารถคล้ายกัน (อาจมีหน่วยความจำมากกว่าและมีพื้นที่ฮาร์ดไดรฟ์) แต่ส่วนใหญ่จะใช้เพื่อแชร์ไฟล์ สิ่งนี้เรียกว่าไคลเอ็นต์ / เซิร์ฟเวอร์ การประมวลผลส่วนใหญ่เปลี่ยนไปที่คอมพิวเตอร์ไคลเอนต์

หนึ่งในข้อเสียของการดำเนินการประมวลผลทั้งหมดบนเครื่องไคลเอนต์คือคุณได้เข้าสู่วัฏจักรถาวรของการติดตั้งและอัพเกรดซอฟต์แวร์ตลอดเวลาและปวดหัวทั้งหมดที่เกิดขึ้นกับสิ่งนั้น โมเดลการเขียนโปรแกรมของเครื่องเหล่านี้ (ส่วนต่อประสานกับผู้ใช้แบบอิงเหตุการณ์) สนับสนุนการสร้างโปรแกรมที่ยุ่งเหยิงและยากที่จะรักษาโปรแกรม (ลูกบอลก้อนใหญ่) ผู้ใช้ปลายทางส่วนใหญ่ไม่มีทักษะในการบำรุงรักษาฮาร์ดแวร์และซอฟต์แวร์ของตนอย่างเหมาะสมซึ่งจำเป็นต้องมีบุคลากรด้านการบำรุงรักษาด้านไอที

เมื่อคอมพิวเตอร์เริ่มมีพลังอำนาจมากขึ้นแผนกแรงงานก็เป็นไปได้ ตอนนี้คุณสามารถมีไฟล์เซิร์ฟเวอร์เซิร์ฟเวอร์ฐานข้อมูลเว็บเซิร์ฟเวอร์เซิร์ฟเวอร์การพิมพ์และอื่น ๆ แต่ละเครื่องสามารถปรับให้เหมาะสมสำหรับงานที่จัดหาและดูแลโดยผู้ที่มีความเชี่ยวชาญที่จำเป็น สามารถเขียนโปรแกรมที่รันในเว็บเบราว์เซอร์ได้ดังนั้นจึงไม่จำเป็นต้องติดตั้งไคลเอนต์อีกต่อไป สิ่งนี้เรียกว่า Multi-Tier หรือ n-Tier เบราว์เซอร์ส่วนใหญ่ใช้เป็นเทอร์มินัลโง่เช่นเดียวกับในเมนเฟรมวันแม้ว่าวิธีการสื่อสารกับเซิร์ฟเวอร์นั้นซับซ้อนกว่ากรรมสิทธิ์น้อยกว่าและมีกลไกการขัดจังหวะแทนที่จะใช้เวลาร่วมกันและการสำรวจ การประมวลผลได้เปลี่ยนกลับไปเป็นเซิร์ฟเวอร์

อย่างไรก็ตามการพัฒนาเว็บไซต์มาพร้อมกับอาการปวดหัวชุดใหม่ทั้งหมด แอปพลิเคชันทางธุรกิจส่วนใหญ่ที่เขียนขึ้นสำหรับเบราว์เซอร์เป็นรูปแบบและรายงานคงที่ มีการโต้ตอบน้อยมากใน UI Javascript ยังไม่พบข้อที่สองและมีปัญหาสำคัญเกี่ยวกับความเข้ากันไม่ได้ของเบราว์เซอร์ อย่างไรก็ตามสิ่งต่าง ๆ ได้ดีขึ้นมาก HTML5 และ CSS3 มอบความสามารถใหม่ ๆ ให้กับโมเดลการเขียนโปรแกรมเบราว์เซอร์ jQuery ออกมาและช่วยให้โปรแกรมเมอร์ทั้งรุ่นค้นพบว่า Javascript มีประโยชน์อย่างไร เฟรมเวิร์กส่วนหน้า UI ใหม่ปรากฏขึ้น มันเป็นไปได้ที่จะเขียน UI ที่มีการโต้ตอบสูงในเบราว์เซอร์หรือแม้แต่เกมที่สมบูรณ์ การประมวลผลย้ายกลับไปที่ไคลเอ็นต์อีกครั้ง

วันนี้คุณสามารถซื้อพลังการประมวลผลในระบบคลาวด์ได้มากหรือน้อยตามที่คุณต้องการและรันโปรแกรมบนเซิร์ฟเวอร์ ฉันกำลังบอกว่าตอนนี้เราอยู่ในสถานที่ซึ่งในฐานะนักพัฒนาซอฟต์แวร์คุณมีตัวเลือกมากมายเกี่ยวกับที่ที่คุณสามารถประมวลผลพลังการประมวลผลของคุณทั้งบนไคลเอนต์และบนเซิร์ฟเวอร์

คุณดูเหมือนจะผสมผสานแนวคิดที่แตกต่างกันสองอย่าง:

1. การแยกงานนำเสนอและตรรกะทางธุรกิจ (MVC) => เพิ่มความสามารถในการบำรุงรักษา
2. การกำหนดการดำเนินการให้กับโหนด => เพิ่มประสิทธิภาพ

ย้อนกลับไปในสมัยก่อนการคำนวณแบบไคลเอนต์ / เซิร์ฟเวอร์มักสับสนว่าเป็นครั้งแรกเพราะโดยทั่วไปแล้วลูกค้าไม่ได้ให้พลังการประมวลผลมากนักเมื่อเทียบกับเซิร์ฟเวอร์ ดังนั้นจึงเป็นเรื่องธรรมดาที่จะย้ายการคำนวณตรรกะทางธุรกิจ "หนัก" (M) ไปยังเซิร์ฟเวอร์ในขณะที่ยังคงการประมวลผลมุมมอง "แสง" (V) ไปยังไคลเอนต์ ในทางกลับกันคุณต้องใช้อนุญาโตตุลาการ (C) บางอย่างเพื่อแปลระหว่างสองคน

ตอนนี้ลูกค้ามีคุณสมบัติในการประมวลผลได้อย่างง่ายดายซึ่งเมื่อบอกเป็นนัยถึงฮาร์ดแวร์เซิร์ฟเวอร์บางตัวที่มีราคาแพงสายจะเบลอว่าจะใช้ตรรกะทางธุรกิจที่ใด - ฝั่งไคลเอ็นต์หรือฝั่งเซิร์ฟเวอร์ จริง ๆ แล้วคำตอบนั้นขึ้นอยู่กับกรณีการใช้งานเฉพาะของคุณและตัวเลือกของการแลกเปลี่ยนเช่น:

• ความล่าช้าของไคลเอ็นต์เทียบกับความซับซ้อน: การประมวลผลฝั่งเซิร์ฟเวอร์ช่วยให้ระบบง่ายขึ้นเนื่องจากไม่จำเป็นต้องมีการปรับใช้รหัส / ดาวน์โหลดไปยังไคลเอนต์

• ซับซ้อนกับโหลดเซิร์ฟเวอร์: การคำนวณฝั่งไคลเอ็นต์อาจเพิ่มความซับซ้อนของระบบ แต่อาจช่วยลดภาระเซิร์ฟเวอร์

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

นี่คือรายการที่ไม่ครบถ้วนสมบูรณ์ของการแลกเปลี่ยนหลายครั้ง

เนื่องจากผู้ใช้ต้องการฟังก์ชั่นที่เหมือนกันเสมอระฆังและเสียงหวีดหวือกับแอพพลิเคชั่นเว็บ (ไม่ใช่แค่เว็บไซต์) ที่พวกเขามีกับแอพเดสก์ท็อป ทำให้สิ่งนี้ทำงานได้ในเบราว์เซอร์ (จริงๆแล้วเบราว์เซอร์หลายตัว) ไม่เหมือนสมัยก่อนเมื่อคุณสามารถเชื่อมโยงแบบฟอร์ม VB ไปยังฐานข้อมูลด้วยรหัสเล็กน้อย วิธีนี้จะง่ายกว่าเมื่อคุณไม่ต้องเดินทางกลับไปที่เซิร์ฟเวอร์

การพัฒนาแบ็กเอนด์ส่วนใหญ่โดยใช้ภาษาการเขียนโปรแกรมเช่น Java หรือ C # เป็นเพียงการสร้างส่วนต่อประสานที่มีลักษณะคล้าย REST และความพยายามอย่างหนักในการแสดงภาพข้อมูลภาพอินพุต / เอาท์พุตการโต้ตอบของผู้ใช้ ฯลฯ ... กรอบด้านข้างเช่น Angular, Backbone, Ember, Knockout, ฯลฯ ...

บางทีการเขียนโปรแกรม / บริการแบ็คเอนด์ดูเหมือนว่าเหมือนเดิม แต่เป็นหัวใจของแอปพลิเคชัน วิธีการเข้ารหัสอาจมีประสิทธิภาพมากขึ้นในพื้นที่เหล่านี้ เครื่องมือภาษาเบราว์เซอร์และเฟรมเวิร์กยังคงมีการพัฒนาดังนั้น UI / UX จึงยากที่จะพัฒนา เป็นสิ่งใหม่ที่ ASP เก่าไม่มี หากเราสามารถหนีไปกับส่วนต่อประสานผู้ใช้ที่มีรูปแบบเรียบง่ายและตาราง html ก็จะไม่มีความสนใจ / hype มากนักในพื้นที่เหล่านั้น แต่ผู้ใช้ต้องการลากและวาง, ภาพเคลื่อนไหว, การเปลี่ยนภาพ, ป๊อปอัปเป็นต้น

ทุกวันนี้ในโครงการส่วนใหญ่ที่ฉันเปิดอยู่ฉันพบว่าเฟรมเวิร์ก JavaScript และการพัฒนาฝั่งไคลเอ็นต์เป็นสิ่งที่ความก้าวหน้าและนวัตกรรมที่น่าตื่นเต้นกำลังดำเนินไป

ทำไมการเคลื่อนไหวนี้จากเซิร์ฟเวอร์ถึงการพัฒนาฝั่งไคลเอ็นต์เกิดขึ้น?

จริงๆแล้วมีสองคำถามที่นี่:

1. เหตุใดการเขียนโปรแกรมฝั่งไคลเอ็นต์จึงเกิดความคืบหน้า
2. เหตุใดแอปพลิเคชันที่เขียนขึ้นเพื่อทำงานบนไคลเอนต์แทนที่จะเป็นเซิร์ฟเวอร์

ทั้งสองแตกต่างกันจริงๆ

เหตุใดการเขียนโปรแกรมฝั่งไคลเอ็นต์จึงเกิดความคืบหน้า

เนื่องจากรันไทม์สภาพแวดล้อมและระบบนิเวศได้ครบกำหนดอย่างมีนัยสำคัญในช่วงสามปีที่ผ่านมาและสิ่งนี้ได้เปิดซอกใหม่ที่นักประดิษฐ์ได้รอการใช้ประโยชน์

การพัฒนา Front-end เคยเป็นเรื่องยากเรื่องยากคุณต้องตั้งโปรแกรมสำหรับเบราว์เซอร์ - เป็นสภาพแวดล้อมที่เป็นมิตร - โดยใช้คุณสมบัติที่ จำกัด ของ ECMAScript 3 ในระบบนิเวศที่ไม่เคยมีศิลปะหรือเครื่องมือในการสร้างแอปพลิเคชันลูกค้าหนา ไม่มีโมดูลตัวโหลด คุณไม่สามารถจัดการการพึ่งพาได้อย่างถูกต้อง มีเครื่องมือขัดผ้าสำลี โครงร่างเป็นสิ่งที่ยังไม่บรรลุนิติภาวะและชื่อเสียงที่ไม่ดีของผู้มีชื่อเสียงที่อยู่ห่างไกลผู้คิดค้นนวัตกรรมที่สามารถแก้ไขปัญหาเหล่านี้ได้

เนื่องจากปัจจัยเหล่านี้มีการเปลี่ยนแปลงเพิ่มขึ้นพวกเขาได้สร้างระบบที่มีความสำคัญสำหรับการพัฒนาแอปพลิเคชันไคลเอนต์ที่หลากหลายและทำงานอย่างต่อเนื่อง

ในการตอบคำถามของคุณนั้นไม่มากที่เทคโนโลยี front-end ใหม่ได้ผลักดันความคืบหน้าไปข้างหน้ามากเท่าที่พวกเขาได้เปิดตัวคอขวดและอนุญาตให้ไคลเอนต์เพื่อติดตามแรงบันดาลใจของผู้ใช้

เหตุใดแอปพลิเคชันที่เขียนขึ้นเพื่อทำงานบนไคลเอนต์แทนที่จะเป็นเซิร์ฟเวอร์

มีหลายสาเหตุที่ใกล้เคียงกัน แต่สิ่งที่แตกต่างที่สุดของปีที่ผ่านมาคือการเพิ่มขึ้นของสมาร์ทโฟน

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

มันแตกต่างกันอย่างไร? ลองคิดดูว่าสมาร์ทโฟนของคุณเป็นเพียงเทอร์มินอลโง่ ทุกการกลายพันธุ์ของรัฐจะต้องไม่ตรงกันและผิดพลาดได้ การโหลดเนื้อหาทุกครั้งจะมีค่าใช้จ่ายเซนต์ คุณจะต้องลงทุนในเซิร์ฟเวอร์ฟาร์มขนาดใหญ่ที่มีเวลาให้บริการห้าสิบเก้านาที คุณจะต้องเสียค่าใช้จ่ายในการคำนวณโดยตรงดังนั้นความนิยมอย่างฉับพลันอาจส่งผลให้ธุรกิจของคุณ

แอปพลิเคชันฝั่งไคลเอ็นต์ช่วยให้คุณจัดการสถานะที่เกี่ยวข้องกับผู้ใช้แต่ละรายในแบบรวดเร็วและซิงโครนัส พวกเขาให้คุณลดค่าใช้จ่ายในการคำนวณของคุณให้กับผู้ใช้ของคุณ พวกเขาช่วยให้คุณได้รับไปกับการหยุดทำงานและการเชื่อมต่อเครือข่ายไม่ดี พวกเขาสร้างรหัสเซิร์ฟเวอร์ให้โง่จนสามารถแคชได้ในโครงสร้างพื้นฐานเครือข่ายเอง - ไฟล์ HTML และ JS แบบคงที่หรือการตอบกลับสำเร็จรูปสำหรับแอปมือถือ

เพื่อกล่าวถึงในวงกว้างมาก: การพัฒนาฝั่งไคลเอ็นต์ใช้ประโยชน์จากต้นทุนต่ำของการใช้คอมพิวเตอร์ส่วนบุคคลกลางกำลังและหลีกเลี่ยงค่าใช้จ่ายสูงของการใช้คอมพิวเตอร์ส่วนกลางกำลังแรงสูง

คุณถามคำถามหลายข้อบางคำถามมีคำตอบที่ดีอยู่แล้ว มีน้อยคนที่ยังไม่ได้รับคำตอบ:

สิ่งที่ฉันต้องการรู้ก็คือทำไมเราถึงทำการเปลี่ยนแปลง (จากการเน้นการเขียนโปรแกรมฝั่งเซิร์ฟเวอร์ไปยังฝั่งไคลเอ็นต์ ... สิ่งเหล่านี้ดูเหมือนจะเกิดขึ้นพร้อมกัน) และการเปลี่ยนแปลง / การเปลี่ยนแปลงนี้แก้ปัญหาอะไร?

Robert Harvey ให้คำตอบที่ยอดเยี่ยม

... จากการรวบรวมภาษาที่นิยมไปจนถึงภาษาสคริปต์

ภาษาสคริปต์มีข้อดีหลายประการ ( เช่น ) เหนือภาษาที่รวบรวมเช่น:

• ง่ายต่อการเรียนรู้และใช้งาน
• กำจัดเวลารวบรวม (การพัฒนาที่เร็วขึ้น)
• ให้คุณสมบัติเพิ่มเติม (การควบคุมแอปพลิเคชันระดับสูง)
• อนุญาตการเปลี่ยนแปลงอย่างรวดเร็วในการเรียกใช้รหัส
• เป็นต้น

... จากความจำเป็นในการเขียนโปรแกรมเพื่อการทำงาน

นี่เป็นการเปรียบเทียบที่ดี แต่ฉันจะสรุปโดยบอกว่าในซอฟต์แวร์แบบกระจาย (คิดว่าการคำนวณแบบคลาวด์) การจัดการการเปลี่ยนแปลงสถานะ (การซิงโครไนซ์ข้ามหลายโหนด) อาจเป็นปัญหาใหญ่ ในการเขียนโปรแกรมการทำงานความต้องการที่จะจัดการกับการเปลี่ยนแปลงสถานะจะต่ำกว่ามาก