ລາຄາຂອງກອບ JavaScript

ບໍ່ມີວິທີທີ່ໄວກວ່າທີ່ຈະຊ້າລົງເວັບໄຊທ໌ (ບໍ່ມີຈຸດມຸ່ງຫມາຍ) ກ່ວາການແລ່ນລະຫັດ JavaScript ຢູ່ໃນມັນ. ເມື່ອໃຊ້ JavaScript, ທ່ານຕ້ອງຈ່າຍຄ່າມັນໃນການປະຕິບັດໂຄງການຢ່າງຫນ້ອຍສີ່ຄັ້ງ. ນີ້ແມ່ນສິ່ງທີ່ລະຫັດ JavaScript ຂອງເວັບໄຊທ໌ໂຫລດລະບົບຂອງຜູ້ໃຊ້ກັບ:

• ກຳລັງອັບໂຫລດໄຟລ໌ຜ່ານເຄືອຂ່າຍ.
• ການແຍກວິເຄາະ ແລະລວບລວມລະຫັດແຫຼ່ງທີ່ບໍ່ໄດ້ບັນຈຸຫຼັງຈາກການດາວໂຫຼດ.
• ປະຕິບັດລະຫັດ JavaScript.
• ການບໍລິໂພກຄວາມຊົງຈໍາ.

ການປະສົມປະສານນີ້ກາຍເປັນ ແພງ​ຫຼາຍ.

ແລະພວກເຮົາກໍາລັງລວມເອົາລະຫັດ JS ຫຼາຍຂຶ້ນໃນໂຄງການຂອງພວກເຮົາ. ໃນຂະນະທີ່ອົງການຈັດຕັ້ງກ້າວໄປສູ່ເວັບໄຊທ໌ທີ່ຂັບເຄື່ອນໂດຍກອບແລະຫ້ອງສະຫມຸດເຊັ່ນ React, Vue ແລະອື່ນໆ, ພວກເຮົາເຮັດໃຫ້ການເຮັດວຽກຫຼັກຂອງເວັບໄຊທ໌ແມ່ນຂຶ້ນກັບ JavaScript.

ຂ້ອຍໄດ້ເຫັນເວັບໄຊທ໌ທີ່ຮຸນແຮງຫຼາຍໂດຍໃຊ້ກອບ JavaScript. ແຕ່ວິໄສທັດຂອງຂ້ອຍກ່ຽວກັບບັນຫາແມ່ນມີຄວາມລໍາອຽງຢ່າງແຂງແຮງ. ຄວາມຈິງແລ້ວແມ່ນວ່າບໍລິສັດທີ່ຂ້ອຍເຮັດວຽກກັບມາຫາຂ້ອຍຢ່າງແນ່ນອນເພາະວ່າພວກເຂົາມີບັນຫາການປະຕິບັດເວັບໄຊທ໌ທີ່ສັບສົນ. ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າຈຶ່ງຢາກຮູ້ວ່າບັນຫານີ້ແຜ່ຫຼາຍເທົ່າໃດ, ແລະ “ຄ່າປັບໃໝ” ທີ່ພວກເຮົາຈະຈ່າຍແນວໃດ ເມື່ອພວກເຮົາເລືອກກອບໜຶ່ງ ຫຼືກອບອື່ນເປັນພື້ນຖານຂອງເວັບໄຊໃດໜຶ່ງ.

ໂຄງ​ການ​ນີ້​ໄດ້​ຊ່ວຍ​ຂ້າ​ພະ​ເຈົ້າ​ຄິດ​ອອກ​ນີ້​. ຮວບຮວມ HTTP.

ຂໍ້ມູນ

ໂຄງການ HTTP Archive ຕິດຕາມຈໍານວນ 4308655 ລິ້ງໄປຫາເວັບໄຊທ໌ desktop ປົກກະຕິແລະ 5484239 ເຊື່ອມຕໍ່ກັບເວັບໄຊທ໌ມືຖື. ໃນບັນດາຕົວຊີ້ວັດຈໍານວນຫຼາຍທີ່ກ່ຽວຂ້ອງກັບການເຊື່ອມຕໍ່ເຫຼົ່ານີ້ແມ່ນບັນຊີລາຍຊື່ຂອງເຕັກໂນໂລຢີທີ່ພົບເຫັນຢູ່ໃນສະຖານທີ່ທີ່ສອດຄ້ອງກັນ. ນີ້ຫມາຍຄວາມວ່າພວກເຮົາສາມາດເອົາຕົວຢ່າງຫລາຍພັນເວັບໄຊທ໌ທີ່ໃຊ້ກອບແລະຫ້ອງສະຫມຸດທີ່ແຕກຕ່າງກັນແລະຮຽນຮູ້ວ່າພວກເຂົາສົ່ງລະຫັດໃຫ້ລູກຄ້າຫຼາຍປານໃດແລະຈໍານວນລະຫັດນັ້ນໃສ່ໃນລະບົບຂອງຜູ້ໃຊ້.

ຂ້ອຍເກັບກຳຂໍ້ມູນຈາກເດືອນມີນາ 2020, ເຊິ່ງເປັນຂໍ້ມູນຫຼ້າສຸດທີ່ຂ້ອຍເຂົ້າເຖິງໄດ້.

ຂ້ອຍໄດ້ຕັດສິນໃຈປຽບທຽບຂໍ້ມູນ HTTP Archive ທີ່ລວບລວມສໍາລັບທຸກເວັບໄຊທ໌ທີ່ມີຂໍ້ມູນສໍາລັບເວັບໄຊທ໌ທີ່ພົບວ່າໃຊ້ React, Vue, ແລະ Angular, ເຖິງແມ່ນວ່າຂ້ອຍໄດ້ພິຈາລະນາໃຊ້ອຸປະກອນແຫຼ່ງອື່ນໆເຊັ່ນກັນ.

ເພື່ອເຮັດໃຫ້ມັນຫນ້າສົນໃຈຫຼາຍ, ຂ້ອຍຍັງໄດ້ເພີ່ມເວັບໄຊທ໌ທີ່ໃຊ້ jQuery ໃສ່ຊຸດຂໍ້ມູນແຫຼ່ງ. ຫ້ອງສະຫມຸດນີ້ຍັງມີຄວາມນິຍົມຫຼາຍ. ມັນຍັງແນະນໍາວິທີການພັດທະນາເວັບໄຊທ໌ທີ່ແຕກຕ່າງຈາກຮູບແບບຄໍາຮ້ອງສະຫມັກຫນ້າດຽວ (SPA) ທີ່ສະເຫນີໂດຍ React, Vue ແລະ Angular.

ລິ້ງຄ໌ໃນ HTTP Archive ເປັນຕົວແທນຂອງສະຖານທີ່ທີ່ພົບເຫັນວ່າກໍາລັງໃຊ້ເຕັກໂນໂລຢີທີ່ພວກເຮົາສົນໃຈ.

ກອບຫຼືຫ້ອງສະຫມຸດ
ການເຊື່ອມຕໍ່ກັບເວັບໄຊທ໌ມືຖື
ການເຊື່ອມຕໍ່ກັບສະຖານທີ່ປົກກະຕິ

jQuery
4615474
3714643

React
489827
241023

Vue
85649
43691

Angular
19423
18088

ຄວາມຫວັງ ແລະຄວາມຝັນ

ກ່ອນທີ່ພວກເຮົາຈະກ້າວໄປສູ່ການວິເຄາະຂໍ້ມູນ, ຂ້ອຍຢາກເວົ້າກ່ຽວກັບສິ່ງທີ່ຂ້ອຍຢາກຫວັງ.

ຂ້າ​ພະ​ເຈົ້າ​ເຊື່ອ​ວ່າ​ໃນ​ໂລກ​ທີ່​ເຫມາະ​ສົມ, ໂຄງ​ຮ່າງ​ການ​ຈະ​ໄປ​ເກີນ​ກວ່າ​ການ​ຕອບ​ສະ​ຫນອງ​ຄວາມ​ຕ້ອງ​ການ​ຂອງ​ຜູ້​ພັດ​ທະ​ນາ​ແລະ​ໃຫ້​ຜົນ​ປະ​ໂຫຍດ​ທີ່​ແນ່​ນອນ​ບາງ​ຢ່າງ​ໃຫ້​ຜູ້​ຊົມ​ໃຊ້​ປະ​ຈໍາ​ວັນ​ຂອງ​ເວັບ​ໄຊ​ຂອງ​ພວກ​ເຮົາ. ຜົນຜະລິດແມ່ນພຽງແຕ່ຫນຶ່ງໃນຜົນປະໂຫຍດເຫຼົ່ານັ້ນ. ການ​ເຂົ້າ​ເຖິງ​ແລະ​ຄວາມ​ປອດ​ໄພ​ຍັງ​ມາ​ໃຈ​ຢູ່​ທີ່​ນີ້​. ແຕ່ນີ້ແມ່ນພຽງແຕ່ສິ່ງທີ່ສໍາຄັນທີ່ສຸດ.

ດັ່ງນັ້ນ, ໃນໂລກທີ່ເຫມາະສົມ, ບາງປະເພດຂອງກອບຄວນຈະເຮັດໃຫ້ມັນງ່າຍຕໍ່ການສ້າງເວັບໄຊທ໌ທີ່ມີປະສິດທິພາບສູງ. ນີ້ຄວນຈະເຮັດໄດ້ເນື່ອງຈາກຄວາມຈິງທີ່ວ່າກອບດັ່ງກ່າວເຮັດໃຫ້ນັກພັດທະນາມີພື້ນຖານທີ່ເຫມາະສົມທີ່ຈະສ້າງໂຄງການ, ຫຼືຍ້ອນຄວາມຈິງທີ່ວ່າມັນວາງຂໍ້ຈໍາກັດໃນການພັດທະນາ, ວາງຄວາມຕ້ອງການສໍາລັບມັນທີ່ເຮັດໃຫ້ມັນຍາກທີ່ຈະພັດທະນາບາງສິ່ງບາງຢ່າງ. ນັ້ນກາຍເປັນຊ້າ.

ຂອບວຽກທີ່ດີທີ່ສຸດຄວນເຮັດທັງສອງຢ່າງ: ໃຫ້ພື້ນຖານທີ່ດີ, ແລະວາງຂໍ້ຈໍາກັດໃນການເຮັດວຽກທີ່ຊ່ວຍໃຫ້ທ່ານບັນລຸຜົນໄດ້ຮັບທີ່ເຫມາະສົມ.

ການວິເຄາະຄ່າປານກາງຂອງຂໍ້ມູນຈະບໍ່ໃຫ້ພວກເຮົາຂໍ້ມູນທີ່ພວກເຮົາຕ້ອງການ. ແລະ, ໃນຄວາມເປັນຈິງ, ວິທີການນີ້ອອກຈາກຄວາມສົນໃຈຂອງພວກເຮົາ ຫຼາຍສິ່ງທີ່ສໍາຄັນ. ແທນທີ່ຈະ, ຂ້ອຍໄດ້ຄະແນນສ່ວນຮ້ອຍຈາກຂໍ້ມູນທີ່ຂ້ອຍມີ. ເຫຼົ່ານີ້ແມ່ນ 10, 25, 50 (ປານກາງ), 75, 90 ເປີເຊັນ.

ຂ້ອຍສົນໃຈໂດຍສະເພາະໃນສ່ວນຮ້ອຍທີ 10 ແລະ 90. ເປີເຊັນທີ 10 ສະແດງໃຫ້ເຫັນເຖິງການປະຕິບັດທີ່ດີທີ່ສຸດ (ຫຼືຢ່າງຫນ້ອຍຫຼາຍຫຼືຫນ້ອຍຢູ່ໃກ້ກັບທີ່ດີທີ່ສຸດ) ສໍາລັບກອບສະເພາະ. ໃນຄໍາສັບຕ່າງໆອື່ນໆ, ນີ້ຫມາຍຄວາມວ່າພຽງແຕ່ 10% ຂອງເວັບໄຊທ໌ທີ່ໃຊ້ກອບສະເພາະສາມາດບັນລຸລະດັບນີ້, ຫຼືລະດັບທີ່ສູງກວ່າ. ສ່ວນຮ້ອຍທີ 90, ໃນທາງກົງກັນຂ້າມ, ແມ່ນອີກດ້ານຫນຶ່ງຂອງຫຼຽນ - ມັນສະແດງໃຫ້ເຫັນພວກເຮົາວ່າສິ່ງທີ່ບໍ່ດີສາມາດເປັນແນວໃດ. ເປີເຊັນທີ 90 ແມ່ນສະຖານທີ່ຕິດຕາມ - 10% ສຸດທ້າຍຂອງເວັບໄຊທີ່ມີລະຫັດ JS ທີ່ໃຫຍ່ທີ່ສຸດຫຼືໃຊ້ເວລາດົນທີ່ສຸດທີ່ຕ້ອງການເພື່ອປະມວນຜົນລະຫັດຂອງພວກເຂົາໃນຫົວຂໍ້ຕົ້ນຕໍ.

ປະລິມານຂອງລະຫັດ JavaScript

ເພື່ອເລີ່ມຕົ້ນດ້ວຍ, ມັນມີຄວາມຮູ້ສຶກທີ່ຈະວິເຄາະຂະຫນາດຂອງລະຫັດ JavaScript ທີ່ສົ່ງໂດຍສະຖານທີ່ຕ່າງໆໃນເຄືອຂ່າຍ.

ຈໍານວນລະຫັດ JavaScript (KB) ທີ່ໂອນໄປຫາອຸປະກອນມືຖື

ເປີເຊັນ
10
25
50
75
90

ສະຖານທີ່ທັງຫມົດ
93.4 
196.6 
413.5 
746.8 
1201.6 

ເວັບໄຊທ໌ jQuery
110.3 
219.8 
430.4 
748.6 
1162.3 

ເວັບໄຊທ໌ Vue
244.7 
409.3 
692.1 
1065.5 
1570.7 

ເວັບໄຊທ໌ Angular
445.1 
675.6 
1066.4 
1761.5 
2893.2 

React ເວັບໄຊທ໌
345.8 
441.6 
690.3 
1238.5 
1893.6 

ຈໍານວນລະຫັດ JavaScript ທີ່ຖືກສົ່ງໄປຫາອຸປະກອນມືຖື

ຈໍານວນລະຫັດ JavaScript (KB) ທີ່ໂອນໄປຫາອຸປະກອນ desktop

ເປີເຊັນ
10
25
50
75
90

ສະຖານທີ່ທັງຫມົດ
105.5 
226.6 
450.4 
808.8 
1267.3 

ເວັບໄຊທ໌ jQuery
121.7 
242.2 
458.3 
803.4 
1235.3 

ເວັບໄຊທ໌ Vue
248.0 
420.1 
718.0 
1122.5 
1643.1 

ເວັບໄຊທ໌ Angular
468.8 
716.9 
1144.2 
1930.0 
3283.1 

React ເວັບໄຊທ໌
308.6 
469.0 
841.9 
1472.2 
2197.8 

ຈໍານວນລະຫັດ JavaScript ທີ່ໂອນໄປຫາອຸປະກອນ desktop

ຖ້າພວກເຮົາເວົ້າພຽງແຕ່ກ່ຽວກັບຂະຫນາດຂອງລະຫັດ JS ທີ່ເວັບໄຊທ໌ສົ່ງໄປຫາອຸປະກອນ, ຫຼັງຈາກນັ້ນທຸກສິ່ງທຸກຢ່າງຈະເບິ່ງຕາມທີ່ທ່ານອາດຈະຄາດຫວັງ. ຄື, ຖ້າຫນຶ່ງໃນກອບຖືກນໍາໃຊ້, ນີ້ຫມາຍຄວາມວ່າເຖິງແມ່ນວ່າໃນສະຖານະການທີ່ເຫມາະສົມ, ປະລິມານຂອງລະຫັດ JavaScript ສໍາລັບເວັບໄຊທ໌ຈະເພີ່ມຂຶ້ນ. ນີ້ບໍ່ແປກໃຈ - ທ່ານບໍ່ສາມາດສ້າງກອບ JavaScript ເປັນພື້ນຖານຂອງເວັບໄຊທ໌ແລະຄາດວ່າຈໍານວນລະຫັດ JS ສໍາລັບໂຄງການຈະຕໍ່າຫຼາຍ.

ສິ່ງທີ່ຫນ້າສົນໃຈກ່ຽວກັບຂໍ້ມູນນີ້ແມ່ນວ່າບາງກອບແລະຫ້ອງສະຫມຸດອາດຈະຖືວ່າເປັນຈຸດເລີ່ມຕົ້ນທີ່ດີກວ່າສໍາລັບໂຄງການອື່ນ. ເວັບໄຊທ໌ທີ່ມີ jQuery ເບິ່ງດີທີ່ສຸດ. ເວັບໄຊທ໌ desktop ຂອງພວກເຂົາມີ 15% ຫຼາຍກວ່າ JavaScript ຫຼາຍກວ່າເວັບໄຊທ໌ທັງຫມົດ, ແລະເວັບໄຊທ໌ມືຖືຂອງພວກເຂົາມີ JavaScript ຫຼາຍກວ່າ 18%. (ຍອມຮັບວ່າ, ມີຂໍ້ມູນບາງອັນຢູ່ນີ້, ຄວາມຈິງແມ່ນວ່າ jQuery ແມ່ນມີຢູ່ໃນຫຼາຍເວັບໄຊທ໌, ດັ່ງນັ້ນມັນເປັນທໍາມະຊາດທີ່ສະຖານທີ່ດັ່ງກ່າວມີຄວາມກ່ຽວຂ້ອງຢ່າງໃກ້ຊິດກັບຈໍານວນເວັບໄຊທ໌ທັງຫມົດຫຼາຍກ່ວາບ່ອນອື່ນ. ແຫຼ່ງຂໍ້ມູນແມ່ນຜົນຜະລິດສໍາລັບແຕ່ລະກອບ.)

ໃນຂະນະທີ່ການເຕີບໂຕຂອງລະຫັດ 15-18% ແມ່ນຕົວເລກທີ່ສໍາຄັນ, ເມື່ອປຽບທຽບກັບກອບແລະຫ້ອງສະຫມຸດອື່ນໆ, ພາສີທີ່ jQuery ກໍານົດແມ່ນຕໍ່າຫຼາຍ. ເວັບໄຊທ໌ Angular ໃນເປີເຊັນທີ 10 ສົ່ງຂໍ້ມູນ 344% ໄປຫາອຸປະກອນ desktop ຫຼາຍກວ່າເວັບໄຊທ໌ທັງຫມົດ, ແລະ 377% ເພີ່ມເຕີມຕໍ່ກັບອຸປະກອນມືຖື. ເວັບໄຊທ໌ React ແມ່ນຫນັກທີ່ສຸດຕໍ່ໄປ, ສົ່ງລະຫັດ 193% ໄປຫາອຸປະກອນ desktop ຫຼາຍກວ່າເວັບໄຊທ໌ທັງຫມົດ, ແລະ 270% ເພີ່ມເຕີມໄປຫາອຸປະກອນມືຖື.

ຂ້າພະເຈົ້າໄດ້ກ່າວເຖິງກ່ອນຫນ້ານີ້ວ່າເຖິງແມ່ນວ່າການນໍາໃຊ້ກອບຫມາຍຄວາມວ່າຈໍານວນລະຫັດທີ່ແນ່ນອນຈະຖືກລວມເຂົ້າໃນໂຄງການໃນຕອນເລີ່ມຕົ້ນຂອງການເຮັດວຽກກ່ຽວກັບມັນ, ຂ້າພະເຈົ້າຫວັງວ່າກອບສາມາດຈໍາກັດຜູ້ພັດທະນາໄດ້. ໂດຍສະເພາະ, ພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບການຈໍາກັດຈໍານວນລະຫັດສູງສຸດ.

ສິ່ງທີ່ຫນ້າສົນໃຈແມ່ນວ່າເວັບໄຊທ໌ jQuery ປະຕິບັດຕາມຄວາມຄິດນີ້. ເຖິງແມ່ນວ່າພວກເຂົາ, ຢູ່ໃນລະດັບເປີເຊັນທີ 10, ແມ່ນເລັກນ້ອຍກວ່າທຸກເວັບໄຊທ໌ (ໂດຍ 15-18%), ພວກເຂົາຢູ່ໃນລະດັບເປີເຊັນທີ 90, ເລັກນ້ອຍກວ່າທຸກເວັບໄຊທ໌ - ປະມານ 3% ໃນທັງສະບັບ desktop ແລະມືຖື. ນີ້ບໍ່ແມ່ນການເວົ້າວ່ານີ້ແມ່ນຜົນປະໂຫຍດທີ່ສໍາຄັນ, ແຕ່ມັນສາມາດເວົ້າໄດ້ວ່າເວັບໄຊທ໌ jQuery ຢ່າງຫນ້ອຍບໍ່ມີຂະຫນາດລະຫັດ JavaScript ຂະຫນາດໃຫຍ່ເຖິງແມ່ນວ່າຢູ່ໃນສະບັບທີ່ໃຫຍ່ທີ່ສຸດຂອງພວກເຂົາ.

ແຕ່ສິ່ງດຽວກັນບໍ່ສາມາດເວົ້າໄດ້ກ່ຽວກັບກອບອື່ນໆ.

ເຊັ່ນດຽວກັບໃນກໍລະນີຂອງເປີເຊັນທີ 10, ຢູ່ທີ່ສະຖານທີ່ເປີເຊັນທີ 90 ໃນ Angular ແລະ React ແຕກຕ່າງຈາກສະຖານທີ່ອື່ນໆ, ແຕ່ພວກເຂົາແຕກຕ່າງກັນ, ແຕ່ຫນ້າເສຍດາຍ, ສໍາລັບຮ້າຍແຮງກວ່າເກົ່າ.

ຢູ່ທີ່ເປີເຊັນທີ 90, ເວັບໄຊທ໌ Angular ສົ່ງຂໍ້ມູນ 141% ໄປຫາອຸປະກອນມືຖືຫຼາຍກວ່າເວັບໄຊທ໌ທັງຫມົດ, ແລະ 159% ເພີ່ມເຕີມຕໍ່ກັບອຸປະກອນ desktop. ເວັບໄຊທ໌ React ສົ່ງ 73% ໄປຫາອຸປະກອນ desktop ຫຼາຍກວ່າເວັບໄຊທ໌ທັງຫມົດ, ແລະ 58% ເພີ່ມເຕີມຕໍ່ກັບອຸປະກອນມືຖື. ຂະໜາດລະຫັດຂອງ React sites ຢູ່ທີ່ 90 ເປີເຊັນແມ່ນ 2197.8 KB. ນີ້ຫມາຍຄວາມວ່າສະຖານທີ່ເຫຼົ່ານີ້ສົ່ງຂໍ້ມູນ 322.9 KB ໄປຫາອຸປະກອນມືຖືຫຼາຍກ່ວາຄູ່ແຂ່ງທີ່ໃກ້ຄຽງ Vue. ຊ່ອງຫວ່າງລະຫວ່າງເວັບໄຊທ໌ desktop ໂດຍອີງໃສ່ Angular ແລະ React ແລະສະຖານທີ່ອື່ນໆແມ່ນຫຼາຍກວ່າເກົ່າ. ຕົວຢ່າງ, ເວັບໄຊທ໌ React desktop ສົ່ງລະຫັດ JS ຫຼາຍກວ່າ 554.7 KB ໄປຫາອຸປະກອນຫຼາຍກວ່າເວັບໄຊທ໌ Vue ທີ່ຄ້າຍຄືກັນ.

ໃຊ້ເວລາໃນການປະມວນຜົນລະຫັດ JavaScript ໃນຫົວຂໍ້ຕົ້ນຕໍ

ຂໍ້ມູນຂ້າງເທິງຊີ້ໃຫ້ເຫັນຢ່າງຊັດເຈນວ່າສະຖານທີ່ທີ່ໃຊ້ກອບແລະຫ້ອງສະຫມຸດທີ່ສຶກສາມີລະຫັດ JavaScript ຈໍານວນຫລາຍ. ແຕ່, ແນ່ນອນ, ນີ້ແມ່ນພຽງແຕ່ສ່ວນຫນຶ່ງຂອງສົມຜົນຂອງພວກເຮົາ.

ຫຼັງຈາກລະຫັດ JavaScript ໄດ້ມາຮອດຕົວທ່ອງເວັບ, ມັນຈໍາເປັນຕ້ອງຖືກນໍາໄປສູ່ສະຖານະເຮັດວຽກ. ໂດຍສະເພາະແມ່ນບັນຫາຈໍານວນຫຼາຍແມ່ນເກີດມາຈາກການກະທໍາເຫຼົ່ານັ້ນທີ່ຕ້ອງໄດ້ປະຕິບັດກັບລະຫັດໃນຫົວຂໍ້ຂອງຕົວທ່ອງເວັບຕົ້ນຕໍ. ກະທູ້ຕົ້ນຕໍແມ່ນຮັບຜິດຊອບສໍາລັບການປຸງແຕ່ງການປະຕິບັດຂອງຜູ້ໃຊ້, ການຄິດໄລ່ຮູບແບບ, ແລະການກໍ່ສ້າງແລະສະແດງຮູບແບບຫນ້າ. ຖ້າທ່ານ overwhelm ກະທູ້ຕົ້ນຕໍກັບວຽກງານ JavaScript, ມັນຈະບໍ່ມີໂອກາດທີ່ຈະເຮັດສໍາເລັດວຽກງານອື່ນໆໃນລັກສະນະທີ່ທັນເວລາ. ນີ້ນໍາໄປສູ່ການຊັກຊ້າແລະ "ເບກ" ໃນການເຮັດວຽກຂອງຫນ້າ.

ຖານຂໍ້ມູນ HTTP Archive ມີຂໍ້ມູນກ່ຽວກັບໄລຍະເວລາທີ່ມັນໃຊ້ເວລາໃນການປະມວນຜົນລະຫັດ JavaScript ໃນຫົວຂໍ້ຕົ້ນຕໍຂອງເຄື່ອງຈັກ V8. ນີ້ ໝາຍ ຄວາມວ່າພວກເຮົາສາມາດເກັບ ກຳ ຂໍ້ມູນນີ້ແລະຮຽນຮູ້ວ່າກະທູ້ຫຼັກໃຊ້ເວລາເທົ່າໃດເພື່ອປະມວນຜົນ JavaScript ຂອງສະຖານທີ່ຕ່າງໆ.

ເວລາ CPU (ເປັນມິນລິວິນາທີ) ກ່ຽວຂ້ອງກັບການປະມວນຜົນສະຄຣິບໃນອຸປະກອນມືຖື

ເປີເຊັນ
10
25
50
75
90

ສະຖານທີ່ທັງຫມົດ
356.4
959.7
2372.1
5367.3
10485.8

ເວັບໄຊທ໌ jQuery
575.3
1147.4
2555.9
5511.0
10349.4

ເວັບໄຊທ໌ Vue
1130.0
2087.9
4100.4
7676.1
12849.4

ເວັບໄຊທ໌ Angular
1471.3
2380.1
4118.6
7450.8
13296.4

React ເວັບໄຊທ໌
2700.1
5090.3
9287.6
14509.6
20813.3

ເວລາ CPU ກ່ຽວຂ້ອງກັບການປະມວນຜົນສະຄຣິບໃນອຸປະກອນມືຖື

ເວລາ CPU (ເປັນມິນລິວິນາທີ) ກ່ຽວຂ້ອງກັບການປະມວນຜົນສະຄຣິບໃນອຸປະກອນເດັສທັອບ

ເປີເຊັນ
10
25
50
75
90

ສະຖານທີ່ທັງຫມົດ
146.0
351.8
831.0
1739.8
3236.8

ເວັບໄຊທ໌ jQuery
199.6
399.2
877.5
1779.9
3215.5

ເວັບໄຊທ໌ Vue
350.4
650.8
1280.7
2388.5
4010.8

ເວັບໄຊທ໌ Angular
482.2
777.9
1365.5
2400.6
4171.8

React ເວັບໄຊທ໌
508.0
1045.6
2121.1
4235.1
7444.3

ເວລາ CPU ກ່ຽວຂ້ອງກັບການປະມວນຜົນສະຄຣິບໃນອຸປະກອນເດັສທັອບ

ໃນທີ່ນີ້ທ່ານສາມາດເບິ່ງສິ່ງທີ່ຄຸ້ນເຄີຍຫຼາຍ.

ສໍາລັບການເລີ່ມຕົ້ນ, ເວັບໄຊທ໌ທີ່ມີ jQuery ໃຊ້ການປຸງແຕ່ງ JavaScript ຫນ້ອຍລົງຢ່າງຫຼວງຫຼາຍໃນຫົວຂໍ້ຕົ້ນຕໍກ່ວາບ່ອນອື່ນ. ຢູ່ທີ່ເປີເຊັນທີ 10, ເມື່ອປຽບທຽບກັບເວັບໄຊທ໌ທັງຫມົດ, ເວັບໄຊທ໌ jQuery ໃນອຸປະກອນມືຖືໃຊ້ເວລາຫຼາຍກວ່າ 61% ໃນການປຸງແຕ່ງລະຫັດ JS ໃນຫົວຂໍ້ຕົ້ນຕໍ. ໃນກໍລະນີຂອງເວັບໄຊທ໌ desktop jQuery, ເວລາປຸງແຕ່ງເພີ່ມຂຶ້ນ 37%. ໃນອັດຕາສ່ວນຮ້ອຍທີ 90, ຄະແນນຂອງສະຖານທີ່ jQuery ແມ່ນໃກ້ຊິດກັບຄະແນນລວມ. ໂດຍສະເພາະ, ສະຖານທີ່ jQuery ໃນອຸປະກອນມືຖືໃຊ້ເວລາ 1.3% ຫນ້ອຍໃນຫົວຂໍ້ຕົ້ນຕໍກ່ວາເວັບໄຊທ໌ທັງຫມົດ, ແລະໃນອຸປະກອນ desktop ເຂົາເຈົ້າໃຊ້ເວລາຫນ້ອຍລົງ 0.7% ໃນຫົວຂໍ້ຕົ້ນຕໍ.

ໃນອີກດ້ານຫນຶ່ງຂອງການຈັດອັນດັບຂອງພວກເຮົາແມ່ນກອບທີ່ຖືກກໍານົດໂດຍການໂຫຼດທີ່ໃຫຍ່ທີ່ສຸດໃນຫົວຂໍ້ຕົ້ນຕໍ. ນີ້ແມ່ນ, ອີກເທື່ອຫນຶ່ງ, Angular ແລະ React. ຄວາມແຕກຕ່າງພຽງແຕ່ລະຫວ່າງພວກມັນແມ່ນວ່າ, ເຖິງແມ່ນວ່າເວັບໄຊທ໌ Angular ສົ່ງລະຫັດຈໍານວນຫຼວງຫຼາຍໄປຫາຕົວທ່ອງເວັບຫຼາຍກ່ວາເວັບໄຊທ໌ React, ມັນໃຊ້ເວລາ CPU ຫນ້ອຍເພື່ອປະມວນຜົນລະຫັດຂອງ Angular sites. ຫນ້ອຍ.

ຢູ່ທີ່ເປີເຊັນທີ 10, Angular desktop sites ໃຊ້ເວລາປະມວນຜົນລະຫັດ JS 230% ຫຼາຍກວ່າທຸກເວັບໄຊທ໌. ສໍາລັບເວັບໄຊທ໌ມືຖືຕົວເລກນີ້ແມ່ນ 313%. ສະຖານທີ່ React ມີການປະຕິບັດທີ່ບໍ່ດີທີ່ສຸດ. ໃນອຸປະກອນ desktop ພວກເຂົາເຈົ້າໃຊ້ເວລາ 248% ລະຫັດປະມວນຜົນຫຼາຍກ່ວາເວັບໄຊທ໌ທັງຫມົດ, ແລະໃນອຸປະກອນມືຖືພວກເຂົາໃຊ້ເວລາຫຼາຍກວ່າ 658% ລະຫັດປະມວນຜົນ. 658% ບໍ່ແມ່ນ typo. ຢູ່ທີ່ເປີເຊັນທີ 10, ສະຖານທີ່ React ໃຊ້ເວລາ 2.7 ວິນາທີຂອງຫົວຂໍ້ຫຼັກໃນການປະມວນຜົນລະຫັດທີ່ມີຢູ່ຂອງພວກເຂົາ.

ຕົວເລກເປີເຊັນທີ 90 ເບິ່ງຄືວ່າດີກວ່າເລັກນ້ອຍເມື່ອປຽບທຽບກັບຕົວເລກຈໍານວນຫຼວງຫຼາຍເຫຼົ່ານີ້. ໂຄງການ Angular, ເມື່ອປຽບທຽບກັບເວັບໄຊທ໌ທັງຫມົດ, ໃຊ້ເວລາຫຼາຍກວ່າ 29% ໃນຫົວຂໍ້ຕົ້ນຕໍໃນອຸປະກອນ desktop, ແລະໃຊ້ເວລາຫຼາຍກວ່າ 27% ໃນອຸປະກອນມືຖື. ໃນກໍລະນີຂອງສະຖານທີ່ React, ຕົວຊີ້ວັດທີ່ຄ້າຍຄືກັນເບິ່ງຄືວ່າ 130% ແລະ 98% ຕາມລໍາດັບ.

ອັດຕາສ່ວນ deviation ສໍາລັບເປີເຊັນທີ 90 ເບິ່ງດີກວ່າຄ່າທີ່ຄ້າຍຄືກັນສໍາລັບເປີເຊັນທີ 10. ແຕ່ໃນທີ່ນີ້ມັນເປັນມູນຄ່າທີ່ຈະຈື່ຈໍາວ່າຕົວເລກທີ່ຊີ້ບອກເວລາເບິ່ງຄືວ່າຂ້ອນຂ້າງຢ້ານ. ໃຫ້ເວົ້າວ່າ - 20.8 ວິນາທີໃນຫົວຂໍ້ຕົ້ນຕໍຂອງອຸປະກອນມືຖືສໍາລັບເວັບໄຊທ໌ທີ່ສ້າງຂຶ້ນໃນ React. (ຂ້າ​ພະ​ເຈົ້າ​ເຊື່ອ​ວ່າ​ເລື່ອງ​ຂອງ​ສິ່ງ​ທີ່​ເກີດ​ຂຶ້ນ​ຢ່າງ​ແທ້​ຈິງ​ໃນ​ໄລ​ຍະ​ນີ້​ແມ່ນ​ມີ​ຄ່າ​ຄວນ​ຂອງ​ບົດ​ຄວາມ​ແຍກ​ຕ່າງ​ຫາກ).

ມີອາການແຊກຊ້ອນທີ່ອາດຈະເກີດຂຶ້ນຢູ່ທີ່ນີ້ (ຂໍຂອບໃຈ Jeremy ສໍາ​ລັບ​ການ​ດຶງ​ດູດ​ຄວາມ​ສົນ​ໃຈ​ຂອງ​ຂ້າ​ພະ​ເຈົ້າ​ກັບ​ຄຸນ​ສົມ​ບັດ​ນີ້​, ແລະ​ສໍາ​ລັບ​ການ​ລະ​ມັດ​ລະ​ວັງ​ການ​ກວດ​ສອບ​ຂໍ້​ມູນ​ຈາກ​ທັດ​ສະ​ນະ​ນີ້​)​. ຄວາມຈິງແລ້ວແມ່ນວ່າຫຼາຍໆສະຖານທີ່ໃຊ້ເຄື່ອງມືດ້ານຫນ້າຫຼາຍອັນ. ໂດຍສະເພາະ, ຂ້ອຍໄດ້ເຫັນຫຼາຍໆເວັບໄຊທ໌ໃຊ້ jQuery ຄຽງຄູ່ກັບ React ຫຼື Vue ຍ້ອນວ່າເວັບໄຊທ໌ເຫຼົ່ານີ້ເຄື່ອນຍ້າຍຈາກ jQuery ໄປຫາກອບຫຼືຫ້ອງສະຫມຸດອື່ນໆ. ດັ່ງນັ້ນ, ຂ້າພະເຈົ້າໄດ້ກັບຄືນໄປຫາຖານຂໍ້ມູນ, ເວລານີ້ເລືອກພຽງແຕ່ການເຊື່ອມຕໍ່ທີ່ກົງກັນກັບເວັບໄຊທ໌ທີ່ໃຊ້ພຽງແຕ່ React, jQuery, Angular ຫຼື Vue, ແຕ່ບໍ່ແມ່ນການປະສົມປະສານໃດໆ. ນີ້ແມ່ນສິ່ງທີ່ຂ້ອຍໄດ້ຮັບ.

ເວລາປະມວນຜົນ (ເປັນ milliseconds) ກ່ຽວຂ້ອງກັບການປະມວນຜົນສະຄຣິບໃນອຸປະກອນມືຖືໃນສະຖານະການທີ່ເວັບໄຊໃຊ້ພຽງແຕ່ກອບຫນຶ່ງຫຼືພຽງແຕ່ຫນຶ່ງຫ້ອງສະຫມຸດ.

ເປີເຊັນ
10
25
50
75
90

ເວັບໄຊທ໌ທີ່ໃຊ້ພຽງແຕ່ jQuery
542.9
1062.2
2297.4
4769.7
8718.2

ເວັບໄຊທີ່ໃຊ້ພຽງແຕ່ Vue
944.0
1716.3
3194.7
5959.6
9843.8

ເວັບໄຊທ໌ທີ່ໃຊ້ພຽງແຕ່ Angular
1328.9
2151.9
3695.3
6629.3
11607.7

ເວັບໄຊທ໌ທີ່ໃຊ້ພຽງແຕ່ React
2443.2
4620.5
10061.4
17074.3
24956.3

ເວລາຂອງໂປເຊດເຊີທີ່ກ່ຽວຂ້ອງກັບການປະມວນຜົນສະຄຣິບໃນອຸປະກອນມືຖືໃນສະຖານະການທີ່ເວັບໄຊທ໌ໃຊ້ພຽງແຕ່ກອບຫນຶ່ງ, ຫຼືຫ້ອງສະຫມຸດດຽວເທົ່ານັ້ນ

ຫນ້າທໍາອິດ, ບາງສິ່ງບາງຢ່າງທີ່ບໍ່ແປກໃຈ: ເມື່ອເວັບໄຊທ໌ຫນຶ່ງໃຊ້ພຽງແຕ່ກອບຫນຶ່ງຫຼືຫ້ອງສະຫມຸດຫນຶ່ງ, ການປະຕິບັດຂອງເວັບໄຊທ໌ດັ່ງກ່າວປັບປຸງເລື້ອຍໆກ່ວາບໍ່. ການປະຕິບັດສໍາລັບແຕ່ລະເຄື່ອງມືເບິ່ງດີກວ່າຢູ່ໃນອັດຕາສ່ວນທີ 10 ແລະ 25th. ມັນເຮັດໃຫ້ຄວາມຮູ້ສຶກ. ເວັບໄຊທີ່ສ້າງຂຶ້ນໂດຍໃຊ້ກອບໜຶ່ງຄວນຈະໄວກວ່າເວັບໄຊທີ່ສ້າງຂຶ້ນໂດຍໃຊ້ກອບ ຫຼືຫ້ອງສະໝຸດສອງ ຫຼືຫຼາຍກວ່ານັ້ນ.

ໃນຄວາມເປັນຈິງ, ຄະແນນສໍາລັບທຸກເຄື່ອງມືດ້ານຫນ້າທີ່ພວກເຮົາກວດສອບເບິ່ງດີກວ່າໃນທຸກກໍລະນີ, ມີຂໍ້ຍົກເວັ້ນທີ່ຢາກຮູ້ຢາກເຫັນ. ສິ່ງທີ່ເຮັດໃຫ້ຂ້ອຍປະຫລາດໃຈແມ່ນວ່າຢູ່ທີ່ 50 ເປີເຊັນແລະສູງກວ່າ, ເວັບໄຊທ໌ທີ່ໃຊ້ React ປະຕິບັດຮ້າຍແຮງກວ່າເກົ່າເມື່ອ React ເປັນຫ້ອງສະຫມຸດດຽວທີ່ພວກເຂົາໃຊ້. ໂດຍວິທີທາງການ, ນີ້ແມ່ນເຫດຜົນທີ່ຂ້ອຍນໍາສະເຫນີຂໍ້ມູນນີ້ຢູ່ທີ່ນີ້.

ນີ້ແມ່ນເລື່ອງແປກເລັກນ້ອຍ, ແຕ່ຂ້ອຍຈະພະຍາຍາມຊອກຫາຄໍາອະທິບາຍສໍາລັບຄວາມແປກປະຫລາດນີ້.

ຖ້າໂຄງການໃດນຶ່ງໃຊ້ທັງ React ແລະ jQuery, ໂຄງການນັ້ນມັກຈະຢູ່ບ່ອນໃດນຶ່ງເຄິ່ງທາງໃນຂະບວນການເຄື່ອນຍ້າຍຈາກ jQuery ໄປຫາ React. ບາງທີລາວມີ codebase ທີ່ຫ້ອງສະຫມຸດເຫຼົ່ານີ້ຖືກປະສົມ. ເນື່ອງຈາກພວກເຮົາໄດ້ເຫັນແລ້ວວ່າເວັບໄຊທ໌ jQuery ໃຊ້ເວລາຫນ້ອຍລົງໃນຫົວຂໍ້ຕົ້ນຕໍກ່ວາເວັບໄຊທ໌ React, ນີ້ອາດຈະບອກພວກເຮົາວ່າການປະຕິບັດຫນ້າທີ່ບາງຢ່າງໃນ jQuery ຊ່ວຍປັບປຸງການປະຕິບັດເວັບໄຊທ໌ເລັກນ້ອຍ.

ແຕ່ຍ້ອນວ່າໂຄງການຍ້າຍຈາກ jQuery ໄປ React ແລະອີງໃສ່ React ຫຼາຍຂຶ້ນ, ສະຖານະການຈະປ່ຽນແປງ. ຖ້າເວັບໄຊທ໌ຖືກສ້າງຂື້ນດ້ວຍຄຸນນະພາບສູງແທ້ໆ, ແລະຜູ້ພັດທະນາເວັບໄຊທ໌ໃຊ້ React ຢ່າງລະມັດລະວັງ, ແລ້ວທຸກຢ່າງຈະດີກັບເວັບໄຊທ໌ດັ່ງກ່າວ. ແຕ່ສໍາລັບເວັບໄຊທ໌ React ໂດຍສະເລ່ຍ, ການນໍາໃຊ້ React ຢ່າງກວ້າງຂວາງຫມາຍຄວາມວ່າຫົວຂໍ້ຕົ້ນຕໍແມ່ນຂຶ້ນກັບການໂຫຼດເພີ່ມຂຶ້ນ.

ຊ່ອງຫວ່າງລະຫວ່າງອຸປະກອນມືຖືແລະ desktop

ອີກວິທີຫນຶ່ງທີ່ຂ້ອຍເບິ່ງຂໍ້ມູນແມ່ນເພື່ອຄົ້ນຫາຊ່ອງຫວ່າງລະຫວ່າງປະສົບການໂທລະສັບມືຖືແລະ desktop. ຖ້າພວກເຮົາເວົ້າກ່ຽວກັບການປຽບທຽບປະລິມານຂອງລະຫັດ JavaScript, ການປຽບທຽບດັ່ງກ່າວບໍ່ໄດ້ເປີດເຜີຍສິ່ງທີ່ຫນ້າຢ້ານກົວ. ແນ່ນອນ, ມັນຈະດີທີ່ຈະເຫັນຈໍານວນລະຫັດທີ່ສາມາດດາວໂຫລດໄດ້ຫນ້ອຍ, ແຕ່ບໍ່ມີຄວາມແຕກຕ່າງກັນຫຼາຍໃນຈໍານວນລະຫັດມືຖືແລະ desktop.

ແຕ່ຖ້າທ່ານວິເຄາະເວລາທີ່ຕ້ອງການເພື່ອປະມວນຜົນລະຫັດ, ຊ່ອງຫວ່າງຂະຫນາດໃຫຍ່ຫຼາຍລະຫວ່າງອຸປະກອນມືຖືແລະ desktop ຈະກາຍເປັນທີ່ສັງເກດເຫັນ.

ເພີ່ມຂຶ້ນໃນເວລາ (ເປັນເປີເຊັນ) ທີ່ກ່ຽວຂ້ອງກັບການປະມວນຜົນ script ໃນອຸປະກອນມືຖືທຽບກັບ desktop

ເປີເຊັນ
10
25
50
75
90

ສະຖານທີ່ທັງຫມົດ
144.1
172.8
185.5
208.5
224.0

ເວັບໄຊທ໌ jQuery
188.2
187.4
191.3
209.6
221.9

ເວັບໄຊທ໌ Vue
222.5
220.8
220.2
221.4
220.4

ເວັບໄຊທ໌ Angular
205.1
206.0
201.6
210.4
218.7

React ເວັບໄຊທ໌
431.5
386.8
337.9
242.6
179.6

ໃນຂະນະທີ່ຄວາມແຕກຕ່າງກັນບາງຢ່າງໃນຄວາມໄວການປະມວນຜົນລະຫັດລະຫວ່າງໂທລະສັບແລະແລັບທັອບແມ່ນຄາດວ່າຈະມີ, ຈໍານວນຂະຫນາດໃຫຍ່ດັ່ງກ່າວບອກຂ້ອຍວ່າກອບທີ່ທັນສະໄຫມບໍ່ໄດ້ຖືກເປົ້າຫມາຍພຽງພໍໃນອຸປະກອນພະລັງງານຕ່ໍາແລະຄວາມປາຖະຫນາທີ່ຈະປິດຊ່ອງຫວ່າງທີ່ໄດ້ກໍານົດໄວ້. ເຖິງແມ່ນວ່າຢູ່ໃນເປີເຊັນທີ 10, ສະຖານທີ່ React ໃຊ້ເວລາ 431.5% ໃນຫົວຂໍ້ຫຼັກຂອງມືຖືຫຼາຍກ່ວາໃນຫົວຂໍ້ຕົ້ນຕໍ desktop. jQuery ມີຊ່ອງຫວ່າງນ້ອຍທີ່ສຸດ, ແຕ່ເຖິງແມ່ນວ່າໃນທີ່ນີ້ຕົວເລກທີ່ສອດຄ້ອງກັນແມ່ນ 188.2%. ເມື່ອຜູ້ພັດທະນາເວັບໄຊທ໌ເຮັດໂຄງການຂອງພວກເຂົາໃນແບບທີ່ເຂົາເຈົ້າຕ້ອງການເວລາ CPU ຫຼາຍຂຶ້ນເພື່ອປຸງແຕ່ງພວກມັນ (ແລະນີ້ແມ່ນສິ່ງທີ່ເກີດຂື້ນ, ແລະມັນພຽງແຕ່ຮ້າຍແຮງຂຶ້ນໃນໄລຍະເວລາ), ເຈົ້າຂອງອຸປະກອນພະລັງງານຕ່ໍາຕ້ອງຈ່າຍຄ່າມັນ.

ຜົນໄດ້ຮັບ

ກອບທີ່ດີຄວນໃຫ້ນັກພັດທະນາມີພື້ນຖານທີ່ດີໃນການກໍ່ສ້າງໂຄງການເວັບ (ໃນດ້ານຄວາມປອດໄພ, ການເຂົ້າເຖິງ, ການປະຕິບັດ), ຫຼືຄວນຈະມີຂໍ້ຈໍາກັດໃນຕົວທີ່ເຮັດໃຫ້ມັນຍາກທີ່ຈະສ້າງບາງສິ່ງບາງຢ່າງທີ່ລະເມີດຂໍ້ຈໍາກັດເຫຼົ່ານັ້ນ.

ນີ້ເບິ່ງຄືວ່າບໍ່ໄດ້ນໍາໃຊ້ກັບການປະຕິບັດໂຄງການເວັບ (ແລະປາກົດຂື້ນກັບພວກເຂົາ ການເຂົ້າເຖິງ).

ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າພຽງແຕ່ຍ້ອນວ່າເວັບໄຊທ໌ React ຫຼື Angular ໃຊ້ເວລາໃນການກະກຽມລະຫັດ CPU ຫຼາຍກ່ວາບ່ອນອື່ນບໍ່ໄດ້ຫມາຍຄວາມວ່າເວັບໄຊທ໌ React ແມ່ນໃຊ້ CPU ຫຼາຍກວ່າເວັບໄຊທ໌ Vue ໃນເວລາທີ່ແລ່ນ. ໃນຄວາມເປັນຈິງ, ຂໍ້ມູນທີ່ພວກເຮົາເບິ່ງຢູ່ເວົ້າຫນ້ອຍຫຼາຍກ່ຽວກັບການປະຕິບັດງານຂອງກອບແລະຫ້ອງສະຫມຸດ. ພວກເຂົາເຈົ້າສົນທະນາເພີ່ມເຕີມກ່ຽວກັບວິທີການພັດທະນາທີ່, ສະຕິຫຼືບໍ່, ກອບເຫຼົ່ານີ້ສາມາດຊຸກດັນໃຫ້ນັກຂຽນໂປລແກລມໄປສູ່. ພວກເຮົາເວົ້າກ່ຽວກັບເອກະສານສໍາລັບກອບ, ລະບົບນິເວດຂອງພວກເຂົາ, ແລະເຕັກນິກການພັດທະນາທົ່ວໄປ.

ມັນຍັງມີມູນຄ່າການກ່າວເຖິງບາງສິ່ງບາງຢ່າງທີ່ພວກເຮົາບໍ່ໄດ້ວິເຄາະຢູ່ທີ່ນີ້, ຄື, ເວລາຫຼາຍປານໃດທີ່ອຸປະກອນໃຊ້ໃນການປະຕິບັດລະຫັດ JavaScript ເມື່ອປ່ຽນລະຫວ່າງຫນ້າຂອງເວັບໄຊທ໌. ການໂຕ້ຖຽງໃນຄວາມໂປດປານຂອງ SPA ແມ່ນວ່າເມື່ອຄໍາຮ້ອງສະຫມັກຫນ້າດຽວຖືກໂຫລດເຂົ້າໄປໃນຕົວທ່ອງເວັບ, ໃນທາງທິດສະດີ, ຜູ້ໃຊ້ຈະສາມາດເຂົ້າເຖິງຫນ້າເວັບໄດ້ໄວຂຶ້ນ. ປະສົບການຂອງຂ້ອຍເອງບອກຂ້ອຍວ່ານີ້ແມ່ນຢູ່ໄກຈາກຄວາມເປັນຈິງ. ແຕ່ພວກເຮົາບໍ່ມີຂໍ້ມູນເພື່ອຊີ້ແຈງບັນຫານີ້.

ສິ່ງທີ່ຊັດເຈນແມ່ນວ່າຖ້າທ່ານໃຊ້ກອບຫຼືຫ້ອງສະຫມຸດເພື່ອສ້າງເວັບໄຊທ໌, ທ່ານກໍາລັງເຮັດການປະນີປະນອມໃນເງື່ອນໄຂຂອງການໂຫຼດໂຄງການໃນເບື້ອງຕົ້ນແລະກຽມພ້ອມທີ່ຈະໄປ. ນີ້ໃຊ້ໄດ້ແມ້ແຕ່ກັບສະຖານະການໃນທາງບວກທີ່ສຸດ.

ມັນເປັນໄປໄດ້ທີ່ຈະເຮັດໃຫ້ການປະນີປະນອມບາງຢ່າງໃນສະຖານະການທີ່ເຫມາະສົມ, ແຕ່ມັນເປັນສິ່ງສໍາຄັນທີ່ນັກພັດທະນາເຮັດໃຫ້ການປະນີປະນອມດັ່ງກ່າວຢ່າງມີສະຕິ.

ແຕ່ພວກເຮົາຍັງມີເຫດຜົນສໍາລັບການ optimism. ຂ້ອຍໄດ້ຮັບການຊຸກຍູ້ໃຫ້ຜູ້ພັດທະນາ Chrome ເຮັດວຽກຢ່າງໃກ້ຊິດກັບຜູ້ທີ່ຢູ່ເບື້ອງຫຼັງບາງເຄື່ອງມືດ້ານຫນ້າທີ່ພວກເຮົາໄດ້ກວມເອົາເພື່ອຊ່ວຍປັບປຸງການປະຕິບັດຂອງເຄື່ອງມືເຫຼົ່ານັ້ນ.

ຢ່າງໃດກໍຕາມ, ຂ້າພະເຈົ້າເປັນບຸກຄົນທີ່ pragmatic. ສະຖາປັດຕະຍະກໍາໃຫມ່ສ້າງບັນຫາການປະຕິບັດເລື້ອຍໆຍ້ອນວ່າພວກເຂົາແກ້ໄຂພວກມັນ. ແລະມັນໃຊ້ເວລາເພື່ອລົບລ້າງຂໍ້ບົກຜ່ອງ. ຄືກັນກັບທີ່ພວກເຮົາບໍ່ຄວນຄາດຫວັງວ່າ ເຕັກ​ໂນ​ໂລ​ຊີ​ເຄືອ​ຂ່າຍ​ໃຫມ່​ ຈະແກ້ໄຂບັນຫາການປະຕິບັດທັງຫມົດ, ທ່ານບໍ່ຄວນຄາດຫວັງວ່ານີ້ຈາກສະບັບໃຫມ່ຂອງກອບທີ່ພວກເຮົາມັກ.

ຖ້າທ່ານຕ້ອງການໃຊ້ຫນຶ່ງໃນເຄື່ອງມືດ້ານຫນ້າທີ່ໄດ້ປຶກສາຫາລືໃນເອກະສານນີ້, ນີ້ຫມາຍຄວາມວ່າທ່ານຈະຕ້ອງພະຍາຍາມເພີ່ມເຕີມເພື່ອຮັບປະກັນວ່າ, ບັງເອີນ, ທ່ານຈະບໍ່ເປັນອັນຕະລາຍຕໍ່ການປະຕິບັດໂຄງການຂອງທ່ານ. ນີ້ແມ່ນບາງສິ່ງທີ່ຄວນພິຈາລະນາກ່ອນທີ່ທ່ານຈະເລີ່ມໃຊ້ກອບໃໝ່:

• ກວດເບິ່ງຕົວເອງດ້ວຍຄວາມຮູ້ສຶກທົ່ວໄປ. ທ່ານຕ້ອງການໃຊ້ກອບທີ່ທ່ານເລືອກແທ້ໆບໍ? JavaScript ບໍລິສຸດສາມາດເຮັດໄດ້ຫຼາຍຢ່າງໃນມື້ນີ້.
• ມີທາງເລືອກທີ່ອ່ອນກວ່າກັບກອບທີ່ທ່ານເລືອກ (ເຊັ່ນ Preact, Svelte ຫຼືສິ່ງອື່ນ) ທີ່ສາມາດໃຫ້ທ່ານ 90% ຂອງຄວາມສາມາດຂອງກອບນັ້ນບໍ?
• ຖ້າທ່ານກໍາລັງໃຊ້ກອບ, ຄິດກ່ຽວກັບວ່າມີບາງສິ່ງບາງຢ່າງທີ່ສະເຫນີທີ່ດີກວ່າ, ອະນຸລັກຫຼາຍ, ທາງເລືອກມາດຕະຖານ (ຕົວຢ່າງ, Nuxt.js ແທນ Vue, Next.js ແທນ React, ແລະອື່ນໆ).
• ຈະ​ເປັນ​ແນວ​ໃດ​ຂອງ​ທ່ານ​ ງົບປະມານ ປະສິດທິພາບ JavaScript?
• ເຈົ້າສາມາດເຮັດໄດ້ແນວໃດ ຂີດ ຈຳ ກັດ ຂະບວນການພັດທະນາເພື່ອເຮັດໃຫ້ມັນຍາກທີ່ຈະແນະນໍາລະຫັດ JavaScript ເຂົ້າໄປໃນໂຄງການຫຼາຍກ່ວາມີຄວາມຈໍາເປັນແທ້ໆບໍ?
• ຖ້າທ່ານກໍາລັງໃຊ້ກອບເພື່ອຄວາມສະດວກໃນການພັດທະນາ, ພິຈາລະນາ ທ່ານຕ້ອງການ ສົ່ງລະຫັດກອບໃຫ້ລູກຄ້າ. ບາງທີເຈົ້າສາມາດແກ້ໄຂບັນຫາທັງຫມົດໃນເຄື່ອງແມ່ຂ່າຍບໍ?

ໂດຍປົກກະຕິແລ້ວ, ແນວຄວາມຄິດເຫຼົ່ານີ້ແມ່ນມີມູນຄ່າການພິຈາລະນາຢ່າງໃກ້ຊິດ, ໂດຍບໍ່ຄໍານຶງເຖິງສິ່ງທີ່ທ່ານເລືອກທີ່ຈະພັດທະນາດ້ານຫນ້າ. ແຕ່ພວກມັນມີຄວາມສໍາຄັນໂດຍສະເພາະໃນເວລາທີ່ທ່ານກໍາລັງເຮັດວຽກຢູ່ໃນໂຄງການທີ່ຂາດການປະຕິບັດເພື່ອເລີ່ມຕົ້ນ.

ທ່ານຜູ້ອ່ານທີ່ຮັກແພງ! ທ່ານເຫັນວ່າເປັນກອບ JavaScript ທີ່ເຫມາະສົມແນວໃດ?

ແຫຼ່ງຂໍ້ມູນ: www.habr.com