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

Это прекрасно... если реальное сравнение обоснованное, а не "мне так показалось, что это удобнее" или "я тут это смог сделать, а там у меня не вышло" или "говорят что это лучше" :)

Вот именно обоснованность твоих утверждений я и пытаюсь понять.
Вот по второму пункту я с тобой согласился, что в определённых случаях это плюс... я даже согласился, что пункт 4 - тоже плюс для WS (хотя в душе остался при мнении что фигня а не аргумент, но всё же, твои слова основаны на чём-то физически существующем).

Но как я понимаю ты пункт 6 обосновать не можешь. То есть там происходит как-то иначе, но чем это лучше по сравнению с ajax ты сам не понимаешь.

Вот и приходим, что в целом, если программиста не пугает лишняя строка кода в виде setInterval(myUpdateFunc, 10000), если ему не требуется передавать огромные объёмы данных, если его канал достаточно широкий, что бы не заморачиваться на экономии лишних килобайт на клиента и если не требуется моментальная синхронизация с сервером, websocket не даст ему никаких плюсов по отношению к ajax (стандартному асинхронному http), а соответственно нет смысла переходить на какую-то альтернативную технологию. :))

А теперь к твоему первому посту, где ты собирался мне голову оторвать Ты раскритиковал мой код по двум пунктам:
1. eval
2. ajax

1. Обсуждение eval провалилось, потому как ты не предоставил никаких аргументов против использования eval (потому на фиг знает какой странице мне это обсуждение надоело... если есть аргументы - всё решается за считанные минуты, как с большинством пунктов по ajax против ws)
2. К указанному случаю все указанные плюсы ws неприменимы

Так что, в итоге получается незачем мне голову отрывать?
Если хочешь, можем в том же ключе что и с ajax обсудить и eval теперь. Культурно, обдумано.
В таком случае начинать следует с конкретных аргументов с твоей стороны, почему eval использовать в указанном конкретном случае плохо и как это сделать лучше (опять же в указанном конкретном случае, который я описал в своём первом сообщении).

P.S. Я не говорю что я абсолютно прав, но я не готов обсуждать чьи-то убеждения. Это просто трата времени. Я из обсуждения хочу вынести объективную информацию, а такое возможно только при полноценной адекватной аргументации. Потому я так быстро теряю интерес к пустому спору... потому я и удивляюсь что skyANA столько усилий приложил в попытке переубедить (честно, я бы не стал!)

вадяИзопропилпропущено...

чем модель отличается от представления?
а есть ли смысл ради модели городить кучу кода и тратить на это время на выполнение?

вадя, ты что! конечно есть...

Ты, разумеется, можешь с сервера отдавать готовое представление, например подготовленные строки для вставки в html таблицу... НО это противопоказано делать там, где отрабатывает основная логика.

Обычно это делается так:


А уже сама функция render подгружает указанный файл представления и заполняет его нужными данными.

Я вот например подумал не о том, что ты html на клиента отправляешь, а первая же мысль о твоём коде была:"ФУ! Он что html собирает прямо в файле где формируются данные? Жесть какая каша!".

То, что я привёл - это стандартный MVC шаблон. Кстати он часто не оправдывает надежд разработчика и к нему постоянно приходится что-то привинчивать. Но это, зачастую, первый шаблон архитектуры, который осваивают программисты. Он один из самых доступных для понимания (например на курсе cs50 это единственный шаблон архитектуры, с которым знакомят начинающих адептов программирования)

Знаком с таким? плюсы применения знаешь или лучше их озвучить?

вадя,

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

приятно удивило

вадяПрограмёр,

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

вадя, ты работаешь один или в команде? :)
Я даже наверное немного уточню вопрос... приходилось ли тебе работать в паре с верстальщиком?
Это важное уточнение, потому что я у себя в отделе строил работу так, что даже с таким подходом как у тебя можно было без проблем разделить работу между двумя программистами. Но вот между программистом и верстальщиком фиг разделишь (мне так кажется... если у тебя получалось делить, с радостью послушаю как ты этого добился)

P.S. Конечно тот отдел, которым я руководил с горем пополам можно назвать отделом, потому как там работало всего 2 человека у меня в подчинении (ещё один программист и верстальщик). Но сейчас таких "отделов" в нише малого и среднего бизнеса большинство, а мне очень был полезен опыт управления маленькой командой... По другому начинаешь смотреть на собственные глупости и косяки, особенно когда точно с такими же сталкиваешься каждый день в лице подчинённых :))

вадя,

прогрессбар там строится на основании данных о количестве отправленных байт информации и их соотношению к общему размеру отправляемых данных. То есть тут никакого взаимодействия с сервером нету. Браузер может посчитать это ничего не спрашивая у сервера. Если вопрос длительной обработки запроса сервером - тут другое дело. Но я не представляю что должен делать сервер, что бы клиент явно заметил его "тупёж" :))

Насчёт того, что ты не работал с верстальщиками - в этом причина твоего непонимания полезности MVC... ты просто не можешь прочувствовать одного из его основных плюсов. И если ты не работаешь совместно с другими программистами то и остальные плюсы тоже немного тускловатые.

Я так скажу, невозможно научиться хорошо проектировать систему работая solo. Всё потому, что основные косяки архитектуры вылазят при включении в работу нескольких исполнителей. Когда понимаешь что теперь между ними невозможно поделить работу или им постоянно надо друг к другу бегать, что бы получить ответ "как оно тут работает" и "почему тут так написано".

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

А мне ничего ни с кем обсуждать не приходилось. Я брал макет дизайнера и составлял требования к программным интерфейсам (которые пользовались всеми участниками процесса) :)
Иногда было совсем в лом или некогда, тогда я просто давал макеты программисту, говорил "передай верстальщику все необходимые для этого макета данные", а верстальщику говорил "тебе во вьюху массив придёт, там всё есть" Это канечно из разряда "подвал эдишын", но что поделаешь, когда сроки горят и не хочется впустую час-другой тратить, тем более что верстальщик с полученными данными и сам разобраться может.

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

Изопропилкстати, что там с eval? справились без него?
Нет... решили что мне голову отрывать не стоит в указанном случае eval - оправданный вариант.

Изопропилвадяпропущено...

я согласился с Прорамером, но так делать не буду :)

а я не согласился - apply и bind - для кого придуманы?

Как в указанном случае можно переписать код без eval?

ИзопропилПрограмёрКак в указанном случае можно переписать код без eval?
каком из, конкретнее.

19844155 в этом... с которого и началось обсуждение eval