Если бы штуковина mongoose изначально проектировалась и писалась на trypescript, то я думаю что удалось бы типизировать. Бывает проще переписать всю библиотеку на trypescript, чем написать полноценные и небажные декларации и «чудо-js-коду».
Есть подозрение что товарищь Eric Elliott никогда не писал что-то сложнее «одноразового кода, стиля — один раз запустил и на помойку».
Типизация может быть слишком строгой, слишком свободной, или попросту неправильной.
Неправильной типизация может быть когда сам код написан на JavaScript, а декларация подключется отдельно. Очень частый случай когда при таком подходе вылазят грабли. Поэтому всегда лучше искать решения изначально написанные на TypeScript, желательно с включенной strict опцией компиляции.
Следующая цитата из его опуса как раз является преимуществом, а не недостатком. То есть один раз описал модель данных и все, больше не нужно постоянно при обращении к коду думать что там за данные такие могут быть и аргументы какого типа, не нужно все держать в голове, можно ведь просто выразить все в однозначном виде в коде. Недостатком это может быть только в случае ондоразовых проектов которыми полагаю Eric Elliott увлекается, но тогда и TypeScript не нужно брать вообще. Для программистов описание типов это не нагрузка, а наоборот облегчение в перспективе. Нагрузкой это может быть для мартышек.
Дополнительная нагрузка на программистов, связанная с типизацией (Typing Overhead)
В этот показатель я включаю ту дополнительную нагрузку на программистов, которую создаёт необходимость типизации сущностей, а также необходимость тестирования, отладки и поддержки аннотаций типов. Отладка типов — это та статья расходов на использование TypeScript, на которую нередко не обращают внимания. Аннотации типов подвержены собственным ошибкам. Типизация может быть слишком строгой, слишком свободной, или попросту неправильной.
говорят что уровень мозга перестал расти сколько-то тысяч лет назад, и начал понемногу уменьшаться. Но, имхо, скорее всего сейчас это компенсирует «качество» мозга — а именно образование.
Плотность записи на носитель информации значительно выросла :)
Вот и я об этом. Если твои родители сидели на велфере (не важно даже какого рода велфер, социальный или депутатско-коррупционный), то вероятность того что ребенок получится лодырем довольно высока. Но это не гены, это воспитание и социальная среда.
Вы не совсем верно поняли посыл. Дети депутатов это те же нахлебники что и социальщики, и те и другие работать не привыкли и вполне вероятно отбор не пройдут если у них внезапно забрать кормушку.
Не умение и не желание работать передаётся по наследству?
Передается воспитанием, социальной средой. Между не может и не хочет большая разница. Категория тех кто не может обычно называется инвалидами.
Надо создавать условия для всех слоёв населения
Условия уже существуют в природе и называются естественным отбором. Перестаешь кормить нахлебников и часть из них находит работу и успешно ее выполняет тк на самом деле могли но не хотели. Другая часть, правда, не проходит отбор.
Изъян этого подхода таков: нужно быть очень и очень внимательным, чтобы не поименовать что-либо во внутренних функциях так же, как и переменные «из кэша», которые вы собираетесь использовать в вашем замыкании. Даже если вам хватит сноровки, чтобы избежать затенения, ссылаться на переменную так высоко в замыкании все равно кажется довольно опасным, и от этого определенно нехорошо.
«Изъян» решается элементарным линтингом, и хорошо бы еще TypeScript сверху.
Потому что сайты десятилетней давности имеет довольно простой фронтент, там сервер делает отрисовку страниц, хранит состояние сесси и тд. Но это только про начальную загрузку страницы. В случае SPA переход между «страницым» почти не ощущается тк все страницы по сути уже подгружены, нужно только вызвать простой Rest ендпоинт чтобы получить данные для отрисовки в шаблон.
Рендеринг шаблонов/страниц в наше время это часть SPA функционала, и это стало происходить тоже потому что машины пользователей стали мощнее. В прошлые века отрисовку страниц делали на сервере (и сейчас иногда начальную делают — server side rendering в понятиях SPA).
А на вопрос так и не ответили, а все ведь просто. Потому что раньше компьютеры пользователей были слабыми и сессионное состоние пользователя хранилось на сервере/мейнфрейме (в памяти/сессии).
Со временем компьютеры пользователей стали мощнее и инженерные компании решили давайте будем выполнять больше кода на стороне клиента и забивать память у пользоваталей, а не у себя. Так появились SPA приложение и хранение сессионного состояния пользователя уже стало происходить на стороне клиента просто в JavaScript переменных. Ввиду того что на сервере состояние больше не хранится со временем стал моден Rest подход к разработке ендпоинтов и написание типового бэкенда упростилось. Количество веб кода и размер проектов стали быстро расти и пришлось изобретать TypeScript и всякие фреймворки для управления сложностью.
Теперь потролю бэкендеров следующим выводом: хардкорным фронтендерам нужно платить больше чем бекендерам потому что типовой бекенд в наши дни делать проще, а хардкорным фуллстекерам которых мало нужно платить как за троих.
Вы поняли с обратной стороны. У MS дела были плохи и им прошлось в срочном порядке становиться топовой компанией контрибьютером в опен-сорс, и дела выровнялись в итоге. Отсюда и подвиг. Стремно ведь наверно было Сатье Наделла такой резкий шаг сделать.
PWA наверно звучит модно, но это всего лишь веб страница работающая в браузерном окружении со всеми вытекающими ограничениями. То есть с системой никакой тесной интеграции по определению не получится сделать, нативные функции и библиотеки не получится использовать, придется ограничиваться только «хранилищем» реализованным в браузере, никакой тебе отдельной трей иконки с кастомным меню, и тд. PWA идея совсем не тянет на замену Electron и это нормально.
Неправильной типизация может быть когда сам код написан на JavaScript, а декларация подключется отдельно. Очень частый случай когда при таком подходе вылазят грабли. Поэтому всегда лучше искать решения изначально написанные на TypeScript, желательно с включенной strict опцией компиляции.
Следующая цитата из его опуса как раз является преимуществом, а не недостатком. То есть один раз описал модель данных и все, больше не нужно постоянно при обращении к коду думать что там за данные такие могут быть и аргументы какого типа, не нужно все держать в голове, можно ведь просто выразить все в однозначном виде в коде. Недостатком это может быть только в случае ондоразовых проектов которыми полагаю Eric Elliott увлекается, но тогда и TypeScript не нужно брать вообще. Для программистов описание типов это не нагрузка, а наоборот облегчение в перспективе. Нагрузкой это может быть для мартышек.
Условия уже существуют в природе и называются естественным отбором. Перестаешь кормить нахлебников и часть из них находит работу и успешно ее выполняет тк на самом деле могли но не хотели. Другая часть, правда, не проходит отбор.
PS ни к чем не призываю.
«Изъян» решается элементарным линтингом, и хорошо бы еще TypeScript сверху.
Со временем компьютеры пользователей стали мощнее и инженерные компании решили давайте будем выполнять больше кода на стороне клиента и забивать память у пользоваталей, а не у себя. Так появились SPA приложение и хранение сессионного состояния пользователя уже стало происходить на стороне клиента просто в JavaScript переменных. Ввиду того что на сервере состояние больше не хранится со временем стал моден Rest подход к разработке ендпоинтов и написание типового бэкенда упростилось. Количество веб кода и размер проектов стали быстро расти и пришлось изобретать TypeScript и всякие фреймворки для управления сложностью.
Теперь потролю бэкендеров следующим выводом: хардкорным фронтендерам нужно платить больше чем бекендерам потому что типовой бекенд в наши дни делать проще, а хардкорным фуллстекерам которых мало нужно платить как за троих.
— blog.honeypot.io/how-much-do-developers-earn-in-germany (тоже риктутеры судя по всему)
— news.ycombinator.com/item?id=18049640 (реальные люди)
— news.ycombinator.com/item?id=18464574 (реальные люди)
Это еще как сказать… зависит от контекста. Склонность к определенным ассоциациям все таки присутствует.