Comments 23
Да, они себя называют надмножеством. С точки зрения синтаксиса тайпскриптисты правы, да, распарсить тайпскрипт может и обычный яваскрипт и добавленный аннотации. А вот с точки зрения семантики, увы, не всякая программа на яваскрипте валидна в тайпскрипте, а наоборот — пожалуйста (только аннотации вырезать).
Вот если б тайпскрипт поддерживал все финты (ну, разве что исключая eval) и добавлял какой-нибудь рантайм, то стало бы TS > JS. А пока теория множеств на стороне старого не очень доброго яваскрипта.
не всякая программа на яваскрипте валидна в тайпскрипте
Насколько я знаю, абсолютно любой валидный JS код является валидным TS кодом. Другое дело, что компилятор может ругаться на какие-нибудь типы (но всё равно скомпилирует и сделает свой output, то есть будут скорей warnings, а не errors).
Если у Вас есть пример JS кода, не являющегося валидным TS, прошу привести.
мб что интересное для себя найдете
Для api есть koajs, простой и легковестный.
А вот мне интересно, существуют реальные люди или компании, которые вот прям что-то взрослое и серьезное держат в продакшне на sails или loopback?
Заранее объяснюсь. Года три назад переносил проект c loopback. Такого насмотрелся, что волосы в самых интимных местах зашевелились.
Про waterline orm из sails слышал схожие отзывы.
Особенно няшно смотрятся еще фреймворки, которые до кучи вставляют в себя утилиты для работы со строками, массивами и тд. Поясняю: к примеру, есть такой движок Phaser для разработки игр на HTML5/JS. В нем есть свой набор утилит для работы с массивами, ну там взять выборку, отсортировать и прочее. У меня был очень большой соблазн использовать эти утилиты в блоке логики. К счастью, я воздержался и не зря — скоро вышла третья версия, в которой нахрен были поломаны все совместимости с предыдущей. Я пересел на третью ради плюшек в графическом движке. Но если бы я использовал утилиты для работы с массивами — мне пришлось бы переписывать и логику, и вообще кучу классов, где использовались утилиты из предыдущей версии.
Авторы фреймворков, которые пытаются сделать из себя God framework, словно не осознают, что они создают очень плохой паттерн архитектуры. Фреймворк должен быть модульным, по сути в нем должен соблюдаться принцип единственной ответственности. То есть не берите God framework в работу — наплачетесь потом, когда он сломает совместимость. Берите мелкие, модульные библиотеки, отвечающие за какие-то отдельные области — вью, базы данных, реактивность.
Микрофреймворки хороши на словах и учебных примерах, объясняющих простые вещи. Но в условиях промышленной разработки команды с ними тратят кучу времени на создание вспомогательного кода, склеевающего одни части с дугими.
Комплексные фреймворки интересны когда у вас несколько однотипных проектов со схожей инфраструктурой и вы хотите их поддерживать за разумные деньги.
Не надо так, в общем. Лучше делать PR или форки.
Какими Node.js-фреймворками вы пользуетесь и почему выбрали именно их?
micro от zeit — легкий, быстрый, простой
Странно что никто ещё не упомянул Apollo Server – вполне себе самодостаточная штука для написания headless-бэкенда. Если его укомплектовать, например, React + React Apollo – получается нормальное SPA, а если докинуть Next.js или Gatsby – статический сайт с SEO и прочим. Городить огород с шаблонами и jquery-плагинами уже становится как-то и не нужно… Можно и альтернативами воспользоваться из мира ангуляра или vue.js – сам протокол-то достаточно универсален.
Это конечно не MVC, вообще написание кода как коллекции резолверов, больших и маленьких, требует иной структуры проекта, другого подхода к выборкам данных, да и их хранению тоже. Кэшировать компоненты при SSR в Next.js тоже получается не всегда тривиально, интересная задача…
Мне же, из-за полюбившегося TypeScript'a пришлось пересесть на Nest.js
Самые популярные Node.js-фреймворки 2018 года