xfg

jQuery - это про императивное программирование. jQuery - это про то "как" манипулировать dom элементами. Итог - смесь dom и бизнес-логики. Это невозможно разделить.

Angular - это про декларативное программирование. В Angular мы не говорим "как", мы говорим "что" мы хотим сделать с dom и он делает это. Что позволяет отделить бизнес-логику от манипуляций с dom.

Соответственно вся эта история не про jquery vs vanilla, а про императивное vs декларативное программирование для работы с dom. Большинство этого не понимает и спорят о jquery vs vanilla, хотя всё это одно и то же, до тех пор пока у вас не появляется какая-то штука, которая меняет парадигму работы с dom с императивного на декларативный. Внутри этой штуки можно использовать хоть vanilla, хоть jquery. Без этой штуки - у вас каша, хоть с vanilla, хоть с jquery.

Собственно об этом написано в википедии:

AngularJS is built on the belief that declarative programming should be used to create user interfaces and connect software components, while imperative programming is better suited to defining an application's business logic.

Остальные фреймворки про то же самое. Это и стало причиной стремительного роста популярности javascript фреймворков.

Высокая цикломатическая сложность подобного кода. Бизнес-логика смешивается с DOM. Практически весь код дублируется.

Такой код сложно поддерживать. Сложно читать. Сложно тестировать. Это действительно слабо. Всё же мы пишем для людей, а не для компьютера. Написать сложный код, очень просто. Написать простой код, очень сложно.

Лучшее что сейчас есть это koa или express для http протокола и socket.io для websocket протокола. PHP тоже от full-stack фреймворков движется в сторону микрофреймворков. Сегодня современный фреймворк это роутинг запросов реализованный на концепции мидлваров.

Проблема спагетти-кода решается не фреймворком, а архитектурой. На сервере это обычно multilayered architecture. Бьете приложение на 4 слоя presentation, application, domain и infrastructure (еще могут называть data access layer или persistence layer). Контроллеры фреймворка куда попадает запрос пользователя это будет ваш самый верхний presentation слой. Слой инфраструктуры лучше собирать из отдельных библиотек, чем завязывать его на фреймворк. В таком случае не придется переписывать весь слой инфраструктуры из-за того, что фреймворк больше не развивается. Application и Domain слои используют Infrastructure слой через интерфейсы, тем самым абстрагируясь от конкретных реализаций. Таким образом вы всегда сможете заменить одну реализацию другой (паттерн Strategy) без изменения вышестоящих слоев. Presentation слой просто вызывает сервисы из application слоя и возвращает результат в html/json/xml/etc клиенту.

Иногда упрощают до 3 или даже 2 слоев. Например если у вас CRUD приложение, тогда application и domain слои не нужны и вы можете оставить только presentation и infrastructure. Также если ваш application слой не делает ничего, кроме вызова domain слоя, то от него также можно избавиться оставив 3 слоя presentation, domain и infrastructure.

Примеры реализации можно найти здесь и здесь. Они на Java. На javascript пока не встречал.

Более подробно тему можно изучить взяв любую книгу на эту тему.

Meteor не советую. Это не будущее. Это костыль. Они хотели сделать фреймворк для real-time приложений. Но фактически получилась просто платформа для стриминга произошедших изменений в mongo прямо на клиент.

Sails это попытка сделать full-stack фреймворк. Но весь мир движется в обратном направлении.

В случае если объект внутри себя инстанциирует другой объект, тогда такой объект должен рассматриваться как единый юнит.

import LineItem from './LineItem';

class Order {
  constructor(lineItems = []) {
    this.lineItems = lineItems;
  }
  addLineItem(name, cost, quantity) {
    this.lineItems.push(new LineItem(name, cost, quantity));
  }
}

В этом случае писать юнит-тест необходимо на класс Order. Необходимости в тестировании класса LineItem нет, так как он является составной частью класса Order. Такие классы носят название - Агрегат. Когда автосалон вас приглашает на тест-драйв автомобиля, то это предполагает тестирование Агрегата в целом, то есть Автомобиля. Тестировать отдельно составные его части такие как колеса/двигатель мы не будем.

В случае если объект принимает другой объект из вне, тогда такие объекты должны рассматриваться как отдельные юниты.

class Route {...}
class Ship {
  addRoute(route) {
   if (!(route instanceof Route)) {
     throw new Error('route must be instance of Route');
   }
    this.route = route;
  }
  ...
}

В этом случае необходимо писать отдельные юнит-тесты на Route и на Ship. Чтобы написать юнит-тест на класс Ship его необходимо изолировать от класса Route с помощью мок-объекта.

Интеграционный тест подразумевает, что вы не будете подменять Route на мок-объект, чтобы протестировать класс Ship. Вместо это необходимо передать настоящую реализацию класса Route. В таком случае мы протестируем взаимодействие между двумя юнитами Ship и Route.

Если говорим об ООП подходе, то прочитать книгу по DDD от Вон Вернона. Фактически автор описывает, как строить многоуровневую архитектуру, чтобы разделить кашу из бизнес-логики, работы с хранилищем, приложением и представлением, на отдельные слои с однонаправленным потоком данных. Книга задает вектор движения и позволяет минимизировать собственные творческие шатания из стороны в сторону, которые приводят в итоге к спагетти коду.

Изучай синтаксис JS если хочешь, но читай умные книжки по архитектуре. Культура кода в JS крайне низкая сейчас. А Node.js это просто платформа для выполнения javascript кода на сервере. Учить там нечего, открыл api, да сделал. Но сначала конечно нужно изучить синтаксис любого языка, который поддерживает ту парадигму, которая тебе интересна, иначе книги по архитектуре будут совсем непонятны. Сейчас доминирует ООП. Поэтому можешь брать любой который нравится JS, Python, PHP, Ruby. Без разницы, все они умеют ооп, в JS используют prototype-based, но это просто один из стилей объектно-ориентированного программирования, суть не меняется. Ну и в JS ооп немного коцаное, но есть языки компилирующиеся в JS призванные исправить это недоразумение, типа TypeScript.

Посмотрите yeoman.io у него огромное количество генераторов это заготовки для старта проекта, можно найти заготовку под что угодно. Структура проекта, препроцессоры, сжатия, оптимизации, юнит-тесты, всё уже настроено. Нужно взять и использовать. Делать всё с нуля, особенно первые разы не стоит. Стоит сначала посмотреть, как это принято правильно делать.

Или на крайняк хорошую литературу посоветуйте.

https://developers.google.com/web/tools/chrome-dev...

Ну 6, хотя по факту, там от версии к версии немного меняется api, что-то помечают депрекейтед, что-то удаляют/добавляют, обновляют версию движка V8 и всё такое. Глобальных изменений, когда меняется всё и вся, такого нет.

Вобще это всего лишь платформа для выполнения javascript кода, расширенная собственным api для работы с файлами, потоками и т.д. Если требуется использовать что-то из api nodejs то открыл доку и почитал, какие там есть свойства/методы и что вообще делает модуль. Всё. Это же не язык программирования, скажи что там можно изучать?

Из популярных для юнит-тестов
mocha
jasmine
Для end-to-end тестов
nightwatch
protractor

Да, можно тестировать как клиентскую часть, так и серверную. На клиентской части когда пишешь юнит-тесты может возникнуть проблема с DOM, так как не очень понятно, как мокать такие зависимости. Поэтому клиент сайд фреймворки, такие как angular пропагандируют подход к написанию кода таким образом, чтобы бизнес-логика никогда не перемешивалась с DOM. Таким образом всю важную бизнес-логику можно будет покрыть юнит-тестами, без всяких проблем.

Функциональные (end-to-end) тесты эмулируют поведение пользователя через реальный браузер. То есть end-to-end тест нажимает кнопочки, заполняет поля, ходит по ссылкам. Эти тесты более медленные, чем юнит-тесты. Изменения в верстке страницы могут их поломать. Но они более высокоуровневые, дают убедиться, что страница работает именно так как предполагалось. Не зависят от кода, а следовательно не имеют проблем с DOM в отличие от юнит-тестов.

Лично я пишу только юнит-тесты. И не пишу интеграционные и функциональные. Юнит-тесты очень быстрые, можно в автоматическом режиме прогонять при каждом сохранении файла проекта. В тоже время они дают приемлемый уровень уверенности в том, что билд проекта скорее будет работать, чем нет. Если писать все типы тестов, то можно выстрелить себе в ногу. Будет медленее. Будет больше проблем с исправлением кучи всяких разных тестов.

Если в сторадж последовательно записывается несколько значений, то да, может. Если в сторадж пишется одно значение, то нет, это атомарная операция. Для первого случая вроде есть решения stackoverflow.com/questions/14330477/atomic-operat...

Потому что на node.js как не пиши, но любое более менее сложное приложение превращается в процедурную лапшу. Абстракций и полиморфизма типов нет, приходится зависеть от конкретных реализаций. В метеоре на котором вы написали свое приложение нет di контейнера, всё валится в глобальную область видимости, используется монго, не поддерживаются транзакции между документами/коллекциями, сильная связанность, тяжело покрыть тестами.

Впечатление от этого всего, что вернулся в начало 2000-ых. Нужно ждать, пока спецификацию ecmascript допилят до вменяемого состояния. Но я думаю, что к тому времени в том же php уже будет асинхронность из коробки, тем более у разработчиков это в планах.

Никакой. JS фреймворки предназначены для создания клиентского приложения. У вас клиента быть не может, т.к. всё рендерится на сервере. Поэтому только низкоуровневые библиотеки аля jquery.

Бекендер предоставляет api для манипулирования данными, а ваша задача эти данные отобразить конечному пользователю. Взаимодействие с сервером ваша задача. Вы делаете полностью клиент. На каком фреймворке или без, вам решать. Но в подавляющем большинстве случаев пишут classic websites, где клиентская часть генерится на сервере и клиент соответственно писать не нужно, поэтому весь сайт делает бекендер, отдать можно только верстку верстальщику, а фронтендер в таком проекте не нужен.

Фронтендер такой же программист. Скажем у фейсбука есть API, вас просят написать веб клиент к этому api. И вы должны это сделать. На выходе должен быть готовый продукт, которым уже может пользоваться конечный потребитель. Это фронтендер. Это его отличает от верстальщика, задача которого картинку напилить в html.

Использовал это usejsdoc.org