Pull to refresh

Comments 37

tonsky ты мне как ламеру поясни — правильно ли я тебя понял, что в области хранения данных веб-приложениями много открытых проблем и нет готовых рецептов?
То есть, если я правильно понял посыл, теперь все хотят изобрести десктопные приложения, только более тормозные, потому что в браузере?

Ведь в сущности, все равно браузеры все равно работают по разному (считай те же проблемы, что и поддержка разных OS). В чем профит? Ведь я могу взять C++Qt или на худой конец Python и не иметь проблем с хранением данных на клиенте и переносимостью + иметь скорость работы в 10 раз выше.
Я думаю, что тут вся причина в популярности JS. Из-за этого его пытаются втулить везде где только можно: сервер, десктоп, МК…
О, это очень интересная тема, на самом деле, зачем вообще веб-приложения. Я так понимаю, факторов несколько:
— кроссплатформенность
— не нужно устанавливать
— UI неплохо рисуется
— среда разработки крутая (dev tools)
— легко интергировать другие сервисы (intercom, например)
— спиратить веб-приложение нельзя

Т.е. если подумать, сделать скажем коллаборативное редактирование можно было бы и десктопном Word-е, и даже каких-то особенных трудностей было бы меньше, возможно (Google Docs, все-таки, в основном занимались тем, что превозмогали платформу, а не пилили код), но почему-то натуральным кажется делать его только в вебе. Наверное, потому что это общее место, где все живут рядом, и логины, и почта, и общение. Ну и понятие «файла» мешается, хочется чтобы все редактировали общий файл, а не у каждого лежал свой, соответственно он должен жить где-то в интернете.
Помоему, как раз перетекание всего на фронтенд и оставить на бекенде только БД, является прямой противоположностью «спиратить нельзя».
Управление доступа к данным можно организовать таким образом, что спиратить будет действительно или нельзя, или очень сложно.
Нельзя так сделать, если все лежит в одном месте. Именно поэтому RSA, да и в целом все уже давно работают c двумя ключами — публичный и приватный. В противном случае рано или поздно расковыряют и скопируют все что нужно.

У нас был замечательный прецедент, когда китайцы умудрились спиратить целиком игру на флеше. Они ее декомпилировали, локализировали сами, разобрали АПИ бекенда и полностью новую серверную часть написали. В итоге, через буквально пару месяцев после выхода игры была такая же но на китайском.
Это если бэкенд простой, положи-сохрани. Пиратские клоны Google Docs, например, бывают?
Зачем кому-то пиратить бесплатное приложение? Поэтому и нету.
Так оно не бесплатное. $5/user/month. Плюс вопросы приватности, корпорации не хотят хранить данные «у дяди». Гитхаб, например, альтернативный есть, но там он полностью с нуля переписан, и бэкенд, и фронтенд.
docs.google.com, с каких пор стало платное? Там платное только для компаний, но это уже полноценный пакет Google for business, который включает куда больше.
А вот это, кстати, очень интересный момент. Да, если вместо бэкенда будет стандартная БД, то пиратиться все это будет проще простого.
— Кроссплатформенности как таковой нет. Все равно приходится поддерживать зоопарк браузеров (причем и десктопных и мобильных), ведь у каждого свои загоны с отображением стилей, расположением элементов и каждый еще себе отдельный JavaScript-движок пилит. В общем, те же проблемы что и поддержкой разных ОС.

— UI и на десктопе неплохо рисуется. Тем более сейчас есть куча штук позволяющих создавать UI с помощью CSS-стилей и HTML-подобной разметки (XAML, QML и все такое)

— Как будто для других языков нет крутых IDE? Я уж не говорю о том, что отладка приложений на десктопе в разы проще

— Обычно у «других сервисов» есть API для различных языков, не только для JavaScript.

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

Итого имеем, что почти единственный незаменяемый «плюс» — не нужно устанавливать. Вот только с не очень быстрым интернетом задолбаешься каждый раз грузить это приложение. Не говоря уже о том, что приложения эти и так работают оч медленно.
Учитывая что все данные на клиенте являются эдаким кешем для данных на сервере, озвученная проблема есть вариация одной из двух сложных вещей в программировании — инвалидации кеша. По этой причине вряд ли стоит надеяться решить её окончательно; но предлагаемый подход явно не лишён некоего изящества, как и всё реактивное программирование в целом.

Вообще, мне интересно: возможен ли перенос концепции реактивности на уровень железа? Впрочем, понятно что возможно всё; правильней сказать, имеет ли это практический смысл, ускорит это программы и упростит ли жизнь программистам?
Если бы это был просто кэш, можно было бы жить — с иммутабельными данными, например, в кэшах легко работать. Тут проблема в том, что клиент, даже веб — это отдельное приложение, которое хочет уметь писать, а не только читать. Т.е. это сразу распределенное приложение с eventual consistency.
В общем-то, запись становится сложной именно когда возникают конфликты между кешем на клиенте и серверными данными. Описанные в статье «любые изменения, которые происходят, распространяются по всей системе» как раз и являются инвалидациями кеша на клиентах и, как верно написано в статье, в общем случае представляют собой нерешабельную красиво задачу.
----Он постепенно находит своё применение и в корпоративном секторе — в Boeing и Walmart пишут на нём код, то есть довольно серьёзный бизнес принимает решение переходить на Clojure.

Несколько неубедительный аргумент. Компании больших размеров покупают в среднем 2-3 компании в день. Среди них может оказатся любой зоопарк решений.

В свое время RIM купил Blackberry Solution for GroupWise написанное на VB, переписав в последствии на С++, но это не мешает сторонникам VB говорить, что на VB даже RIM-e используется.

Или допустим покупает IBM продукт как Blackberry Enterprise Service, а в качестве хранилиша данных там используется только MSSQL, можно вполне утверждать, что DB/2 настолько плоха, что даже сами айбиэмовцы пользуются услугами конкурента.

Если бы Walmart заявил что является стратегическим партнером компании, производяшей Clojure, то оригинальному сообшению было больше веры.
Аргумент действительно неубедительный. Маленькие языки таким вот и перебиваются — кто-то где-то в какой-то компании на нем пишет. Такого, чтобы супергигант поставил на что-то маргинальное, не бывает по определению.
Почему странно? Первый раз увидели сайт, не оптимизированный под мобильник?
Нет, уже 2016 к концу подходит почему бы не оптимизировать.
Можно писать на голом local storage"
Увы, далеко не всё.
Например, есть информация, что iOS в любой момент может освободить Local Storage при нехватке памяти, и Android движется в этом направлении.
Не хочется в это верить, но вот ссылки:
Don't Assume localStorage Will Always Work In Your Hybrid App
Localstorage — is it cleared after app restarts/ periodically in iOS?
localStorage not being persisted in hybrid app
Мне в своём мобильном приложении, использующем Local Storage для хранения некоторых данных (настройки и т.д.), с обнулением LS пока не приходилось сталкиваться, но англоязычные товарищи, как видите, беспокоятся.
Вот и думай теперь, то ли забить, то ли смотреть в сторону PouchDB или чего-то ещё.
Почему-то ссылки не публикуются…
Вот они текстом:
http://gonehybrid.com/dont-assume-localstorage-will-always-work-in-your-hybrid-app «Don't Assume localStorage Will Always Work In Your Hybrid App»
https://forum.ionicframework.com/t/localstorage-is-it-cleared-after-app-restarts-periodically-in-ios/21819 «Localstorage — is it cleared after app restarts/ periodically in iOS?»
https://bugs.chromium.org/p/chromium/issues/detail?id=481380 «localStorage not being persisted in hybrid app»
Ну я говорил все-таки не о персистентном хранении, а о том, как хранить состояние приложения в течение одной сессии.
Не знаю как насчет далекого будущего а ближайшее все таки топает в сторону облачных вычислений и хранений данных. То есть в противоположную сторону от представленной в статье.
А если речь о некоем приложении выполняющем работу с локальными данными клиента то это не фронтэнд, потому что по сути не веб. Даже если прога выполняется в браузере, загружена с инета и ходит в инет за какими нибудь сервисами.

А что, бывает необлачный веб?
вы правду не понимаете разницу между облачными сервисами и просто веб сервером апач на шаред хостинге?
В любом случае сути дела не меняет. Нет никаких причин выполнять вычисления на стороне клиента. Это просто нерентабельно.
Нет никаких причин выполнять вычисления на стороне клиента. Это просто нерентабельно.

Раундтрип до сервера всегда быстрее?

> вы правду не понимаете разницу между облачными сервисами и просто веб сервером апач на шаред хостинге?

Облако — это просто чей-то чужой сервер.

> Нет никаких причин выполнять вычисления на стороне клиента

Какие вычисления-то?

Нет никаких причин выполнять вычисления на стороне клиента. Это просто нерентабельно

Очень даже есть причины. И автор говорит о них в статье (для интерактивности данные должны быть под рукой).
А нерентабельно, как раз гонять мегабайты между клиентом и сервером. Данные веб-приложения можно разделить на
  • условно-постоянные (справочники и перечисления)
  • часто изменяемые (документы)
  • служебные (индексы и регистры)

Справочники логично кешировать в IndexedDB и загружать в память браузера при старте приложения.
Документы и регистры могут реплицироваться с сервером в зависимости от от задачи в разных пропорциях.
В metadata.js мы попытались завернуть ссылочную типизацию и репликацию с PouchDB и 1С в некое высокоуровневое API — получилось достаточно эффективно для разработки offline-first браузерных приложений.
при нынешних скоростях и копеечной стоимости интернета (про ближайшее будущее даже говорить не приходится — уже 5g сети тестируют) — такие танцы с бубном как реплицирование БД и синхронизация справочников — дикий изврат. Такие проблемы были лет десять назад. Теперь SAAS сервисы и иже с ними очень даже интерактивно работают с обычным тонким клиентом в браузере.


.
уже 5g сети тестируют

У моих клиентов реальная потребность в offline-first. Базовая функциональность приложения должна быть доступна offline.
Станки должны крутиться и машины разгружаться вне зависимости от наличия связи.

с обычным тонким клиентом в браузере

Сферические кони в вакууме, наверное с обычным тонким клиентом работают.
Я про реальную жизнь с реальными заказами. Там, к сожалению, без данных на клиенте не получается.
Там, к сожалению, без данных на клиенте не получается.

Если у вас что то не получается это ваши проблемы — учите матчасть. Нет никаких причин вытаскивать данные на клиента.
Потому что это не дает никаких преимуществ (если это конечно не браузерная игра какая нибудь). Только создает проблемы. Во первых стоимость разработки — кроме серверной части, которую и так надо делать, нужно делать клиентскую, а стоимость работы программиста гораздо выше нынешней стоимости железа. Во вторых такие решения очень плохо идут на мобильных платформах — а клиенты ща переезжают именно туда (это как пример РЕАЛЬНОЙ жизни).

У моих клиентов реальная потребность в offline-first. Базовая функциональность приложения должна быть доступна offline.

По моему мы обсуждаем общий подход а не специфических клиентов в шахте или глухой таежной деревне.
Но для подобных клиентов пишутся десктопные проги — вам не кажется нелогичным писать приложение в браузере для клиентов у которых нет нормального интернета?..

http://www.uxmatters.com/mt/archives/2016/04/beyond-airplane-mode.php
Sign up to leave a comment.