Максим Кич писал(а):Ну вот я и говорю, это называется «Мы возьмём JS и будем на нём пытаться писать как на %some_other_language%». То же ООП может быть на классах, может быть на прототипах — и это два разных ООП. Классы в js (даже нативные из ECMA6) — это синтаксический сахар чистой воды, они уродливы потому что они там, где их быть не должно.
Увы, но если это самое ООП все с прототипов переделывают на классы - это о чём-то да говорит. Я далёк от не умеющих ошибаться миллионов, я считаю, как уже говорил выше, что языки всё же тоже продукт, у которого есть пользователи. И если пользователи в большинстве своём пытаются писать на JS как на %some_other_language%, это означает что где-то js свернул не туда, ведь для этих самых пользователей он и делался.
Максим Кич писал(а):Я не в курсе за питон. Может там нет стандартного удобного и наполненного репозитория пакетов/пакетного менеджера? В Rust, скажем, есть crate и зависимости тянут за милую душу, хотя сам язык по своему очень продуманный. А для браузерного JS так чисто исторически неоткуда было взяться изобилию библиотек, потому что до совсем недавшего времени перед языком принципиально другие задачи стояли.
Есть. Раньше с этим похуже было, но даже лет семь-десять назад Python Package Index существовал. Но никаких left-pad и lodash там нет - потому что в сам язык встроены str.rjust, map, filter, for и т. д. Не знаю что там ещё есть в лодаше, но практически уверен что любой пример с ней перелагается на питон без использования сторонних библиотек. Хотя ладно, питон конечно силён именно своей концепцией "батарейки в комплекте", у него есть свои модули, которые по большей части включены в стандартную поставку. Но, если честно, лично я теми же functools/itertools пользовался от силы пару раз, бьюлтинов хватало на всё. Вопрос в том, почему js не имеет встроенных штуковин для такого простого, базового поведения как, например, форматирование строк?
Максим Кич писал(а):C# как сферический язык в вакууме мне очень нравится. Но потом начинается Asp.Net и вся элегантность языка теряется за монструозностью навороченных поверх конструкций.
Хехе. Буквально недавно один знакомый мне директор серьёзной фирмы, занимающейся вебом на дотнете, написал что они перешли именно на ту схему апи + тяжёлый клиент, потому что она лучше.
https://habrahabr.ru/post/275333/ вот она. Именно про это я и говорил, как ты ни пытайся, а js (пока) обойти особо не получится. Сильно надеюсь что в будущем это изменится.
Максим Кич писал(а):JS проектировался, чтобы работать со структурой, которая может измениться по независящим от данного конкретного скрипта причинам.
Тут у меня сразу два возражения. Первое - увы, но как пользователя языка меня не особо волнует
почему оно сделано плохо, какие там давние причины изуродовали младенца. Не знаю как там было в девяносто пятом (между прочим, js - мой ровесник), но уже давненько содержимое страницы зависит только от разработчика. Второе - такие проблемы есть у любого многопоточного приложения, но почему-то там не жертвуют явностью ошибок в пользу... В пользу чего? Не вижу никаких преимуществ. Особенно учитывая что js строго однопоточен, так что можно и обычную проверку провести, не боясь что между ифом и использованием проверяемого значения кто-то внезапно внедрится.
А теперь такая явная проверка - единственное что остаётся, пиши свой бойлерплейт и и думать забудь что язык может тебе помогать хоть чуточку.
Максим Кич писал(а):Случается. Но не так часто, как может показаться. Возможно, это просто сила привычки. this в js ведёт себя не так как в другом языке? Ну так и js — это не другой язык.
И поэтому пиши бойлерплейт с var self = this или байндами, ага. Ты действительно думаешь что это признак хорошо спроектированного языка? Я ведь лишь утверждаю что js спроектирован слишком плохо для свалившейся на него популярности, ты с этим согласен?
Максим Кич писал(а):А в какой области видимости и на каких типах данных JS должен уметь переопределять операторы?
А мне не слишком это важно. Пусть вызов a + b транслируется в a.__add__(b), или как угодно - хоть какой-нибудь путь для сокращения бойлерплейта! Чем меньше кода - тем лучше, чем легче его прочитать - тем лучше. JS почему-то предпочитает избегает соблюдения этого правила, и я искренне не понимаю, почему.
Максим Кич писал(а):Очень дискуссионный. Кроме API и DB есть ещё third party API, приём и отправка e-mail-ов и сообщений для ботов, cron-job-ы всяческие, генерация контента типа pdf-ин — и это не считая того, что «относительно несложное преобразование» может слегка растянуться.
Ну да, согласен. На сервере останется ещё куча работы, но вот та часть что связана с UI полностью уедет на клиента - смотри статью выше.
Максим Кич писал(а):Третья война Браузеров? Спасибо, я слишком стар для этого ))) Я лучше перебьюсь меньшим количеством свистоперделок, но они будут гарантированно работать.
А я вот, пожалуй, жду её с нетерпением. Хотя и думаю что она будет выглядеть скорее как "один запилил, все остальные быстренько стырили, энтузиасты выпустили полифил чтобы всё выглядело как наиболее удобный вариант". Если война - цена удобства для юзера, то я, как юзер, только за.
Cfyz писал(а):Иронично, что год назад браузеры были к этому ближе, чем сейчас -- я имею в виду что еще недавно в браузерах поддерживались native-бинарные плагины, посредством которых можно было хоть заинтегрироваться в ОС. Но все выпилили. Давать браузеру пускать корни в ОС это опасно: кто-то запихнет в трей плеер, а кто-то -- шифровальщик-вымогатель. Браузеру наоборот нельзя давать быть на равных с десктопными приложениями, потому что иначе это фактически эксплоит выполнения произвольного кода прямиком из сети. Electron.js и основанные на нем приложения -- это совсем другое дело, потому что это товар штучный, пользователь начинает с ним работу осознанно и на индивидуальной основе.
Извечная гонка. Появились автомобили, появились и ДТП, появились ПДД. Так и тут будет - попапы забороли, вредоносные экстеншены борют, тут тоже заборют, никуда не денутся. Тем более что я говорю не про встраивание нативного кода, а скорее про апи вида create_tray_icon(icon_image, context_menu_text_to_func_dict, on_click_func, on_double_click_func, widget_dom) - ну, ты понял. И работу с ним сделать по аналогии с нотификациями, с явным запросом разрешения юзера.
Всё вышесказанное - ИМХО, если не указано обратное.