การพัฒนาเว็บกับการพัฒนาเดสก์ท็อป - การพัฒนาเว็บนั้นแย่กว่านี้หรือไม่? [ปิด]


29

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

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

(และเปรียบเทียบการพัฒนาแอป Flash หรือ Silverlight อย่างไร)


5
ฉันยังไม่ได้ลงคะแนนให้ปิด แต่ฉันคิดว่ามันอาจจะสร้างสรรค์มากขึ้นถ้ามันสามารถนำไปใช้ในการพัฒนาเว็บเทียบกับการพัฒนาเดสก์ท็อป
Josh K

K: โอเคฉันพยายามที่จะเรียบเรียงคำถามใหม่โดยไม่ทำให้คำตอบที่มีอยู่นั้นไม่ถูกต้อง ขอบคุณ
Josh Kelley

คำตอบ:


26

ไม่

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

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

ฉันไม่สามารถแสดงความคิดเห็นของ Flash หรือ Silverlight เพราะฉันไม่ได้ใช้


5
ฉันเกลียดที่จะเป็นว่าคนที่แต่งตัวประหลาด แต่ ... :s/loose/lose/:)
ดรฮันนิบาลเล็คเตอร์

@dr Hannibal: แก้ไขมัน บางครั้งฉันก็แตะปุ่มสองครั้ง ;)
Josh K

4
@dr ฮันนิบาล: มีเช่นประสานองค์ที่มาจากคำว่า "ฉันเกลียดที่จะเป็นว่าคนที่แต่งตัวประหลาด" มาจาก "ฮันนิบาลเล็คเตอร์" :)
Skilldrick

25

ดังที่คนอื่น ๆ พูดถึงมันเป็นเรื่องของการแลกเปลี่ยนและการมีความรู้ที่ถูกต้อง

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

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

อย่าคิดว่าคุณจะหลีกเลี่ยงการแฮ็กเฉพาะแพลตฟอร์มที่นี่และถ้าคุณสร้างสิ่งที่สำคัญ

แล้วส่วนที่สนุก อะไรดีที่สุด? เบราว์เซอร์ที่อัปเดตตัวเองอย่างสม่ำเสมอเกือบจะเหมือน Chrome จริงๆ หรือรุ่นที่เปิดตัวการรักษาความปลอดภัยอัปเดตเฉพาะคุณสมบัติรายเดือนและรายใหญ่ทุกยุคหิน (เช่น IE)? คำตอบนั้นไม่ชัดเจนอย่างที่คุณคิดเพราะการอัปเดต "โปร่งใส" เหล่านี้บางครั้งอาจทำให้โค้ดของคุณเสียหายและคุณจะต้องทำตามและตอบกลับทันที หรือคอยจับตาดูเบต้าและ dev รุ่นก่อนวางจำหน่ายในขณะที่กำลังพัฒนาและทดสอบอยู่ สำหรับเบราว์เซอร์ทั้งหมดที่คุณพูดอย่างโง่เขลาว่าคุณต้องการการสนับสนุน (ขอให้โชคดี)

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

สำหรับ 2 ย่อหน้าสุดท้ายบางครั้งแนวคิดที่พบบ่อยคือแพคเกจเว็บเบราว์เซอร์ที่กำหนดค่าไว้ล่วงหน้าพร้อมกับตัวติดตั้งของคุณซึ่งจะเชื่อมต่อกับเว็บแอปของคุณ (โฮสต์ในพื้นที่หรือบนเว็บ) มันยอดเยี่ยมมากเพราะคุณสามารถควบคุมความถี่ในการอัปเดตและคุณสามารถ "หยุด" สถานะและคุณรู้ว่าจะต้องสนับสนุนและทดสอบอะไร นอกจากนี้คุณสามารถเพิ่มสิ่งดีๆเช่นส่วนขยายผู้ใช้โดยเฉพาะ ตัวอย่างเช่นการบรรจุ Chromium "แช่แข็ง" ที่มีส่วนขยาย Chrome ขนาดเล็กที่คุณพัฒนาขึ้นเพื่อทำให้การใช้งานแอปพลิเคชันเว็บของคุณง่ายขึ้นสำหรับผู้ใช้ประเภทต่างๆนั้นจะดีมาก ในทางกลับกัน ... ตอนนี้คุณต้องรับผิดชอบหากมีการละเมิดความปลอดภัยเกิดขึ้นเพราะคุณทำรอบการปล่อยค้างไว้และแอปของคุณจะไม่ได้รับประโยชน์จากการปรับปรุงความเร็ว (ถ้ามี)

มันเหมือนกับขวานสองขวาน

หมายเหตุ:ฉันมีอคติที่แข็งแกร่งต่อเว็บเพราะโดยทั่วไปแล้วเป็นกองใหญ่ของเทคโนโลยีครึ่งอบ (และฉันสุภาพที่นี่), จนถึงเลเยอร์ OSI ซึ่งเราเพิ่มเลเยอร์ของอึซ่อนปัญหาภายใต้โดยไม่ต้องแก้จริง ๆ หรือแก้ไขพวกเขา

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

อืมและคาดว่าจะมีการพัฒนาที่สนุกสนานในอนาคตในขณะนี้ที่มีระบบปฏิบัติการรุ่นเก่าที่มีน้ำหนักเบาจำนวนมากวางไข่สำหรับสภาพแวดล้อมอุปกรณ์พกพา (เน็ตบุ๊กสมาร์ทโฟน PDAs แท็บเล็ต eBooks ... ) .. แต่ด้วยส่วนแบ่งใหม่ทั้งหมดของข้อบกพร่องในการแสดงผล UI

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


แก้ไข: สิ่งอื่น ๆ ที่ต้องพิจารณา ...

รับสมัครงาน

มันยากมากในการค้นหาผู้พัฒนาเว็บที่มีความรู้ คุณคิดว่ามีฝูงพวกเขา แต่พวกเขาหายไปในสระว่ายน้ำขนาดใหญ่ของคนที่ไร้ความสามารถพอสมควรที่คิดว่ามีการจัดการในการเขียน JavaScript / ECMAScript 700 บรรทัดเพื่อดำเนินการตรวจสอบความถูกต้องในรูปแบบของพวกเขา และเป็นสิ่งที่สามารถทำได้ในแง่ของทักษะระดับสูง

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

ความเข้าใจ

ไม่มีใครจะพิจารณาคุณอย่างจริงจังเมื่อคุณพูดว่า "ฉันเป็นนักพัฒนาเว็บ" มันมีไว้สำหรับ sub-class ของโปรแกรมเมอร์นักพัฒนาไม่ใช่เหรอ? คนที่คุณเพิกเฉยและเยาะเย้ยจากระยะไกลและไม่เข้าร่วมเมื่อพวกเขาไปรับกาแฟ :)

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

จากนั้นพวกเขาก็ตระหนักว่า ECMAScript ซับซ้อนอย่างบ้าคลั่งสามารถ แต่จะปฏิเสธที่จะทบทวนความคิดเห็นของพวกเขา เพราะมันเป็นเว็บ เราไม่ชอบสิ่งที่อยู่ภายในเราชอบสิ่งที่ทำให้เราสามารถทำได้


-2, 10 ... ฉันเห็นฉันส่งเสริมการโต้เถียง;)
haylem

ความแตกต่างระหว่างเบราว์เซอร์กลายเป็นปัญหาที่น้อยลง แน่นอนมีความไม่สอดคล้องเล็กน้อยในวิธีที่พวกเขาจัดการ CSS และอะไร แต่ส่วนใหญ่ฉันไม่เคยมีปัญหาสำคัญกับเบราว์เซอร์ที่ทันสมัย ถ้าคุณขวาอยู่บนขอบเลือดกับ HTML5, <canvas>และสิ่งที่ชอบ ...
คณบดีฮาร์ดิง

6
"หมายเหตุ: ฉันมีอคติที่แข็งแกร่งต่อเว็บเพราะโดยทั่วไปเป็นกองใหญ่ของเทคโนโลยีครึ่งอบ (และฉันสุภาพที่นี่) ลงไปที่เลเยอร์ OSI ซึ่งเราเพิ่มชั้นของอึที่ซ่อนปัญหาภายใต้โดยไม่ต้องจริงๆ การแก้ปัญหาหรือแก้ไขพวกเขา " - คุณเป็นฉัน ?????
Bobby Tables

2
ฉันทำงานกับผู้ชายสองคนที่เป็นผู้เชี่ยวชาญด้านการพัฒนาเว็บจริงทำสิ่งที่น่าอัศจรรย์และใช้มันเป็นแพลตฟอร์มการพัฒนาซอฟต์แวร์ที่จริงจัง พวกเขาเคารพฉันอย่างลึกซึ้ง แต่นั่นเป็นเพียงสองครั้งในช่วง 15 ปีที่ผ่านมา ส่วนที่เหลือ ... ดีฉันเคยมีกิ๊กในฐานะ "ผู้เชี่ยวชาญ" Perl เพียงเพราะรหัสตัวอย่างของฉันมีโครงสร้างมากกว่าสปาเก็ตตี้ที่ผู้สัมภาษณ์เคยเป็น; ในขณะนั้นความเชี่ยวชาญ Perl ของแท้ของฉันอาจพอดีกับปลอกมือ
Bob Murphy

2
+1 สำหรับ ECMAScript นั้นดีไม่ดีและเรียกว่า ECMAScript
Alan Pearce

14

ในฐานะที่เป็นคนที่ได้รับการจัดการกับทั้งสอง (มากกว่าเดสก์ท็อปมากกว่าเว็บ): โดยส่วนใหญ่แล้วฉันรู้สึกว่า "clunkiness ทั่วไป" ในการพัฒนาเว็บ แม้จะมีเครื่องมือและกรอบงานที่ดีที่สุด abstractions ก็ยังรั่วไหลอยู่มากและคุณต้องรับมือกับความจริงที่ว่าคุณกำลังใช้โปรโตคอลไร้สัญชาติอยู่ตลอดเวลา

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

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


4
เหตุผลที่ทำให้รู้สึกว่า "โดยทั่วไปมักเป็นเรื่องไร้สาระ" อาจเป็นเพราะคุณใช้เฟรมเวิร์กที่พยายามทำให้ "เป็นนามธรรม" ออกไป ... อะไรเว็บ? เว็บไร้สัญชาติ ไม่ว่า "webforms" ใน ASP.NET จะทำให้คุณคิดเป็นอย่างอื่นอย่าลืมว่ามันไร้สัญชาติ นักพัฒนาที่เร็วกว่ายอมรับว่าเป็นความจริงที่ไม่สามารถเปลี่ยนแปลงได้พวกเขาจะสามารถเขียนเว็บแอปพลิเคชันที่มีคุณภาพได้เร็วขึ้น
Jason Whitehorn

1
+1 ก็พูดได้ดี แม้จะมีเฟรมเวิร์กอย่าง Rails ซึ่งควรจะเป็นวิธีแก้ปัญหาการเขียนทุกอย่างในสแต็คเทคโนโลยีเดียว แต่พวกเขาก็จัดการได้ด้วยการเปลี่ยนแนวทางปฏิบัติที่แนะนำจาก RJS เป็น "Unobtrusive JS"
Jas

11

สิ่งที่คิดมากที่สุดจากเดสก์ท็อปไปยังเว็บคือแอพพลิเคชั่นเว็บไร้สัญชาติโดยเนื้อแท้

คิดส่วนนั้นออกมาและคุณก็ทำได้ดี


เบราว์เซอร์มีความสำคัญอย่างไร
JeffO

@Jeff ความไม่สอดคล้องกันระหว่างเบราว์เซอร์นั้นน่ารำคาญ แต่ก็ไม่มีนัยสำคัญจริงๆ
Steven A. Lowe

4
คุณต้องเขียนสำหรับเบราว์เซอร์จริง (ความไม่สอดคล้องกันบางอย่าง), Internet Explorer (ความไม่สอดคล้องกันมากขึ้น) และบางทีลูกของปีศาจ (IE6)
TRiG

2
@Malfist: ถ้าคุณไม่ระวังด้วยวิธีนี้ (ไร้สัญชาติ + การประชุม = stateful) ที่คุณสามารถออกแบบอีมูกับเครื่องยนต์เครื่องบินเจ็ตปิดเมื่อคุณอยากเดิมสำหรับนกอินทรี;)
Piskvor

1
@Jim G: แน่นอนมันเป็น แต่ความแตกต่างระหว่างเบราว์เซอร์และอัลนั้นเล็กมากเมื่อเทียบกับการออกแบบแอพพลิเคชั่นไร้สัญชาติ
Steven A. Lowe

5

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

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


2
ปัญหาความเข้ากันได้ของเบราว์เซอร์เป็นปัญหาใหญ่ แต่จริง ๆ แล้วเพื่อความสมดุลอย่าลืมว่าเขาเปรียบเทียบกับการพัฒนาเดสก์ท็อปซึ่งคุณต้องจัดการกับระบบปฏิบัติการไลบรารีรุ่นต่าง ๆ และอื่น ๆ
Carson63000

@Carson หากพวกเขาพัฒนาจาวาสก์ท็อปความเจ็บปวดนี้จริง ๆ แล้วค่อนข้างน้อย บางทีมันอาจจะแย่กว่านั้นสำหรับ. NET หรือ Win32 API

2

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

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


2

การพัฒนาเว็บไม่ได้เลวร้ายไปกว่านั้นมันแตกต่างกันมาก

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

  • HTML
  • จาวาสคริ
  • CSS
  • ภาษาฝั่งเซิร์ฟเวอร์ (Java / PHP / อะไรก็ได้ ... )
  • RDBMS (หรือเทคโนโลยีการจัดเก็บบางส่วน)
  • ... และสิ่งอื่น ๆ อีกมากมายเช่น Flash, Silverlight และอื่น ๆ

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


1

ไม่

ตราบใดที่คุณเลือกเครื่องมือที่เหมาะสมการพัฒนาเว็บไซต์นั้นสะอาดและง่ายเหมือนการพัฒนาเดสก์ท็อป

API ของเว็บ (html, CSS, Javascript และ DOM) เทียบเท่ากับ win32 api ในที่สุดทุกอย่างจะพูดถึงระดับ API นั้น แต่คุณก็บ้าถ้าคุณตั้งโปรแกรมไว้ด้านบนโดยไม่ต้องใช้ห้องสมุดเพื่อย่อความยุ่งเหยิงคำฟุ่มเฟื่อยและความไม่ลงรอยกันจากคุณ

ดังนั้นระวังเกี่ยวกับกรอบทางเลือกของคุณ ปัญหาบางอย่างเกิดขึ้นเองโดยเลือกเครื่องมือที่ไม่ดี (เช่นปัญหาความเข้ากันได้ของเบราว์เซอร์)

เป็นไปได้ที่จะมีแพลตฟอร์ม dev บนเว็บที่สะอาดและสม่ำเสมอด้วยภาษาเดียว เช่นหากคุณต้องการให้เป็น "java ทั้งหมดตลอดเวลา" คุณสามารถใช้ GWT และเขียนทั้งรหัสฝั่งไคลเอ็นต์และรหัสฝั่งเซิร์ฟเวอร์ใน Java หรือหากคุณต้องการให้เป็นจาวาสคริปต์ทั้งหมดคุณสามารถเลือกอย่าง Ext JS สำหรับฝั่งไคลเอ็นต์และ node.js สำหรับฝั่งเซิร์ฟเวอร์


0

ฉันได้ยินว่ามันอธิบายว่า "... ความหายนะของการมีอยู่ของฉัน" และฉันก็เห็นด้วย ฉันได้รับการเสนอราคา $$$ หนึ่งชั่วโมงเพื่อทำการพัฒนาเว็บไซต์ HTML และฉันได้ปฏิเสธ มันเจ็บปวดมาก ฉันใช้เวลาส่วนใหญ่เป็น HTML และเพิ่งเริ่มทำงานกับ "แพลตฟอร์มแฟลช" เป็นหนึ่งในกรอบงานที่ซับซ้อนที่สุดที่ฉันเคยเห็นและไม่มีใครรู้เกี่ยวกับมัน เมื่อผู้คนนำ Flash มาพวกเขาคิดถึง Flash เมื่อ 10 ปีที่แล้ว มันโตขึ้น ... มาก ฉันรักการเขียนซอฟต์แวร์อีกครั้ง

มันยังมีข้อเสียอยู่ บางครั้งข้อบกพร่องก็คงอยู่ตลอดไป แต่ก็ดีขึ้น (ขอบคุณสตีฟเจ)

BTW มีปัญหาการขาดแคลนที่สำคัญสำหรับนักพัฒนา Flex ฉันถูกทาบทามจากหลาย ๆ บริษัท ที่ป่วย หากคุณรู้จัก CS ของคุณให้ใช้เวลาเรียนรู้ Flex Hardcore อีก 6 เดือนข้างหน้าแล้วโทรหาฉัน ฉันจะส่งข้อเสนองานทั้งหมดที่ฉันต้องทำ

ปรับปรุง: การสนับสนุนเบราว์เซอร์ข้ามเป็นจุดปวดหลัก สิ่งที่ใช้งานได้ในเบราว์เซอร์หนึ่งจะไม่ทำงานในอีกเบราว์เซอร์ แต่จะไม่ทำงานในเวอร์ชันก่อนหน้า

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

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


คุณสามารถแก้ไขคำตอบของคุณเพื่ออธิบายว่าทำไมคุณถึงคิดว่ามันเป็นความหายนะของการดำรงอยู่ของคุณ?
Josh Kelley

อัปเดตคำตอบของฉันด้านบน

1
สามเหรียญต่อชั่วโมง ไม่น่าแปลกใจที่คุณปฏิเสธไม่ได้เลยแม้แต่น้อยวันนี้? ;)
Piskvor
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.