ฉันถูกถามในวันนี้และไม่สามารถให้คำตอบที่เหมาะสมได้
typescript ถ่ายทอดเป็น JS จากนั้นมีต้นไม้สั่น "น้อยกว่า" (ไม่บังคับ) และมีอะไรอีกบ้างในกระบวนการทำให้ใช้งานได้ แต่ไม่มีอะไรเช่นนั้น (afaik) เกี่ยวข้องกับการ "รวบรวม" ทุกอย่างได้รับการรวมและปรับให้เหมาะสมอย่างมาก แต่ยังไม่ได้รวบรวมจริงใช่ไหม?
แม้จะมีผู้ควบคุม - "ล่วงหน้า" ซึ่งทำงานได้อย่างเห็นได้ชัด ฉันคิดถึงอะไร?
Javascript เองก็ยังตีความได้ใช่ไหม?
คำตอบ:
คุณคิดว่าการคอมไพล์หมายถึงการใช้ซอร์สโค้ดและผลิตโค้ดเครื่องรหัสระดับต่ำเป็นต้น แต่การคอมไพล์นั้นหมายถึงการเอาซอร์สโค้ดหนึ่งอันมาเปลี่ยนเป็นซอร์สโค้ดอื่น ดังนั้นจึงดูสมเหตุสมผลที่จะกล่าวว่าการใช้ typescript และการสร้าง JavaScript เป็นรูปแบบหนึ่งของการรวบรวม ไม่แตกต่างกับสิ่งที่ (ตัวอย่าง) c # ทำเมื่อรวบรวมเป็นภาษา IL
ที่กล่าวว่าฉันพูดคำดีสำหรับเรื่องนี้คือTranspiling ฉันขอแนะนำว่าคอมไพเลอร์ typescript อธิบายได้ดีกว่าว่าเป็น Transpiler
ความแตกต่างนั้นบอบบางและทรานส์ไพเลอร์สามารถคิดได้ว่าเป็นคอมไพเลอร์ประเภทหนึ่ง แต่ภาษาที่คอมไพล์ (บริสุทธิ์) คือ (โดยปกติ) เปลี่ยนภาษาระดับสูงเป็นภาษาระดับต่ำ (ใกล้เคียงกับรหัสเครื่อง) เช่นตัวอย่าง C # Transpiler เปลี่ยนภาษาระดับสูงให้เป็นภาษาระดับเดียวกัน (ของนามธรรม) (ระดับสูงด้วย) *
ผลมาจากการรวบรวมรหัสที่เป็นปกติไม่ใช่ภาษาที่คุณจะเขียนด้วยตัวคุณเอง ผลลัพธ์ของทรานสไพเลอร์เป็นภาษาระดับสูงอีกภาษาหนึ่ง ในทางทฤษฎีคุณสามารถเขียน IL ได้ (เป็นตัวอย่าง) แต่ออกแบบมาให้สร้างโดยคอมไพเลอร์และไม่มีเครื่องมือหรือการสนับสนุนในการทำเช่นนี้คุณสร้าง IL โดยรวบรวม C # / vb.net เท่านั้น ในขณะที่ Javascript เป็นภาษาโปรแกรมที่ใช้งานได้ (และใช้แล้ว) ในสิทธิของตนเอง
* คำเตือนมากมายเนื่องจากคำจำกัดความของคำเหล่านี้และการใช้งานค่อนข้างคลุมเครือ
ดูเหมือนคุณจะถามคำถามสามข้อในหนึ่งข้อ:
อะไรคือความแตกต่างระหว่างคอมไพเลอร์และทรานสไพเลอร์?
@ JörgWMittag ให้คำตอบที่ดีมากสำหรับคำถามนี้
Angular และ TypeScript ใช้คอมไพเลอร์หรือทรานสไพเลอร์หรือไม่
ทั้ง TS และ Angular ใช้คอมไพเลอร์จริง พวกเขาทำตามขั้นตอนเดียวกันของการวิเคราะห์คำศัพท์การแยกวิเคราะห์การวิเคราะห์เชิงความหมายและการสร้างรหัสเป็นคอมไพเลอร์ C / C ++ ที่สร้างรหัสแอสเซมบลี (ยกเว้นอาจเป็นการเพิ่มประสิทธิภาพ) คุณจะเห็นว่าชั้น / โฟลเดอร์ที่มีชื่อ "คอมไพเลอร์" ทั้งในเชิงมุมและTS
คอมไพเลอร์เชิงมุมไม่เกี่ยวข้องกับคอมไพเลอร์ TypeScript จริงๆ คอมไพเลอร์เหล่านี้แตกต่างกันมาก
มีคอมไพเลอร์ Angular แยกต่างหากหรือไม่? มันรวบรวมอะไร?
Angular มีคอมไพเลอร์สองตัว:
งานของคอมไพเลอร์มุมมองคือการเปลี่ยนแม่แบบที่คุณระบุสำหรับแม่แบบองค์ประกอบเข้าสู่การแสดงภายในขององค์ประกอบซึ่งเป็นโรงงานมุมมองที่ถูกนำมาใช้เพื่อยกตัวอย่างเช่นมุมมอง
นอกจากเปลี่ยนแม่แบบคอมไพเลอร์ดูยังรวบรวมข้อมูลเมตาดาต้าต่างๆในรูปแบบของการตกแต่งเช่น@HostBinding, @ViewChildฯลฯ
สมมติว่าคุณกำหนดองค์ประกอบและแม่แบบดังนี้:
@Component({
selector: 'a-comp',
template: '<span>A Component</span>'
})
class AComponent {}
การใช้ข้อมูลนี้คอมไพเลอร์จะสร้างโรงงานส่วนประกอบที่ง่ายขึ้นเล็กน้อยดังต่อไปนี้:
function View_AComponent {
return jit_viewDef1(0,[
elementDef2(0,null,null,1,'span',...),
jit_textDef3(null,['My name is ',...])
]
อธิบายโครงสร้างของมุมมองส่วนประกอบและใช้เมื่อสร้างอินสแตนซ์คอมโพเนนต์ โหนดแรกคือนิยามองค์ประกอบและโหนดที่สองคือนิยามข้อความ คุณจะเห็นได้ว่าแต่ละโหนดได้รับข้อมูลที่ต้องการเมื่อถูกสร้างอินสแตนซ์ผ่านรายการพารามิเตอร์ เป็นงานของคอมไพลเลอร์ในการแก้ไขการอ้างอิงที่จำเป็นทั้งหมดและจัดเตรียมไว้ที่รันไทม์
ฉันขอแนะนำอย่างยิ่งให้อ่านบทความเหล่านี้:
นอกจากนี้โปรดดูคำตอบว่า Angular AOT และ JIT compiler แตกต่างกันอย่างไร
งานของคอมไพเลอร์โมดูลคือการสร้างโรงงานโมดูลซึ่งโดยพื้นฐานแล้วจะมีคำจำกัดความที่ผสานของผู้ให้บริการ
สำหรับข้อมูลเพิ่มเติมโปรดอ่าน:
typescript จะเปลี่ยนเป็น JS จากนั้นมีต้นไม้สั่น "น้อยกว่า" (ไม่บังคับ) และมีอะไรอีกบ้างในกระบวนการทำให้ใช้งานได้ แต่ไม่มีอะไรเช่นนั้น (afaik) เกี่ยวข้องกับการ "รวบรวม" ทุกอย่างได้รับการรวมและปรับให้เหมาะสมอย่างมาก แต่ยังไม่ได้รวบรวมจริงใช่ไหม?
การคอมไพล์หมายถึงการแปลงโปรแกรมที่เขียนด้วยภาษาAให้เป็นโปรแกรมเทียบเท่าความหมายที่เขียนด้วยภาษาBซึ่งการประเมินโปรแกรมที่คอมไพล์ตามกฎของภาษาB (เช่นการตีความด้วยล่ามสำหรับB ) จะให้ผลลัพธ์เดียวกันและมี ผลข้างเคียงเช่นเดียวกับการประเมินโปรแกรมต้นฉบับตามกฎของภาษาA (ตัวอย่างเช่นการตีความด้วยล่ามสำหรับA )
รวบรวมหมายความแปลโปรแกรมจากภาษาภาษาB นั่นหมายความว่าทั้งหมด (โปรดทราบว่าAและBเป็นภาษาเดียวกันเป็นไปได้อย่างสมบูรณ์แบบ)
ในบางกรณีเรามีชื่อเฉพาะสำหรับคอมไพเลอร์บางประเภทขึ้นอยู่กับว่าAและBคืออะไรและคอมไพเลอร์ทำอะไร:
นอกจากนี้โปรดทราบว่าแหล่งข้อมูลเก่า ๆ อาจใช้คำว่า "translation" และ "translator" แทน "compilation" และ "compiler" ตัวอย่างเช่น C พูดถึง "หน่วยการแปล"
คุณอาจสะดุดกับคำว่า "ตัวประมวลผลภาษา" ซึ่งอาจหมายถึงคอมไพเลอร์ล่ามหรือทั้งคอมไพเลอร์และล่ามขึ้นอยู่กับนิยาม
Javascript เองก็ยังตีความได้ใช่ไหม?
JavaScript เป็นภาษา ภาษาคือชุดของกฎและข้อ จำกัด เชิงตรรกะ ภาษาไม่ได้รับการตีความหรือเรียบเรียง ภาษาเพียงแค่มี
การรวบรวมและการตีความเป็นลักษณะของคอมไพเลอร์หรือล่าม (duh!) ทุกภาษาสามารถใช้งานได้ด้วยคอมไพเลอร์และทุกภาษาสามารถใช้งานได้ด้วยล่าม หลายภาษามีทั้งคอมไพเลอร์และล่าม เอ็นจิ้นการประมวลผลประสิทธิภาพสูงสมัยใหม่จำนวนมากมีทั้งคอมไพเลอร์อย่างน้อยหนึ่งตัวและล่ามอย่างน้อยหนึ่งตัว
คำศัพท์ทั้งสองนี้อยู่ในชั้นนามธรรมที่แตกต่างกัน หากภาษาอังกฤษเป็นภาษาที่พิมพ์ "ภาษาที่แปลความหมาย" จะเป็นข้อผิดพลาดประเภท
โปรดทราบว่าบางภาษาไม่มีทั้งล่ามหรือคอมไพเลอร์ มีภาษาที่ไม่มีการใช้งานเลย ยังคงเป็นภาษาและคุณสามารถเขียนโปรแกรมได้ คุณไม่สามารถเรียกใช้งานได้
นอกจากนี้โปรดทราบว่าทุกอย่างถูกตีความในบางประเด็น : หากคุณต้องการดำเนินการบางอย่างคุณต้องตีความ การคอมไพล์เพียงแค่แปลโค้ดจากภาษาหนึ่งไปยังอีกภาษาหนึ่ง มันไม่ทำงาน การตีความทำงาน (บางครั้งเมื่อมีการใช้งานล่ามในฮาร์ดแวร์เราเรียกว่า "CPU" แต่ก็ยังคงเป็นล่ามอยู่)
ตรงประเด็น: ทุกการใช้งาน JavaScript หลักที่มีอยู่ในปัจจุบันมีคอมไพเลอร์
V8 เริ่มต้นจากการเป็นคอมไพเลอร์ที่บริสุทธิ์: มันรวบรวม JavaScript ตรงไปยังรหัสเครื่องดั้งเดิมที่ปรับให้เหมาะสมในระดับปานกลาง ต่อมามีการเพิ่มคอมไพเลอร์ตัวที่สอง ตอนนี้มีคอมไพเลอร์สองตัว: คอมไพเลอร์น้ำหนักเบาที่สร้างโค้ดที่ปรับให้เหมาะสมระดับปานกลาง แต่ตัวคอมไพเลอร์นั้นเร็วมากและใช้ RAM เพียงเล็กน้อย คอมไพเลอร์นี้ยังฉีดโค้ดการทำโปรไฟล์ลงในโค้ดที่คอมไพล์ คอมไพเลอร์ตัวที่สองเป็นคอมไพเลอร์ที่มีน้ำหนักมากขึ้นช้ากว่าและมีราคาแพงกว่าซึ่งจะสร้างโค้ดที่แน่นกว่าและเร็วกว่ามาก นอกจากนี้ยังใช้ผลลัพธ์ของโค้ดการสร้างโปรไฟล์ที่คอมไพเลอร์ตัวแรกใส่เข้าไปเพื่อทำการตัดสินใจเกี่ยวกับการเพิ่มประสิทธิภาพแบบไดนามิก นอกจากนี้การตัดสินใจว่าจะคอมไพล์โค้ดใหม่โดยใช้คอมไพลเลอร์ตัวที่สองจะขึ้นอยู่กับข้อมูลการทำโปรไฟล์นั้น สังเกตว่าไม่มีล่ามเข้ามาเกี่ยวข้อง V8 ไม่เคยตีความมันมักจะรวบรวม มันไม่ ' ไม่มีล่ามด้วยซ้ำ (อันที่จริงฉันเชื่อว่าทุกวันนี้ฉันกำลังอธิบายการทำซ้ำสองครั้งแรก)
SpiderMonkey รวบรวม JavaScript เป็น SpiderMonkey bytecode ซึ่งจะแปลความหมาย ล่ามยังกำหนดโปรไฟล์โค้ดจากนั้นโค้ดที่ถูกเรียกใช้บ่อยที่สุดจะถูกคอมไพเลอร์โดยคอมไพเลอร์ไปยังโค้ดเครื่องดั้งเดิม ดังนั้น SpiderMonkey จึงมีคอมไพเลอร์สองตัว : หนึ่งจาก JavaScript ถึง SpiderMonkey bytecode และอีกตัวหนึ่งจาก SpiderMonkey bytecode เป็นรหัสเครื่องดั้งเดิม
เอ็นจิ้นการเรียกใช้ JavaScript เกือบทั้งหมด (ยกเว้น V8) เป็นไปตามโมเดลของคอมไพเลอร์ AOT ที่คอมไพล์ JavaScript เป็น bytecode และเอนจิ้นโหมดผสมที่สลับระหว่างการตีความและการคอมไพล์ไบต์โค้ดนั้น
คุณเขียนในความคิดเห็น:
ฉันคิดจริงๆว่ารหัสเครื่องมีส่วนเกี่ยวข้อง
"รหัสเครื่อง" หมายถึงอะไร?
ภาษาเครื่องของชายคนหนึ่งคือภาษากลางของอีกคนหนึ่งหรือในทางกลับกัน? ตัวอย่างเช่นมีซีพียูที่สามารถรัน JVM bytecode บน CPU ได้โดย JVM bytecode เป็นรหัสเครื่องดั้งเดิม และมีล่ามสำหรับรหัสเครื่อง x86 เมื่อคุณเรียกใช้รหัสเครื่อง x86 เหล่านั้นจะถูกตีความโดยรหัส
มีตัวแปล x86 ที่เรียกว่า JPC ที่เขียนด้วยภาษาจาวา ถ้าฉันเรียกใช้รหัสเครื่อง x86 บน JPC ที่ทำงานบน JVM CPU ดั้งเดิม…ซึ่งเป็นรหัส bytecode และรหัสใดคือรหัสดั้งเดิม หากฉันรวบรวมรหัสเครื่อง x86 เป็น JavaScript (ใช่มีเครื่องมือที่สามารถทำได้) และเรียกใช้ในเบราว์เซอร์บนโทรศัพท์ของฉัน (ซึ่งมีซีพียู ARM) ซึ่งเป็นรหัส bytecode และรหัสเครื่องใดเป็นรหัสดั้งเดิม จะเกิดอะไรขึ้นถ้าโปรแกรมที่ฉันกำลังรวบรวมเป็นโปรแกรมจำลอง SPARC และฉันใช้เพื่อเรียกใช้รหัส SPARC
โปรดทราบว่าทุกภาษาทำให้เกิดเครื่องนามธรรมและเป็นภาษาเครื่องสำหรับเครื่องนั้น ดังนั้นทุกภาษา (รวมถึงภาษาระดับสูง) จึงเป็นรหัสเครื่องดั้งเดิม นอกจากนี้คุณสามารถเขียนล่ามสำหรับทุกภาษา ดังนั้นทุกภาษา (รวมถึงรหัสเครื่อง x86) จึงไม่ใช่ภาษาพื้นเมือง
การรับโค้ดที่คุณเขียนเพื่อรันบนเบราว์เซอร์มีสองสิ่ง:
1) Transpiling typescript เข้า JavaScript นี่เป็นปัญหาที่แก้ไขได้ ฉันคิดว่าพวกเขาใช้แค่ webpack
2) การรวบรวมแนวคิดมุมเข้าไปใน JavaScript ฉันหมายถึงสิ่งต่างๆเช่นส่วนประกอบท่อคำสั่งเทมเพลตเป็นต้นนี่คือสิ่งที่ทีมแกนเชิงมุมทำงาน
ในกรณีที่คุณสนใจจริงๆในบิตสองคอมไพเลอร์เชิงมุมเขียนนาฬิกาคอมไพเลอร์โทเบียสบ๊อชอธิบายเชิงมุมคอมไพเลอร์ที่ AngularConnect 2016
ฉันคิดว่ามีความสับสนเล็กน้อยระหว่างการถ่ายโอนและการรวบรวม มันไม่สำคัญและเป็นเรื่องของรสนิยมส่วนตัวพวกเขาทั้งสองเพียงแค่เปลี่ยนระหว่างการแสดงรหัส แต่คำจำกัดความที่ฉันใช้เป็นการส่วนตัวคือการถ่ายทอดระหว่างภาษาสองภาษาที่แตกต่างกันในระดับนามธรรมที่ใกล้เคียงกัน (เช่น typescript ถึง javascript) ในขณะที่การคอมไพล์ต้องลดระดับความเป็นนามธรรม ฉันคิดว่าจากเทมเพลตส่วนประกอบท่อคำสั่งและอื่น ๆ จนถึงเพียงแค่จาวาสคริปต์เป็นขั้นตอนลงบันไดนามธรรมและนั่นคือสาเหตุที่เรียกว่าคอมไพเลอร์
การเปลี่ยนแปลงที่สำคัญที่สุดอย่างหนึ่งจาก Angular 4 เป็น 5 คือคอมไพเลอร์ได้รับการเขียนใหม่ให้เร็วขึ้นและละเอียดขึ้น ในอดีตแอปพลิเคชัน Angular ใช้สิ่งที่เราเรียกว่าการคอมไพล์ Just-in-Time (JIT) โดยที่แอปพลิเคชันถูกคอมไพล์ที่รันไทม์ในเบราว์เซอร์ก่อนที่จะรัน คอมไพเลอร์อัปเดตใน Angular 5 ทำให้การย้ายไปยัง AOT ซึ่งทำให้แอปทำงานได้เร็วขึ้นเนื่องจากมีการรวบรวมน้อยลงเมื่อเรียกใช้แอป AOT จะเปิดใช้งานโดยค่าเริ่มต้นในรุ่นการผลิตใด ๆ ตั้งแต่ Angular CLI เวอร์ชัน 1.5
สมมติว่าเราต้องการสร้างแอปพลิเคชันสำหรับการปรับใช้และรันคำสั่งต่อไปนี้:
ng build --prod
มีบางสิ่งเกิดขึ้น: เวอร์ชันที่ใช้งานจริงการลดขนาดสินทรัพย์บันเดิลการแฮชชื่อไฟล์การเขย่าต้นไม้ AOT ... (เราสามารถเปิด / ปิดใช้งานได้โดยใช้แฟล็กเช่น aot = false) กล่าวโดยย่อธง prod จะสร้างบันเดิลที่ได้รับการปรับให้เหมาะสมของแอปพลิเคชันโดยทำการคอมไพล์ AOT โดยใช้ngc (คอมไพเลอร์เชิงมุม) เพื่อสร้างโค้ดที่ปรับให้เหมาะสมพร้อมสำหรับเบราว์เซอร์ ( ใช่มันรวบรวมเทมเพลตล่วงหน้า )
คอมไพเลอร์ TypeScript, tscมีหน้าที่ในการคอมไพล์ไฟล์ TypeScript เป็นคอมไพเลอร์ที่รับผิดชอบในการใช้งานคุณลักษณะ TypeScript เช่นประเภทคงที่และผลลัพธ์คือ JavaScript บริสุทธิ์ซึ่งคีย์เวิร์ดและนิพจน์ TypeScript ถูกลบออก
คอมไพเลอร์ TypeScript มีคุณสมบัติหลักสองประการคือเป็นทรานสไพเลอร์และตัวตรวจสอบประเภท คอมไพเลอร์ถ่ายทอด TypeScript เป็น JavaScript ทำการแปลงต่อไปนี้ในซอร์สโค้ดของคุณ:
เมื่อเรียกใช้คอมไพลเลอร์จะค้นหาคอนฟิกูเรชันที่โหลดใน tsconfig.json (รายการโดยละเอียดของตัวเลือกคอมไพเลอร์ทั้งหมดพร้อมกับค่าดีฟอลต์สามารถพบได้ที่นี่ )
โดยส่วนใหญ่คอมไพเลอร์ TypeScript จะทำงานเหมือนกับคอมไพเลอร์ใด ๆ แต่มีข้อแตกต่างอย่างหนึ่งที่สามารถจับได้โดยไม่ระมัดระวัง: โดยค่าเริ่มต้นคอมไพลเลอร์ยังคงปล่อยโค้ด JavaScript แม้ว่าจะพบข้อผิดพลาดก็ตาม โชคดีที่สามารถปิดใช้งานพฤติกรรมนี้ได้โดยตั้งค่าการnoEmitOnErrorกำหนดค่าเป็น true ในไฟล์ tsconfig.json
หมายเหตุ : tscและngcมีวัตถุประสงค์ที่แตกต่างกันและไม่เกี่ยวกับการเลือกอย่างใดอย่างหนึ่ง คำตอบนี้อาจจะเป็นที่สนใจ
คำตอบนี้สร้างขึ้นโดยอิงจากเนื้อหาจากหนังสือต่อไปนี้
Cloe, M. (2018). "โครงการ Angular 5: เรียนรู้การสร้างเว็บแอปพลิเคชันหน้าเดียวโดยใช้โครงการมากกว่า 70 โครงการ"
Dewey, B. , Grossnicklaus, K. , Japikse, P. (2017). "การสร้างเว็บแอปพลิเคชันด้วย Visual Studio 2017: การใช้. NET Core และ Modern JavaScript Frameworks"
ฟรีแมน, A. (2019). "Essential TypeScript: ตั้งแต่เริ่มต้นจนถึงระดับมืออาชีพ"
Ghiya, P. (2018). "TypeScript Microservices"
Iskandar, A. , Chivukulu, S. (2019). "การพัฒนาเว็บด้วย Angular และ Bootstrap - Third Edition"
Hennessy, K. , Arora, C. (2018). "เชิงมุม 6 ตามตัวอย่าง"
Jansen, R. , Wolf, I. , Vane, V. (2016). "TypeScript: การพัฒนา JavaScript สมัยใหม่"
โมฮัมเหม็ด, Z. (2019). "โครงการเชิงมุม".
เซชาดรี, S. (2018). "เชิงมุม: ขึ้นและทำงาน"
วิลเคน, J. (2018). "เชิงมุมในการดำเนินการ".