Alexey Grachev: ໄປ Frontend

ກອງປະຊຸມ Kyiv Go ເດືອນພຶດສະພາ 2018:

ນຳ: - ສະບາຍດີທຸກຄົນ! ຂອບໃຈສໍາລັບການຢູ່ທີ່ນີ້! ມື້ນີ້ພວກເຮົາມີສອງລໍາໂພງຢ່າງເປັນທາງການ - Lyosha ແລະ Vanya. ມັນຈະມີອີກສອງຢ່າງຖ້າພວກເຮົາມີເວລາ. ຜູ້ເວົ້າທໍາອິດແມ່ນ Alexey Grachev, ລາວຈະບອກພວກເຮົາກ່ຽວກັບ GopherJS.

Alexey Grachev (ຕໍ່ໄປນີ້ - AG): – ຂ້ອຍເປັນຜູ້ພັດທະນາ Go ແລະຂ້ອຍຂຽນບໍລິການເວັບໃນ Go. ບາງຄັ້ງທ່ານຕ້ອງຈັດການກັບ frontend, ບາງຄັ້ງທ່ານຕ້ອງປີນມີ handles. ຂ້ອຍຕ້ອງການເວົ້າກ່ຽວກັບປະສົບການຂອງຂ້ອຍແລະການຄົ້ນຄວ້າກ່ຽວກັບ Go on the frontend.

ນິທານແມ່ນນີ້: ທໍາອິດພວກເຮົາຈະສົນທະນາວ່າເປັນຫຍັງພວກເຮົາຕ້ອງການທີ່ຈະດໍາເນີນການໄປໃນດ້ານຫນ້າ, ຫຼັງຈາກນັ້ນພວກເຮົາຈະສົນທະນາກ່ຽວກັບວິທີທີ່ພວກເຮົາສາມາດເຮັດໄດ້. ມີສອງວິທີ - Web Assembly ແລະ GopherJS. ໃຫ້ເບິ່ງວ່າການຕັດສິນໃຈເຫຼົ່ານີ້ຢູ່ໃນສະຖານະໃດແລະສິ່ງທີ່ສາມາດເຮັດໄດ້.

ມີຫຍັງຜິດພາດກັບ frontend?

ທຸກຄົນເຫັນດີວ່າທຸກຢ່າງແມ່ນດີກັບ frontend?

ການທົດສອບຈໍານວນຫນ້ອຍ? ສ້າງຊ້າ? ລະບົບນິເວດ? ດີ.

ກ່ຽວກັບດ້ານຫນ້າ, ຂ້າພະເຈົ້າມັກຄໍາເວົ້າທີ່ຜູ້ພັດທະນາດ້ານຫນ້າຄົນຫນຶ່ງເວົ້າໃນຫນັງສືຂອງລາວ:

Javascript ບໍ່ມີລະບົບປະເພດ. ຕອນນີ້ຂ້ອຍຈະຕັ້ງຊື່ບັນຫາທີ່ຂ້ອຍພົບໃນການເຮັດວຽກຂອງຂ້ອຍແລະອະທິບາຍວິທີທີ່ພວກມັນຖືກແກ້ໄຂ.

ລະບົບປະເພດໂດຍທົ່ວໄປແມ່ນຍາກທີ່ຈະໂທຫາລະບົບປະເພດໃນ Javascript - ມີເສັ້ນທີ່ຊີ້ບອກປະເພດຂອງວັດຖຸ, ແຕ່ໃນຄວາມເປັນຈິງນີ້ບໍ່ມີຫຍັງກ່ຽວຂ້ອງກັບປະເພດ. ບັນຫານີ້ແມ່ນຖືກແກ້ໄຂໃນ TypeScript (Javascript add-on) ແລະ Flow (ຕົວກວດສອບແບບຄົງທີ່ຂອງ Javascript). ໃນຄວາມເປັນຈິງ, ດ້ານຫນ້າໄດ້ໄປເຖິງການແກ້ໄຂບັນຫາຂອງລະບົບປະເພດທີ່ບໍ່ດີໃນ Javascript.

ບໍ່ມີຫ້ອງສະຫມຸດມາດຕະຖານໃນຕົວທ່ອງເວັບເຊັ່ນນັ້ນ - ມີບາງວັດຖຸກໍ່ສ້າງແລະຫນ້າທີ່ "magic" ໃນຕົວທ່ອງເວັບ. ແຕ່ຂ້ອຍບໍ່ມີຫ້ອງສະຫມຸດມາດຕະຖານໃນ Javascript ຄືກັນ. ບັນຫານີ້ໄດ້ຖືກແກ້ໄຂແລ້ວໂດຍ jQuery (ທຸກຄົນໃຊ້ jQuery ກັບທຸກ prototypes, ຜູ້ຊ່ວຍ, ຫນ້າທີ່ທີ່ຈໍາເປັນເພື່ອເຮັດວຽກ). ໃນປັດຈຸບັນທຸກຄົນໃຊ້ Lodash:

callback hell. ຂ້າພະເຈົ້າຄິດວ່າທຸກຄົນໄດ້ເຫັນລະຫັດ Javascript ປະມານ 5 ປີກ່ອນຫນ້ານີ້, ແລະມັນຄ້າຍຄື "noodle" ຈາກ intricacies incredible callbacks. ໃນປັດຈຸບັນບັນຫານີ້ໄດ້ຖືກແກ້ໄຂ (ດ້ວຍການເປີດຕົວ ES-15 ຫຼື ES-16), ຄໍາສັນຍາໄດ້ຖືກເພີ່ມເຂົ້າໃນ Javascript ແລະທຸກຄົນເລີ່ມຫາຍໃຈງ່າຍຂຶ້ນສໍາລັບໄລຍະຫນຶ່ງ.

ຈົນ​ກ​່​ວາ Promice hell ມາ​ພ້ອມ… ຂ້າ​ພະ​ເຈົ້າ​ບໍ່​ຮູ້​ວ່າ​ວິ​ທີ​ການ​ອຸດ​ສາ​ຫະ​ກໍາ​ແຖວ​ຫນ້າ​ໃນ​ການ​ຄຸ້ມ​ຄອງ, ແຕ່​ພວກ​ເຂົາ​ເຈົ້າ​ສະ​ເຫມີ​ຂັບ​ໄລ່​ຕົນ​ເອງ​ເຂົ້າ​ໄປ​ໃນ​ປ່າ​ແປກ​ບາງ. ພວກເຮົາຍັງໄດ້ຈັດການເພື່ອເຮັດໃຫ້ hell ສຸດ "ຄໍາຫມັ້ນສັນຍາ". ຫຼັງຈາກນັ້ນ, ພວກເຮົາໄດ້ແກ້ໄຂບັນຫານີ້ໂດຍການເພີ່ມ primitive ໃຫມ່ - async/await:

ດ້ວຍ asynchrony, ບັນຫາໄດ້ຖືກແກ້ໄຂ. Async/await ແມ່ນຂ້ອນຂ້າງເປັນທີ່ນິຍົມກັນໃນພາສາຕ່າງໆ. Python ແລະອື່ນໆມີວິທີການນີ້ - ມັນດີພຽງພໍ. ບັນຫາຖືກແກ້ໄຂ.

ບັນຫາອັນໃດທີ່ບໍ່ໄດ້ຮັບການແກ້ໄຂ? ຄວາມ​ສັບ​ສົນ​ທີ່​ເພີ່ມ​ຂຶ້ນ​ຢ່າງ​ຫຼວງ​ຫຼາຍ​ຂອງ​ໂຄງ​ການ​, ຄວາມ​ສັບ​ສົນ​ຂອງ​ລະ​ບົບ​ນິ​ເວດ​ແລະ​ໂຄງ​ການ​ຂອງ​ຕົນ​ເອງ​.

• syntax ຂອງ Javascript ແມ່ນແປກເລັກນ້ອຍ. ພວກເຮົາທຸກຄົນຮູ້ບັນຫາກ່ຽວກັບການເພີ່ມ array ແລະວັດຖຸແລະ tricks ອື່ນໆ.
• Javascript ແມ່ນຫຼາຍຮູບສັນຍາລັກ. ໃນປັດຈຸບັນນີ້ແມ່ນລະບົບການກົດດັນໂດຍສະເພາະໃນເວລາທີ່ລະບົບນິເວດມີຂະຫນາດໃຫຍ່ຫຼາຍ:
  • ທຸກຄົນຂຽນໃນແບບທີ່ແຕກຕ່າງກັນ - ຜູ້ໃດຜູ້ຫນຶ່ງຂຽນໂຄງສ້າງ, ບາງຄົນຂຽນແບບເຮັດວຽກ, ນັກພັດທະນາທີ່ແຕກຕ່າງກັນຂຽນແຕກຕ່າງກັນ;
  • ຈາກແພັກເກັດທີ່ແຕກຕ່າງກັນ (packages) paradigms ທີ່ແຕກຕ່າງກັນໃນເວລາທີ່ທ່ານໃຊ້ແພັກເກັດທີ່ແຕກຕ່າງກັນ;
  • "ມ່ວນ" ຫຼາຍກັບການຂຽນໂປລແກລມທີ່ມີປະໂຫຍດໃນ Javascript - ຫ້ອງສະຫມຸດ rambda ປະກົດຕົວແລະຕອນນີ້ບໍ່ມີໃຜສາມາດອ່ານໂຄງການທີ່ຂຽນຢູ່ໃນຫ້ອງສະຫມຸດນີ້.

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

Web Assembly ແມ່ນຫຍັງ?

ພວກທີ່ກ້າຫານຈາກມູນນິທິ Mozilla ແລະບໍລິສັດອື່ນໆຈຳນວນໜຶ່ງໄດ້ມາກັບສິ່ງດັ່ງກ່າວເຊັ່ນ Web Assembly. ນີ້​ແມ່ນ​ຫຍັງ?

• ນີ້ແມ່ນເຄື່ອງ virtual ທີ່ສ້າງຂຶ້ນໃນຕົວທ່ອງເວັບທີ່ສະຫນັບສະຫນູນຮູບແບບຖານສອງ.
• ໂປລແກລມ Binary ມາຮອດນັ້ນ, ພວກເຂົາຖືກປະຕິບັດເກືອບພື້ນເມືອງ, ນັ້ນແມ່ນ, ຕົວທ່ອງເວັບບໍ່ຈໍາເປັນຕ້ອງແຍກ "noodles" ທັງຫມົດຂອງລະຫັດ javascript ທຸກໆຄັ້ງ.
• ຕົວທ່ອງເວັບທັງຫມົດໄດ້ປະກາດການສະຫນັບສະຫນູນ.
• ເນື່ອງຈາກວ່ານີ້ແມ່ນ bytecode, ທ່ານສາມາດຂຽນ compiler ສໍາລັບພາສາໃດກໍ່ຕາມ.
• ສີ່ຕົວທ່ອງເວັບທີ່ສໍາຄັນແລ້ວສົ່ງກັບ Web Assembly ສະຫນັບສະຫນູນ.
• ພວກເຮົາຄາດວ່າຈະມີການຊ່ວຍເຫຼືອພື້ນເມືອງໃນ Go ໃນໄວໆນີ້. ສະຖາປັດຕະຍະກຳໃໝ່ນີ້ໄດ້ຖືກເພີ່ມແລ້ວ: GOARCH=wasm GOOS=js (ໄວໆນີ້). ມາຮອດປະຈຸ, ຕາມທີ່ຂ້ອຍເຂົ້າໃຈ, ມັນບໍ່ມີປະໂຫຍດ, ແຕ່ມີຄໍາຖະແຫຼງທີ່ແນ່ນອນວ່າມັນຈະຢູ່ໃນ Go.

ຈະເຮັດແນວໃດໃນປັດຈຸບັນ? GopherJS

ໃນຂະນະທີ່ພວກເຮົາບໍ່ມີ Web Assembly ສະຫນັບສະຫນູນ, ມີ transpiler ເຊັ່ນ GopherJS.

• ລະຫັດ Go ຖືກແປເປັນ Javascript "ບໍລິສຸດ".
• ດໍາເນີນການໃນທຸກຕົວທ່ອງເວັບ - ບໍ່ມີຄຸນສົມບັດໃຫມ່ທີ່ສະຫນັບສະຫນູນພຽງແຕ່ໂດຍຕົວທ່ອງເວັບທີ່ທັນສະໄຫມ (ນີ້ແມ່ນ Vanilla JS, ເຊິ່ງເຮັດວຽກກັບສິ່ງໃດກໍ່ຕາມ).
• ມີການສະຫນັບສະຫນູນເກືອບທຸກຢ່າງທີ່ຢູ່ໃນ Go, ລວມທັງ goroutines ແລະຊ່ອງທາງ ... - ທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາຮັກແລະຮູ້ຫຼາຍ.
• ເກືອບຫໍສະຫມຸດມາດຕະຖານທັງຫມົດແມ່ນໄດ້ຮັບການສະຫນັບສະຫນູນ, ຍົກເວັ້ນການຫຸ້ມຫໍ່ເຫຼົ່ານັ້ນວ່າມັນບໍ່ມີຄວາມຫມາຍທີ່ຈະສະຫນັບສະຫນູນໃນຕົວທ່ອງເວັບ: syscall, ການໂຕ້ຕອບສຸດທິ (ມີລູກຄ້າ net / http, ແຕ່ບໍ່ມີເຄື່ອງແມ່ຂ່າຍ, ແລະລູກຄ້າຖືກ emulated ຜ່ານ XMLHttpRequest) . ໂດຍທົ່ວໄປ, ຫ້ອງສະຫມຸດມາດຕະຖານທັງຫມົດແມ່ນມີຢູ່ - ນີ້ແມ່ນຢູ່ໃນຕົວທ່ອງເວັບ, ນີ້ແມ່ນ Go stdlib ທີ່ພວກເຮົາຮັກ.
• ລະບົບນິເວດຂອງແພັກເກັດທັງຫມົດໃນ Go, ທຸກໆການແກ້ໄຂຂອງພາກສ່ວນທີສາມ (ການສ້າງແບບຈໍາລອງ, ແລະອື່ນໆ) ສາມາດຖືກລວບລວມກັບ GopherJS ແລະດໍາເນີນການໃນຕົວທ່ອງເວັບ.

ການໄດ້ຮັບ GopherJS ແມ່ນງ່າຍຫຼາຍ - ມັນເປັນພຽງແຕ່ຊຸດ Go ປົກກະຕິ. ພວກເຮົາເຮັດການໄປຮັບແລະພວກເຮົາມີຄໍາສັ່ງ GopherJS ເພື່ອສ້າງແອັບພລິເຄຊັນ:

ນີ້ຄືໂລກສະບາຍດີຂະໜາດນ້ອຍ...

...ໂປຣແກຣມ Go ປົກກະຕິ, ຊຸດ fmt ປົກກະຕິຂອງຫ້ອງສະໝຸດມາດຕະຖານ ແລະ Binding Js ເພື່ອເຂົ້າເຖິງ API ຂອງຕົວທ່ອງເວັບ. Println ໃນທີ່ສຸດຈະຖືກປ່ຽນເປັນ console log ແລະຕົວທ່ອງເວັບຈະຂຽນ "ສະບາຍດີ gophers"! ມັນງ່າຍດາຍຫຼາຍ: ພວກເຮົາສ້າງ GopherJS - ພວກເຮົາເປີດຕົວມັນຢູ່ໃນຕົວທ່ອງເວັບ - ທຸກສິ່ງທຸກຢ່າງເຮັດວຽກ!

ຕອນນີ້ແມ່ນຫຍັງ? ຜູກມັດ

ມີການຜູກມັດສໍາລັບກອບ js ທີ່ນິຍົມທັງຫມົດ:

• jquery;
• Angular.js
• D3.js ສໍາລັບການວາງແຜນແລະເຮັດວຽກກັບຂໍ້ມູນໃຫຍ່;
• React.js
• VueJS;
• ຍັງມີການສະຫນັບສະຫນູນສໍາລັບ Electron (ນັ້ນແມ່ນ, ພວກເຮົາສາມາດຂຽນຄໍາຮ້ອງສະຫມັກ desktop ໃນ Electron);
• ແລະສິ່ງທີ່ມ່ວນທີ່ສຸດແມ່ນ WebGL (ພວກເຮົາສາມາດເຮັດໃຫ້ຄໍາຮ້ອງສະຫມັກທີ່ມີຮູບພາບເຕັມຮູບແບບ, ລວມທັງເກມທີ່ມີຮູບພາບ 3D, ດົນຕີແລະສິ່ງດີໆທັງຫມົດ);
• ແລະການຜູກມັດອື່ນໆຫຼາຍຢ່າງກັບກອບ javascript ແລະຫ້ອງສະຫມຸດທີ່ນິຍົມທັງຫມົດ.

Framework

1. ມີກອບເວັບທີ່ພັດທະນາແລ້ວໂດຍສະເພາະສໍາລັບ GopherJS - Vecty. ນີ້ແມ່ນການປຽບທຽບເຕັມຮູບແບບຂອງ React.js, ແຕ່ພັດທະນາໃນ Go ເທົ່ານັ້ນ, ໂດຍມີສະເພາະຂອງ GopherJS.
2. ມີຖົງເກມ (ຢ່າງກະທັນຫັນ!). ຂ້ອຍພົບສອງອັນທີ່ນິຍົມທີ່ສຸດ:
   • engo ;
   • Ebiten.

ຂ້າພະເຈົ້າຈະສະແດງໃຫ້ເຫັນສອງສາມຕົວຢ່າງຂອງວິທີການເບິ່ງແລະສິ່ງທີ່ສາມາດຂຽນໄດ້ໃນ Go:

ຫຼືທາງເລືອກນີ້ (ຂ້ອຍບໍ່ພົບເຄື່ອງຍິງ 3D, ແຕ່ບາງທີມັນມີຢູ່):

ຂ້ອຍແນະນໍາຫຍັງ?

ໃນປັດຈຸບັນອຸດສາຫະກໍາແຖວຫນ້າແມ່ນຢູ່ໃນສະພາບທີ່ທຸກພາສາທີ່ເຄີຍຮ້ອງອອກມາຈາກ Javascript ຈະແລ່ນໄປບ່ອນນັ້ນ. ໃນປັດຈຸບັນທຸກສິ່ງທຸກຢ່າງຈະລວບລວມກັບ "Web Assemblies". ພວກເຮົາຕ້ອງການຫຍັງເພື່ອເອົາສະຖານທີ່ທີ່ສົມຄວນຢູ່ທີ່ນັ້ນເປັນ "gophers"?

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

ແລະຕອນນີ້ - ເປັນໂອກາດທີ່ດີທີ່ຈະສ້າງຫ້ອງສະໝຸດ UI ໃນ Go ທີ່ຈະໃຊ້ໃນ GopherJS! ສຸດທ້າຍເຈົ້າສາມາດຂຽນກອບຂອງເຈົ້າເອງໄດ້! ເວລາໄດ້ມາເຖິງເວລາທີ່ທ່ານສາມາດຂຽນກອບ, ແລະມັນຈະເປັນຫນຶ່ງໃນທໍາອິດແລະໄດ້ຮັບການຮັບຮອງເອົາໄວ, ແລະທ່ານຈະເປັນດາວ (ຖ້າມັນເປັນກອບທີ່ດີ).

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

ເຈົ້າສາມາດຂຽນເກມໄດ້! ເພື່ອຄວາມມ່ວນ...

ນັ້ນແມ່ນສິ່ງທີ່ຂ້ອຍຢາກເວົ້າ.

ຄໍາຖາມຂອງທ່ານ

ຄໍາຖາມ (ຕໍ່ໄປນີ້ເອີ້ນວ່າ Q): - ຂ້ອຍຂຽນໃນ Go ຫຼື Js?

AG: – ທ່ານ​ຂຽນ​ກິດ​ຈະ​ກໍາ​, ຊ່ອງ​ທາງ​, ໂຄງ​ສ້າງ​, ການ​ຝັງ – ທຸກ​ສິ່ງ​ທຸກ​ຢ່າງ​ໃນ Go… ທ່ານ​ຈອງ​ກິດ​ຈະ​ກໍາ​, ຜ່ານ​ຫນ້າ​ທີ່​ທີ່​ນັ້ນ​.

ໃນ: - ນັ້ນແມ່ນ, ຂ້ອຍຂຽນໃສ່ Js "naked"?

AG: - ບໍ່, ທ່ານຂຽນຄືກັບວ່າຢູ່ໃນ Go ແລະເຊື່ອມຕໍ່ກັບ browser API ( API ບໍ່ໄດ້ປ່ຽນແປງ). ທ່ານສາມາດຂຽນການຜູກມັດຂອງທ່ານເອງເພື່ອໃຫ້ຂໍ້ຄວາມເຂົ້າມາໃນຊ່ອງທາງ - ມັນບໍ່ຍາກ.

ໃນ: - ແມ່ນຫຍັງກ່ຽວກັບມືຖື?

AG: - ຂ້ອຍໄດ້ເຫັນແນ່ນອນ: ມີຕົວຍຶດສໍາລັບ Cordova patch ທີ່ Js ເປີດຕົວ. ໃນ React Native, ຂ້ອຍບໍ່ຮູ້; ບາງທີມີ, ອາດຈະບໍ່ (ບໍ່ສົນໃຈໂດຍສະເພາະ). ເຄື່ອງຈັກເກມ N-go ຮອງຮັບທັງແອັບພລິເຄຊັນມືຖື - ທັງ iOs ແລະ Android.

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

AG: - Web Assembly ເປັນຮູບແບບ binary, ແລະ binary ເລີ່ມຕົ້ນບໍ່ສາມາດໃຫຍ່ກວ່າຂໍ້ຄວາມໃນການປ່ອຍສຸດທ້າຍ ... Runtime ດຶງທ່ານ, ແຕ່ນີ້ແມ່ນຄືກັນກັບການດຶງຢູ່ໃນຫ້ອງສະຫມຸດມາດຕະຖານ Javascript ເມື່ອມັນບໍ່ມີ, ດັ່ງນັ້ນພວກເຮົາໃຊ້ບາງ. Lodash ຂ້ອຍບໍ່ຮູ້ວ່າ Lodash ໃຊ້ເວລາດົນປານໃດ.

ໃນ: - ແນ່ນອນຫນ້ອຍກວ່າ runtime ...

AG: - ໃນ Javascript "ບໍລິສຸດ"?

ໃນ: - ແມ່ນແລ້ວ. ພວກເຮົາບີບອັດກ່ອນສົ່ງ...

AG: - ແຕ່ນີ້ແມ່ນຂໍ້ຄວາມ ... ໂດຍທົ່ວໄປ, megabyte ແມ່ນຄ້າຍຄືຫຼາຍ, ແຕ່ວ່າທັງຫມົດ (ທ່ານມີ runtime ທັງຫມົດ). ຕໍ່ໄປ, ທ່ານຂຽນເຫດຜົນທາງທຸລະກິດຂອງທ່ານເອງທີ່ຈະເພີ່ມ binary ຂອງທ່ານ 1%. ມາຮອດປະຈຸ, ຂ້າພະເຈົ້າບໍ່ເຫັນມັນຂ້າ frontend. ຍິ່ງໄປກວ່ານັ້ນ, Web Assembly ຈະເຮັດວຽກໄວກວ່າ Javascript ສໍາລັບເຫດຜົນທີ່ຊັດເຈນ - ມັນບໍ່ຈໍາເປັນຕ້ອງຖືກວິເຄາະ.

ໃນ: - ເຖິງຕອນນັ້ນ, ຈຸດ moot ... ຍັງບໍ່ທັນມີການປະຕິບັດການອ້າງອິງຂອງ "Wasma" (ສະພາແຫ່ງເວັບໄຊຕ໌), ດັ່ງນັ້ນຫນຶ່ງສາມາດຕັດສິນ unambiguously. Conceptually, ແມ່ນ: ພວກເຮົາທຸກຄົນເຂົ້າໃຈວ່າ binary ຄວນໄວ, ແຕ່ການປະຕິບັດໃນປະຈຸບັນຂອງ V8 ດຽວກັນແມ່ນມີປະສິດທິພາບຫຼາຍ.

AG: - ແມ່ນແລ້ວ.

ໃນ: - ການລວບລວມຢູ່ທີ່ນັ້ນເຮັດວຽກເຢັນຫຼາຍແລະມັນບໍ່ແມ່ນຄວາມຈິງທີ່ວ່າຈະເປັນປະໂຫຍດອັນໃຫຍ່ຫຼວງ.

AG: - ສະພາແຫ່ງເວັບໄຊຕ໌ຍັງເຮັດໂດຍ guys ໃຫຍ່.

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

AG: - ບາງທີ. ໃຫ້ເຮົາເບິ່ງ.

ໃນ: – ພວກ​ເຮົາ​ບໍ່​ມີ​ບັນ​ຫາ​ກ່ຽວ​ກັບ backend ໄດ້… ບາງ​ທີ​ພວກ​ເຮົາ​ຄວນ​ຈະ​ປະ​ໄວ້​ບັນ​ຫາ​ເຫຼົ່າ​ນີ້​ຢູ່​ໃນ frontend? ເປັນຫຍັງໄປບ່ອນນັ້ນ?

AG: - ພວກເຮົາຕ້ອງຮັກສາພະນັກງານແຖວໜ້າ.

ບາງໂຄສະນາ🙂

ຂອບໃຈສໍາລັບການຢູ່ກັບພວກເຮົາ. ເຈົ້າມັກບົດຄວາມຂອງພວກເຮົາບໍ? ຕ້ອງການເບິ່ງເນື້ອຫາທີ່ຫນ້າສົນໃຈຫຼາຍບໍ? ສະຫນັບສະຫນູນພວກເຮົາໂດຍການວາງຄໍາສັ່ງຫຼືແນະນໍາໃຫ້ຫມູ່ເພື່ອນ, cloud VPS ສໍາລັບນັກພັດທະນາຈາກ $4.99, ການປຽບທຽບທີ່ເປັນເອກະລັກຂອງເຊີບເວີລະດັບເຂົ້າ, ເຊິ່ງຖືກປະດິດໂດຍພວກເຮົາສໍາລັບທ່ານ: ຄວາມຈິງທັງໝົດກ່ຽວກັບ VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps ຈາກ $19 ຫຼືວິທີການແບ່ງປັນເຄື່ອງແມ່ຂ່າຍ? (ສາມາດໃຊ້ໄດ້ກັບ RAID1 ແລະ RAID10, ສູງສຸດ 24 cores ແລະສູງສຸດ 40GB DDR4).

Dell R730xd 2x ລາຄາຖືກກວ່າຢູ່ໃນສູນຂໍ້ມູນ Equinix Tier IV ໃນ Amsterdam? ທີ່ນີ້ເທົ່ານັ້ນ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV ຈາກ $199 ໃນປະເທດເນເທີແລນ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - ຈາກ $99! ອ່ານກ່ຽວກັບ ວິທີການສ້າງໂຄງສ້າງພື້ນຖານຂອງບໍລິສັດ. ຫ້ອງຮຽນທີ່ມີການນໍາໃຊ້ເຄື່ອງແມ່ຂ່າຍຂອງ Dell R730xd E5-2650 v4 ມູນຄ່າ 9000 ເອີໂຣສໍາລັບເງິນບໍ?

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