[laimas]

какие еще есть недостатки кроме необходимости передавать с сервера несколько бОльший объем данных

Дело не в недостатках и объемах, все упирается в задачи и целесообразность. Объемы могут быть не такими и большими, но ...

Сначала простой пример. Пусть мы выводим постранично табличные данные, при этом заказывая сортировку по N полям с нужными условиями. Данные при этом, это связанные таблицы имеющие индексы (а как иначе, иначе это плохо), а индексы хранятся на сервере, клиенту их сервер естественно не передает. Если просматривать все данные с этим набором сортировки, то эти условия и определят порядок их получения клиентом. Если изменять условия сортировки на клиенте и сортировать на клиенте, что можно и не возбраняется, то мы будем сортировать только часть данных (текущие, полученные клиентом) не переопределяя их порядок получения во всем наборе.

Случай посложнее. Пусть БД, это клиенты (заказчики), товары и заказы. База данных проектируется исходя из принципов нормализации, и каждая эта сущность может описана в базе N связанными таблицами, при этом заказы могут быть связаны с клиентами и товарами через внешние ключи. Нужно получить определенный список любой сущности по определенным условиям. Для SQL это не является проблемой, это его повседневная задача, если же это решать на клиенте, то данные всех таблиц нужно выгрузить на клиента. У клиента (JS) не было и нет такого инструментария, ибо это не являлось и не является его задачами. Если вы будете писать сами, то нужно углубиться прежде всего в вопросы сортировки, их способы, индексацию (это затрагивает и сортировку, и очень важно для выборки, что в сущности и есть "фильтр") и т.д.

Получится ли у вас написать нечто такое же гибкое как у SQL движка я не знаю, но вряд ли это будет целесообразно. Если ограничится некими условиями, а именно, работать только с браузера имеющего поддержку WebSQL, вот тогда да - вы будете иметь полноценную реляционную базу данных на клиенте, sqlite движок. Работая с ней оперировать вы будете не дикостью в виде объектов и т.п., а обычным SQL языком, что гораздо удобнее. В этом случае база "живет" на клиенте у ее пользователя, а на сервер выгружается ее копия (синхронизация) для потребителей. При этом можно вообще отказаться от браузера и иметь ПО, которое полноценно может использовать COM объекты системы, что есть несомненный плюс в делопроизводстве.

Все бы хорошо, но не всегда такое возможно. Что если БД эта предполагает многопользовательский доступ - N менеджеров работающих с ней, что естественно предполагает изменение данных. Хороший торгаш знает, что информация о заказах, это информация о спросе, а спрос, это не только "достать и привезти", но и стратегия маркетинга. Чтобы получать информацию в реальном времени всем менеджерам запрашивать они ее должны с одной БД, то есть с сервера. Если, к примеру, из этой БД грузить данные им в браузер где они ее могут фильтровать/сортировать и т.п., то это гарантированная предпосылка, что они могут пропустить новые заказы. Или изучая спрос, менеджер может изменять параметры заказа, или обслуживая заказ изменяет его статус, что естественно изменяет общую информацию и другие менеджеры должны быть в курсе. В многопользовательском режиме обязательно возникают вопросы, которые решаются в SQL блокировками, транзакциями.

Эти вопросы также нужно будет учитывать, если они затрагивают проект ваш и перенося некие задачи на клиента решать эти проблемы. А делать выборку, сортировать конечный набор табличных данных, это можно и нужно переносить на клиента. То есть как поступать, это вопрос ну уж точно не из области "JS может отличать А от Б, и процессоры уже не 486-е, значит сделает", все определяется данными, задачами, доступом и т.д.