Блог компании RUVDS.com
JavaScript
Node.JS
Разработка веб-сайтов
Комментарии 22
+2
TypeScript — подмножества JavaScript

TypeScript, which is a superset of JavaScript

Супермэн — не сверхчеловек, а недочеловек? :)

-1

Да, они себя называют надмножеством. С точки зрения синтаксиса тайпскриптисты правы, да, распарсить тайпскрипт может и обычный яваскрипт и добавленный аннотации. А вот с точки зрения семантики, увы, не всякая программа на яваскрипте валидна в тайпскрипте, а наоборот — пожалуйста (только аннотации вырезать).


Вот если б тайпскрипт поддерживал все финты (ну, разве что исключая eval) и добавлял какой-нибудь рантайм, то стало бы TS > JS. А пока теория множеств на стороне старого не очень доброго яваскрипта.

0
не всякая программа на яваскрипте валидна в тайпскрипте


Насколько я знаю, абсолютно любой валидный JS код является валидным TS кодом. Другое дело, что компилятор может ругаться на какие-нибудь типы (но всё равно скомпилирует и сделает свой output, то есть будут скорей warnings, а не errors).

Если у Вас есть пример JS кода, не являющегося валидным TS, прошу привести.
0
Может быть вопрос несколько не в тему. Очень часто (почти всегда) говоря про node.js подразумевают веб разработку и её окружение. А есть проекты на node.js не связанные с веб?
Я просто к тому, что я на ноде пишу консольные программы и всё на удивление хорошо и удобно работает
0
У нас один из проектов заточен под smpp-протокол (масло масляное). Под капотом node.js, RabbitMQ. Крутится с два десятка демонов.
0
>А есть проекты на node.js не связанные с веб?
тыщи их electronjs.org/apps. Из самых известных и крупных — Visual Studio Code, Atom, Slack
+1

Как и следовало ожидать, они сравнили колбеки с промисами. Спорно. Если мне и потребуются 33000rps, то уж я тогдо лучше возьму голый сокет и стану напрямую слать буферы.


А вот валидация запросов / ответов у них прикольная, спасибо за наводку!

0

А вот мне интересно, существуют реальные люди или компании, которые вот прям что-то взрослое и серьезное держат в продакшне на sails или loopback?


Заранее объяснюсь. Года три назад переносил проект c loopback. Такого насмотрелся, что волосы в самых интимных местах зашевелились.
Про waterline orm из sails слышал схожие отзывы.

+1
Категорически не понимаю, почему любят в один комок лепить ORM и HTTP библиотеки/фреймворки.
Причем грешат этим большинство, и не только в JS мире.

А в некоторых случаях еще и админпанель для такой комбинации входит в состав фреймворка. Зачем? Почему?
+2
как пишет Роберт Мартин, авторам фреймворка интересно привязать вас ко всему, им очень интересно, что вы внедрите фреймворк во все слои своей архитектуры и будете зависеть от него во всех областях. Но взамен вы не получите никаких обязательств, ведь автор фреймворка может в любой момент сломать совместимость с обратными версиями и вы будете чертыхаться, переписывая все слои, от админки до работы с базы данными

Особенно няшно смотрятся еще фреймворки, которые до кучи вставляют в себя утилиты для работы со строками, массивами и тд. Поясняю: к примеру, есть такой движок Phaser для разработки игр на HTML5/JS. В нем есть свой набор утилит для работы с массивами, ну там взять выборку, отсортировать и прочее. У меня был очень большой соблазн использовать эти утилиты в блоке логики. К счастью, я воздержался и не зря — скоро вышла третья версия, в которой нахрен были поломаны все совместимости с предыдущей. Я пересел на третью ради плюшек в графическом движке. Но если бы я использовал утилиты для работы с массивами — мне пришлось бы переписывать и логику, и вообще кучу классов, где использовались утилиты из предыдущей версии.

Авторы фреймворков, которые пытаются сделать из себя God framework, словно не осознают, что они создают очень плохой паттерн архитектуры. Фреймворк должен быть модульным, по сути в нем должен соблюдаться принцип единственной ответственности. То есть не берите God framework в работу — наплачетесь потом, когда он сломает совместимость. Берите мелкие, модульные библиотеки, отвечающие за какие-то отдельные области — вью, базы данных, реактивность.
0

Микрофреймворки хороши на словах и учебных примерах, объясняющих простые вещи. Но в условиях промышленной разработки команды с ними тратят кучу времени на создание вспомогательного кода, склеевающего одни части с дугими.


Комплексные фреймворки интересны когда у вас несколько однотипных проектов со схожей инфраструктурой и вы хотите их поддерживать за разумные деньги.

+1
да, в реальности приходится любить большие фреймворки

я не совсем точно выразился, и скорее хотел сказать — «если в фреймворке еще и есть утилиты по работе со строками или массивами, не спешите использовать еще и эту фичу — лучше избегать дополнительных зависимостей».
0
Какими Node.js-фреймворками вы пользуетесь и почему выбрали именно их?

micro от zeit — легкий, быстрый, простой
+1

Странно что никто ещё не упомянул Apollo Server – вполне себе самодостаточная штука для написания headless-бэкенда. Если его укомплектовать, например, React + React Apollo – получается нормальное SPA, а если докинуть Next.js или Gatsby – статический сайт с SEO и прочим. Городить огород с шаблонами и jquery-плагинами уже становится как-то и не нужно… Можно и альтернативами воспользоваться из мира ангуляра или vue.js – сам протокол-то достаточно универсален.


Это конечно не MVC, вообще написание кода как коллекции резолверов, больших и маленьких, требует иной структуры проекта, другого подхода к выборкам данных, да и их хранению тоже. Кэшировать компоненты при SSR в Next.js тоже получается не всегда тривиально, интересная задача…

0
Вряд ли я кого-то удивлю, еще одним Node.js фреймворком, о котором никто не слышал, но в моей практике, он себя достаточно хорошо показал adonisjs.com. Правда, смотреть его стоит только при условии, что вы ищите решение на нативном js.
Мне же, из-за полюбившегося TypeScript'a пришлось пересесть на Nest.js
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.