Về số 1, dòng sản phẩm sẽ gần như sau:
JavaScript - cao nhất, được nhập động, GC. Bạn chỉ có thể sử dụng HTML5/CSS cho giao diện người dùng của mình, khung công tác XAML (không gian tên Windows.UI.XAML) không khả dụng. Cung cấp một số API JS tiêu chuẩn (được chỉ định bởi HTML5) ngoài bề mặt có sẵn của WinRT, chẳng hạn như lưu trữ cục bộ hoặc IndexedDB. Được gõ động, quá trình xử lý CPU nặng có thể chậm hơn .NET hoặc C++, mặc dù động cơ JS vẫn rất nhanh do được biên dịch JIT và được tối ưu hóa rất nhiều. Bạn có thể tiêu thụ các thành phần C++ và .NET WinRT, nhưng không viết riêng của bạn trong JS. Một số khía cạnh của phép chiếu ngôn ngữ dường như bị giới hạn tương ứng - ví dụ: cho đến nay tôi có thể thấy, chẳng có cách nào để thực hiện một giao diện WinRT trong JS, ví dụ. Các thư viện JS hiện có thường có thể được tái sử dụng mà không cần hoặc tốn ít công sức, miễn là chúng hoạt động trong IE10.
.NET (C#/VB) - ở mức trung bình, được nhập tĩnh với tính năng nhập động tùy chọn (dynamic từ khóa v.v.) và GC. Giao diện người dùng XAML là khung mặc định cho giao diện người dùng, nhưng bạn cũng có thể sử dụng HTML bằng cách sử dụng điều khiển WebView. Cung cấp quyền truy cập đầy đủ vào thư viện WinRT, nhưng cũng có một số đặc điểm riêng của nó, đôi khi thuận tiện hơn để sử dụng (ví dụ: Stream và IInputStream/IOutputStream). Ngoài ra, chỉ có một hỗ trợ mức ngôn ngữ đặc biệt cho các hoạt động không đồng bộ (async và await từ khóa), được sử dụng nhiều khi sử dụng API WinRT do thiết kế không đồng bộ cao. Nói chung, cung cấp hầu hết cú pháp đường - ngoài công cụ không đồng bộ, bạn sẽ nhận được LINQ to objects (hoạt động trên các bộ sưu tập WinRT). Có thể viết các thành phần WinRT của riêng bạn, sau đó có thể được sử dụng từ JS hoặc C++/CX. Các thư viện .NET hiện có có thể hoặc không thể tái sử dụng được, tùy thuộc vào những lớp nào trong .NET Framework mà chúng dựa vào; các thành phần được viết cho Silverlight hoặc WP7 có nhiều khả năng được tái sử dụng mà không có hoặc thay đổi tối thiểu, trong khi các thành phần được viết cho .NET 4 Full hoặc Hồ sơ khách hàng có thể yêu cầu thay đổi đáng kể để chạy.
C++/CX (Phần mở rộng thành phần Visual C++) - thấp/trung cấp, được nhập tĩnh, không chỉ GC - chỉ đếm ngược. Gần nhất "với kim loại" ở chỗ mô hình đối tượng của nó được thiết kế để ánh xạ trực tiếp tới WinRT mà không có sự không phù hợp trở kháng - do đó vẫn nạp tiền - nhưng vẫn đủ cao để tránh boilerplate và nói chung là an toàn để sử dụng (ví dụ ngoại lệ hơn là HRESULTs, làm đối tượng và không xử lý, dynamic_cast thay vì QueryInterface v.v.). Không có lớp bổ sung, đối tượng proxy, vv giữa bạn và WinRT, tất cả các cuộc gọi đều trực tiếp. Trong hầu hết các trường hợp, nhanh nhất trong cả ba trường hợp, mặc dù sự khác biệt chính xác thay đổi đáng kể tùy thuộc vào nhiệm vụ cụ thể và có thể trừ đi một số (ví dụ: ứng dụng hướng sự kiện không có hoặc ít tính toán) và đáng kể cho những người khác (ví dụ: phân tích cú pháp hoặc toán học nặng)). Câu chuyện giao diện người dùng giống với .NET. Ngoài ra, bạn nhận được toàn bộ thư viện chuẩn C++ có sẵn cho bạn, cũng như một tập con của ATL. Có thể viết các thành phần WinRT của riêng bạn, sau đó có thể được sử dụng từ JS hoặc .NET. Các thư viện C++ hiện tại có thể hoặc không thể tái sử dụng được, tùy thuộc vào các API mà chúng sử dụng; những người dựa hoàn toàn vào tiêu chuẩn C/C++ thường sẽ không hoạt động mà không có thay đổi, trong khi những người gọi API Win32 có thể gây ra vấn đề nếu họ dựa vào API không có sẵn trong vùng chứa ứng dụng Metro.
Về # 3, bộ phim này - http://channel9.msdn.com/Events/BUILD/BUILD2011/TOOL-789C - nên trả lời hầu hết các câu hỏi của bạn liên quan đến việc sử dụng Win32 (mà tôi đoán những gì "ở mức độ thấp DLL" có nghĩa là) từ các ứng dụng Metro. Lưu ý rằng trong khi video là về C++, điều này cũng áp dụng đầy đủ cho C#, như P/Invoke và COM Interop vẫn còn đó. Vì vậy, nếu bạn có thể gọi nó từ C++, bạn có thể gọi nó từ C#.
Về # 2 họ nói trong bài phát biểu rằng jquery được hỗ trợ và (IIUC) sẽ được vận chuyển cùng với VS. – CAFxX