Comments 24
Мне этот доклад чем-то напомнил «merge request на 5000 строк — looks good to me» — вроде всё по делу, но за основной идеей следить непросто, слишком много посторонних мелких деталей (хотя возможно это потому, что я очень давно на JS ничего не писал).
Это немного забавно, что когда-то «давно» (2011-12-13 годы) новообращенные разработчики часто любили «противопоставлять» «новые» «быстрые» языки и технологии разработки «старому» «медленному» «кровавому» энтерпрайзу.
Прошло время и народ с восторгом открывал для себя «паттерны»,«автоматическое тестирование» разного масштаба, «шины/очереди», «DI/IOC», SOA (хотя сейчас примерно тоже самое называется msa), SOLID, новые названия старых паттернов и т.д.
Те кто «отрицали», «отвергали» и «противопоставляли», теперь (часто дав новые названия) «пропагандируют» и несут в массы те же идеи.
Прошло время и народ с восторгом открывал для себя «паттерны»,«автоматическое тестирование» разного масштаба, «шины/очереди», «DI/IOC», SOA (хотя сейчас примерно тоже самое называется msa), SOLID, новые названия старых паттернов и т.д.
Те кто «отрицали», «отвергали» и «противопоставляли», теперь (часто дав новые названия) «пропагандируют» и несут в массы те же идеи.
Понимаю, что доклад был сделан давно, но всё же внесу коррективу. Проблема со scoped slots во Vue уже решена в версии 2.6
А почему просто не взять надежный хорошо проработанный язык, транслирующийся в js? Благо таких полно.
UFO just landed and posted this here
Чтобы хорошо писать на одном языке, нужно знать этот язык. Чтобы хорошо писать на языке, который транслируется в другой, придется разбираться с обоими. Так что выгоды будет немного.
Мало кто из хорошо пишущих на C++, Rust или Haskell разбираются в тонкостях ассемблера.
Даже байткод jvm и .net специалисты в Java, Scala, C# и F# не всегда знают.
Даже байткод jvm и .net специалисты в Java, Scala, C# и F# не всегда знают.
Тем не менее, программистам нужно знать отличия платформ, под которые они компилируют. Под Windows и Linux есть свои нюансы компиляции. То же самое и здесь – в любом случае придется разбираться с DOM API, которое определяется в Javascript.
Очень редко. Обычно все тонкости спрятаны в библиотеках.
Elm прекрасно прячет DOM в TEA (The Elm Architecture). В других, которые я смотрел, кишки DOM торчат, но без особой привязки к js. DOM — это всего лишь API для работы с HTML/XML.
Elm прекрасно прячет DOM в TEA (The Elm Architecture). В других, которые я смотрел, кишки DOM торчат, но без особой привязки к js. DOM — это всего лишь API для работы с HTML/XML.
А что насчёт байгдингов к другим библиотекам? Не использовать JS вообще и портировать все на Elm может быть очень затратно
В Elm уже есть много готовых библиотек, при этом пакетный менджер проверяет их совместимость по semantic versioning. Вызывать js из него действительно не очень удобно. В PureScript взаимодейстсие с js, судя по отзывам, гороздо проще.
По поводу затратности, надо сравнивать затратами на обеспечение сравнимой надежности.
По поводу затратности, надо сравнивать затратами на обеспечение сравнимой надежности.
Так и не понял причем тут JavaScript. Автор топит за надежность в контексте JS но примеры приводит вообще никак не связанные с. Ну серьезно, на формы забыли повесить валидацию — виноват, конечно, JS. А типы данных кто будет описывать? А на уровне API где ваша валидация? Ну да, у нас же тут аутсорсинг, нам некогда, мы конкурируем с индусами… Детский сад.
типы данных кто будет описыватьСтрока конвертируется в число, как и было задумано. Здесь не ошибка типизации.
примеры приводит вообще никак не связанныеДа, примеры скорее про уровень аутсорса, зато хорошо читаются как сборник анекдотов.
Строка конвертируется в число, как и было задумано. Здесь не ошибка типизации.
Я не о примитивах. Например, для геолокации есть стандартные Position и Coordinates. А в кастомных типах валидация может быть реализована через аксессоры свойств. В любом случае, это не особенно важно, если некорректных значений можно с легкостью накидать в API через тот-же Postman или curl. И даже если так, выбросить некорректные значения на этапе анализа полученных данных — вроде совсем не «рокет сайнс». Так что все верно — сборник анекдотов.
Я обычно эту строку или результирующее число проверяю на валидность. С докладом да, непонятно, причём тут js.
Дальше они поняли, что планировщик — это очень сложно, поэтому они создали proposal, чтобы внедрить это прямо в JavaScript. Scheduler — это proposal stage 0.Звучит любопытно, но я ничего подобного среди proposal'ов не нашёл. У кого-нибудь есть ссылка на то, о чём говорит автор?
Main-thread Scheduling API
github.com/WICG/main-thread-scheduling
github.com/WICG/main-thread-scheduling
в общем хорошо
Sign up to leave a comment.
Надёжный JavaScript: в погоне за мифом