JUG Ru Group corporate blog
JavaScript
Comments 24
+3

Мне этот доклад чем-то напомнил «merge request на 5000 строк — looks good to me» — вроде всё по делу, но за основной идеей следить непросто, слишком много посторонних мелких деталей (хотя возможно это потому, что я очень давно на JS ничего не писал).

+4
Это немного забавно, что когда-то «давно» (2011-12-13 годы) новообращенные разработчики часто любили «противопоставлять» «новые» «быстрые» языки и технологии разработки «старому» «медленному» «кровавому» энтерпрайзу.
Прошло время и народ с восторгом открывал для себя «паттерны»,«автоматическое тестирование» разного масштаба, «шины/очереди», «DI/IOC», SOA (хотя сейчас примерно тоже самое называется msa), SOLID, новые названия старых паттернов и т.д.

Те кто «отрицали», «отвергали» и «противопоставляли», теперь (часто дав новые названия) «пропагандируют» и несут в массы те же идеи.
+3
Понимаю, что доклад был сделан давно, но всё же внесу коррективу. Проблема со scoped slots во Vue уже решена в версии 2.6
0
А почему просто не взять надежный хорошо проработанный язык, транслирующийся в js? Благо таких полно.
+1
Надёжный хорошо проработанный язык? А такие есть? Чтобы на них ещё люди писали? А людей надо много!

«Есть два типа языков: одни, которые все ругают, и другие, на которых никто не пишет.»
0
Такие есть. Смотря какие люди. Интеллектуальное большенство до них действительно не доберается.
0
Чтобы хорошо писать на одном языке, нужно знать этот язык. Чтобы хорошо писать на языке, который транслируется в другой, придется разбираться с обоими. Так что выгоды будет немного.
0
Мало кто из хорошо пишущих на C++, Rust или Haskell разбираются в тонкостях ассемблера.
Даже байткод jvm и .net специалисты в Java, Scala, C# и F# не всегда знают.
0
Тем не менее, программистам нужно знать отличия платформ, под которые они компилируют. Под Windows и Linux есть свои нюансы компиляции. То же самое и здесь – в любом случае придется разбираться с DOM API, которое определяется в Javascript.
0
Очень редко. Обычно все тонкости спрятаны в библиотеках.
Elm прекрасно прячет DOM в TEA (The Elm Architecture). В других, которые я смотрел, кишки DOM торчат, но без особой привязки к js. DOM — это всего лишь API для работы с HTML/XML.
0
А что насчёт байгдингов к другим библиотекам? Не использовать JS вообще и портировать все на Elm может быть очень затратно
0
В Elm уже есть много готовых библиотек, при этом пакетный менджер проверяет их совместимость по semantic versioning. Вызывать js из него действительно не очень удобно. В PureScript взаимодейстсие с js, судя по отзывам, гороздо проще.
По поводу затратности, надо сравнивать затратами на обеспечение сравнимой надежности.
+8
Так и не понял причем тут JavaScript. Автор топит за надежность в контексте JS но примеры приводит вообще никак не связанные с. Ну серьезно, на формы забыли повесить валидацию — виноват, конечно, JS. А типы данных кто будет описывать? А на уровне API где ваша валидация? Ну да, у нас же тут аутсорсинг, нам некогда, мы конкурируем с индусами… Детский сад.
0
типы данных кто будет описывать
Строка конвертируется в число, как и было задумано. Здесь не ошибка типизации.

примеры приводит вообще никак не связанные
Да, примеры скорее про уровень аутсорса, зато хорошо читаются как сборник анекдотов.
-1
Строка конвертируется в число, как и было задумано. Здесь не ошибка типизации.

Я не о примитивах. Например, для геолокации есть стандартные Position и Coordinates. А в кастомных типах валидация может быть реализована через аксессоры свойств. В любом случае, это не особенно важно, если некорректных значений можно с легкостью накидать в API через тот-же Postman или curl. И даже если так, выбросить некорректные значения на этапе анализа полученных данных — вроде совсем не «рокет сайнс». Так что все верно — сборник анекдотов.
0
Я обычно эту строку или результирующее число проверяю на валидность. С докладом да, непонятно, причём тут js.
0

Я так понял посыл вводной в том, что смотрите, на какие суммы в баксах может выстрелить если писать не надёжный код. А дальше о том, что в Js про надёжность есть и насколько не с ней не радужно.

0
Дальше они поняли, что планировщик — это очень сложно, поэтому они создали proposal, чтобы внедрить это прямо в JavaScript. Scheduler — это proposal stage 0.
Звучит любопытно, но я ничего подобного среди proposal'ов не нашёл. У кого-нибудь есть ссылка на то, о чём говорит автор?
0
Любопытная история. Хотя он и не совсем proposal, и не совсем от разработчиков React. :)
Спасибо.
Only those users with full accounts are able to leave comments. , please.