ในปี 1999 Refsnes ข้อมูลการพัฒนารุ่นแรกของ AppML
แล้วจากนั้น AppML ก็ขึ้นอยู่กับการร้องขอ HTTP การสื่อสารระหว่างลูกค้าเว็บและเว็บเซิร์ฟเวอร์ ต่อมาวิธีการนี้กลายเป็นที่รู้จักกันดีเป็น AJAX
ในเดือนกันยายน 2000 โครงการพัฒนาสำหรับลูกค้านอร์เวย์ขนาดใหญ่เริ่มต้น เป้าหมายของโครงการคือการแปลงระบบข้อมูลขนาดใหญ่ (ประมาณ 300 โปรแกรม) จากโปรแกรมสก์ท็อป Windows เพื่อการประยุกต์ใช้อินเทอร์เน็ตที่ทันสมัยโดยใช้เพียง AppML
ระบบ AppML ตามที่เปิดตัวในปี 2001 หลายเดือนก่อนกำหนดการเป็นโปรแกรม AJAX เชิงพาณิชย์แห่งแรกของโลก โครงการนี้ได้รับความสำเร็จอย่างมากกับเวลาในการพัฒนาลดลง 75% เมื่อเทียบกับการพัฒนาเว็บสามัญ ตั้งแต่นั้นมาใช้งานใหม่ได้รับการเพิ่มและระบบในขณะนี้ครอบคลุมกว่า 1000 โปรแกรมประยุกต์ที่ทำงาน
ในเดือนกุมภาพันธ์ปี 2015 w3ii เปิดตัว AppML เป็นผลิตภัณฑ์ใหม่ที่เปิดให้ประชาชน
AppML เป้าหมายในการออกแบบ:
- การใช้งาน AppML ต้องเรียกใช้ผ่านทางอินเทอร์เน็ต
- การใช้งาน AppML ต้องแพลตฟอร์ม
- การใช้งาน AppML ต้องใช้มาตรฐานอินเทอร์เน็ตเท่านั้น (HTML, CSS, JavaScript)
- การใช้งาน AppML ต้องสนับสนุนความหลากหลายของความต้องการใช้
- การใช้งาน AppML ต้องเป็นตัวอธิบาย
- การใช้งาน AppML ต้องง่ายต่อการพัฒนาในการดูแลรักษาและการเปลี่ยนแปลง
- การใช้งาน AppML จะต้องพิสูจน์ได้ในอนาคต
ย่อหน้าด้านล่างอธิบาย Refsnes ข้อมูลของวิสัยทัศน์เดิม s (1999) เกี่ยวกับ f งานเว็บ uture
executables จะตาย, JavaScript จะอยู่
executables รวบรวม (compiled from languages like C or Java) ไม่สามารถทำงานบนฮาร์ดแวร์ที่แตกต่างกัน
executables (EXE files, ActiveX and COM objects, DLL-files) เป็นส่วนประกอบที่ป้องกันไม่ให้การพัฒนาโปรแกรมประยุกต์ที่สามารถทำงานผ่านทางอินเทอร์เน็ต
แอพลิเคชันในอนาคตจะไม่ใช้หรือพึ่งพา executables หรือส่วนประกอบอื่น ๆ ที่ติดตั้งบนคอมพิวเตอร์ของลูกค้า
ข้อเสนอแนะของเรา:
เขียนใช้งานในอนาคตของคุณโดยใช้ HTML เท่านั้น, CSS และ JavaScript
ตรวจสอบให้แน่ใจการใช้งานในอนาคตของคุณทำงานในเว็บเบราเซอร์ใด ๆ
การใช้งานเว็บจะบริการทางอินเทอร์เน็ต
ประวัติศาสตร์ที่เต็มไปด้วยขนาดใหญ่เพื่อสร้างการใช้งาน หลายเหล่านี้เสียชีวิตอย่างรวดเร็วเพราะพวกเขาไม่สามารถอยู่รอดได้เปลี่ยนแปลงความต้องการ
การประยุกต์ใช้งานควรมีความยืดหยุ่นทั่วไปและสง่างามปรับตัวเข้ากับการเปลี่ยนแปลงโดยไม่ต้องล่มสลายหรือถูกทำลาย
การประยุกต์ใช้งานควรจะสามารถขนาดจากการสนับสนุนไม่กี่ล้านคำขอต่อวัน
การประยุกต์ใช้งานควรจะสามารถแพร่กระจายจากเซิร์ฟเวอร์หนึ่งไปยังอีกมากมายหรือจะย้ายระหว่างเซิร์ฟเวอร์โดยไม่ทำลายแอพลิเคชัน
การประยุกต์ใช้งานควรจะสามารถที่จะให้ความร่วมมือกับโปรแกรมอื่น ๆ
การประยุกต์ใช้งานไม่ควรมีฝูงใหญ่ของรหัส
การประยุกต์ใช้งานควรจะแบ่งออกเป็นบริการขนาดเล็กที่มีความง่ายในการสร้างและดูแลรักษาง่าย
การประยุกต์ใช้งานควรจะตั้งค่าของบริการอินเทอร์เน็ตที่สามารถส่งข้อมูลที่จะส่งคำขออินเทอร์เน็ต
การประยุกต์ใช้งานควรขอบริการผ่านอินเทอร์เน็ตโปรโตคอลมาตรฐานโดยไม่ต้องรักษาเชื่อมต่อแบบถาวรไปยังเซิร์ฟเวอร์
ข้อเสนอแนะของเรา:
เขียนใช้งานในอนาคตของคุณโดยใช้ SOA ตามอินเทอร์เน็ต (Service Oriented Architecture)
ให้บริการแอพลิเคชันของคุณโดยทั่วไปและมีความยืดหยุ่นและพร้อมที่จะให้บริการที่แตกต่างกันของการร้องขอ
การประยุกต์ใช้งานในอนาคตจะง่ายต่อการสร้างและแก้ไข
ลูกค้าและเซิร์ฟเวอร์จะแลกเปลี่ยนข้อมูลในทางที่เข้าใจง่าย
การประยุกต์ใช้งานจะไม่ได้รับรหัสถ้ามันสามารถหลีกเลี่ยงได้
การประยุกต์ใช้งานจะถูกสร้างขึ้นและแก้ไขโดยรุ่นที่แก้ไขไม่ได้โดยการแก้ไขโค้ด
รายละเอียดพลิเคชันจะสามารถอ่านได้โดยมนุษย์
รายละเอียดการประยุกต์ใช้จะเป็นตัวอธิบาย
การประยุกต์ใช้งานจะถูกเขียนโดยผู้ใช้ไม่ได้เขียนโปรแกรม
ข้อเสนอแนะของเรา:
ใช้แฟ้มข้อความที่อ่านของมนุษย์ที่จะอธิบายให้บริการและให้บริการโดยการดำเนินการคำอธิบายเหล่านี้
ใช้ไฟล์ข้อความ (like JSON files) เพื่ออธิบายการใช้งาน
ใช้ไฟล์ข้อความ (like JSON files) เพื่อแลกเปลี่ยนข้อมูล
ใช้ HTML, CSS และ JavaScript เพื่อดำเนินการใช้งาน
สามนักพัฒนาเว็บเล็ก ๆ น้อย ๆ ...
กาลครั้งหนึ่งมีสามนักพัฒนาเว็บเล็ก ๆ น้อย ๆ ในการพัฒนาเว็บไซต์ใหม่
1. การพัฒนาเว็บแรกที่ถูกใช้ AppML
2. การพัฒนาเว็บที่สองคือการใช้ภาษาการเขียนโปรแกรมเซิร์ฟเวอร์ที่เขาชื่นชอบ
3. ที่สามใช้กรอบการพัฒนาเว็บองค์กรมืออาชีพ
นักพัฒนาเว็บแรกมีการสาธิตและทำงานในสองวัน หลังจากทำงานร่วมกันกับผู้ใช้ต้นแบบออกก็พร้อมในหนึ่งสัปดาห์ และหลังจากสองสัปดาห์ของการทดสอบอัจฉริยะได้อย่างรวดเร็วและง่ายต่อการใช้เว็บไซต์ก็พร้อมที่จะเผยแพร่
นักพัฒนาเว็บที่สองมีเว็บไซต์ของเขาพร้อมที่ภายหลัง 6 เดือน แต่รายละเอียดที่มีการเปลี่ยนแปลงความต้องการของตนและไม่พอใจ นักพัฒนาเว็บที่ไม่สามารถทำให้การเปลี่ยนแปลงที่สำคัญให้กับโครงการของเขาเพราะมันมีรหัสมากเกินไป ดังนั้นเขาจึงเริ่มต้นการพัฒนารุ่นที่ 2
นักพัฒนาเว็บที่สามไม่เคยมีการจัดการเพื่อให้การทำงานของเขา กรอบการพัฒนาเว็บมืออาชีพเป็นเรื่องยากมากที่จะใช้เรื่องยากมากที่จะเข้าใจและเกือบจะเป็นไปไม่ได้ที่จะทดสอบ
ลองดูที่วิธีการที่นักพัฒนาแรกก็กระทำ