Здравствуйте, _NN_, Вы писали:
_NN>Похоже у вас есть супер концепция онлайн магазинов нового поколения.
Ровно наоборот — идея старше жабоскрипта, но работает для всех и работает хорошо. Достаточно посмотреть в любой магазин, созданый без JS.
_NN>Работать будет лучше , быстрее и удобнее.
Именно. Браузер — это не просто "рамки, через которые мы глядим в Сеть" — весь его интерфейс должен помогать сёрфингу. И в частности, индикатор "загрузка данных" — категорически необходимая вещь, которая прекрасно работает на "простом HTML" и просто бесполезна при жабоскриптовых подковёрных манипуляциях. И это я не говорю просто об ошибках JS-ваятелей — понять их невозможно ("variable zzyyxx doesn't contain method buy"), иногда ошибки не видно вообще (и при этом ничего не работает), какого чёрта?? На серверной стороне могут хотя бы получить под зад иксепшыном и протрэйсить его в логах, а на клиентской стороне — кто будет отлаживать весь этот жабопонос? Очевидно же, у прогера стоит тройка популярных браузеров последних версий и ему пофиг, что у тебя IE 5 — никто не будет тестировать все версии всех браузеров во всех конфигах.
_NN>Можете попробовать сделать эскиз и узнать действительно ли всем это удобнее.
"попробовать сделать" — это целая серьёзная задача, вряд ли моё свободное время стоит на неё тратить. Общий посыл прост — в зад жабоскрипты, да здравствует простой HTML.
_NN>Потому как если удобно будет исключительно вам, то этот рынок слишком мал, чтобы под него прогибаться.
Ну да, я же какую-то экзотику прошу — чтобы просто ВСЁ И ВЕЗДЕ РАБОТАЛО!
Да я вам прямо сейчас выкачу ошибку на этом же сайте RSDN: сижу в Опере 12.15, форумные сообщения вижу в виде 10 строк вверху. Ниже идёт IFRAME, в который загружаются сами сообщения. Так вот: когда какое-то сообщение загружено, его высота — ТОЛЬКО ПОЛОВИНА свободного пространства, т.е. заняты сверху треть и снизу треть. Но при этом нельзя увеличить IFRAME! Почему? Да просто кто-то глупый и ленивый впендюрил туда жабоскрипт, делающий автовысоту по каким-то неведомым калькуляциям и не протестировал это в Опере. Вопрос: зачем козе баян? Зачем вообще этот "мастер" полез жабописакать, если его контора не может себе позволить всестороннее тестирование? И ТАК ВЕЗДЕ! (я про интернет-шопы) Никто и никогда не напрягается на тщательные тесты. У шэфа в IE работает? Значит всё отлично! Будь это "простой HTML", и ошибки было бы найти намного легче, и работало бы не в "избранных" (КЕМ?) браузерах, а вообще в любых приложениях, мало-мальски работающих с гипертекстом. Кстати, бурлящий сейчас мобильный сегмент как раз тот самый случай, когда экономия на всяких жабоскриптах позволила бы писать крохотные, маложрущие браузеры с парсером уровня BBcode и его бы хватало за глаза (по кр. мере для тривиальщины типа веб-магаза).
Здравствуйте, matumba, Вы писали:
M>Ну да, я же какую-то экзотику прошу — чтобы просто ВСЁ И ВЕЗДЕ РАБОТАЛО!
С точки зрения бизнеса это совершенно неинтересно.
Если что-то не работает у 1% пользователей, а стоимость высока, то никому это не нужно.
Так везде.
M> Будь это "простой HTML", и ошибки было бы найти намного легче, и работало бы не в "избранных" (КЕМ?) браузерах, а вообще в любых приложениях, мало-мальски работающих с гипертекстом.
Да ну. Тот же HTML5 взять только теги, и уже не во всех браузерах работает.
Или CSS3.
Уже не работает везде, и заметьте никакого JS.
Юзабилити никак не связано с наличием или отсутствием JS.
Ровно как и количество данных передаваемых по сети.
Можно сделать сайт с JS который передает данных на порядок меньше чем сайт без JS.
В настольных приложениях нет JS, однако это не делает их более удобными или менее удобными.
Все зависит от приложения, а не только технологий.
P.S.
Кстати как вы без JS делаете чат ?
Заставляете перегружать страницу каждую секунду ?
Здравствуйте, _NN_, Вы писали:
_NN>Кстати как вы без JS делаете чат ? _NN>Заставляете перегружать страницу каждую секунду ?
Зачем? Что-то вроде long-polling только потихонечку льются сообщения чата, скажем во фрейм.
Другой фрейм — обычная форма. Раньше так делали. Хотя схема перегружать раз в секунду была по моему более популярна. =)
Но JS всё равно лишним не будет.
Здравствуйте, _NN_, Вы писали:
M>>Ну да, я же какую-то экзотику прошу — чтобы просто ВСЁ И ВЕЗДЕ РАБОТАЛО! _NN>С точки зрения бизнеса это совершенно неинтересно.
Согласен. Гораздо интереснее "заказать" _NN_'а и отнять у него все деньги, все 200 баксов. Только... причём тут это? Мне не интересны соображения тех, кто изображает из себя пизнесмена, мне интересна ТЕХНИЧЕСКАЯ часть, поэтому я пришёл на RSDN, а не вконтактик.
_NN>Если что-то не работает у 1% пользователей, а стоимость высока, то никому это не нужно.
Если какая-то технология используется только потому, что кто-то раздул пузырь и при этом страдают юзеры, в &^$#&$#у такую технологию.
Не надо никого специально поддерживать — для этого уже постарались дедушки из W3C — чтобы У ВСЕХ было хорошо!
_NN>Да ну. Тот же HTML5 взять только теги, и уже не во всех браузерах работает.
К чему эти передёргивания? Вы правда думаете, что этой лажей можно меня сбить с толку? HTML 3.0 — бери и юзай.
_NN>Юзабилити никак не связано с наличием или отсутствием JS.
Связано и напрямую. Невозможно огранить алмаз напильником, поэтому технологии — не единственная, но решающая вещь. Читайте внимательно коммент про "прогресс загрузки".
_NN>В настольных приложениях нет JS, однако это не делает их более удобными или менее удобными.
Зачем опять уводить разговор в сторону? А Путина не хотите обсудить? Хочется поупражняться — сходите на митинг.
_NN>Кстати как вы без JS делаете чат ?
Невнимательно читаете: "Я не выступаю против аяхов-жабоскриптов как таковых, где-то они просто незаменимы. Но я боюсь, что большинство сайтов прекрасно обошлись бы классическим HTML".
Здравствуйте, _NN_, Вы писали:
_NN>Кстати как вы без JS делаете чат ?
Вопрос: а кто вообще сказал, что чат надо делать в браузере? А почему не в калькуляторе? В тостере?
"Мобил-дебилизация" привела к тому, что сначала применяют не то и не там, подставляют костыли, а потом винят тех же браузописак, неспособных сделать всё красиво и у всех.
Вдвойне смешно смотреть на все эти прыжки в браузерах зная, что 99% людей сидят в своей вендюшечке и никуда с неё не собираются. Ну так и напиши WPF приложение, всем будет радость и главное — это будет красивое, нативное приложение с полным использованием низлежащей инфраструктуры (диск, мышь, USB-устройства и т.п.).
Одна жертва "мобилизации" уже поплатилась за свою Windows 8, ждём остальных, кому чужие грабли не урок!
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, _NN_, Вы писали:
_NN>>Кстати как вы без JS делаете чат ?
M>Вопрос: а кто вообще сказал, что чат надо делать в браузере? А почему не в калькуляторе? В тостере?
Потому что браузер есть везде.
Получается по вашему, браузеры как бы и не так уж нужны ?
Пусть каждая программа работает по своему протоколу и использует свой собственный язык разметки и вообще делает все что хочет.
Подозреваю, такая ситуация была изначально.
Странно что эта концепция не выжила
Здравствуйте, _NN_, Вы писали:
M>>Вопрос: а кто вообще сказал, что чат надо делать в браузере? А почему не в калькуляторе? В тостере? _NN>Потому что браузер есть везде.
Ответ неверный.
Выбор платформы, инструментов и прочего должен основываться на клиентах (их платформе), а так же на сложности будущего приложения.
Если большинство клиентов — вендузятники, вопрос о "гипертексте" вообще не встаёт! Но если вдруг задуман многоплатформенный хит, даже в этом случае всё ещё есть важная альтернатива — писать ХТМЛки или (при широком взаимодействии с низлежащей ОС) для каждой платформы делать своё приложение. Простой как тапок пример: графический редактор. Да, можно загемороиться с canvas, что-то там сваять уровня Paint. Но когда придёт пора расширений и недостаточного быстродействия, браузописаки сядут в лужу, т.к. сэкономили на "экзешниках", зато прокакали главный путь развития!
Итого: для того, чтобы связываться с убогой, подверженой ошибкам и нестандартам, зато "вездеплатформенной" средой, у фантазёра должны быть очень веские основания! И не только желание покрыть все компьютеры мира, но и обоснование — будет ли коммерчески рентабельно писать под те же ведропланшеты, юзеры которых жлобятся даже на доллар.
_NN>Получается по вашему, браузеры как бы и не так уж нужны ?
Я этого не говорил, я лишь подчёркиваю ограниченность браузосреды и как бы "совсем не аппликашную" природу Web'а — гипертекст. То, что поверх него наклали ещё и ужасный жабоскрипт, ступорит окончательно и хочется спросить: "Вы чё хотели сделать-то?". Здесь уместно вспомнить Java — то светлое многоплатформенное будущее, за которое сейчас рвут тельняшки. Почему не взлетело? Ведь жабу портировали подо всё мыслимое железо! Да просто потому, что в браузере жаба — ограничена, а на виндо-десктопе — нафик не нужна, есть свои нативные средства разработки.
Здравствуйте, fddima, Вы писали: F>Другой фрейм — обычная форма. Раньше так делали. Хотя схема перегружать раз в секунду была по моему более популярна. =)
О да, я прекрасно помню это "раньше". Был такой "диванчик". Пробовал я в нём сидеть с модема — бесполезное занятие. За время обновления фрейма дискуссия уезжала на пару экранов, так что даже читать это было невозможно — не то, что участвовать.
Именно поэтому меня так забавляют потрясающе некомпетентные высказывания matumba в этом топике.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, matumba, Вы писали:
M>Месье слышал что-нибудь о скорости передачи информации? Ну, там, "кибибиты", "ебибуты"... Построй сайт хоть на оптических ЦПУ, по сети всё равно надо передавать информацию, что заведомо дольше, чем реакция человека "нажал — ничего не видно".
Спасибо за ликбез про скорость передачи. Судя по применяемым терминам типа "кибибитов", вы ведёте речь о ширине полосы.
Для неё крайне важно сокращать объём передаваемых данных. AJAX занимается именно этим — когда вы добавляете товар в корзину, на сервер улетает полкилобайта и обратно полкилобайта. Для интересу прикиньте объём типичной страницы вашего любимого магазина и поделите одно на другое.
M>Забавно... ВЕСЬ ТЫРНЕТ — это сплошная перезагрузка страниц, что здесь может быть раздражающего? Нажал — получил документ по ссылке, это норма. Медленная работа — увы, чаще некомпетентность веб-писакакателей, чем объективная необходимость. Вот было бы поменьше всяких "градиентиков-жабоскриптиков", тырнет стал бы намного чище и быстрее.
Ухты. Одним абзацем выше были умные рассуждения про то, что "по сети всё равно надо передавать информацию", и что оно "заведомо дольше", и вдруг "медленная работа — это некомпетентость". Вы уж определитесь, какой фактор главнее.
M>Месье полагает, что сделать запрос на сервер из жабоскрипта — это волшебным образом в 10 раз быстрее того же браузера? Спешу вас огорчить, это всё тот же самый механизм HTTP. Да, данных передаётся меньше, но оптимизация "когда-что-кому" передавать — это и есть "правильная структура сайта".
А, вот мы и дошли до сути. Ну, расскажите нам про "правильную структуру сайта", которая волшебным образом сократит объём данных, передаваемых при полной загрузке страниц. Приоткройте, так сказать, завесу тайны.
Для AJAX я себе очень хорошо представляю, как контролировать объём данных, ездящих вверх-вниз. А также как повышать визуальную отзывчивость UI, компенсируя латентность сети при помощи асинхронной работы. Что вы собираетесь мне предложить взамен в без-JS реализации на HTML 3.0?
M>Я не выступаю против аяхов-жабоскриптов как таковых, где-то они просто незаменимы. Но я боюсь, что большинство сайтов прекрасно обошлись бы классическим HTML, не вызывая попаболь тысяч юзеров "нестандартных" браузеров позади всяких "фильтров рекламы". И уж конечно, для меня намного приятнее "перегрузить страницу", подтверждая результат моих действий, чем ждать долбаные скрипты — то ли зависли, то ли вообще сломались, то ли сеть рухнула, то ли сервер тормозит.... я наелся ваших аяксов по самые гланды — СПАСИБО, НЕ НАДО.
Странный мазохизм. То есть ждать 10 секунд на загрузку страницы вы согласны, а не ждать совсем или ждать 100мс вы уже несогласны.
M>Не последний, но видимо раньше вас — я начинал в 93-м, когда 2 КБ/с считался "хороший коннект" и трафик не разбазаривали на "стразики".
Что характерно, все упомянутые вами "стразики" трафик экономят весьма существенно. CSS позволяет ужать HTML в разы, передавая только семантик маркап; JS и динамика позволяет ужать его ещё в разы, передавая только дельту.
M>Да и дизайнеры были более профессиональные — у нас не было страниц по 500КБ только чтобы показать профайл юзера. Учитесь, господа!
Я вас умоляю. Дело вовсе не в дизайнерах, а в увеличившихся требованиях.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, matumba, Вы писали:
I>>Это проблема медленных сайтов.
M>Месье слышал что-нибудь о скорости передачи информации? Ну, там, "кибибиты", "ебибуты"... Построй сайт хоть на оптических ЦПУ, по сети всё равно надо передавать информацию, что заведомо дольше, чем реакция человека "нажал — ничего не видно".
Я — слышал. А вот ты похоже в прошлом веке застрял. Нынче пиксел на мониторе загорается позже, чем успевает прийти запрос по сети на другой континент. Вот это современное состояние дел, а то о чем ты говоришь — прошлый век.
I>>И это лучше, чем показ второго окна.
M>Не факт, просто ваше личное мнение. Я уже объяснил ранее — корзину ВООБЩЕ НЕ НАДО ВИДЕТЬ. В крайнем случае — сойдёт и попап с беглым просмотром содержимого.
Это твой конкретный сценарий. Я например совершенно по другому покупки делаю. Моя жена тоже совершенно иначе делает, при чем я вообще не могу понять, чем она руководствуется.
I>>Это азы UI. Пользователя бесят перегрузки страницы, показы новых окошек и медленная работа.
M>Забавно... ВЕСЬ ТЫРНЕТ — это сплошная перезагрузка страниц, что здесь может быть раздражающего? Нажал — получил документ по ссылке, это норма. Медленная работа — увы, чаще некомпетентность веб-писакакателей, чем объективная необходимость. Вот было бы поменьше всяких "градиентиков-жабоскриптиков", тырнет стал бы намного чище и быстрее.
Пока что большая часть инета сделана на старых технологиях.
I>>Потому он отриентируется на сайте совсем не так как ты, и для него нужен другой UI, не такой как для тебя.
M>Во время покупки, от того, что я знаю внутреннюю кухню, мне ни жарко, ни холодно — покупаю как все, без хаков Так что не надо тут из меня изображать изгоя, я такой же средний юзер.
На счет "как все" — тут я сильно сомневасюь. Тебе просто удобно по себе мерять.
M>Возможно, сейчас я слышу опыт продавца женского белья, потому что только подобная категория сначала набирает полные руки шмотья, а потом решает "купить-не купить". И ДАЖЕ В ЭТОМ случае "загляд в корзину" — не более, чем вопрос "а не много ли я набрала?". Поиск и чтение описаний товаров занимает НАМНОГО большее время, чем собственно копание в белье набраных товарах.
Ты лучше сядь на день другой рядом с таким вот юзером и запиши подробно как он пользуется сайтом.
M>>>Короче, без жабоскриптов ЖИЛИ и могли бы жить дальше, сохраняя функциональность ВО ВСЕХ БРАУЗЕРАХ СРАЗУ. I>>Ну да, вместо ожидания запроса ожидали в десять раз больше — перегрузку страницы и тд и тд.
M>Месье полагает, что сделать запрос на сервер из жабоскрипта — это волшебным образом в 10 раз быстрее того же браузера? Спешу вас огорчить, это всё тот же самый механизм HTTP. Да, данных передаётся меньше, но оптимизация "когда-что-кому" передавать — это и есть "правильная структура сайта".
В том то и дело, что быстрее. Во первых, пересылается совсем коротенький запрос и назад идет совсем короткий респонз. Во вторых, серверное приложение реагирует много быстрее. Разница примерно на порядок.
M>Я не выступаю против аяхов-жабоскриптов как таковых, где-то они просто незаменимы. Но я боюсь, что большинство сайтов прекрасно обошлись бы классическим HTML, не вызывая попаболь тысяч юзеров "нестандартных" браузеров позади всяких "фильтров рекламы". И уж конечно, для меня намного приятнее "перегрузить страницу", подтверждая результат моих действий, чем ждать долбаные скрипты — то ли зависли, то ли вообще сломались, то ли сеть рухнула, то ли сервер тормозит.... я наелся ваших аяксов по самые гланды — СПАСИБО, НЕ НАДО.
Зайди на stackoverflow и подробно объясни, чего там зависает, сломалось, рухнуло и тд.
M>Не последний, но видимо раньше вас — я начинал в 93-м, когда 2 КБ/с считался "хороший коннект" и трафик не разбазаривали на "стразики". Да и дизайнеры были более профессиональные — у нас не было страниц по 500КБ только чтобы показать профайл юзера. Учитесь, господа!
Я ж про что и говорю. Посмотри последний аутлук OWA и сравни с тем, что было в 93м.
Здравствуйте, matumba, Вы писали:
M>2. долбаная регистрация, сделаная недотумками по шаблонам других недотумков — вот здесь бы применить ваш интеллект!
Кстати говоря, последний раз я регистрировался в магазине наверное лет 5-6 назад. Даже в амазоне как то зарегился и забыл и пароль, и емейл и всё на свете, прикинь, это не помешало мне делать покупки на амазоне
Вот типичный интернет-магазин http://sushivesla.by/ Не далее чем 5 дней назад я заказывал там килограм-другой еды.
Покажи и внятно объясни, чем тебе мешает джаваскрипт, аджакс, корзина и прочие свистелки.
Здравствуйте, matumba, Вы писали:
M>Здравствуйте, _NN_, Вы писали:
_NN>>Кстати как вы без JS делаете чат ?
M>Вопрос: а кто вообще сказал, что чат надо делать в браузере? А почему не в калькуляторе? В тостере?
Потому что юзерам нужно живое общение, при чем без ожидания ответа днями или неделями. Эту потребность покрывает процентов наверное 80 всех сайтов, собтвенно чат именно для этого и нужен, при том незачем открывать новое окно.
Здравствуйте, matumba, Вы писали:
M>>>Вопрос: а кто вообще сказал, что чат надо делать в браузере? А почему не в калькуляторе? В тостере? _NN>>Потому что браузер есть везде.
M>Ответ неверный. M>Выбор платформы, инструментов и прочего должен основываться на клиентах (их платформе), а так же на сложности будущего приложения. M>Если большинство клиентов — вендузятники, вопрос о "гипертексте" вообще не встаёт! Но если вдруг задуман многоплатформенный хит, даже в этом случае всё ещё есть важная альтернатива — писать ХТМЛки или (при широком взаимодействии с низлежащей ОС) для каждой платформы делать своё приложение. Простой как тапок пример: графический редактор. Да, можно загемороиться с canvas, что-то там сваять уровня Paint. Но когда придёт пора расширений и недостаточного быстродействия, браузописаки сядут в лужу, т.к. сэкономили на "экзешниках", зато прокакали главный путь развития!
Я написал несколько рисовалок(почти), в т.ч. одну на JS со всякими аджаксами. Нынче нет инструментов, которые позвляют сделать кроссплатформенную рисовалку при чем достаточно быструю. Просто нет.
А вот требования сделать такое есть. Тебя такая разница не смущает ?
Я говорю, что раньше делали — один фрейм — долговисящее соединение непрерывно грузящее документ (сообщения из чата).
Никакой периодической перезагрузки. Второй фрейм только постит сообщения на сервер и сам может и не перегружаться (JS).
Как раз на модемах этот подход работал отлично, т.к. паразитного трафика почти не было.
А вот с любителями перегружать фрейм полностью — да, одна перезагрузка, и привет, как минимум пол и больше экрана сообщений уже уехало. А то и вообще уехало.
Здравствуйте, Ikemefula, Вы писали:
I>Я написал несколько рисовалок(почти), в т.ч. одну на JS со всякими аджаксами. Нынче нет инструментов, которые позвляют сделать кроссплатформенную рисовалку при чем достаточно быструю.
Браво! Вы уже процитировали мой ответ, осталось выделить ту основную мысль, которую вы прочли и ... не поняли?
Но если вдруг задуман многоплатформенный хит ... для каждой платформы делать своё приложение.
Здравствуйте, Ikemefula, Вы писали:
I>А вот JS в Web вобщем требует такого обсуждения.
Это нетехнические факторы, они малоинтересны.
Вкратце, моё мнение на эту тему таково: майкрософт сделала для комьюнити в разы больше, чем гугл. Гугл — империя зла, с планом зохватить мир. Майкрософт до сих пор — пушистые зайки, которые хотят зарабатывать на партнёрстве, а не на доминировании. В последнее время МС тоже пробует примерить на себя костюм какашки, но пока что у них это не очень получается — тридцать лет образа жизни так просто не выкинешь.
S>>Да, я вижу вот такую цитату: S>>
S>>Мне исходники не нужны, мне нужны технологии, как раз те, что могла выдать микрософт но не выдала.
S>>Может, я слово "выдала" неправильно понимаю? Вы тогда расшифруйте поподробнее. I>Очевидно, не правильно. Представь себе, ты хочешь что бы я выдал Башара Асада. Очевидно, я этого не могу. Но при этом, отсюда не следует, что я скрываю этого Башара Асада.
Не понимаю вашу аналогию. Так вы могли выдать Асада, но не выдали? Или Майкрософт всё-таки не могла выдать технологии, и упрекнуть её не в чем?
I>Выше стоимость продукта — значит многие продукты не смогут переступить этот порог. Это значит, что ты будешь инвестировать время не пойми во что и никакого выхлопа за это не получишь. Скажем, люди которые инвестировали время в SL сейчас учатся заново, потому что мобайл прошел мимо SL. Люди которые инвестировали время в webForms, учатся заново, веб прошел мимо webforms. Люди которые инвестировали время в IE снова учатся заново. Те кто инвестировал время в IIS, обратно учатся заново.
I>Для сравнения, люди которые 10 лет назад инвестировали время в JS,Python, Ruby, Java, Apache до сих пор накапливают опыт, опаньки !
Да ну, чушь какая. Что там можно инвестировать в Apache или IIS? Что там можно инвестировать в Java? Там ничего нового с 1999 года не произошло.
Выиграли те, кто инвестировал в фундаментальные вещи — например, в разбирательство с тем, как устроен протокол HTTP.
Вообще, если выстроить стек технологий, то окажется, что все, кто инвестировал во что-то, "абстрагирующее" от пайплайна, огрёб.
А те, кто инвестировал в изучение самого пайплайна — выиграл.
Под пайплайном я (упрощённо) понимаю SQL->HTTP/REST->HTML/CSS/JS
Попытки сбежать от HTML/CSS/JS в Silverlight провалились. Попытки сбежать от HTML/CSS/JS в WebForms провалились. Попытки сбежать от HTML/CSS/JS в апплеты провалились (это, кстати, часть той Java, в которую инвестировали время 10 лет назад. Куда теперь девать этот чудный опыт?)
Попытки сбежать от HTTP в RPC активно проваливаются, хотя инерция мышления всё ещё велика.
Попытки сбежать от SQL в разнообразный NoSQL или ORM будут зрелищно проваливаться в ближайшие пять лет.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>>Может, я слово "выдала" неправильно понимаю? Вы тогда расшифруйте поподробнее. I>>Очевидно, не правильно. Представь себе, ты хочешь что бы я выдал Башара Асада. Очевидно, я этого не могу. Но при этом, отсюда не следует, что я скрываю этого Башара Асада. S>Не понимаю вашу аналогию. Так вы могли выдать Асада, но не выдали? Или Майкрософт всё-таки не могла выдать технологии, и упрекнуть её не в чем?
Не мог и не выдал. И Микрософт не мог и не выдал.
I>>Для сравнения, люди которые 10 лет назад инвестировали время в JS,Python, Ruby, Java, Apache до сих пор накапливают опыт, опаньки ! S>Да ну, чушь какая. Что там можно инвестировать в Apache или IIS? Что там можно инвестировать в Java? Там ничего нового с 1999 года не произошло.
Это значит, что люди накапливали опыт все эти годы, а не перескакивали с одного на другое.
S>Выиграли те, кто инвестировал в фундаментальные вещи — например, в разбирательство с тем, как устроен протокол HTTP.
Правильно. А если сегодня ты учишь одну технологию, завтра — другую, не совсем ясно, где взять время на изучение HTTP.
S>Попытки сбежать от HTML/CSS/JS в Silverlight провалились. Попытки сбежать от HTML/CSS/JS в WebForms провалились. Попытки сбежать от HTML/CSS/JS в апплеты провалились (это, кстати, часть той Java, в которую инвестировали время 10 лет назад. Куда теперь девать этот чудный опыт?)
Та версия джавы издохла более 10 лет назад.
S>Попытки сбежать от HTTP в RPC активно проваливаются, хотя инерция мышления всё ещё велика. S>Попытки сбежать от SQL в разнообразный NoSQL или ORM будут зрелищно проваливаться в ближайшие пять лет.
NoSql правильно называть co-SQL. Если ты покажешь, как легко и просто в SQL писать быстрые глубокие иерархичические запросы, я покажу тебе рынок, на котором ты озолотишься прямо со вчерашнего дня.
Вот пример, как давно SQL умеет искаропки такие запросы как "BFS", "DFS", "graph diameter" ? А между тем есть no-SQL решения, которые умеют это буквально искаропки, при чем так, что код писаный на коленке студентом запущеный на десктопном железе рвет в хлам по перформансу запросы к Oraclе которые оптимизировала целая бригада программистов.
Тут ты наверное хочешь вспомнить транзакции, ACID и тд. Ну а представь, что кастомеру сначала нужен перформанс. Нет перформанса — нет продукта. И SQL как то быстро сдулся
Здравствуйте, Ikemefula, Вы писали: I>Не мог и не выдал. И Микрософт не мог и не выдал.
Ок, ну вот теперь мы определились. А то вы обмолвились, что МС чего-то мог, но не сделал, что меня и удивило до крайности.
А так-то я согласен: мог смочь, если бы знал чего хотеть, но хотел не того, в итоге того и не смог Пытается теперь смочь. С некоторым опозданием.
I>Это значит, что люди накапливали опыт все эти годы, а не перескакивали с одного на другое.
Непонятно, какой именно опыт можно накопить с апачом (ну, кроме опыта о том, что его архитектура — это академический антипример, и что единственный способ его готовить — это ставить lighttpd или nginx в качестве реверс-прокси впереди апача).
IIS — тоже, вид сбоку. Типичный веб-девелопер с IIS сталкивается раз в полгода, когда нужно подправить site bindings. Весь "опыт с IIS" — это опыт администрирования. Разработка как таковая совершенно не изменилась с версии, грубо говоря, 4.0.
S>>Выиграли те, кто инвестировал в фундаментальные вещи — например, в разбирательство с тем, как устроен протокол HTTP. I>Правильно. А если сегодня ты учишь одну технологию, завтра — другую, не совсем ясно, где взять время на изучение HTTP.
Ну, так и кто в этом виноват? Я до сих пор ежедневно наблюдаю как в живую, так и в профильном форуме людей, незнакомых с fiddlertool.com. На основании чего их допускают к разработке веб приложений, лично мне совершенно непонятно.
I>Та версия джавы издохла более 10 лет назад.
Какая версия джавы? Апплеты и сейчас есть
I>NoSql правильно называть co-SQL. Если ты покажешь, как легко и просто в SQL писать быстрые глубокие иерархичические запросы, я покажу тебе рынок, на котором ты озолотишься прямо со вчерашнего дня.
Всё зависит от вашего определения "быстрых" и "глубоких"
Потому что "иерархические запросы" на SQL мы писали ещё в 2000х, когда занимались автоматизацией MLM. Скорость устраивала — один из наших проектов в 2001 году набрал 1 миллион подписчиков. Все — в одном дереве.
I>Вот пример, как давно SQL умеет искаропки такие запросы как "BFS", "DFS", "graph diameter" ? А между тем есть no-SQL решения, которые умеют это буквально искаропки, при чем так, что код писаный на коленке студентом запущеный на десктопном железе рвет в хлам по перформансу запросы к Oraclе которые оптимизировала целая бригада программистов.
Перед тем, как я начну делать категоричные утверждения, хочу отметить, что я вполне допускаю существование таких задач, в которых быстрая изкоробочная реализация BFS/DFS/Graph diameter — это core value. Я в первую очередь против того, чтобы пытаться сбежать от SQL на поле SQL, а не на поле graph processing и прочих реальных матанов.
А теперь мне было бы интересно посмотреть на пример реальной задачи, которая типа влёт решается на co-SQL и никак не решается на SQL (ну, или точнее — на современной RDBMS, которые по факту все постреляционные)
I>Тут ты наверное хочешь вспомнить транзакции, ACID и тд. Ну а представь, что кастомеру сначала нужен перформанс. Нет перформанса — нет продукта. И SQL как то быстро сдулся
Ок, давай потренируемся на воображаемой задачке, посмотрим, насколько быстро сдуется RDBMS.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Будь это "простой HTML", и ошибки было бы найти намного легче, и работало бы не в "избранных" (КЕМ?) браузерах, а вообще в любых приложениях, мало-мальски работающих с гипертекстом. Кстати, бурлящий сейчас мобильный сегмент как раз тот самый случай, когда экономия на всяких жабоскриптах позволила бы писать крохотные, маложрущие браузеры с парсером уровня BBcode и его бы хватало за глаза (по кр. мере для тривиальщины типа веб-магаза).
