Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Serginio1, Вы писали:
F> Всем бы твой задор а потом ещё и в мирное русло. Цены бы вам не было б. Я серьезно. Я не думаю что у нас огромная разница в возрасте или что-то такое, более того — я последние годы — везде тыкаю дотнет в грязь, если могу это по делу. Но. Ты окрылён чем-то, — а я нет. Sinix — тоже нет. Вашему TS2 всё ещё нужен сторонний транспилер что-бы это работало в реальных браузерах. Потом выясниться что всё тот же TS2 делает что-то не так. Потом когда до кого-то дойдет что он способен язык ради фана — он сделает XS1 который будет компилироваться сразу в вебассембли что несмотря на мегабайты TS — видимо не дано. Я это к чему — я лучше буду из C++ эти самые web assembly генерить, новаторы эти малёха поднадоели. При том, противно, что самый говёный продукт подхватывается на ура. Angular1 + TS — отличные примеры. За ангуляром1 кроме персистентных утечек в "родном" хроме но не фф и ие — ничего не стояло. Ах, забыл. Гугл стоял. А за — TS "экс" сотрудник, да такое экс, что вдруг получил первоклассную поддержку языка в студии из коробки. Тьфу. F> Более того — NIMH/NIH — это то чем должен пользоваться разработчик, но TS выстрелил так быстро, что в независимость я не верю. F> С дотнетом и неткорой лучше. Много лучше.
Предложи это мирное русло. Мне 53 годика. Кстати ищу работу.
Что касается web assembly то это аналог asm.js. Ты
выиграешь только в скорости выполнения на примитивных типов. JS объекты web assembly, компоненты ты на нем писать не сможешь.
Ну это аналог asm.js. То есть код на C++ компилируется в Wasm который дергается из JS
WebAssembly призвана дополнить и работать вместе с JavaScript — с помощью API-интерфейсов WebAssembly JavaScript, вы можете загрузить модули WebAssembly в приложение JavaScript и обмениваться функциональность между ними. Это позволяет воспользоваться преимуществами производительности и мощности WebAssembly и выразительность и гибкость в JavaScript в тех же программах, даже если вы не знаете, как писать код WebAssembly.
Сборка из C / C ++ для WebAssembly (ТБД) Когда вы написали модуль кода на языке , как C / C ++, вы можете скомпилировать его в .wasm с помощью инструмента Emscripten . Давайте посмотрим, как это работает.
Что касается TS то он лучше JS компилируется при изменении итд. Все можешь настроить в tsConfig, WebPack. И в Edge и Хроме ты отлаживаешь именно TS, а не JS.
Что касается Angular 2, то вполне себе нормальеый фремворк поле Jqury UI и прочих. Мне как 1с/C# программисту далекому от Web программирования очень понятны.
Был вчера под впечатлением, так что в целом — забей.
S> Предложи это мирное русло. Мне 53 годика.
Тут осечка вышла. Но... тогда вдвойне уважуха. Когда я ходил в офисы на работу — люди твоего возраста с трудом числа складывали.
S> Кстати ищу работу.
Тут ничем не могу помочь, увы.
S> Что касается web assembly то это аналог asm.js. Ты S> выиграешь только в скорости выполнения на примитивных типов. JS объекты web assembly, компоненты ты на нем писать не сможешь. S>http://rsdn.org/forum/flame.comp/6693034.1
люди пишут что из webasm не будет доступа к DOM.
S>
S>WebAssembly призвана дополнить и работать вместе с JavaScript — с помощью API-интерфейсов WebAssembly JavaScript, вы можете загрузить модули WebAssembly в приложение JavaScript и обмениваться функциональность между ними. Это позволяет воспользоваться преимуществами производительности и мощности WebAssembly и выразительность и гибкость в JavaScript в тех же программах, даже если вы не знаете, как писать код WebAssembly.
Это же, но простыми словами — мы добавили webasm, но JavaScript мы убирать не будем, т.к. потерять совместимость — это значит выкинуть браузер на мусорку. С помощью webasm вы сможете делать тоже самое что и на JS (обмениваться функциональностью между модулями).
S>
S>Сборка из C / C ++ для WebAssembly (ТБД) Когда вы написали модуль кода на языке , как C / C ++, вы можете скомпилировать его в .wasm с помощью инструмента Emscripten . Давайте посмотрим, как это работает.
S>https://developer.mozilla.org/en-US/docs/WebAssembly S> От JS ты не избавишься.
Тогда мы возвращаемся опять к началу — нафига оно тогда? Ну т.е. почему нельзя было сделать так, что бы от JS можно было избавиться?
S> Что касается TS то он лучше JS компилируется при изменении итд. Все можешь настроить в tsConfig, WebPack. И в Edge и Хроме ты отлаживаешь именно TS, а не JS.
То, что TS лучше JS — я и не спорю. Но по факту — от остальных его выгодно отличает только разкрученность. Опять таки — да, это хорошо, что появился инструмент который быстро развивается и имеет первоклассную поддержку. Но и ты пойми — google-closure-compiler умел при своей source-to-source компиляции: a) inlining b) dead code elimination. Поэтому какой-нибудь google-closure или даже маргинальный haxe на порядок мощнее как инструменты, позволяющий использовать несколько мегабайтные библиотеки и не затаскивать весь код библиотек в браузер (что всё ещё критично для скорости загрузки).
Насчет отладки я не понял. sourcemaps работают для любых языков, с TS это никак не связано. Это же свойство дебаггера, а не языка.
S> Что касается Angular 2, то вполне себе нормальеый фремворк поле Jqury UI и прочих. Мне как 1с/C# программисту далекому от Web программирования очень понятны. S> Что касается размеров, то пример в https://yadi.sk/d/0If7C5jZ3CEhmf жмутся webpack менее 5 mb S> Кстати Angular 1 и 2 это несколько разные вещи
Разные. Полность. Тем не менее — репутацию они у заработали именно на angular 1. Моя инертность мышления отвергает их изделие просто потому что angular 1 в моё время добавил исключительно только проблемы. Кстати, приблизительно о такой инертности говорит и Sinix со своим великим и ужасным энтерпрайзом.
В любом случае — дружба мир жвачка.
Я в любом случае рад, что инструменты развиваются. Как только мне попадёт в руки веб-проект — обязательно рассмотрю возможность связки TS2+A2. До того я активно использовал TS1 в некоторых местах — но не без проблемно. Куча подводных камней с той же студией и т.п.
Здравствуйте, fddima, Вы писали:
F> Опять таки — да, это хорошо, что появился инструмент который быстро развивается и имеет первоклассную поддержку. Но и ты пойми — google-closure-compiler умел при своей source-to-source компиляции: a) inlining b) dead code elimination. Поэтому какой-нибудь google-closure или даже маргинальный haxe на порядок мощнее как инструменты
И поэтому же они пока пролетают со свистом — технологии слишком пока завязаны на JS и слишком далекий от него уход приводит к сложностям.
TS практичен в том числе и тем, что очень недалеко отходит от JS, сохраняя с ним почти полную обратную совместимость и весьма прозрачную транслируемость.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Здравствуйте, AndrewVK, Вы писали:
AVK>И поэтому же они пока пролетают со свистом — технологии слишком пока завязаны на JS и слишком далекий от него уход приводит к сложностям. AVK>TS практичен в том числе и тем, что очень недалеко отходит от JS, сохраняя с ним почти полную обратную совместимость и весьма прозрачную транслируемость.
Так не так уж и слишком завязы. Если для одних это была цель, то для TS — цель наоборот этого не делать. Т.е. есть хороший язык, первоклассная поддержка — но абсолютно нет кодогенерации. Увы, мне этого не понять.
Здравствуйте, fddima, Вы писали:
F> Так не так уж и слишком завязы. Если для одних это была цель, то для TS — цель наоборот этого не делать. Т.е. есть хороший язык, первоклассная поддержка — но абсолютно нет кодогенерации. Увы, мне этого не понять.
Тем не менее практика показала, что TS однозначно самый популярный JS транспилер в истории. Еще хоть сколько нибудь заметная популярность была у CoffeeScript, который, что характерно "The golden rule of CoffeeScript is: “It’s just JavaScript”.". А вот перечисленные тобой языки остались на маргинальной обочине.
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
F> Так не так уж и слишком завязы. Если для одних это была цель, то для TS — цель наоборот этого не делать. Т.е. есть хороший язык, первоклассная поддержка — но абсолютно нет кодогенерации. Увы, мне этого не понять.
Кодогенерация это про шаблоны?
На самом деле у них есть кодогенерация для async await
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, AndrewVK, Вы писали:
F>> Так не так уж и слишком завязы. Если для одних это была цель, то для TS — цель наоборот этого не делать. Т.е. есть хороший язык, первоклассная поддержка — но абсолютно нет кодогенерации. Увы, мне этого не понять. AVK>Тем не менее практика показала, что TS однозначно самый популярный JS транспилер в истории. Еще хоть сколько нибудь заметная популярность была у CoffeeScript, который, что характерно "The golden rule of CoffeeScript is: “It’s just JavaScript”.". А вот перечисленные тобой языки остались на маргинальной обочине.
Да, но closure-compiler и closure-libary — основа для широко используемых приложений от гугла. В своё время — первопроходцев из области "самых используемых браузерных приложений в истории". Проблема в том, что closure-compiler — не имеет своего внятного языка, а использует размеченный JS комментариями и доступ к свойствам объектам странный (a.b и a["b"] — для него разные вещи). Разумеется такой подход не мог и не может хорошо работать — порождает кучу ошибок на ровном месте.
haxe — я привёл только как пример подобного компилятора, но в котором уже есть и типы и модульность и компиляция в JS с оптимизациями (самая важная — выкидывать ненужный библиотечный код). Учитывая, что над ним работают три "коллеги" и не используется он широко — понятно, что шероховатостей там масса.
Здравствуйте, Serginio1, Вы писали:
F>> Так не так уж и слишком завязы. Если для одних это была цель, то для TS — цель наоборот этого не делать. Т.е. есть хороший язык, первоклассная поддержка — но абсолютно нет кодогенерации. Увы, мне этого не понять. S> Кодогенерация это про шаблоны? S> На самом деле у них есть кодогенерация для async await
Я знаю про async/await. Это опять таки хорошо, — но это синтаксический сахар вокруг высокоуровневых вещей.
Но, нет, я же писал выше, что кодогенерация — это инлайнинг и dead code elimination (да и куча других довольно мелких вещей). Сейчас типичный деплоймент это использование готовых библиотек — они в свою очередь бывают весьма пузатые (даже минифицированные). Если к примеру взять туже closure-libary — то исходники всех компонент — 24Мб. Очевдно, что всё и сразу не нужно.
Тоже самое касается и остальных библиотек — половина jquery в полном объеме сразу тоже мало кем используется. Add: Они он даже выпустили 2 версии, полную и slim. Совершенный ручник.
Здравствуйте, AndrewVK, Вы писали:
F>> Да, но closure-compiler и closure-libary — основа для широко используемых приложений от гугла. AVK>Ключевое слово тут гугл, а не closure.
Ключевое — это практическое существование не малых продуктов созданных на конкретном тулчейне, которые демонстрируют сильные стороны подхода. Но, пожалуй хватит спорить ни о чём.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Serginio1, Вы писали:
F>>> Так не так уж и слишком завязы. Если для одних это была цель, то для TS — цель наоборот этого не делать. Т.е. есть хороший язык, первоклассная поддержка — но абсолютно нет кодогенерации. Увы, мне этого не понять. S>> Кодогенерация это про шаблоны? S>> На самом деле у них есть кодогенерация для async await F> Я знаю про async/await. Это опять таки хорошо, — но это синтаксический сахар вокруг высокоуровневых вещей. F> Но, нет, я же писал выше, что кодогенерация — это инлайнинг и dead code elimination (да и куча других довольно мелких вещей). Сейчас типичный деплоймент это использование готовых библиотек — они в свою очередь бывают весьма пузатые (даже минифицированные). Если к примеру взять туже closure-libary — то исходники всех компонент — 24Мб. Очевдно, что всё и сразу не нужно. F> Тоже самое касается и остальных библиотек — половина jquery в полном объеме сразу тоже мало кем используется.
Он и пакует и HTML и CSS и JavaScript в 3 файла. В моем проекте есть и JQuery и Angular 2 плюс Proxy Promise. и Все это упаковывается в менее 5 МБ.
И при этом с файлами можно работать локально без сервера.
Возможно как и в .Net можно делать оптимизации на уровне компиляции TS в JS. Но думаю, что развитие WebPack более универсально.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Понятно, но для этого и существует webPack CEF, ES6, Angular 2, WebPack 2 .Net Core десктопное приложение без серверной части
Минификация != dead code elimination, последний должен выкидывать ненужные классы, ненужные методы уменьшая общий объем кода, что для чистого JS — невозможно и часто сопряжено со знанием об устройстве модулей. Элементарнейший случай — не включать не нужные модули. Наподобии как в C# — наличие референса на сборку во время компиляции не означает что результирующая сборка будет её референсить, в случае если она не используется. В традиционной нативной линковке (тоже простой случай) — неиспользуемые объектные модули не включаются в результирующий исполнимый модуль, поэтому линкуя статическую стандартную библиотеку => мы платим более-менее только за то, что используем.
Здравствуйте, fddima, Вы писали:
F>Здравствуйте, Serginio1, Вы писали:
S>> Понятно, но для этого и существует webPack CEF, ES6, Angular 2, WebPack 2 .Net Core десктопное приложение без серверной части F> Минификация != dead code elimination, последний должен выкидывать ненужные классы, ненужные методы уменьшая общий объем кода, что для чистого JS — невозможно и часто сопряжено со знанием об устройстве модулей. Элементарнейший случай — не включать не нужные модули. Наподобии как в C# — наличие референса на сборку во время компиляции не означает что результирующая сборка будет её референсить, в случае если она не используется. В традиционной нативной линковке (тоже простой случай) — неиспользуемые объектные модули не включаются в результирующий исполнимый модуль, поэтому линкуя статическую стандартную библиотеку => мы платим более-менее только за то, что используем.
Net Core так и поступает. Правда там модульность плюс ограничен Reflection/ А так согласен из-за отсутствия типизации, сложно отследить какие классы нужно выбрасывать.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S>>Как сборки .net core могут быть "оптимизированы" под .native, если это два разных форка .net framework? S>То есть CoreClr и .Net Native выполняют один и тот же CIL код.
Ну да. _рантайм_ CoreClr используется для отладки, а библиотеки BCL UWP были синхронизированы с CoreClr. Но как из этого следует, что "сборки под .Net Core оптимизированы для .Net Native" — я
S> Мне интересно если разница между нативным кодом S>1. JIT .Net CLR S>2. JIT CoreCLR S>3. Net Native
На сегодня — есть. Первые два используют разные версии RyuJit, в .net core более свежая. Бинарный код .net native порождает бэкэнд от ms с++.
S>>Всё остальное — это уже следствия. S> И чем же оно противоречит приведенное мною?
Я уже пару раз писал, если с вашей точки зрения разницы нет — значит нет
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>>>Как сборки .net core могут быть "оптимизированы" под .native, если это два разных форка .net framework? S>>То есть CoreClr и .Net Native выполняют один и тот же CIL код. S>Ну да. _рантайм_ CoreClr используется для отладки, а библиотеки BCL UWP были синхронизированы с CoreClr. Но как из этого следует, что "сборки под .Net Core оптимизированы для .Net Native" — я
Возможно я не прав , но я имел ввиду разбиение на модули
Традиционная реализация .NET Framework не предусматривает разбиения на модули, поэтому компоновщик (linker) не может включить в приложение лишь ту часть инфраструктуры, которая нужна приложению. Но .NET Core, по сути, является ответвлением .NET Framework, реализация которой оптимизирована с учетом модульности . Другое преимущество этой реализации — возможность поставлять .NET Core Framework как набор NuGet-пакетов, что позволяет вам обновлять индивидуальные классы вне самой .NET Framework. Однако, прежде чем двигаться дальше, давайте обсудим изменения в NuGet.
Кстати ILSpy не читает сборки Core. Не подскажешь, каким рефлектором можно пользоваться?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Serginio1, Вы писали:
S>> Кстати ILSpy не читает сборки Core. Не подскажешь, каким рефлектором можно пользоваться?
Q>dotPeek?
Спасибо. Только я не понял. Смотрю классы, методы. А они с комментариями. Понял, что показываются реальные модули или это декомпилированный код?
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
S> Спасибо. Только я не понял. Смотрю классы, методы. А они с комментариями. Понял, что показываются реальные модули или это декомпилированный код?
Там можно включить показ именно декомпилированного кода; как C#, так и IL.
Я это к чему — я лучше буду из C++ эти самые web assembly генерить, новаторы эти малёха поднадоели. При том, противно, что самый говёный продукт подхватывается на ура. Angular1 + TS — отличные примеры. За ангуляром1 кроме персистентных утечек в "родном" хроме но не фф и ие — ничего не стояло. Ах, забыл. Гугл стоял. А за — TS "экс" сотрудник, да такое экс, что вдруг получил первоклассную поддержку языка в студии из коробки. Тьфу.
Но... тогда вдвойне уважуха. Когда я ходил в офисы на работу — люди твоего возраста с трудом числа складывали.
