Здравствуйте, CreatorCray, Вы писали:
C>>Чем конкретно JS хуже, например, чем C# или Python? CC>Да тем что это Perl для Web — позволяет говнокодить так, что потом проще залить бетоном и поставить знак biohazard
Ну так копролиты можно писать на любом языке, хотя JS делает это очень простым.
С другой стороны, при соблюдении минимальных правил техники безопасности, на JS можно писать вполне нормально.
Здравствуйте, CoderMonkey, Вы писали:
CM>Здравствуйте, Евгений Акиньшин, Вы писали:
ЕА>>Если с Блазором не получиться как с Сильверлайтом, то можно будет ангуляры с реактами забыть, как страшный сон.
CM>Достаточно того, чтобы просто WebAssembly взлетел.
Да вроде все нормально идет:
1) во всех основных браузерах уже есть, даже на мобилках
2) некоторые самые хипстреские веб-приложения (которые нам тут приводят в поимер того, как все в мире переходит на js ) активно используют вебасм и, я думаю, без него вообще не реализуемы
так что вряд ли загнется.
Опять же, гуглу выгодно, чтоб как можно больше приложений переползали в веб, а хром сейчас основной браузер
а вот тулзами пока беда
нормального .net рантайма нет, Мигель сказал что работают над этим, но он будет на основе mono, а не .net core и не понятно, когда они его доделают, и что там будет с производительностью и стабильностью
Здравствуйте, Евгений Акиньшин, Вы писали:
CM>>Достаточно того, чтобы просто WebAssembly взлетел. ЕА>Да вроде все нормально идет:
WebAsm вполне работает везде. У нас на нём на С++ написана достаточно жёсткая оптимизационная задача, например.
Здравствуйте, Cyberax, Вы писали:
CC>>Да тем что это Perl для Web — позволяет говнокодить так, что потом проще залить бетоном и поставить знак biohazard C>Ну так копролиты можно писать на любом языке, хотя JS делает это очень простым.
Ну так за это и не любят что JS что Perl.
C>С другой стороны, при соблюдении минимальных правил техники безопасности, на JS можно писать вполне нормально.
Вот только где взять достаточно народу, который таки способен соблюдать эти правила?
Куда эффективнее заставлять их соблюдать правилами самого языка.
Тот же TypeScript не просто так начали пилить.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Евгений Акиньшин, Вы писали:
CM>>>Достаточно того, чтобы просто WebAssembly взлетел. ЕА>>Да вроде все нормально идет: C>WebAsm вполне работает везде. У нас на нём на С++ написана достаточно жёсткая оптимизационная задача, например.
C>Непонятно нафиг он нужен для простого UI.
Для простого не нужен, так для него и ангуляр не нужен.
Речь же шла о довольно громоздких фреймворках на которых делают веб приложения класса "замена десктопного софта"
Если у тебя бекенд на дот нете и приложение достаточно сложное, то плюсы написания кода клиента и сервера на одном языке очевидны: не надо дублировать логику, не надо переключаться между языками, легче найти разработчиков, более мощный строго-типизированный язык. Все это значительно сокращает время разработки.
C>Ещё проблема Блазора в том, что они пытаются построить притворный параллельный мир с параллельным рантаймом (в Блазоре, например, своя реализация сборщика мусора!!!). Epic fail incoming!
А в webassembly сборщик мусора появился?
В любом случае Блазор очень интересная технология и в мире .Net её активно обсуждают. Это как раз еще один подход с фронэнду.
Ты же Электрон представляешь как серебряную пулю. Чем больше конкурирующих технологий тем лучше.
А пока доля электрона на мобильных устройствах ничтожно мала.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
C>>Ещё проблема Блазора в том, что они пытаются построить притворный параллельный мир с параллельным рантаймом (в Блазоре, например, своя реализация сборщика мусора!!!). Epic fail incoming! S>А в webassembly сборщик мусора появился?
Он есть в JS, что автоматически делает его доступным в языках, которые просто транспилируют в JS. Например: Dart, Type Script, Kotlin.
S> В любом случае Блазор очень интересная технология и в мире .Net её активно обсуждают. Это как раз еще один подход с фронэнду.
Нету там ничего интересного. GWT v2.0 — версия для лузеров.
S> Ты же Электрон представляешь как серебряную пулю. Чем больше конкурирующих технологий тем лучше. S>А пока доля электрона на мобильных устройствах ничтожно мала.
Где мала? Slack, Skype — уже на Electron. Более того, и без Electron'а примерно процентов так 50% приложений на Андроиде — это обёртки над HTML.
Здравствуйте, Евгений Акиньшин, Вы писали:
C>>Непонятно нафиг он нужен для простого UI. ЕА>Для простого не нужен, так для него и ангуляр не нужен.
Сам Блазор ещё побольше Angular'а будет.
ЕА>Если у тебя бекенд на дот нете и приложение достаточно сложное, то плюсы написания кода клиента и сервера на одном языке очевидны: не надо дублировать логику, не надо переключаться между языками, легче найти разработчиков, более мощный строго-типизированный язык. Все это значительно сокращает время разработки.
Это не работает. Окружение серверного .NET и браузерного кардинально отличаются, потому код один фиг придётся адаптировать.
Я же говорю, всё это было в GWT ещё 12 лет назад. Погибло по той же причине — чистый JS банально мощнее и удобнее, тогда как преимущества переиспользования кода получаются исключительно теоретическими.
Здравствуйте, CreatorCray, Вы писали:
CC>>>Да тем что это Perl для Web — позволяет говнокодить так, что потом проще залить бетоном и поставить знак biohazard C>>Ну так копролиты можно писать на любом языке, хотя JS делает это очень простым. CC>Ну так за это и не любят что JS что Perl.
Положим, у Perl 5 и другие минусы есть.
А JS в среднем народ любит, как ни странно.
C>>С другой стороны, при соблюдении минимальных правил техники безопасности, на JS можно писать вполне нормально. CC>Вот только где взять достаточно народу, который таки способен соблюдать эти правила?
Оттуда же, откуда и программистов, соблюдающих правила на Java.
CC>Куда эффективнее заставлять их соблюдать правилами самого языка. CC>Тот же TypeScript не просто так начали пилить.
TypeScript — это нынче скорее подмножество JS. И да, если есть такая возможность — надо сразу на нём писать.
Здравствуйте, CreatorCray, Вы писали:
C>>Чем конкретно JS хуже, например, чем C# или Python? CC>Да тем что это Perl для Web — позволяет говнокодить так, что потом проще залить бетоном и поставить знак biohazard
Говнокод, страшнее, чем на Си и С++, я видел только когда на ассемблере писал. Кое как работающий код, где пятьсот страниц адресной арифметики и разных приседаний с битами это не хухры-мухры. Собственно, говнокод всегда там, где автоматических инструментов не хватает, т.е. когда код выбросить нельзя, а изменить слишком рисковано. В джаваскрипте говнокод относительно легко выбросить и при этом довольно быстро можно найти недорогое решение для частного случая.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Serginio1, Вы писали:
C>>>Ещё проблема Блазора в том, что они пытаются построить притворный параллельный мир с параллельным рантаймом (в Блазоре, например, своя реализация сборщика мусора!!!). Epic fail incoming! S>>А в webassembly сборщик мусора появился? C>Он есть в JS, что автоматически делает его доступным в языках, которые просто транспилируют в JS. Например: Dart, Type Script, Kotlin.
Но в WebAssembly то его нет. S>> В любом случае Блазор очень интересная технология и в мире .Net её активно обсуждают. Это как раз еще один подход с фронэнду. C>Нету там ничего интересного. GWT v2.0 — версия для лузеров.
А вот при чем тут GWT v2.0 и Blazor. В блазоре то Mono. Для шарпа это аналог http://www.cshtml5.com/ https://metanit.com/sharp/articles/csharp/1.php
S>> Ты же Электрон представляешь как серебряную пулю. Чем больше конкурирующих технологий тем лучше. S>>А пока доля электрона на мобильных устройствах ничтожно мала. C>Где мала? Slack, Skype — уже на Electron. Более того, и без Electron'а примерно процентов так 50% приложений на Андроиде — это обёртки над HTML.
То есть 2 приложения? Ты не путай парсеры и рендеры с гибридным приложением. Есть парсеры и рендеры для Xaml. По мне так Xaml более удобный
У гибридного приложения на первом месте браузер у которого есть порт к нативным функциям
у которых нет ограничений в песочнице.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Евгений Акиньшин, Вы писали:
C>>>Непонятно нафиг он нужен для простого UI. ЕА>>Для простого не нужен, так для него и ангуляр не нужен. C>Сам Блазор ещё побольше Angular'а будет.
Да ну и фиг с ним.
Обещают в мегабайт в релизе вписаться, для корпоративного приложения это не о чем
ЕА>>Если у тебя бекенд на дот нете и приложение достаточно сложное, то плюсы написания кода клиента и сервера на одном языке очевидны: не надо дублировать логику, не надо переключаться между языками, легче найти разработчиков, более мощный строго-типизированный язык. Все это значительно сокращает время разработки. C>Это не работает. Окружение серверного .NET и браузерного кардинально отличаются, потому код один фиг придётся адаптировать.
C>Я же говорю, всё это было в GWT ещё 12 лет назад. Погибло по той же причине — чистый JS банально мощнее и удобнее, тогда как преимущества переиспользования кода получаются исключительно теоретическими.
Это неверная аналогия.
Проблема GWT (и подобных решений) была в том, что приходилось транслировать код в абсолютно чуждое окружение. (Конкретно с GWT я никогда не работал, но имел дело с похожим решением для .net.) Там практически любой код может дать непредсказуемый эффект. Элементарный пример — вычисления с типом decimal.
Блазор в этом плане скорее похож на сильверлайт — весь рантайм мы тащим с собой и точно знаем что он работает так же, как на десктопе и сервере. На сильверлайте можно было легко реюзать большую часть бизнес логики.
Здравствуйте, Serginio1, Вы писали:
C>>Он есть в JS, что автоматически делает его доступным в языках, которые просто транспилируют в JS. Например: Dart, Type Script, Kotlin. S> Но в WebAssembly то его нет.
Вот потому и не надо делать фреймворк на WebAssembly.
C>>Нету там ничего интересного. GWT v2.0 — версия для лузеров. S> А вот при чем тут GWT v2.0 и Blazor. В блазоре то Mono. Для шарпа это аналог http://www.cshtml5.com/ S>https://metanit.com/sharp/articles/csharp/1.php
Та же идеология, видом в профиль.
S> У гибридного приложения на первом месте браузер у которого есть порт к нативным функциям S>у которых нет ограничений в песочнице.
Так Electron работает ровно так же. Только он может нативные модули подключать напрямую в JS-движок, и делать их доступными без сетевого вызова.
Здравствуйте, Евгений Акиньшин, Вы писали:
C>>Я же говорю, всё это было в GWT ещё 12 лет назад. Погибло по той же причине — чистый JS банально мощнее и удобнее, тогда как преимущества переиспользования кода получаются исключительно теоретическими. ЕА>Это неверная аналогия.
Верная.
ЕА>Проблема GWT (и подобных решений) была в том, что приходилось транслировать код в абсолютно чуждое окружение. (Конкретно с GWT я никогда не работал, но имел дело с похожим решением для .net.) Там практически любой код может дать непредсказуемый эффект. Элементарный пример — вычисления с типом decimal.
А что, для C# будет по-другому? Сейчас в WebAssembly нет даже многопоточности. Окружение будет однозначно другое, с другим поведением и требованиями.
Пример с decimal — левый. В GWT он прекрасно работал.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Serginio1, Вы писали:
C>>>Он есть в JS, что автоматически делает его доступным в языках, которые просто транспилируют в JS. Например: Dart, Type Script, Kotlin. S>> Но в WebAssembly то его нет. C>Вот потому и не надо делать фреймворк на WebAssembly.
Угу. Хороший ответ. C>>>Нету там ничего интересного. GWT v2.0 — версия для лузеров. S>> А вот при чем тут GWT v2.0 и Blazor. В блазоре то Mono. Для шарпа это аналог http://www.cshtml5.com/ S>>https://metanit.com/sharp/articles/csharp/1.php C>Та же идеология, видом в профиль.
Абсолютно другая. Одно дело делать Html страницу, другое встраивать приложение в браузер.
S>> У гибридного приложения на первом месте браузер у которого есть порт к нативным функциям S>>у которых нет ограничений в песочнице. C>Так Electron работает ровно так же. Только он может нативные модули подключать напрямую в JS-движок, и делать их доступными без сетевого вызова.
Сам по себе современный JavaScript использует JIT-компиляцию, хорошо оптимизирован и работает быстро, но построение интерфейса на основе DOM-дерева — не очень эффективный процесс. Использование современных JS-фреймворков даёт дополнительный уровень нагрузки. Для слабых телефонов и/или при активном использовании интерактивных элементов, это может быть проблемой.
“Ненативное ощущение”
Это довольно неформальный, но очень важный пункт. Сайт в браузере реагирует на жесты и отображается немного не так, как мобильное приложение. Наиболее заметный элемент этого ощущения, задержку 300ms при нажатиях, Cordova решает, но многие другие детали остаются.
Проблема браузерной совместимости
На старых версиях Android (до версии 5), WebView был частью платформы и не обновлялся автоматически. Соответственно, использовать современные возможности браузеров в гибридных приложениях на этих устройствах не получится.
Как следствие, гибридные приложения либо ограничивают минимальную версию Android (оставляя за бортом около 13% устройств на данный момент), либо включают WebView в код приложения (проект CrossWalk), увеличивая размер приложения на несколько десятков мегабайт.
Предназначение
Быстрое создание одноразовых приложений. При наличии существенного бюджета на разработку, гибридным подходом, как правило, брезгуют.
Все таки пока реальный подход это общий код, а UI отдельный для каждой платформы.
А здесь у Xamarin а есть преимущество в том числе и Mono в WebAssembly
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Cyberax, Вы писали:
C>А JS в среднем народ любит, как ни странно.
Молодые ишшо. Не накопались пока ещё в старом чужом коде.
C>Оттуда же, откуда и программистов, соблюдающих правила на Java.
Java куда более строгий язык
) активно используют вебасм и, я думаю, без него вообще не реализуемы
Ты не путай парсеры и рендеры с гибридным приложением. Есть парсеры и рендеры для Xaml. По мне так Xaml более удобный
