Bugün bana soruldu ve düzgün bir cevap veremedim.
JS'ye typcript transpiles. Sonra, "daha az" (isteğe bağlı) ve bir dağıtım yapma sürecinde başka neler var? Ama bunun gibi hiçbir şeyin (afaik) "derleme" ile ilgisi yoktur. Her şey paketlenir ve büyük ölçüde optimize edilir, ancak aslında derlenmez, değil mi?
Hatta gerçekten dikkate değer bir iş yapan bir "vaktinden önce" derleyici bile var. Neyi özlüyorum
Javascript kendisi hala yorumlanıyor, değil mi?
Yanıtlar:
Derlemenin kaynak kodunu alıp makine kodu, düşük seviyeli kodlar vb. Bu nedenle, Typescript almanın ve JavaScript üretmenin bir derleme biçimi olduğunu söylemek mantıklı görünüyor . IL diline derlendiğinde (örneğin) c # 'ın yaptığı şeyden farklı değildir.
Bununla birlikte, bunun için daha iyi bir kelime Transpiling olduğunu söyledi . Typescript derleyicisinin bir Transpiler olarak daha iyi tanımlanmasını öneririm.
Fark çok ince ve bir aktarıcı bir tür derleyici olarak düşünülebilir; ancak (saf) derlenmiş bir dil, (genellikle) yüksek seviyeli bir dili, C # örneğinde olduğu gibi, düşük (daha) seviyeli bir dile (makine koduna yakın) çevirmektir. Bir aktarıcı, yüksek seviyeli bir dili benzer seviyeli (soyutlama) bir dile (aynı zamanda yüksek seviyeli) dönüştürür. *
Derlenen kodun sonucu, genellikle kendi kendinize yazacağınız bir dil değildir . Bir aktarıcının sonucu, başka bir yüksek seviyeli dildir. Teorik olarak, IL yazabilirsiniz (örnek olarak), ancak gerçekten bir derleyici tarafından üretilmek üzere tasarlanmıştır ve bunu yapmak için hiçbir araç veya destek yoktur, yalnızca C # / vb.net'i derleyerek IL üretersiniz. Javascript ise kendi başına kullanılabilir (ve kullanılan) bir programlama dilidir.
* Bu kelimelerin tanımları ve kullanımları oldukça belirsiz olduğundan çok sayıda uyarı
Görünüşe göre üç soru soruyorsunuz:
Derleyici ve aktarıcı arasındaki fark nedir?
@ JörgWMittag bu soruya çok iyi bir cevap verdi.
Angular ve TypeScript derleyiciler veya aktarıcılar uygular mı?
Hem TS hem de Angular gerçek derleyiciler uygular . Derleme kodu üreten C / C ++ derleyicileriyle aynı sözcük analizi, ayrıştırma, anlam analizi ve kod oluşturma aşamalarını takip ederler (muhtemelen optimizasyon hariç). Sen görebilirsiniz hem de "derleyici" olarak adlandırılır klasör sınıf / açısal ve TS .
Açısal derleyici, TypeScript derleyicisiyle gerçekten ilgili değildir. Bunlar çok farklı derleyicilerdir.
Ayrı bir Angular derleyici var mı? Ne derliyor?
Angular'ın iki derleyicisi vardır:
Görünüm derleyicisinin görevi, bileşen şablonu için belirlediğiniz şablonu , daha sonra bir görünüm örneğini somutlaştırmak için kullanılan bir görünüm fabrikası olan bir bileşenin dahili sunumuna dönüştürmektir .
Şablonu dönüştürmenin yanı sıra, görünüm derleyici ayrıca çeşitli meta veri bilgilerini @HostBinding, @ViewChildvb . Dekoratörler biçiminde derler .
Bir bileşeni ve onun şablonunu şu şekilde tanımladığınızı varsayalım:
@Component({
selector: 'a-comp',
template: '<span>A Component</span>'
})
class AComponent {}
Bu verileri kullanarak derleyici aşağıdaki biraz basitleştirilmiş bileşen fabrikasını oluşturur:
function View_AComponent {
return jit_viewDef1(0,[
elementDef2(0,null,null,1,'span',...),
jit_textDef3(null,['My name is ',...])
]
Bir bileşen görünümünün yapısını açıklar ve bileşeni başlatırken kullanılır. İlk düğüm eleman tanımı, ikincisi ise metin tanımıdır. Her düğümün, parametreler listesi aracılığıyla somutlaştırılırken ihtiyaç duyduğu bilgileri aldığını görebilirsiniz. Gerekli tüm bağımlılıkları çözmek ve bunları çalışma zamanında sağlamak bir derleyicinin işidir.
Şu makaleleri okumanızı şiddetle tavsiye ederim:
Ayrıca, Angular AOT ve JIT derleyicisi arasındaki fark nedir sorusunun cevabına bakın .
Modül derleyicisinin işi, temelde sağlayıcıların birleştirilmiş tanımlarını içeren bir modül fabrikası oluşturmaktır.
Daha fazla bilgi için şunu okuyun:
TypeScript, JS'ye dönüşür. Sonra, "daha az" (isteğe bağlı) ve bir dağıtım yapma sürecinde başka neler var? Ama bunun gibi hiçbir şeyin (afaik) "derleme" ile ilgisi yoktur. Her şey paketlenir ve büyük ölçüde optimize edilir, ancak aslında derlenmez, değil mi?
Derleme , A dilinde yazılmış bir programı, B dilinde yazılmış anlamsal olarak eşdeğer bir programa dönüştürmek anlamına gelir, öyle ki derlenmiş programı B dili kurallarına göre değerlendirmek (örneğin, onu B için bir tercümanla yorumlamak ) aynı sonucu verir ve Orijinal programı A dili kurallarına göre değerlendirmekle aynı yan etkiler (örneğin, onu A için bir tercümanla yorumlamak ).
Derleme basitçe bir programı A dilinden B diline çevirmek anlamına gelir . Tüm anlamı bu. (Ayrıca, A ve B'nin aynı dilde olmasının tamamen mümkün olduğuna dikkat edin .)
Bazı durumlarda, A ve B'nin ne olduğuna ve derleyicinin ne yaptığına bağlı olarak belirli türdeki derleyiciler için daha özel isimlere sahibiz :
Ayrıca, eski kaynakların "derleme" ve "derleyici" yerine "çeviri" ve "çevirmen" terimlerini kullanabileceğini unutmayın. Örneğin, C "çeviri birimleri" hakkında konuşuyor.
Ayrıca "dil işlemcisi" terimiyle de karşılaşabilirsiniz. Bu, tanıma bağlı olarak bir derleyici, yorumlayıcı veya hem derleyici hem de yorumlayıcı anlamına gelebilir.
Javascript kendisi hala yorumlanıyor, değil mi?
JavaScript bir dildir. Diller bir dizi mantıksal kural ve kısıtlamadır. Diller yorumlanmaz veya derlenmez. Diller sadece vardır .
Derleme ve yorumlama, bir derleyici veya yorumlayıcının özellikleridir (ha!). Her dil bir derleyici ile uygulanabilir ve her dil bir yorumlayıcı ile uygulanabilir. Birçok dilde hem derleyici hem de yorumlayıcı bulunur. Birçok modern yüksek performanslı yürütme motorunda hem en az bir derleyici hem de en az bir yorumlayıcı bulunur.
Bu iki terim, farklı soyutlama katmanlarına aittir. İngilizce yazılmış bir dil olsaydı, "yorumlanmış dil" bir tür hatası olurdu.
Ayrıca bazı dillerin yorumlayıcı veya derleyici olmadığına da dikkat edin. Hiç uygulaması olmayan diller var. Yine de bunlar diller ve bunlara program yazabilirsiniz. Onları çalıştıramazsın.
Ayrıca, her şey de yorumlanır notu o noktada : Bir şeyi yürütmek istiyorsanız, gereken yorumlamak. Derleme sadece kodu bir dilden diğerine çevirir. Çalıştırmıyor. Yorumlama onu çalıştırır. (Bazen, donanımda bir yorumlayıcı uygulandığında, buna "CPU" diyoruz, ancak yine de bir yorumlayıcıdır.)
Örnek olay: Şu anda var olan her bir ana akım JavaScript uygulamasının bir derleyicisi vardır.
V8, saf bir derleyici olarak başladı: JavaScript'i doğrudan orta düzeyde optimize edilmiş yerel makine koduna derledi. Daha sonra ikinci bir derleyici eklendi. Şimdi, iki derleyici var: orta düzeyde optimize edilmiş kod üreten ancak derleyicinin kendisi çok hızlı ve az RAM kullanan hafif bir derleyici. Bu derleyici ayrıca derlenen koda profil oluşturma kodunu da ekler. İkinci derleyici, daha ağır, daha yavaş, daha pahalı bir derleyicidir, ancak çok daha sıkı, çok daha hızlı kod üretir. Ayrıca, dinamik optimizasyon kararları almak için ilk derleyici tarafından enjekte edilen profil oluşturma kodunun sonuçlarını kullanır. Ayrıca, ikinci derleyiciyi kullanarak hangi kodun yeniden derleneceğine karar, bu profil oluşturma bilgisine göre verilir. İşin içinde hiçbir zaman bir tercüman bulunmadığını unutmayın. V8 asla yorumlamaz, her zaman derler. Yapmaz hatta bir tercüman içermelidir. (Aslında bugünlerde öyle olduğuna inanıyorum, ilk iki yinelemeyi açıklıyorum.)
SpiderMonkey, JavaScript'i daha sonra yorumladığı SpiderMonkey bayt koduna derler. Yorumlayıcı aynı zamanda kodun profilini çıkarır ve daha sonra en sık çalıştırılan kod bir derleyici tarafından yerel makine koduna derlenir. Dolayısıyla, SpiderMonkey iki derleyici içerir : biri JavaScript'ten SpiderMonkey bayt koduna ve diğeri SpiderMonkey bayt kodundan yerel makine koduna.
Neredeyse tüm JavaScript yürütme motorları (V8 hariç), JavaScript'i bayt koduna derleyen bir AOT derleyicisinin bu modelini ve bu bayt kodunu yorumlama ve derleme arasında geçiş yapan karma modlu bir motoru izler.
Bir yorum yazdın:
Makine kodunun işin içinde olduğunu düşünüyordum.
"Makine kodu" ne anlama geliyor?
Bir insanın makine dili nedir, diğerinin orta dili ve tersi nedir? Örneğin, doğal olarak bu tür bir CPU, JVM bayt kodu yürütebilir işlemciler bulunmaktadır JVM bayt kodu olan özgün bir makine kodu. O x86 makine kodunu çalıştırdığınızda Ve x86 makine kodu için tercümanlar vardır edilir bayt kodu yorumlanır.
Java ile yazılmış JPC adlı bir x86 yorumlayıcısı var. Yerel bir JVM CPU üzerinde çalışan JPC üzerinde x86 makine kodunu çalıştırırsam… bayt kodu hangisidir ve yerel kod hangisidir? X86 makine kodunu JavaScript'e derlersem (evet, bunu yapabilen araçlar var) ve bunu telefonumdaki (ARM CPU'lu) bir tarayıcıda çalıştırırsam, bayt kodu ve yerel makine kodu hangisidir? Ya derlediğim program bir SPARC öykünücüsüyse ve onu SPARC kodunu çalıştırmak için kullanıyorsam?
O Not her dil soyut bir makineyi tetiklediğini ve makine için makine dilidir. Dolayısıyla, her dil (çok yüksek seviyeli diller dahil) yerel makine kodudur. Ayrıca her dil için bir tercüman yazabilirsiniz. Dolayısıyla, her dil (x86 makine kodu dahil) yerel değildir.
Bir tarayıcıda çalıştırmak için yazdığınız kodu almak iki şeyi içerir:
1) Typescript'i JavaScript'e dönüştürmek . Bu, çözülmüş bir problemdir. Sanırım sadece webpack kullanıyorlar.
2) Açısal soyutlamaları JavaScript'te derlemek . Bileşenler, borular, yönergeler, şablonlar vb. Gibi şeyleri kastediyorum. Açısal çekirdek ekibin üzerinde çalıştığı şey budur.
Açısal derleyici olan ikinci bit ile gerçekten ilgileniyorsanız, derleyici yazarı Tobias Bosch'un AngularConnect 2016'da Angular Derleyiciyi açıkladığını izleyin .
Sanırım burada aktarım ve derleme arasında biraz karışıklık var. Bunun bir önemi yok ve kişisel bir zevk meselesi, ikisi de sadece kodun temsilleri arasında dönüşüm yapıyor. Ancak kişisel olarak kullandığım tanım , transpilasyonun benzer bir soyutlama düzeyinde iki farklı dil arasında olduğu (örneğin , typcript'ten javascript'e), oysa derlemenin soyutlama düzeyinde bir adım atması gerektiğidir. Bence şablonlardan, bileşenlerden, borulardan, yönergelerden vb. Sadece javascript'e, soyutlama merdiveninin bir aşamasıdır ve bu yüzden derleyici olarak adlandırılır.
Angular 4'ten 5'e en önemli değişikliklerden biri, derleyicinin yeniden yazılmasının daha hızlı ve daha kapsamlı olmasıdır. Geçmişte, Angular uygulamaları, uygulamanın çalıştırılmadan önce tarayıcıda çalışma zamanında derlendiği Just-in-Time (JIT) derlemesi dediğimiz şeyi kullanıyordu. Angular 5'teki derleyici güncellemeleri, AOT'ye geçişi geliştirdi ve bu, uygulamayı çalıştırırken daha az derleme gerçekleştirdiğinden uygulamanın daha hızlı çalışmasını sağladı. AOT, Angular CLI'nin 1.5 sürümünden bu yana herhangi bir üretim yapısında varsayılan olarak etkinleştirilir.
Diyelim ki dağıtım için bir uygulama oluşturmak ve aşağıdaki komutu çalıştırmak istiyoruz:
ng build --prod
Birkaç şey olur: üretim sürümü, küçültme, paket varlıkları, dosya adı karması, ağaç sallama, AOT ... (bunu bayrakları kullanarak etkinleştirebilir / devre dışı bırakabiliriz, örn. Aot = false). Kısacası, prod bayrağı , tarayıcı için hazır optimize edilmiş kod oluşturmak için ngc'yi (Angular derleyici) kullanarak AOT derlemesi yaparak uygulamanın optimize edilmiş bir paketini oluşturur ( Evet, şablonları önceden derler ).
TypeScript derleyicisi, tsc , TypeScript dosyalarını derlemekten sorumludur. Statik türler gibi TypeScript özelliklerinin uygulanmasından sorumlu olan derleyicidir ve sonuç, TypeScript anahtar sözcüklerinin ve ifadelerinin kaldırıldığı saf JavaScript'tir.
TypeScript derleyicisinin iki ana özelliği vardır: bir aktarıcı ve bir tür denetleyicidir. Derleyici TypeScript'i JavaScript'e aktarır. Kaynak kodunuzda aşağıdaki dönüşümleri yapar:
Derleyici bunu çağırarak tsconfig.json'a yüklenen konfigürasyonları arar (Varsayılan değerlerle birlikte tüm derleyici seçeneklerinin ayrıntılı listesi burada bulunabilir ).
Çoğu açıdan, TypeScript derleyicisi herhangi bir derleyici gibi çalışır. Ancak dikkatsizliği yakalayabilecek bir fark vardır: varsayılan olarak, derleyici bir hata ile karşılaştığında bile JavaScript kodu yaymaya devam eder. Neyse ki, bu davranış noEmitOnErrortsconfig.json dosyasındaki yapılandırma ayarı true olarak ayarlanarak devre dışı bırakılabilir .
Not : tsc ve ngc'nin farklı amaçları vardır ve bu, birini diğerinin üzerine seçmekle ilgili değildir. Bu cevap ilgi çekici olabilir .
Bu cevap, aşağıdaki kitapların içeriğine göre oluşturulmuştur.
Cloe, M. (2018). "Angular 5 Proje: 70+ Projeyi Kullanarak Tek Sayfalı Web Uygulamaları Oluşturmayı Öğrenin".
Dewey, B., Grossnicklaus, K., Japikse, P. (2017). "Visual Studio 2017 ile Web Uygulamaları Oluşturma: .NET Core ve Modern JavaScript Çerçevelerini Kullanma".
Freeman, A. (2019). "Temel TypeScript: Başlangıçtan Pro'ya".
Ghiya, P. (2018). "TypeScript Mikro Hizmetleri".
Iskandar, A., Chivukulu, S. (2019). "Angular ve Bootstrap ile Web Geliştirme - Üçüncü Baskı".
Hennessy, K., Arora, C. (2018). "Örnekle Açısal 6".
Jansen, R., Wolf, I., Vane, V. (2016). "TypeScript: Modern JavaScript Geliştirme".
Muhammed, Z. (2019). "Açısal Projeler".
Seshadri, S. (2018). "Açısal: Yukarı ve Çalışıyor".
Wilken, J. (2018). "Açısal Eylemde".