Здравствуйте, Ikemefula, Вы писали:
I>Вообще, у Микрософта кучка софта выходит именно на JS. Например Visual Studio Code, Azure Explorer и тд. Вот такие нынче дотнеты.
Ну сейчас то интересно сравнивать с Xamarin. Сейчас изучаю Angular 2 так TS очень приятный язык. Так что скорее и у MS напрямую JS навряд ли пользуются.
Кстати а есть возможность компилировать TS в asm.js?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Кстати а есть возможность компилировать TS в asm.js? S>> Нашел только старую тему https://github.com/Microsoft/TypeScript/issues/375
S>Прямо по ссылке расписано почему нет S>То же самое касается WebAssembly. GC там пока тоже нет.
As explained in the high-level goals, to achieve a Minimum Viable Product, the initial focus is on C/C++.
However, by integrating with JavaScript at the ES6 Module interface, web developers don't need to write C++ to take advantage of libraries that others have written; reusing a modular C++ library can be as simple as using a module from JavaScript.
Beyond the MVP, another high-level goal is to improve support for languages other than C/C++. This includes allowing WebAssembly code to allocate and access garbage-collected (JavaScript, DOM, Web API) objects 🦄. Even before GC support is added to WebAssembly, it is possible to compile a language's VM to WebAssembly (assuming it's written in portable C/C++) and this has already been demonstrated (1, 2, 3). However, "compile the VM" strategies increase the size of distributed code, lose browser devtools integration, can have cross-language cycle-collection problems and miss optimizations that require integration with the browser.
When WebAssembly gains the ability to access garbage-collected objects 🦄, those objects will be shared with JavaScript, and not live in a walled-off world of their own.
After the MVP, to realize the high-level goals of (1) integrating well with the existing Web platform and (2) supporting languages other than C++, WebAssembly needs to be able to:
reference DOM and other Web API objects directly from WebAssembly code;
call Web APIs (passing primitives or DOM/GC/Web API objects) directly from WebAssembly without calling through JavaScript; and
efficiently allocate and manipulate GC objects directly from WebAssembly code.
The following document is a high-level sketch of one approach for implementing the above goals. Consider the contents incomplete and expect change over time.
An important constraint is that, while WebAssembly should allow tight integration with the Web, it should not bake in details or Web standards dependencies that prevent execution in a non-Web embedding. This suggests a design (called opaque reference types below) that hides the details of JavaScript and WebIDL behind Web-embedding-specific builtin modules. On the other hand, WebAssembly can define a set of native GC primitives that allowed portable GC code to be written regardless of the host environment.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>То же самое касается WebAssembly. GC там пока тоже нет.
S>> Я плох в английском и перевожу с помощью Гугл переводчика S>>https://github.com/WebAssembly/design/blob/master/GC.md
S>Я ж не зря написал про _пока_ нет По ссылке, в первом абзаце, жирным заголовком: S>
Здравствуйте, turbocode, Вы писали:
T>•We now have offline help available by installing the Help Viewer component in the Visual Studio installer.
"Release Candidate" же. Там ещё много чего отваливаться/прикручиваться обратно будет.
P.S. По поводу троллинга вам надо в другие разделы обратиться. У нас тут уже есть ответственный за это дело товарищ, очень ответственный. Вакансия занята, короч.
Re[4]: Updating Visual Studio 2017 Release Candidate
T>>•We now have offline help available by installing the Help Viewer component in the Visual Studio installer. S>"Release Candidate" же. Там ещё много чего отваливаться/прикручиваться обратно будет. S>P.S. По поводу троллинга вам надо в другие разделы обратиться. У нас тут уже есть ответственный за это дело товарищ, очень ответственный. Вакансия занята, короч.
MS сам себя похоже троллит.
Re[3]: Updating Visual Studio 2017 Release Candidate
Вот давно замечал у адептов .NET Core потуги к подмене понятий, чтобы захватить куски пирога, ничего при этом путного не сделав. В статье вообше нет такого сочетания как "Core". Ну прям Геббельсы какие-то.
Напоминаю положение вещей в исчеслении булевой алгебры:
.NET Core != .NET = true
ASP.NET Core != ASP.NET = true
Если представить, что .NET Framework это процессор Zilog Z80, то ближайшая аналогия для .NET Core это Intel 8008. Другими словами, не жилец в рыночых условиях.
Здравствуйте, Aquilaware, Вы писали:
A>Здравствуйте, Serginio1, Вы писали:
S>>«Производительность – это фича». Интервью с Марко Чеккони, Stack Overflow <br />
<span class='lineQuote level2'>S>></span>
A>Это не имеет никакого отношения к .NET Core.
A>Вот давно замечал у адептов .NET Core потуги к подмене понятий, чтобы захватить куски пирога, ничего при этом путного не сделав. В статье вообше нет такого сочетания как "Core". Ну прям Геббельсы какие-то.
Ты хоть смотрел или читал данную ссылку? Там много интересного, в том числе и .Net Core
Там есть и про .Net Core в том числе и про разработку кестрел, и Net Native ( В чем разница между NetFramework и NetCore) и много чего интересного.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Aquilaware, Вы писали:
A>Здравствуйте, Serginio1, Вы писали:
S>>Introducing .NET Standard S>>Удобный REST для Xamarin-приложений
A>Если представить, что .NET Framework это процессор Zilog Z80, то ближайшая аналогия для .NET Core это Intel 8008. Другими словами, не жилец в рыночых условиях.
Это дутые бенчмарки, потому что Кестрел никто в здравом уме не выставит на прямую на 80/443 порт из-за соображений безопасности. Сначала пропустят через Nginx или тот же IIS в прокси режиме. И какую производительность получим в результате? Как минимум такую же как у IIS или Nginx в прокси режиме или хуже.
