Trình biên dịch góc "biên dịch" là gì?

Tôi đã được hỏi điều đó ngày hôm nay và không thể đưa ra câu trả lời thích hợp.

Chuyển đổi đoạn mã định dạng sang JS. Sau đó là rung cây, "ít hơn" (tùy chọn) và những gì khác trong quá trình triển khai. Nhưng không có gì như thế (afaik) có liên quan gì đến "biên dịch". Mọi thứ đều được đóng gói và tối ưu hóa rất nhiều, nhưng nó không thực sự được biên dịch, phải không?

Thậm chí còn có một trình biên dịch "đi trước thời đại", thực sự làm một công việc đáng chú ý. Tôi nhớ gì?

Bản thân Javascript vẫn được diễn giải, đúng không?

Bạn đang cho rằng biên dịch có nghĩa là lấy mã nguồn và tạo ra mã máy, mã cấp thấp, v.v. Nhưng thực ra biên dịch chỉ có nghĩa là lấy một mã nguồn và biến nó thành một mã khác. Vì vậy, có vẻ hợp lý khi nói rằng việc lấy Typecript và tạo JavaScript là một hình thức biên dịch. Nó không khác với những gì (ví dụ) c # làm khi nó được biên dịch sang ngôn ngữ IL.

Điều đó nói rằng, tôi muốn nói một từ tốt hơn cho điều này là Vận chuyển . Tôi đề nghị rằng trình biên dịch Typecript được mô tả tốt hơn như một Trình chuyển đổi.

Sự khác biệt là nhỏ và một trình chuyển đổi có thể được coi là một loại trình biên dịch; nhưng một ngôn ngữ biên dịch (thuần túy) là (thường) chuyển một ngôn ngữ cấp cao sang một ngôn ngữ cấp thấp (gần giống với mã máy), như ví dụ C #. Một bộ chuyển tiếp biến một ngôn ngữ cấp cao thành một ngôn ngữ cấp độ tương tự (trừu tượng hóa) (cũng cấp cao). ^*

Kết quả của mã được biên dịch thường không phải là ngôn ngữ mà bạn sẽ tự viết . Kết quả của một bộ chuyển tiếp là một ngôn ngữ cấp cao khác. Về lý thuyết, bạn có thể viết IL (làm ví dụ) nhưng nó thực sự được thiết kế để được tạo ra bởi trình biên dịch và không có công cụ hoặc hỗ trợ nào để làm việc này, bạn tạo IL bằng cách biên dịch C # / vb.net mà thôi. Trong khi Javascript là một ngôn ngữ lập trình có thể sử dụng (và được sử dụng) theo đúng nghĩa của nó.

_{* Rất nhiều lưu ý vì định nghĩa của những từ này và cách sử dụng chúng khá mơ hồ}

Có vẻ như bạn đang hỏi ba câu hỏi trong một:

• Sự khác biệt giữa một trình biên dịch và một trình vận chuyển là gì?
• Angular và TypeScript có triển khai trình biên dịch hoặc trình biến đổi không?
• Có trình biên dịch Angular riêng không? Nó biên dịch những gì?

Sự khác biệt giữa trình biên dịch và trình chuyển đổi là gì?

@ JörgWMittag đã đưa ra một câu trả lời rất tốt cho câu hỏi này.

Angular và TypeScript có triển khai trình biên dịch hoặc trình biến đổi không?

Cả TS và Angular đều triển khai các trình biên dịch thực . Chúng tuân theo các giai đoạn phân tích từ vựng, phân tích cú pháp, phân tích ngữ nghĩa và tạo mã giống như các trình biên dịch C / C ++ tạo ra mã hợp ngữ (ngoại trừ có thể là để tối ưu hóa). Bạn có thể thấy rằng lớp / thư mục được đặt tên là "trình biên dịch" trong cả Angular và TS .

Trình biên dịch góc không thực sự liên quan đến trình biên dịch TypeScript. Đây là những trình biên dịch rất khác nhau.

Có trình biên dịch Angular riêng không? Nó biên dịch những gì?

Angular có hai trình biên dịch:

• Xem trình biên dịch
• Trình biên dịch mô-đun

Công việc của trình biên dịch dạng xem là biến đổi mẫu bạn chỉ định cho mẫu thành phần thành biểu diễn bên trong của một thành phần là một nhà máy chế độ xem sau đó được sử dụng để khởi tạo một thể hiện dạng xem .

Bên cạnh việc chuyển đổi mẫu, trình biên dịch chế độ xem cũng biên dịch các thông tin siêu dữ liệu khác nhau dưới dạng trình trang trí như @HostBinding, @ViewChildv.v.

Giả sử bạn xác định một thành phần và mẫu của nó như thế này:

@Component({
  selector: 'a-comp',
  template: '<span>A Component</span>'
})
class AComponent {}

Sử dụng dữ liệu này, trình biên dịch tạo ra nhà máy sản xuất thành phần đơn giản hơn một chút sau:

function View_AComponent {
  return jit_viewDef1(0,[
      elementDef2(0,null,null,1,'span',...),
      jit_textDef3(null,['My name is ',...])
    ]

Nó mô tả cấu trúc của một khung nhìn thành phần và được sử dụng khi khởi tạo thành phần. Nút đầu tiên là định nghĩa phần tử và nút thứ hai là định nghĩa văn bản. Bạn có thể thấy rằng mỗi nút nhận được thông tin cần thiết khi được khởi tạo thông qua danh sách tham số. Công việc của một trình biên dịch là giải quyết tất cả các phụ thuộc bắt buộc và cung cấp chúng trong thời gian chạy.

Tôi thực sự khuyên bạn nên đọc những bài viết này:

• Đây là những gì bạn cần biết về các thành phần động trong Angular
• Đây là lý do tại sao bạn sẽ không tìm thấy các thành phần bên trong Angular

Ngoài ra, hãy xem câu trả lời cho Sự khác biệt giữa trình biên dịch Angular AOT và JIT là gì.

Công việc của trình biên dịch mô-đun là tạo một nhà máy sản xuất mô-đun về cơ bản chứa các định nghĩa được hợp nhất của các trình cung cấp.

Để biết thêm thông tin, hãy đọc:

• Tránh nhầm lẫn thường gặp với các mô-đun trong Angular

Bản ghi kiểu chuyển dịch sang JS. Sau đó là rung cây, "ít hơn" (tùy chọn) và những gì khác trong quá trình triển khai. Nhưng không có gì như thế (afaik) có liên quan gì đến "biên dịch". Mọi thứ đều được đóng gói và tối ưu hóa rất nhiều, nhưng nó không thực sự được biên dịch, phải không?

Biên dịch có nghĩa là chuyển đổi một chương trình được viết bằng ngôn ngữ A thành một chương trình tương đương về mặt ngữ nghĩa được viết bằng ngôn ngữ B sao cho việc đánh giá chương trình đã biên dịch theo các quy tắc của ngôn ngữ B (ví dụ như thông dịch nó bằng một trình thông dịch cho ngôn ngữ B ) mang lại cùng một kết quả và có tác dụng phụ giống như đánh giá chương trình gốc theo các quy tắc của ngôn ngữ A (ví dụ thông dịch nó với một thông dịch viên cho A ).

Compilation chỉ có nghĩa là dịch một chương trình từ ngôn ngữ Một ngôn ngữ B . Đó là tất cả những gì nó có nghĩa. (Cũng lưu ý rằng A và B hoàn toàn có thể là cùng một ngôn ngữ.)

Trong một số trường hợp, chúng ta có nhiều tên chuyên biệt hơn cho một số loại trình biên dịch nhất định, tùy thuộc vào A và B là gì và trình biên dịch làm gì:

• nếu A được coi là hợp ngữ và B được coi là ngôn ngữ máy, thì chúng ta gọi nó là trình hợp dịch ,
• nếu A được coi là ngôn ngữ máy và B được coi là hợp ngữ, thì chúng tôi gọi nó là trình tháo gỡ ,
• nếu A được coi là cấp thấp hơn B , thì chúng tôi gọi nó là trình dịch ngược ,
• nếu A và B là cùng một ngôn ngữ và chương trình kết quả theo một cách nào đó nhanh hơn hoặc nhẹ hơn, thì chúng tôi gọi nó là trình tối ưu hóa ,
• nếu A và B là những ngôn ngữ đó, và chương trình kết quả là nhỏ hơn, sau đó chúng tôi gọi nó là một minifier ,
• nếu A và B là các ngôn ngữ giống nhau và chương trình kết quả là khó đọc hơn, thì chúng tôi gọi nó là một obfuscator ,
• nếu A và B được coi là ở cùng một mức độ trừu tượng, thì chúng tôi gọi nó là một trình chuyển đổi và
• nếu A và B được coi là ở cùng một mức độ trừu tượng và chương trình kết quả duy trì định dạng, nhận xét và ý định của người lập trình để có thể duy trì kết quả chương trình theo cùng một kiểu như chương trình gốc, thì chúng tôi gọi nó là một công cụ tái thiết kế .

Ngoài ra, lưu ý rằng các nguồn cũ hơn có thể sử dụng thuật ngữ "bản dịch" và "người dịch" thay vì "biên dịch" và "trình biên dịch". Ví dụ, C nói về "đơn vị dịch".

Bạn cũng có thể tình cờ bắt gặp thuật ngữ "bộ xử lý ngôn ngữ". Điều này có thể có nghĩa là một trình biên dịch, một trình thông dịch hoặc cả hai trình biên dịch và trình thông dịch tùy thuộc vào định nghĩa.

Bản thân Javascript vẫn được diễn giải, đúng không?

JavaScript là một ngôn ngữ. Ngôn ngữ là một tập hợp các quy tắc logic và các hạn chế. Ngôn ngữ không được thông dịch hoặc biên dịch. Ngôn ngữ chỉ là .

Biên dịch và thông dịch là những đặc điểm của một trình biên dịch hoặc trình thông dịch (duh!). Mọi ngôn ngữ đều có thể được triển khai bằng trình biên dịch và mọi ngôn ngữ đều có thể được thực hiện với trình thông dịch. Nhiều ngôn ngữ có cả trình biên dịch và thông dịch viên. Nhiều công cụ thực thi hiệu suất cao hiện đại có cả ít nhất một trình biên dịch và ít nhất một trình thông dịch.

Hai thuật ngữ này thuộc các lớp trừu tượng khác nhau. Nếu tiếng Anh là ngôn ngữ được nhập, thì "ngôn ngữ thông dịch" sẽ là lỗi nhập.

Cũng lưu ý rằng một số ngôn ngữ không có trình thông dịch hoặc trình biên dịch. Có những ngôn ngữ không có triển khai nào cả. Tuy nhiên, chúng là ngôn ngữ và bạn có thể viết chương trình trong đó. Bạn chỉ không thể chạy chúng.

Ngoài ra, hãy lưu ý rằng mọi thứ đều được diễn giải tại một số điểm : nếu bạn muốn thực thi điều gì đó, bạn phải diễn giải nó. Biên dịch chỉ dịch mã từ ngôn ngữ này sang ngôn ngữ khác. Nó không chạy nó. Phiên dịch chạy nó. (Đôi khi, khi một trình thông dịch được triển khai trong phần cứng, chúng tôi gọi nó là "CPU", nhưng nó vẫn là một trình thông dịch.)

Trường hợp cụ thể: mọi triển khai JavaScript chính thống hiện có đều có một trình biên dịch.

V8 khởi đầu như một trình biên dịch thuần túy: nó biên dịch JavaScript thẳng thành mã máy gốc được tối ưu hóa vừa phải. Sau đó, một trình biên dịch thứ hai đã được thêm vào. Bây giờ, có hai trình biên dịch: một trình biên dịch nhẹ tạo ra mã được tối ưu hóa vừa phải nhưng bản thân trình biên dịch này rất nhanh và sử dụng ít RAM. Trình biên dịch này cũng đưa mã biên dịch vào mã đã biên dịch. Trình biên dịch thứ hai là trình biên dịch nặng hơn, chậm hơn, đắt hơn, tuy nhiên, nó tạo ra mã chặt chẽ hơn, nhanh hơn nhiều. Nó cũng sử dụng kết quả của mã cấu hình được đưa vào bởi trình biên dịch đầu tiên để đưa ra quyết định tối ưu hóa động. Ngoài ra, quyết định biên dịch lại mã nào bằng trình biên dịch thứ hai được thực hiện dựa trên thông tin biên dịch đó. Lưu ý rằng không lúc nào có thông dịch viên tham gia. V8 không bao giờ thông dịch, nó luôn biên dịch. Nó không' t thậm chí chứa một thông dịch viên. (Trên thực tế, tôi tin rằng ngày nay điều đó xảy ra, tôi đang mô tả hai lần lặp đầu tiên.)

SpiderMonkey biên dịch JavaScript thành mã byte SpiderMonkey, mã này sau đó sẽ thông dịch. Trình thông dịch cũng cấu hình mã và sau đó mã được thực thi thường xuyên nhất sẽ được trình biên dịch biên dịch thành mã máy gốc. Vì vậy, SpiderMonkey chứa hai trình biên dịch: một từ JavaScript sang SpiderMonkey bytecode, và một từ SpiderMonkey bytecode sang mã máy gốc.

Hầu hết tất cả các công cụ thực thi JavaScript (ngoại trừ V8) đều tuân theo mô hình này của trình biên dịch AOT biên dịch JavaScript thành mã byte và công cụ chế độ hỗn hợp chuyển đổi giữa thông dịch và biên dịch mã byte đó.

Bạn đã viết trong một bình luận:

Tôi thực sự đã nghĩ rằng mã máy ở đâu đó có liên quan.

"Mã máy" thậm chí có nghĩa là gì?

Ngôn ngữ máy của một người là ngôn ngữ trung gian của người khác và ngược lại là gì? Ví dụ, có những CPU có thể thực thi JVM bytecode một cách tự nhiên, trên một CPU như vậy, JVM bytecode là mã máy gốc. Và có các trình thông dịch cho mã máy x86, khi bạn chạy mã máy x86 đó sẽ được thông dịch theo mã máy.

Có một trình thông dịch x86 được gọi là JPC được viết bằng Java. Nếu tôi chạy mã máy x86 trên JPC chạy trên CPU JVM gốc… thì mã bytecode nào và mã nào là mã gốc? Nếu tôi biên dịch mã máy x86 sang JavaScript (vâng, có những công cụ có thể làm điều đó) và chạy nó trong trình duyệt trên điện thoại của tôi (có CPU ARM), thì mã bytecode nào và mã máy gốc nào? Điều gì sẽ xảy ra nếu chương trình tôi đang biên dịch là trình giả lập SPARC và tôi sử dụng nó để chạy mã SPARC?

Lưu ý rằng mọi ngôn ngữ đều tạo ra một máy trừu tượng và là ngôn ngữ máy cho máy đó. Vì vậy, mọi ngôn ngữ (kể cả những ngôn ngữ cấp rất cao) đều là mã máy riêng. Ngoài ra, bạn có thể viết thông dịch viên cho mọi ngôn ngữ. Vì vậy, mọi ngôn ngữ (bao gồm cả mã máy x86) đều không phải là ngôn ngữ gốc.

Lấy mã bạn đã viết để chạy trên trình duyệt liên quan đến hai điều:

1) Dịch chuyển các Typecript sang JavaScript . Đây là loại một vấn đề đã được giải quyết. Tôi nghĩ họ chỉ sử dụng webpack.

2) Biên dịch các phần trừu tượng góc cạnh thành JavaScript . Ý tôi là những thứ như thành phần, đường ống, chỉ thị, mẫu, v.v. Đây là những gì nhóm cốt lõi góc cạnh làm việc.

Trong trường hợp bạn thực sự quan tâm đến bit thứ hai đó, trình biên dịch góc cạnh, hãy xem tác giả trình biên dịch Tobias Bosch giải thích về Trình biên dịch Angular tại AngularConnect 2016 .

Tôi nghĩ rằng có một chút nhầm lẫn đang xảy ra ở đây giữa chuyển ngữ và biên dịch. Nó không quan trọng và là vấn đề của sở thích cá nhân, cả hai đều chỉ là sự chuyển đổi giữa các biểu diễn mã. Nhưng định nghĩa cá nhân tôi sử dụng là sự chuyển dịch là giữa hai ngôn ngữ khác nhau ở mức độ trừu tượng tương tự (ví dụ: typecript thành javascript), trong khi quá trình biên dịch yêu cầu giảm một bước về mức độ trừu tượng. Tôi nghĩ rằng từ các mẫu, thành phần, đường ống, chỉ thị, v.v. đến chỉ javascript là một bước xuống bậc thang trừu tượng và đó là lý do tại sao nó được gọi là trình biên dịch.

Trình biên dịch Angular

Một trong những thay đổi quan trọng nhất từ ​​Angular 4 lên 5 là trình biên dịch đã được viết lại nhanh hơn và kỹ lưỡng hơn. Trước đây, các ứng dụng Angular sử dụng cái mà chúng tôi gọi là biên dịch Just-in-Time (JIT), nơi ứng dụng được biên dịch trong thời gian chạy trong trình duyệt trước khi chạy. Các bản cập nhật trình biên dịch trong Angular 5 đã nâng cao việc chuyển sang AOT, giúp ứng dụng chạy nhanh hơn vì nó thực hiện ít biên dịch hơn khi chạy ứng dụng. AOT được bật theo mặc định trong bất kỳ phiên bản sản xuất nào kể từ phiên bản 1.5 của Angular CLI.

Giả sử chúng tôi muốn xây dựng một ứng dụng để triển khai và chạy lệnh sau:

ng build --prod

Một số điều xảy ra: phiên bản sản xuất, thu nhỏ, nội dung gói, băm tên tệp, rung cây, AOT ... (chúng ta có thể bật / tắt tính năng này bằng cách sử dụng cờ, ví dụ: aot = false). Tóm lại, cờ sản xuất tạo ra một gói ứng dụng được tối ưu hóa bằng cách thực hiện biên dịch AOT sử dụng ngc (trình biên dịch Angular) để tạo mã tối ưu sẵn sàng cho trình duyệt ( Có, nó biên dịch trước các mẫu ).

Trình biên dịch TypeScript

Trình biên dịch TypeScript, tsc , chịu trách nhiệm biên dịch các tệp TypeScript. Nó là trình biên dịch chịu trách nhiệm triển khai các tính năng của TypeScript, chẳng hạn như các kiểu tĩnh và kết quả là JavaScript thuần túy mà từ khóa và biểu thức TypeScript đã bị loại bỏ.

Trình biên dịch TypeScript có hai tính năng chính: nó là một trình chuyển tiếp và một trình kiểm tra kiểu. Trình biên dịch chuyển TypeScript sang JavaScript. Nó thực hiện các biến đổi sau trên mã nguồn của bạn:

• Xóa tất cả các loại chú thích.
• Biên dịch các tính năng JavaScript mới cho các phiên bản JavaScript cũ.
• Biên dịch các tính năng của TypeScript không phải là JavaScript chuẩn.

Gọi nó, trình biên dịch tìm kiếm các cấu hình được tải trong tsconfig.json (Danh sách chi tiết của tất cả các tùy chọn trình biên dịch, cùng với các giá trị mặc định, có thể được tìm thấy tại đây ).

Trong hầu hết các khía cạnh, trình biên dịch TypeScript hoạt động giống như bất kỳ trình biên dịch nào. Nhưng có một điểm khác biệt có thể phát hiện ra điều không cẩn thận: theo mặc định, trình biên dịch tiếp tục phát ra mã JavaScript ngay cả khi nó gặp lỗi. May mắn thay, hành vi này có thể bị vô hiệu hóa bằng cách đặt cài đặt noEmitOnErrorcấu hình thành true trong tệp tsconfig.json.

Cần lưu ý : tsc và ngc có các mục đích khác nhau và không phải là chọn cái này hơn cái kia. Câu trả lời này có thể được quan tâm .

Câu trả lời này được tạo ra dựa trên nội dung từ những cuốn sách sau

• Cloe, M. (2018). "Dự án Angular 5: Tìm hiểu cách xây dựng ứng dụng web trang đơn bằng cách sử dụng hơn 70 dự án".

• Dewey, B., Grossnicklaus, K., Japikse, P. (2017). "Xây dựng ứng dụng web với Visual Studio 2017: Sử dụng .NET Core và Khung JavaScript hiện đại".

• Freeman, A. (2019). "TypeScript cơ bản: Từ Sơ cấp đến Chuyên nghiệp".

• Ghiya, P. (2018). "TypeScript Microservices".

• Iskandar, A., Chivukulu, S. (2019). "Phát triển Web với Angular và Bootstrap - Phiên bản thứ ba".

• Hennessy, K., Arora, C. (2018). "Angular 6 bằng ví dụ".

• Jansen, R., Wolf, I., Vane, V. (2016). "TypeScript: Phát triển JavaScript hiện đại".

• Mohammed, Z. (2019). "Dự án góc cạnh".

• Seshadri, S. (2018). "Angular: Up and Running".

• Wilken, J. (2018). "Angular in Action".