Development for Android
Development for Linux
Development for Windows
Software
Comments 2444
+39
Это всё, конечно, правильно, но, мне интересно, готов ли автор (да, я вижу что это перевод) платить вместо условной тысячи долларов за новый телефон — платить 50 000? И тогда действительно расширят штат разработчиков, чтобы у них было время писать ядро системы отдельно под каждый телефон. А ещё придётся платить за каждый веб-сайт, потому что разрабатывать каждый раз всё с нуля, без использования библиотек и фреймворков — будет очень и очень дорого. Вот поэтому, там где оно надо (космос, например, или военка) — там и оптимизируют. А в реальном мире пользователю важнее получить приложение за 1$ которое будет работать и на его телефоне, и на планшете, и даже на телевизоре…
+8
Всё хорошо в меру. Только что попробовали открыть XML файл в пару сотен метров (не спрашивайте зачем) в 17 VisualStudio под десяткой. На относительно свежем компе с 4 пнём (хз какой именно) и 16ГБ оперативки. Через 15 минут грохнули не дождавшись его выхода из медитации.
+19
Мгновенно, он умеет обрабатывать кусочками из произвольного места. Только colorer плагин будет в фоне с начала расцветку считать.
+1
Я не придираюсь — даю детали для потенциально заинтересовавшихся реализацией.
+4
Мне кажется, memory mapped files тут мало при чём. Речь о том, что некоторые редакторы способны отображать файл, лишь распарсив его целиком, а некоторым достаточно распарсивания некоторых определённых частей (в т.ч. той, которая должна быть отображена в данный момент, т.к. находится в видимой на экране части документа). Memory mapped files тут в принципе можно применить, но, по-моему, не обязательно, обычных lseek/read вполне достаточно, разница скорее в алгоритмах, а не в lseek+read vs. mmap.
+1
Memory mapped files тут не просто можно, а обязательно ибо иначе будет больше вероятность лагов ;)
+1
Мне кажется, или в случае, если весь файл влезает в RAM (точнее даже не так, если все данные, необходимые парсеру/просмотрщику влезают в RAM), то это совершенно лишнее? Исходя из определения
+2
Не лишнее, memory mapped files позволяют убрать лишнюю прослойку и сразу использовать данные из файлового кэша системы. При использовании обычного подхода получится, что система в любом случае откроет файл и он в любом случае будет в кеше, но в память приложения данные придётся копировать. и для sasha1024 тоже.
0
Я так понимаю, в кэше будет не обязательно весь файл, а может быть часть файла (если он большой).
А что значит «но в память приложения данные придётся копировать»?
Upd.: А, всё, я кажется, понял. При read происходит перенос данных в уже выделенную пользователем память. При этом эта память уже контроллируется приложением, т.е. оптимизировать это каким-то ре'map'ингом страниц (или как там ОС это делать может) не выйдет.
0
Агу, именно так. Кроме того остаётся пусть и небольшой но оверхед на работу самих API файловой системой, а тут для приложения сразу доступен уже очищенный от всего связанного с ФС кусок памяти содержащий данные файла.
0
Ну, оверхед на работу с файловой системой будет в любом случае — разве нет?
0
Этот оверхед конечно останется, но вся эта работа и так производится. Просто тут очень удобно получается, что данные уже лежат в памяти и воспринимать их как файл нет никакой необходимости.
0
О чём вы спорите?
Far давно в Open Source — уже можно было пять раз посмотреть
+2
По сути, благодаря mmap мы избегаем лишнего копирования данных из одного участка оперативной памяти в другой. Что достаточно быстрая операция. А основной затык тут не в mmap vs. lseek+read, а именно в алгоритмах, которые либо довольствуются малыми кусочками файла, либо заставляют вычитать с диска (нагрузка на диск) и распарсить (нагрузка на процессор и опять же таки оперативную память) значительный кусок файла или вообще весь файл.
+3
редактор/ide отображает (при подсветке синтаксиса и прочих плюшках) не plain text (где да, memory mapping помог бы) а по сути AST дерево, которое надо где то хранить. И вот это AST во первых весит больше исходника, во вторых его еще создать надо — то есть распарсить весь исходник. vim худо бедно справляется потому что у него подсветка на регулярках, и она регулярно ломается.
0
И вот это AST во первых весит больше исходника…
Кстати, необязательно. Это AST может:
  • во-первых, не содержать в себе сами строки, а лишь ссылаться на позиции в исходном файле;
  • во-вторых, быть не полностью детализированным (т.е. условно говоря, мы распарсим первую функцию в файле-исходнике полностью на всю глубину, но если она выше екрана, то тут же забудем результат парсинга за исключением её собственно начала и конца (т.е. удалим все узлы глубже узла самой функции), а если она снова попадёт в экран — распарсим заново (т.е. детализируем этот кусочек дерева)).
Но, да, на практике там делают немногие, та и в любом случае всё, что выше экрана, придётся распарсить, а это время, даже если результат детально не хранить.
0
Похожий функционал был еще в некоторых DOS-приложениях (для просмотра БОЛЬШИХ изображений вроде растровых карт) а в DOS memory-mapped files не бывает. Руками можно все сделать. Сложно но можно.
0

Memory mapped files — это просто немного удобства для программиста. Под CP/M-80 (в которой ещё не было не то что mmf — банальных file handles) текстовый редактор wordstar спокойно правил файл больше размера оперативки.

+5
Не знаю, как фар, а блокнот++ открывает за <1сек.
Вообще по опыту там дико тормозит подсветка кода, и такая беда не только там.
+4
Ну конечно, ведь в этом случае надо разбить текст на токены, и хорошо если разработчик предусмотрел токенизацию ± экран, но ведь в сложных больших структурах где, к примеру, есть один корень и много ветвей (тот же xml), это может быть нереально, соответственно нельзя определить где находится начало, откуда можно стартовать синтаксический разбор, и соответственно корректную подсветку создать просто не выйдет.
0
Как раз в xml это проще простого. Токенов там мало и они все достаточно легко распознаются. Там не требуется делать разметку с корня, достаточно чуть отойти назад и найти начало любого токена. Проблема будет только с CDATA, но на него пофиг.
+1
Возможно, но опять же имхо зависит от структуры xml, на моём текущем проекте xml, смёрженный из 5-10 xml может быть от 100-150 MiB и выше, как повезёт. В этом случае открытие файла в np++ становится мучением, как и работа с ним.
0
Раньше использовал EditPlus2 (не помню, почему отказался частично), до 50Мб он переваривал не морщась, больше не пробовал.
0
При открытии большой пачки файлов, пусть даже мелких, на сотню байт-пару килобайт, зависает на иногда до 5-10 секунд, на так и не посчитал каком по счёту файле, что-то после 120, но не всегда на одинаковом количестве. (вот сейчас проверил — завис, правда только на пару секунд, на 127-ом)

Я тоже отказался от него в больше части предыдущих операций и перешёл на AkelPad. Он оказался лучше Notepad++.
0
Если не секрет, зачем нужно открывать 100+ файлов одновременно? А если какое-то однотипное массовое редактирование, то уж проще скриптами. Ну и пару сек — это не катастрофа. Многие редакторы один файл открывают дольше.
0
Пара секунд только сейчас, при открытии же «обычной пачки» из ~200-300 файлов — зависает на заметное время.

Для перевода делаю копию файлов. А им нужно иногда конвертирование между форматами (из Unix в Win) и изменение кодировки (последнее можно автоматизировать).
После покупки автором оригинала — огрызкобука, часть файлов он стал сохранять в формате Unix. Изредка он заменяет много файлов, бывают сбои синхронизации и резервного копирования. На самом деле такое редко нужно, но всё же бывало, такое приходилось делать массово.
Да, можно написать конвертер и я писал один (но только для смены кодировки), но он тоже не универсален, тем более учитывая, что иногда файлы для работы нельзя выделить из всей пачки :(.
0
«Осталось понять, чем...» вы читали предыдущий комментарий :(. В котором я достаточно полно описал, зачем мне нужен редактор, да, помимо двух «конвертаций»!
А ещё, помимо самого скрипта, мне внезапно(!) понадобится интерпретатор — сам perl. Офигенный «скрипт», угу.
А ещё, он делает только одно, довольно редко нужное действие, но не делает второе, самое важное конвертирование — смену кодировки.
0
А ещё, он делает только одно, довольно редко нужное действие, но не делает второе, самое важное конвертирование — смену кодировки.
Смену кодировки делает iconv.

А ещё, помимо самого скрипта, мне внезапно(!) понадобится интерпретатор — сам perl.
На любой современной Unix-системе он есть. А откуда у вас возьмутся файлы в Unix-кодировке если у вас нету Unix'а — для меня загадка.

В любом случае если такое происходит не один раз в жизни, то проще поставить CygWin, чем забивать гвозди микроскопом, если один раз — можно и потерпеть пока редактор эти файлы откроет…
0
В любом случае если такое происходит не один раз в жизни, то проще поставить CygWin, чем забивать гвозди микроскопом

Забивание гвоздей микроскопом — это как раз куча мусора в системе в виде cygwin'ов, перлов и прочей ненужной гадости для решения одной задачи.

0
Ваши комментарии оскорбляют мой разум! Даже не знаю, чего в них больше — издёвки, насмешки или просто оскорбления.

Вы второй раз не потрудились прочитать, видимо лозунг — «комментарий не читай, ответ строчи», вам весьма близок?

Ezhyg 24.09.18 в 00:41
После покупки автором оригинала — огрызкобука, часть файлов он стал сохранять в формате Unix

khim 24.09.18 в 04:30
А откуда у вас возьмутся файлы в Unix-кодировке если у вас нету Unix'а — для меня загадка.

Для меня загадка — диагноз, который можно поставить по этой цепочке комментариев.
Вдобавок даже в предыдущем комментарии вы, похоже, так же не потрудились прочитать комментарий на который решились ответить, с как бы «желанием» помочь.
Смену кодировки делает iconv.

Я рад за него, чесслово! Мало того, изредка, даже использую его помощь.

На любой современной Unix-системе он есть.

Не на любой. Но это и не важно, при чём тут юниксы ваще? EditPlus2 — Windows программа, как я могу работать в ней, при этом конвертировать что-то скриптом питона, а затем айконвом? (только не вздумайте мне рассказывать про вторую машину или виртуалки)

В любом случае если такое происходит не один раз в жизни, то проще поставить CygWin, чем забивать гвозди микроскопом, если один раз — можно и потерпеть пока редактор эти файлы откроет…

Да уж… тащить огромный пакетище для мелких разовых вещей — очень по красноглазиковски!
Здесь я согласен с Druu

Если уж вы решили комментировать, то будьте добры, потратьте своё, безусловно бесценное, время и прочитайте уже комментируемое!
0
Не оскорбляйтесь так сильно. Я, например, долго пытался понять, автор какого именно оригинала купил огрызок, и почему он, автор, решил сохранять в Юникс-формате.

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

Ну а айконв, наверное, посоветовали, поскольку вы писали свой велосипед.

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

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

Что до сотен файлов открытых в редакторе — то, очень интересное наблюдение. Прям как в том анекдоте, на любую бензопилу, найдется рельса которая её сломает. Интересно, сколько сотен или тысяч файлов повесят редактор окончательно.
Да, так и не понял каким именно вы пользуетесь.
0
Я никогда не оскорбляюсь, не вижу смысла. Чего и вам желаю :D

долго пытался понять, автор какого именно оригинала купил огрызок, и почему он, автор, решил сохранять в Юникс-формате.

Автор оригинала (файлов), переводимого мной (слово перевод вам надеюсь понятно?)

Формат Юникс, потому что огрызкобук же, потому что там этот формат вообще-то по умолчанию в его редакторе. А не самого мак-а, потому что его редактор — *никсовый, а не яблочный.

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

поскольку вы писали свой велосипед.

Так я и написал. Хотя это не скрипт и уж точно не велосипед! Нормальная команда запуска редактора без гуя (консольно), с параметрами конвертирования из одной кодировки в другую. И я сразу же объяснил, что конвертировать надо «два раза», но нет… начинается снова предложение вначале одного, на перле, потом второго на пхп, да и вообще не под ту ось. Это же клиника!

Что до сотен файлов открытых в редакторе — то, очень интересное наблюдение.

Я же говорю, это бывает нужно редко, ну какие буквы-то незнакомы? :(
Тем более, не важно — отдельно я сконвертирую или вместе, мне же всё равно эти файлы открывать и редактировать.
Всего файлов там около 3800, но ни разу ещё не было чтобы «испортилось» больше пары сотен.

И я описал почему я так же отказался, как и автор комментария, прокомментированного мной.
Раньше использовал EditPlus2 (не помню, почему отказался частично)


0xd34df00d в репах есть:
безазотистые вещества (6,5 %), азотистые вещества (1,1 %), жиры (0,2 %), минеральные соли (в нём очень большое содержание кальция), витамины (А — 0,04 мг, С — 8—20 мг, B1 — 0,08—0,11 мг), значительное количество сахаров и витамина PP. Богата янтарной кислотой.

Никаких dos2unix там нет! Это ген такой или вещество?
0
Осталось понять, зачем тягать какие-то непонятные скрипты, если в репах есть dos2unix.
0
Notepad++ не очень, т. к. не предназначен даже для самого базового редактирования кода (не поддерживает Tab indent space align). Зато зачем-то поддерживает подсветку кода. Бред.
+1
Подсветка кода сильно нужнее. Хотя выравнивание не помешало бы, есть такое.
0
Но и подсветку значительно сложнее сделать. На несколько порядков.
0
Это чем сложнее?)
Какая разница какой фон под символом?
Красный, белый или зилёный?
Почему белый фон под символом рендерится за 10мс, а красный фон за 100мс?))) Цыфры условные.
Вы вообще понимаете, что разницы в принципе нет никакой? И не должно быть.
Разница получается в таких вот поделиях исключительно потому, что поделие сделано из говна и палок. Подсветку прикручивают не на том уровне абстракций. Всего навсего…
+2
Для подсветки нужен хоть какой-то синтаксический анализатор конкретного языка. На регулярках или строящий AST, обрабатывающий весь файл целиком или потоковый, в основном потоке или в фоновом процессе, но анализатор. Для каждого языка.
-1
Ага ага…
Вы еще скажите, что отрисовка процессором символа с фоном медленней, чем определение того какой под символом фон нужен.
-2
Как это причем?
У вас решение какое-то дичайшее.
Вы говорите что парсить строчьку дороже, чем символ с красным фоном рисовать.
ВЫ ОБЪЯСНИТЕСЬ ХОТЯ БЫ КАК-ТО??? Как такое может быть вообще?
Или вы что не понимаете, что вы люто бредите??
+3
Какую строчку? А если 900 строчками выше объявлен символ начала комментария?
+1
Вообще то тут сильно зависит от того, что парсить и как рисовать. И на каком железе. Парсинг строки кода на C++ может быть сильно медленнее, чем отрисовка символа 16х16 пикселей с заданным фоном.
А вообще мне кажется, Вы с VolCh о разных вещах говорите. Вы — о времени выполнения, а он — о времени разработки.
0
Особенно учитывая, что парсинг C++ неразрешим в смысле Тьюринга и требует полноценного интерпретатора C++.
0
Конечно парсить строчку, иной раз в несколько мегабайт длиной, дороже, чем рисовать сиволы с разным цветом фона. Как минимум в случае когда символы мы по любому рисуем и нам нужно лишь определять каким цветом и с каким фоном их рисовать.
0
В реальность вернитесь уже.
У вас строка бывает длиной в несколько мегабайт? И зачем подсвечивать эту строчку длиной в мегабайт?
Вы про какой парсинг сейчас говорите?
Давайте разбираться. Парсинг всего документа целиком — это одно. И да, совершенно прав человек, когда пишет, что если начало комментария 900 строчками выше, то надо парсить весь документ. Так символ комментария может быть не только на 900 строк выше, а выше еще и на 1800-ой строке. Комментарий кто-то попытался сделать вложенным например. И не надо говорить что где-то это запрещено, а где-то разрешено, и где-то документ будет валидным, а где-то нет. Суть не в этом. Парсить ДОКУМЕНТ в любом случае нужно. Но я не про парсинг документа) Я про парсинг строки. Т.е. где в строке подсветить символы. Я про графику. И только. Т.е. есть строка, уже распарсенная. Так вот вам в этой строке нужно подсветить исходя из распарсенного — символы 10,11,12, 34,35,36 и т.д. Вот это и тормозит. А тормозить не должно никак. Имея именно распарсенный документ любой, т.е. абсолютно любой — тормозит именно подсветка символов. Это же увидеть абсолютно легко. Берете документ на 10кб и на 10мб — подсветка тормозит в обоих случаях. И тормозит именно определение того, где какой символ подкрасить, т.е. фон поменять. А фон меняют через лютые костыли зачем-то. Вот это и тормозит больше всего.
Выходит так, что тормозит не парсинг документа, а графика. Это как с курсором выжирающим ядро. Типа того.
0
Документ состоит из строк. Распарсить документ = распарсить все строки. И это вам нужно вернуться в реальность, где строки никто не парсит снова, чтобы подсветить её части. Определение цветов символов в строке — это не парсинг.
0
Да что вы говорите) Т.е. если вы получили некую структуру данных о документе, то в ней что-то сказано о том где и как красить фон символов? Наложение раскраски тоже никто не отменял. Закомментированное что-то может быть тоже внутри раскрашено, но бледно. Перенос строки разве кто-то отменял? И как вы в такой строке красить собираетесь? А если идут 20 табов и строка уходит за экран? Тоже подкрашивать то что ушло за экран? Вам графическую часть парсить придется и еще как. И да, тут нужно будет тоже парсить. И это парсинг тоже.
0
Наложение — это наложение, проецирование если угодно, может разметка, но никак не парсинг. И до графической части там ещё далеко.
0
А до какого уровня парсить, насколько подробную подсветку мы хотим?
Рисовать буквы одним цветом, цифры другим, прочие символы третьим — элементарно и почти ничего не стоит. Подсветка ключевых слов, строк, комментариев — уже зависит от синтаксиса языка. Выделить имена классов, элементы перечислений, парные скобки — нужен полноценный парсер. Неиспользуемые параметры? Неинициализированные переменные? Теперь рисование разноцветных символов требует транслятора с анализом dataflow…
0
Я имею ввиду реализовать подсветку синтаксиса в редакторе программного кода на порядки сложнее, чем реализовать в редакторе tab indent space align.

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

Так вот, Notepad++ решил пойти по странному пути. Потратить годы работы на подсветку синтаксиса — это ок, а потратить 5 минут времени на Tab indent space align — не ок, хотя эти две фичи одинаково важны.
+2
Ну, на счет одинаково важны — это все таки субъективно. Я вот вообще почти не слыхивал про tab indent space align, а подсветка синтаксиса очень помогает.
+1

Если отключить из редактора intellisence, подсветку синтаксиса, то вероятнее он откроется быстрее. Тот же sublime, если автоматом не поставит подсветку синтаксиса, то может открывать файлы в разы больше чем с подсветкой. Хотя Vim например и с подсветкой открывает достаточно шустро.

+7
Блокнот++ открывает быстрее секунды с подсветкой. На самом деле там 2 проблемы
1. подсветка. У многих она тормозит. У некоторых — безбожно.
2. Весь файл в одну строку. Такая подстава многие редакторы ставит на колени. Как пример: PSPad с подсветкой справляется, а вот с однострочниками нет. Более того, там даже прокрутка будет безбожно тормозить (если вкл автоматический перенос)
0
Помнится перестал использовать PSPad после того как надоели постоянные падение при попытке открыть хотя бы метровый файл
0
Та же самая ситуация, сам по себе PSPad был отличным продуктом, но если бы не эти мелочи. Но зато я открыл для себя существование Notepad++ и Sublime Text
0
Если бы ещё в Notepad++ можно было бы редактировать программный код. Туда зачем-то впихнули подсветку синтаксиса, а какой в этом толк, если всё-равно не поддерживает tab indent space alignment.
0
Подсветка синтаксиса в Notepad++ полезна тем чтобы глаза не вытекали и чтобы можно было, например, скрипт для cmd отредактировать. А для редактирования кода и разработки есть IDE, её и необходимо использовать.
0
Имеющаяся IDE неповоротлива и бедна на подсветку синтаксиса, поэтому используется Notepad++
+1
  1. Написал бы, но я работаю с другими языками программирования.
  2. Это странно, для такой базовой функциональности писать плагин. Давайте ещё напишем плагин нажатия клавиши Enter, чтобы перенести курсор на следующую строку, предваритально создав её, потом напишем плагин для стрелок — а чё, хочешь перемещаться по коду, ставь плагин! и т. д.
  3. У notepad++ есть какие-то баги с плагинами — не сохраняются настройки.
  4. Но конечно же всегда можно сделать Pull Request! Но даже если бы я писал на этом языке, то не знаю, стал ли бы я делать. Потому что когда языки совпадали, я пулл реквестил аж в 5 проектов. В двух из них авторы до сих пор рассматривают их уже 2 года (хотя перед pull request'ом я с ними общался, они были не против изменений). Казалось бы, всё готово, им нужно только одну кнопку нажать и смержить изменения, но нет. В одном проекте исправил ошибку, но pull request тупо отклонили, сказав, что не хотим мы ваших исправлений. И только в двух проектах pull request'ы без проблем приняли.

    Выяснять отношения и годами просить принять pull request поднадоедает. Хочется просто взять, реализовать фичу, и всё, а не заниматься не пойми чем. Хочется заниматься именно программированием.
0
хм
  • вы перемещаетесь по коду стрелочками
  • «Выучить новый язык программирования» на уровне написания плагина непосильная задача

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

И самое главное — ради чего? Ради того, чтобы следующий человек пришёл и сказал «А где tab indent space alignment?»? Ну да, наверное, найдёт плагин в гугле. По факту плагин уже есть давно. Но работает плохо. +В Notepad++ не сохраняются настройки плагинов.
0
Не замечал такой проблемы. Может, это из-за того что программа с плагинами поставлена в папку Program Files запись в которую под правами пользователя по умолчанию системой пресекается.
0
Интересно, а куда ещё ставить программы, кроме как в Program Files? И по идее плагины должны хранить настройки в аппдате, там же, где хранят свои настройки другие нормальные приложения
0
Должны, но приложение можно поставить и по старинке, оно будет всё хранить в своей папке получая каждый раз облом. А в новой винде есть ещё и прозрачный механизм переноса этих файлов в профиль для старых приложений, они не заметят подвоха. Может, механизм как-то неправильно работает — насройки исправно сохраняются, но плагины пытаются читать их по старому месту?
0
Может, механизм как-то неправильно работает — насройки исправно сохраняются, но плагины пытаются читать их по старому месту?

Вряд ли. Это нужно сохранять настройки от пользователя, а запускать от админа, только тогда отключится виртуализация файловой системы.
0
Странно. Сам активно им пользовался и падений особо не припомню. Отказался как раз из-за невозможности работы с большими однострочными файлами (дичайше тормозил). Но если файл порубить предварительно на строки — вполне норм. Для нарезки использовал EditPlus2, он без проблем пережевывал 50+метров (больше просто не пробовал)
0
Я в читерскую бытность частенько открывал непотребные файлы текстовыми редакторами. Переживали такое немногие. Это было году в 2004 в расцвет WinXP и тогда много чего под винды отваливалось по разным причинам.
+1

Ну сделай ты подсветку синтаксиса отдельными потоком, чтобы не мешать пользователю пользоваться твоей программой.
Сперва разработчики для iOS догадались (ОК, их заставили) переносить тяжёлые и долгие операции в фоновые потоки.
За ними подтянулись разработчики для Android.
А на десктопах всё так же по старинке всё одним потоком, последовательно — если у пользователя комп тормозит, то пусть купит себе новый, ага.

0
Ну у джетбрейнс парсинг отдельным потоком или процессом
+1

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

+1
… с правами админа (десктоп), с доступом ко всем возможным действиям, нужным и ненужным, но пусть будут (мобайл)…

Первое еще можно понять — сисадмин по своей лени выдал разработчику полные права для изменения либ и прочего, вот последний так же ленится релогаться туда-обратно и пишет под админом. Ваше право, возьмите да укажите в требованиях к установке полные права. Нееет, мы умолчим о том, что разработка у нас через одно место, а юзер пусть грешит на себя — то ли комп глючит, то ли ОС криво встала… Из последнего — надстройка Overwolf для TeamSpeak3: под юзером запускалась, все рисовала, но не коннектилась к ей же запущенному TS3.
Порой доходит до абсурда — пользовался плагином EveryHTTPS, и на одном из сайтов сертификат был выдан на айпишник локалхоста, то есть у админа всё работало…
0

Чтобы делать что-то в отдельном потоке — нужны на порядок более квалифицированные разработчики. Без этого ловим глюки и тормоза (потоки ждут друг друга — не раз наблюдал, как в несколько потоков оказывается медленннее, чем в 1).

0
Ну, я думаю, такие вещи, как посветка синтаксиса, в любом случае квалифицированные разработчики делают, не?
+1
нужны на порядок более квалифицированные разработчики.

Что значит «на порядок более квалифицированные»? Человек, если вообще способен быть программистом, способен и освоить многопоточность. Многопоточность может потребовать больше внимательности и времени на проектирование, но для её использования не нужно какое-то профессиональное просветление. Это такой же обязательный навык для любого программиста (кроме тех, кто пожизненно связался с какой-то принципиально однопоточной платформой), как и умение делать циклы. Просто проходится на чуть более поздних лекциях.
0
Я бы согласился, если бы не истории, что физзбазз для людей просто рокет саенс.
0
Не забывайте, что в коде неминуемо будут ошибки, которые потом придётся искать. Как по вашему, достаточно для этого «пройти многопоточность на более поздних лекциях»?

Конечно, сейчас есть методы, позволяющие кардинально уменьшить сложность многопоточного кода (например, делать все данные либо локальными, либо immutable — вроде современные языки даже научились жёстко устанавливать это ограничение), но всё равно сложности хватает.
0
Проблема в том что эту подсветку и структуру данных которую читает процесс редеринга надо синхронизировать. И тут мы получаем два варианта: или отрисовка пишет непосредственно в структуру которой оперирует рендер и огромные процессорные ресурсы улетают на обработку блокировок или у синтаксиса своя копия отрисока с ней сверяется по необходимости и мы имеем примерно удвоенное потребление памяти.
+2
у синтаксиса своя копия отрисока с ней сверяется по необходимости и мы имеем примерно удвоенное потребление памяти.

С одной стороны, да. С другой стороны, я помню, как четверть века назад притормаживала подсветка синтаксиса в Turbo Pascal 7 на компьютере «Поиск 1.04». Было примерно как сейчас у меня в браузере при комментировании этой ветки. Лагало, неприятно было, но работать было можно.
Checkit показывал, что быстродействие того «Поиска» было на уровне 0,5 от IBM PC XT (там был 16-битный проц на 5МГц, 608К ОЗУ, и программная эмуляция видеоадаптера IBM CGA). И там подтормаживала подсветка синтаксиса. Блин, но я никак не могу понять, почему она в некоторых IDE подтормаживает сейчас, на восьми 64-битных суперскаляных ядрах по 4ГГц каждое.
+9
XML хороший пример, но в другом смысле. Среди читающих это есть некоторая доля программистов, некоторым из них приходилось парсить XML. Сколько из них пользовались XML DOM парсером, который по определению жрет память, а сколько гораздо более экономным XML SAX парсером? Вот то-то же, DOM настолько удобен для программиста, что в 99% процентов случаев ему прощали его цену. А из десятков таких нюансов и складывается общий оверхед.
+4
На самом деле sax\dom — это фигня (хотя да, скорость там очень отличается). Недавно столкнулся с кодом, который на больших объёмах почему-то (только у клиента) дико тормозил. Практически экспоненциально! Т.е. для файлов в 100 кб вывод занимает секунд 10, а метр — уже к часу дело идёт. Начал разбираться. Оказалось файл формируется по шаблону, а шаблон тупо нарезается на блоки, из которых собирается файл. String.replace-ом. В итоге у разраба на машине с 16Гб оперативки всё работает, а вот у клиента с 2..4Гб моментально выжирается вся оперативка и дальше становится всё очень печально…
+3

Напомнило, как я в своё время всадил фееричную багу.
После нескольких часов работы программа начинала тормозить. Причина: в ней было отладочное окошко с текстбоксом лога, в который я при обработке очередного блока данных добавлял точку (что-то тип dbgForm.textboxLog.Text.Append(".") — дело было на дельфях). Что с каждой точкой оказывалось всё медленней...

0
В драйверах Qualcomm как-то нашли кусочек кода, где для того, чтобы найти максимум в массиве, его сортировали по неубыванию. Пузырьком.
Это драйвер, т.е. критичный к производительности код. Для мобильных устройств. От Qualcomm.
0
Если массив маленький, то не критично. Но зачем так криво делать? Можно просто в цикле прогнать один раз.
0

Да возможно все гораздо проще — исходно надо было сортировать небольшой массив или его часть, сделали пузырек, потом требования изменились и оказалось, что нужен только один элемент, а пузырек остался, т.к. не стали все переделывать.


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

+9
Абсолютно точно.
То ли в 2014, то ли в 2015 у нас налоговая приняла законы, по которым XML-ины электронной отчётности по размеру стали допустимы до 10гб (вроде бы с изначального «копеечного» лимита 10-100мб), так все решения на DOM'ах очень красиво посыпались, когда пошли клиенты с громадными «контролируемыми сделками» и «книгами для ндс». Потому что DOM одной только памяти жрёт х10 от размера файла, и если раньше (100мб-1гб) на это закрывались глаза, то на 100гб глаза уже не закроешь, не говоря уже о платформе х86.
Делал в те времена в системе электронной отчётности проект по уходу с DOM (легаси было крепко на него завязано, XPath и прочие плюшки активно использовались) на SAX в один пробег, с «эмуляцией» плюшек или обоснованным отказом от них — веселья было много. Теперь в резюме указываю тег XML, а на собеседованиях периодически посмеиваются, мол, что там знать-то, древовидная структура, теги/атрибуты и всё. Так-то оно да, но, как и в физическом мире, когда масса объекта пересекает определённые границы, проявляется много интересных эффектов, о которых даже не думаешь, щупая маленькие объекты.
0
Мы с этой проблемой лет на 10 раньше столкнулись. Объёмы тогда были не такие, но 50..100 метров на тех машинах тоже было не подарком.
+1
Однопроходный алгоритм в ленивом DOM-парсере вполне может быть O(1) по памяти.

Да, я такое писал с одним из хаскелевских DOM-парсеров. Было очень удобно, приятно, естественно и эффективно.
+3

Почему?


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

0
Это сильно зависит от структуры документа. Бывают форматы, где есть ссылки из начала в конец, т.е. для обработки самого начала уже надо иметь доступ ко всему файлу. И загружать его всё равно придётся полностью. Так что никакое О(1) не отменит того, что грузиться оно будет медленнее и памяти занимать сильно больше. Причём второе — бессмысленно, т.к. программы обычно всё-таки не работают с самим деревом, а просто загружают его в свою структуру просто дублируя данные.
0
Ну, в этом случае можно просто сохранить ссылку на кусок в конце.

А вот если вам нужно посчитать, скажем, 0.95-персентиль по некоторым нодам в документе, это уже может быть болезненно, да.
0
В смысле? Чтобы сохранить ссылку нужно сначала распарсить весь файл и найти, куда ссылаться, т.е. нужна доп логика над парсером. Проще sax-ом обработать в один проход. А ещё ссылки бывают не только вперёд, но и назад. DOM для того и нужен, чтобы работать с рандомным доступом, без этого смысла в нём нет.
0
Ну это уже от конкретной задачи зависит, так сферически в вакууме трудно обсуждать конструктивно, но смысл в том, что встретили ссылку вперёд — сохранили в список соответствующий предикат. Тогда вы будете O(n) по числу предикатов/ссылок, а не по всему объёму документа.

А иногда оказывается выгоднее тупо распарсить документ два-три раза, зато каждый раз в один проход.
0
Вот только вы, похоже, не учли один нюанс. В этом случае парсер(!) должен знать структуру конкретного файла, чтобы понимать, что является ссылкой, а что якорем. Что слегка убивает идею универсального псевдо-dom. Imho на этом этапе проще перейти к нормальному sax, это будет проще, чем морочиться со всей лишней логикой чтобы вкорячить сюда то, что тут не требуется. (троллейбус.jpg)
0
Зачем это парсеру знать? Парсер просто выдаёт ленивое дерево нод, знать это нужно вам, когда вы по этому дереву проходите.
0
Парсер просто выдаёт ленивое дерево нод

А как парсер сможет выдать дерево нод (не важно лениво или нет), не зная структуры документа?


Вообще по такой логике можно любую задачу решить за О(1) — объявить что ф-я, которая делает то, что нужно, ленивая, и не запускается, т.к. оказывается не нужна.
В итоге можно мгновенно решать np-задачи.

0
А как парсер сможет выдать дерево нод (не важно лениво или нет), не зная структуры документа?

А зачем парсеру знать структуру? Парсер — это синтаксис, структура — это семантика конкретных элементов. XML-парсеру пофиг, OOXML там, налоговые выверты или XHTML.

И если это ссылки, скажем, в смысле примечаний формата fb2 какого-нибудь, то не вижу проблем.
0
Ок. Пусть fb2.
Есть док, у которого в самом начале ссылка на картинку с обложкой, которая лежит в конце. Когда клиент захочет сразу же отобразить обложку (ну он же работает с dom и уверен, что она уже загружена) вы предлагаете:
1. загрузить весь документ до обложки и работать как с обычным dom?
2. дропнуть всё до обложки а потом начать парсить сначала, когда клиент продолжит читать документ с начала первой главы?
3. ???
0
Когда клиент захочет сразу же отобразить обложку (ну он же работает с dom и уверен, что она уже загружена)
Даже если она уже загружена — поиск в нём долог и дорог. И да, сложить две строки — это тоже дорого и сложно. Как и выделить подстроку. И как изменить регистр. И как многое другое. Лучше всего про эту банальность (как и почти любую другую банальности) описал Джоел

Если вы будете помнить, о том, что поиск в DOM — это дорого и долго, то у вас всё будет работать быстро и с DOM'ом и, чуть медленнее (но со значительной экономией памяти) — с «ленивым» DOM'ом. Если же вы будете считать, что складывать строки легко и быстро — то вам, извините, никакие абстракции не помогут. Скорее помешают.

У меня есть ощущение, что вина всему — то, что начинающие программисты больше не начинают с Бейсика на C64. Когда вы писали на языке, который был в 100-500 раз медленнее (не в 100500, а в 100-500 — это довольно точная оценка), чем тот же алгоритм в машинных кодах и при этом процессор у вас был частотой 1 (один) мегагерц… то увидеть, что операции со строками — таки медленные можно было почти что невооружённым глазом. А сейчас — сеньор-программисты об этом не подозревают… а абстракции… абстракции могут быть любыми — важно только не забывать, что все они — дырявые
0
Собственно на вопрос вы так и не ответили. Те, кто понимает, что dom — это медленно и дорого — его по возможности не используют, так что речь не о них. И при повторном чтении там будет совсем не чуть медленнее (тем более что построение dom уже само по себе весьма затратно). Да и речь вообще была о том, что просто так заменить dom на ленивый нельзя. А не просто так — почему сразу не использовать sax?
0
А не просто так — почему сразу не использовать sax?

Для униформности.

Впрочем, я тут ещё подумал и понял, что в ленивом сеттинге разницы между DOM и SAX нет вообще. Что там функция, паттерн-матчащаяся на ноды, что там функция, паттерн-матчащаяся на выплевки SAX-парсера.

И если вспомнить, что в ленивых языках всякие списки, ленивые деревья и прочее — это скорее управляющие структуры, а не структуры данных, то это начинает иметь всё больше и больше смысла.
0
Для ленивых — может быть. Для остальных — наоборот, меньше смысла, т.к. логика обработки меняется.
0
Если у меня недостаточно памяти, то я бы делал (2), в первый проход дропая всё, кроме обложки. SAX'ом вы тоже два прохода будете делать, впрочем.
0
Вы меня упорно отказываетесь понимать. Какие 2 прохода? Вы работаете с dom! В sax всё прекрасно делается за 1 проход. Речь не о нехватке памяти, а о дублировании в памяти всего документа в dom.

А если вы работаете проходами, то на кой чёрт вам dom, если всё равно алгоритм работы полностью меняется. IMHO ленивый dom имеет смысл только при простой последовательной обработке, когда очень лень эту обработку писать. Да и то по факту сильно проще там не станет.
0
Как вы с SAX решите вашу задачу с fb2 выше в один проход?

DOM мне затем, что, с учётом ремарки выше, это вопрос того, кто оборачивает поток XML-сущностей (тег/атрибут/етц) в управляющую структуру. Мне удобнее, когда это уже сделали за меня, чем строить дерево ручками.
0
А в чём проблема? Мы же знаем, что картинка будет позже в добавим, когда дойдёт до неё дело. А вот работающие с dom такими вопросами обычно не заморачиваются, т.к. по идее всё дерево доступно полностью сразу.

Это всё хорошо, когда вы пишите редактор xml или сериализацию один-в-один. Но когда данные в памяти не соответствуют структуре файла (а обычно так и бывает) — их всё равно придётся преобразовывать. И когда это делать разницы нет. Хоть при обработке потока xml, хоть выгребая из дерева. Но первое быстрее и требует меньше памяти.
0
А вот работающие с dom такими вопросами обычно не заморачиваются, т.к. по идее всё дерево доступно полностью сразу.
Никогда оно не бывает «доступно всё сразу». если всем известные числа вспомнить, то легко понять, что переход к следующему элементу — это что-то типа 0.5 нс (обращение к кешу L1), у куда-то «вдаль» — что-то типа 100 нс. Разница — два порядка. И да, это в полностью распарсенном и загруженном дереве.
0
Всё-таки речь не о том, что они не бесплатны, а о том, что об этом никто не задумывается. Особенно с учётом того, что на загрузку там тратится на много порядков больше времени, чем на доступ. Собственно на фоне загрузки доступ уже можно считать условно бесплатным. Ну не считая случаев, когда загрузка засрёт всю память и мы будем работать со свопом. Это к обработке уже не относится.
0
Особенно с учётом того, что на загрузку там тратится на много порядков больше времени, чем на доступ.
Ой ли? А если прикинуть? Если доступ к памяти занимает 100 наносекунд, то на 10Гбит/с канале вы за это время загрузите 120 байт. То есть «много порядков» у вас будет только если ссылки из одного места в другое случаются пару раз в файле на мегабайт. Иначе — эти величины очень даже могут быть сравнимы.

Собственно те самые числа «должен знать каждый» именно потому что часто вещи, которые «на много порядков больше времени» занимают вовсе не так много, как вам кажется — и соотвественно «очень простые и быстрые» вещи часто оказываются вовсе не такими «простыми и быстрыми»…

Ну не считая случаев, когда загрузка засрёт всю память и мы будем работать со свопом.
А почему, собственно? Если у вас система на SSD, то обращение к своп-файлу вполне может происходить на скоростях в несколько гигабайт в секунду… а вот если нужен произвольный доступ — то там числа совсем-совсем другие, конечно…

Это к обработке уже не относится.
А у чему это, я извиняюсь, относится? Если вам дадут XL-файл гиг на 10 — что вы ним будете делать?
0
100 наносекунд, то на 10Гбит/с канале вы за это время загрузите 120 байт.

Да нифига вы за это время не загрузите. На один TCP-handshake куда больше времени уйдет.
0
Иначе — эти величины очень даже могут быть сравнимы.
В сферических условиях в вакууме всё может быть. В общем случае на больших файлах разница будет и приличная
А почему, собственно? Если у вас система на SSD, то обращение к своп-файлу вполне может происходить на скоростях в несколько гигабайт в секунду… а вот если нужен произвольный доступ — то там числа совсем-совсем другие, конечно…
В основном потому, что изначально задача была в частности «не засрать всю память». А если это неизбежно — то не полагаться, что программа всегда будет работать на машине с топовым ссд неограниченного размера или как минимум с 128Гб оперативки.

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

А у чему это, я извиняюсь, относится? Если вам дадут XL-файл гиг на 10 — что вы ним будете делать?
Для начала я выясню, что, собственно с этим файлом требуется сделать. И если нет задачи написать клон excel — обычно требуется лишь загрузка из него значений, для чего пихать весь файл в память нет совершенно никакой необходимости.

Если вдруг имелся всё-таки XML файл, то тем более. SAX-парсеру размеры файла совершенно не важны.
0
Если доступ к памяти занимает 100 наносекунд, то на 10Гбит/с канале вы за это время загрузите 120 байт.

Это сравнение апельсинов с бегемотами. Сравнивать задержку доступа с устоявшейся скоростью передачи несколько странно.

Если у вас система на SSD, то обращение к своп-файлу вполне может происходить на скоростях в несколько гигабайт в секунду… а вот если нужен произвольный доступ — то там числа совсем-совсем другие, конечно…

А если произвольный доступ не нужен, то можно снова лениво стримить всё дерево в DFS-порядке, и мы вернулись в начало.
0
Если доступ к памяти занимает 100 наносекунд, то на 10Гбит/с канале вы за это время загрузите 120 байт.
Это сравнение апельсинов с бегемотами. Сравнивать задержку доступа с устоявшейся скоростью передачи несколько странно.
Время есть время. Тот п#зд$ц, который мы тут наблюдаем в Хроме вот на этой самой странице с вероятностью 99% связан с тем, что кто-то исходил из логики: на загрузку там тратится на много порядков больше времени, чем на доступ… но применение этой логики достаточное число раз привело к тому, что… имеем то, что имеем то, что имеем: Chrome 54 — работает быстро, а «ускоренный» Chrome 69-70… вот так, как он работает…

А если произвольный доступ не нужен, то можно снова лениво стримить всё дерево в DFS-порядке, и мы вернулись в начало.
Не совсем. На SSD «ленивое» построение дерева приведёт, скорее всего, к ускорению. В оперативке — вряд ли. Но в случае, если человек считает, что произвольный доступ не стоит ничего и не учитывает того, что он, в общем-то, не так далёк от скорости работы сети… не поможет ничего!
0
Ну вот точно так же вы её лениво добавите, когда дело дойдёт до неё, и с DOM. Я перестал понимать ваше изначальное возражение о ссылках вперёд.
0
Я пытался объяснить, что вы используете сложный компонент с неизвестной внутренней логикой вместо быстрого и простого как полено, и при этом всё равно вынуждены использовать его как простой потому, как иначе не получится. Ну не смог и ладно…
0
А зачем парсеру знать структуру? Парсер — это синтаксис, структура — это семантика конкретных элементов.

Парсер же возвращает АСТ (ну, условно, в общем АСТ может быть произвольным графом, а не деревом)? АСТ — это и есть структура документа, разве нет?

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

В лиспе АСТ является произвольным графом.

0

Штука в том, что ридер-макросы не являются токенами, и в них вы можете производить произвольного вида вычисления. Например — взять кусок АСТ и замкнуть его самого на себя:
для
#1=(yoba . #1#)
получится бесконечный АСТ '(yoba yoba yoba yoba yoba ....)
можно сделать такой цикличный АСТ, отдать на евал и он повиснет, например, ну или построить граф любого вида.

0
Может быть и никак.
С чего вы взяли что оно ему надо было?
Он же не полную реализацию стандарта заваял. Полная реализация вообще никому не нужна, никогда.
0
Еще раз?) Давайте отвечу по-другому. Ему не нужная реализация полного дома. И вам не нужна) Она никому не нужна.
Человек отбросил лишнее, и алгоритмически оно у него полетело. При этом совместимость осталась.
В чем собственно проблема?

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

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

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

В итоге — вменяемых реализаций нет. Людей понимающих реализации тоже нет.
Что остается в сухом остатке, впрочем на самом деле в жидком? Правильно: только гавно.
0
Но для случаев кода дом не нужен полностью, должны быть другие реализации. И их должно быть много.

Так а почему вы их еще не написали? Идите и пишите, вместо того чтобы в комментах говно обсуждать.

0
Можно же просто написать свою. Я в начале этого года пытался писать свой браузер. Разбивку на токены и построение DOM реализовывал сам. И оно работает вполне шустро (правда, на очень больших файлах пока не тестил)
0
Да чтоб я помнил, какой я библиотекой пользовался из тучи.

Мог быть просто завязанный узел, могло вообще не быть и делегировано на уровень выше (ну как в дереве тут).
0
Хм, библиотеку не помните, но уверены, что она обеспечивала O(1) по памяти? Звучит правдоподобно.
0
А вы помните все применённые вами библиотеки, языковые возможности и тому подобное в каждом нетривиальном случае 5-7 лет назад?

Достаточно помнить своё удивление, в конце концов, что ты просто написал код с DOM-стилем беготни по дереву, а он просто за счёт ленивости скомпилировался в O(1).
+2
Нелюблю аппл, но помню как хлопал в ладоши при подключении к клиенту пирса (файлообменник в Новосибе) с маковского Леонардо (или как-там) клиента, который сначала подключался, показывал чатик и позволял уже формировать запросы на поиск файлов, а в фоне отрисовывал всю чепуху с 30к пользователей онлайн… На старом компе под виндовым DC++ это занимало минуту, на новом — секунд 15… Даже оптимизировать ничего не надо, просто ненужную задачу выбросили в фон и нехай там хоть по 5 минут думает.
+2

Или снимаешь галочку отображения списка клиентов в виндовом DC клиенте и получаешь тот же результат. При количестве пользователей в десятки тысяч этот список все равно смысла не имеет. Это не местечковый хаб с чатиком из начала 2000х, не нужен там этот список, там большая часть не люди, а приставки к ТВ.
Я ещё и чат отключал. Запуск приложения и подключение к хабу — секунда, ну может две.

0
А в vscode как на этом же файле? Это ведь vscode сейчас как раз модно и молодежно.
0
Лучше чем Sublime (возможно от версии зависит). У меня саблим долго грузил и падал на файле 131МБ, а vscode свободно открыл (предупредил о возможных тормозах и предложил отключить подсветку, я не стал этого делать и так норм работает, только памяти выжирает не мало) и в отличие от n++ сворачивал и разворачивал огромные ветки/узды без особых тормозов (в n++ они были минутами).
0
Невероятно, но факт. МС 20 лет (!), начиная с Windows 98 заявляет, что-де «переписали большую часть кода с нуля на ассемблере» и т.д. и т.п. Но с каждым разом «переписанная» система становится всё больше, а детские глюки как были, так и остаются.
0
Невероятно, но факт. МС 20 лет (!), начиная с Windows 98 заявляет, что-де «переписали большую часть кода с нуля на ассемблере» и т.д. и т.п.
Где? Я хочу почитать про такое.
0
никогда они такого не говорили.
9x до самого своего упора, до ME, была допиленной 95 виндой на которую в 98 накатили IE4… да и закопали её потому что «переписывать» было себе дороже
0
Ну, я и сам так считаю и спорить не буду. Но точно помню слова про переписанный код, ассемблер, рост производительности и всё такое.
+9
нет не 1$, а блин 1$ + стоимость нового телефона за XYZKRE фантиков, потому что на старом это не работает.
+3

Именно так. Лично мне пришлось пару лет назад купить новый телефон, потому, что полностью устраивающий меня galaxy s2 открывал сообщение в скайпе за 30 секунд. К слову, прямо сейчас при наборе этого сообщения и пришедший ему на смену s6 подтормаживает. Неужто разрабы хабра тоже вирусом поражены?

0
1000 комментов, каждый в среднем по 300 символов. Сколько это? 300 килобайт?
0
Килобайты особо непричём, скорее дело в количестве Dom нод и т. п.
0
Способ повесить ваш Chrome на минуту-полторы, если у вас x86:

1. Нажмите на этой странице Ctrl+U
2. Нажмите Ctrl+A на открывшейся вкладке
3. Кликните по выделенному тексту правой кнопкой мыши в любом месте
4. <>
5. <>
6. <>
7. Снимайте процесс, если надоело ждать.
0
У меня Firefox и он не подвесился, хотя реагировал не сразу (сотни миллисекунд).
0
Надо проверить, интересно. У меня в Chrome 45 всё встало «колом» :)
0

Прошло полгода — спустя минуту исходный код страницы так и не открылся...

0
Хм, а давайте устроим перекличка, насколько браузеры вообще с этой статьей справляются спустя столько времени?
Мозила (66.0.5 х64) — норм, хоть и подлагивает.
0
Мозилла той же версии — нормально, и даже подлагивает почти незаметно. Исходник открывал полминуты, после чего появились первые 240 строк, после чего остаток открывался еще полминуты.
Вивальди 2.5.1525.43 (64-bit)
Примерно так же. Единственно, исходник открывал почти минуту, зато открыл сразу полный текст.
Palemoon 28.5 x64
Конкретные лаги и фризы, до десяти секунд, на протяжении всех пяти минут проверки. Исходный код открыл очень быстро, секунд за десять, но догружал до полного все ту же минуту.
IE11 приятно поразил почти полным отсутствием лагов при прокрутке после загрузки страницы. Но дальше…
Дальше начались сначала фризы при вызове контекстного меню, потом попытку открыть исходный код после пятиминутного ожидания пришлось прерывать снятием задачи в таскменеджере, потом и окно браузера со страницей пришлось убивать через таскменеджер, поскольку никакой вменяемой реакции добиться уже не получалось.

Вердикт: за Palemoon обидно.
0
У хабра вроде есть приложение, где (наверное) можно хорошо оптимизировать отображение только нужной информации, для плавности.
+21
А кто сказал, что сделать хорошее, быстрое и надежное приложение обязательно очень долго и очень дорого?
Вот тот же Web. Да, если каждый раз с нуля переписывать все эти библиотеки и фреймворки, то конечно. Только нужны ли они на 99% сайтов? Веб — это информация, текст, таблицы, картинки. Для этого всего вообще не нужен ни js, ни всякие библиотеки/фреймворки. уберите бессмысленное и бесполезное украшательство — и веб начнет летать на самых убогих компьютерах.
А там, где они нужны, как правило, хватило бы ресурсов и для написания «с нуля». Но незачем, ибо пипл и так хавает.
+35
обычно люди которые так говорят, не занимались веб разработкой. Такие иллюзии достаточно быстро ломаются об реальность на больших проектах.
+2
Реальность состоит в том, что никто не хочет и не будет переделывать всё с нуля на больших проектах даже если это спасёт планету от метеорита. Ещё реальность состоит в том, что с первого раза может получиться только случайно, а в большом проекте — никогда.
+1
Ну, почему. Иногда переделывают. Это занимает от нескольких месяцев до нескольких лет, в зависимости от сложности и количества разработчиков. Скажем, потому что поддерживать сайт на XSLT и других древних технологиях уже нет смысла — проще переписать. Естественно, не обходится без багов (никто не совершенен), а к моменту что-то неизбежно уже устареет.
0
Причем тут «хочет, не хочет».
Кто за это платит? По своему желанию переделываются только пет-проекты.
В случае больших проектов, переделать все это далеко не копейки.
+15
Я никогда не работал в больших корпорациях, поэтому хотелось бы узнать, почему, например, когда я открываю Facebook.com как неавторизованный пользователь, страница занимает 6.16 MB и браузер отправляет 65 запросов? Наверное, дело в том, что форма регистрации использует AJAX-запросы и там всё «очень сложно»?! Ну, достаточно открыть страницу авторизации с «обычной» формой и полюбоваться «оптимизацией» — 3.75 MB и 37 запросов. Также, например, «оптимизирована» и главная страница Twitter.com — никаких форм с AJAX-запросами, однако размеры страницы составляет 2.41 MB, и браузер отправляет 18 запросов.

Забавно, что даже при редактировании файла на Github.com страница весит
лишь 1.63 MB (а там ведь подсветка кода, AJAX-запросы, живой поиск, предпросмотр, и другие полезные функции).
+18

«Вы ничего не понимаете, веб-программирование — это крайне очень супер сложно и вообще сперва добейся (закончи месячные курсы фулл-стека на пайтоне)».

+3
Представьте сколько аналитики, поведенческих метрик и рекламы с вас собирают facebook и twitter.
Ну и конкретно на facebook большинство запросов это статика. Как прикажите картинки то грузить?
+18
На странице авторизации Facebook загружаются 6 картинок: два спрайта и 4 однопиксельных изображений. Общий размер картинок: 33.76 килобайт, когда страница занимает 3.75 мегабайт и это только для того чтобы отображать форму с двумя полями и одной кнопкой.

Насчёт аналитики — даже Google Analytics и Яндекс.Метрика с Вебвизором вместе взятых не занимают больше 250 KB. Тут проблема не в аналитике, а в том, что разработчики банально не используют условные загрузки. По моему мнению, незачем загружать стили/скрипты комментариев, чата, списка друзей, редактирование профиля и других функций недоступны неавторизованных пользователей. Но, возможно это лишь мои иллюзии, ведь я не работал в крупных корпорациях.
0
Ну как же зачем?! Прогреть кэши перед входом пользователя на основной сайт, а не форму авторизации. Да, на одну страницу это слишком жирно, но зато после авторизации пользователь уже не будет ждать пока все скрипты загрузятся, особенно с медленным инетом, а сразу начнет поглощать контент.
+3
А Вы точно веб-разработчик? Даже если Вы правы насчёт этой теории, это, мягко говоря, неправильно. Не говоря уже о том, что после авторизации, страница «нагревается» до 42 MB.
Заголовок спойлера

0
Почему это неправильно? Если для ФБ ценны в первую очередь те, кто пойдет авторизироваться или регистрироваться, то логично сделать удобнее именно им.

А то, что там после загрузки еще больше, ни о чем не говорит. Вполне вероятно, что на странице логика грузятся только те библиотеки, которые делают изначальное отображение интерфейса и общие для всех пользователей. А после авторизации уже происходит фактические наполнение данными, но пользователь сразу видит уже какой-то каркас интерфейса.
-1
Если пользователь РЕШИЛ зарегестрироваться, то его не остановят мегабайты первой странички. Может, в первый раз отпугнёт и он передумает но через день-два-неделю он обязательно вернётся и зарегистрируется.
К сожалению, сам на мобильном интернете очень многих постов и картинок просто не увидел — тупо не дождался их загрузки, дольше 10 секунд загрузки — это уже бесполезная трата времени и вещь уходит куда-то далеко в бесконечную ленту событий, возврат к которой в будущем маловероятен.
+2
Неправильно, по крайней мере потому, что нужно уважать пользователей и помнить, что не у всех топовые устройства и высокоскоростной + безлимитный интернет. Правильно, когда нужное загружается «при необходимости», а не по принципу «а вдруг пользователь захочет каждую минуту загрузить новый аватар, редактировать профиль, отправить сотни эмодзи в чате, сделать селфи, и многое другое, причём всё сразу».

Вы предполагаете, что разработчики заранее кэшируют данные, а я не думаю, что они отличаются от тех, кто подключают jQuery на всех страницах сайтах, когда данная библиотека будет использована только на странице контактов, и то, чтобы анимировать одну кнопку, если пользователь открыл страницу 29 февраля в полночь. Во-первых, если бы они заботились об активных пользователях, они бы использовали условные загрузки по крайне мере после авторизации. Во-вторых, они подключают мегабайтные скрипты на всех страницах. В-третьих, пару мегабайт до авторизации лишь «цветочки» по сравнению, с тем, что происходит после. Если бы Вы проверили Вашу «теорию» о кэшировании, то заметили бы, что после авторизации сайт совсем «не летает», даже если все скрипты загружаются из кэша. Он и не будет, ведь это не SPA, и мегабайтные скрипты выполняются каждый раз, когда пользователь переходит на другую страницу.

Facebook и Twitter лишь примеры, но они далеко не единственные кто не допускают, что пользователь не будет использовать даже 10% функционала. Посмотрите, сколько ненужных стилей, скриптов и медиа файлов загружаются на веб-сайтах; какие права требуют простые приложения; какие спецэффекты используются, дабы рассказать какие «мы современные»; сколько шрифтов подключаются лишь, чтобы «показать красивое название сайта». Практически все с каждым днём «улучшают» свои программы и сайты, но, к сожалению, это происходит только в пресс-релизах.

Напоследок, хотелось бы напомнить, что даже js-файл размером в 1 MB это довольно много для сайта, где пользователи пишут и читают обычные посты. И, тем не менее, Вы хотите оправдать разработчиков, которые подключают десятки мегабайт JavaScript. Боюсь, я не могу согласиться с Вами, поэтому, прошу Вас, не вздумайте переходить на сторону зла!
0
Я напомню, что Фейсбук непосредственно заинтересован, чтобы им пользовалось как можно больше людей и не будет специально делать так, чтобы ухудшить динамику регистраций или логинов.
Еще напомню, что эта компания стоит сотни миллиардов и каждый день ее сервисом пользуется больше миллиарда человек и этого бы не было, если бы они разгильдяйски относились к таким важным элементам, как главная страница сайта.

С вашей стороны очень самонадеянно считать что вы знаете лучше, как надо делать и что решение сделать именно такой механизм работы страницы авторизации у Фейсбука продиктован ленью или некомпетентностью разработчиков.

У них есть огромное количество данных о том, что происходит на сервисе на каждом этапе его работы, данные о сотнях миллионах пользователей (если говорить о веб версии). Равно как и есть возможность протестировать и сравнить множество альтернативных вариантов.

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

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

Но сервис вполне логично ставит интересы таких посетителей ниже тех, кто авторизацию пройдет.
+4
Еще напомню, что эта компания стоит сотни миллиардов и каждый день ее сервисом пользуется больше миллиарда человек и этого бы не было, если бы они разгильдяйски относились к таким важным элементам, как главная страница сайта.

Наивное утверждение. Сервис настолько огромен и популярен, что у существующих пользователей просто-напросто нет выбора (нет аналогов, куда перейти, ведь все друзья в сидят в фейсбуке). А с новыми пользователями то же самое — в мелкую соцсеть типа MySpace идти нет смысла, так как там почти никого нет.

А если вы почитаете, что люди пишут про скорость работы (что веб версии, что мобильного приложения в том же Google Play), то вы увидите, что негативных отзывов гораздо больше, чем позитивных (я правда читал только русскоязычные комментарии, но можно начать хотя бы с России как частного случая). Вы только вспомните: мобильное приложение фейсбука стало настолько тяжёлым, что из него выпилили мессенджер и выпустили отдельным приложением! А потом ещё выпустили Facebook Lite, к слову…
0
Хотелось бы добавить, что лично я не считаю, что огромное количество денег и пользователей это показатель профессионализма. Скорее это говорит о том, что они хорошие бизнесмены и маркетологи.

Действительно, сверхпопулярные компании могут позволить себе очень многое. И если они изначально работают над привлечением новых пользователей, то став популярными, чаще всего в первую очередь они думают, как извлечь максимальную прибыль. Как монополисты они уверены, что пользователи никуда не убегут, а значит, они могут творить любую дичь. Правда, некоторые из них (например, IE, ICQ, MySpace, Yahoo) поплатились за это.
0
А что в своё время натворил MySpace? Я туда заходил 2-3 года назад и был в полном восторге — и от дизайна, и от того, насколько сайт был шустрым и минималистичным.
+2
Это сейчас он «шустрый и реалистичный». Потому что у разработчиков нет ресурсов, чтобы рюшечек навешать. А когда Facebook «взлетел» примерно 10 лет назад — всё было наоборот.

Дорога ложка к обеду. Очень хороший пример тут — OS/2 и Windows. Когда в 1992м вышла OS/2, которая требовала 8MB, а на 4MB еле «шевелилась», то народ выбрал вышедшую тогда же Windows 3.1, которая сносно работала на 1MB, а на 2MB «летала». IBM вложила кучу ресурсов и в 1994м выпустил OS/2 Warp, которая более-менее работала на 2MB, а на 4MB — так вообще хорошо. Про неё начали потихоньку говорить, но через полгода — вышла Windows 95, которая требовала уже 4MB, а для приличной работы — 8MB… казалось бы должен был быть провал? Но нет: за 3 года ситуация с памятью изменилась и те 8MB, которые в 1992м казались чем-то запредельным в 1995м уже перешли в категорию «дорого, но терпимо»… а зато у Windows95 была куча программ, которых у OS/2 не было…
+1
Я напомню, что Фейсбук непосредственно заинтересован, чтобы им пользовалось как можно больше людей и не будет специально делать так, чтобы ухудшить динамику регистраций или логинов.
Еще напомню, что эта компания стоит сотни миллиардов и каждый день ее сервисом пользуется больше миллиарда человек и этого бы не было, если бы они разгильдяйски относились к таким важным элементам, как главная страница сайта.

Я не встречал ни одного человека, который бы сказал что ему нравится дизайн и функциональность фейсбука. Ни в России, ни в Европе. Пользуются им все просто потому что им уже пользуются все и чтобы с него уйти нужно, во-первых, найти куда, а так как все пользуются ФБ, то адекватно развитого ничего и нет, во-вторых, переманить туда всех нужных знакомых, что тоже титанический труд, человеку проще ничего не менять и плеваться чем напрягать мозг и совершать какие-то действия, а в-третьих, нужно придумать что делать с новыми знакомыми и всякими группами которые тоже будут по умолчанию в ФБ. Так что пока этим поделием в принципе можно будет пользоваться — им будут пользоваться все. Это никак не говорит о том что они знают что делают. Более того я знаю больше одного человека, которые из-за всего этого бреда в ФБ отказались от него несмотря на все перечисленные пункты.
+1
На самом деле вы оба правы. Facebook, конечно, знает что делает, но… не сегодняшний Facebook. Хочу напомнить, что Facebook — далеко не первая социальная сеть, до него были MySpace, Orkut и другие. А знаете что с ними произошло? Их обошёл маленький и шустрый (в те времена) Facebook. А потом… потом менеджеры в Facebook выяснили что «рюшечки» привлекают пользователей! Процесс идёт по накатанной схеме. В результате в какой-то момент вы имеете кучу пользователей, которых привлекли на начальном этапе (и ненавидящих современный Facebook), пользователей которых «зачинатели» привели и тех, кто фанатеет от рюшечек и кому пофигу что они тормозят. Тут вы имеете максимальную капитализацию, аудиторию и прочее. Но эта ситуация неустойчива: в какой-то момент, после очередного раунда «добавления рюшечек» всё начинает тормозить настолько, что люди начинают уходить. И если этого не осознать и добавить «рюшечек» ещё — то всё начнёт рассыпаться: вначале уйдут первые (ценившие скорость), потом вторые (так как ушли первые), а потом и ценившие «рюшечки» не захотят в «пустом доме» жить. Но Facebook'у пока удаётся балансировать «на грани»: периодически он всё-таки занимается оптимизацией своих страниц, в результате такого коллапса, как, скажем, у Orkut'а не происходит.
-1
Позвольте сообщить, что супер-профессионалы из супер-прибыльной компании не оправдывали Ваши слова: habr.com/ru/post/444766
-2
Крупные корпорации это всегда бюрократия. Не исключено, что какие-нибудь маркетологи решили, что именно страница логина должна принять на себя удар по перфомансу и сразу подгрузить всё, что нужно юзеру, чтобы после логина он на доли секунды быстрее увидел свою вожделенную ленту новостей.
0
Можно ещё вспомнить «модемные» времена и Мейл.ру, чья страничка весила килобайт 50. И при этом работала, письма писались, отправлялись. Понятно, что сейчас там и форматирование и всякая живая загрузка. Но, страница выросла мегабайт до 5, если не больше, то раз в 100. Но удобство (как ни измеряй;) и скорость в 100 раз не выросли.
+1
Че-то вы загнули… 1.1МБ на странице авторизации ФБ
Заголовок спойлера
image
0
Chrome показывает размер сжатых данных. Активируйте «Use large request rows», чтобы увидеть реальный размер.

Заголовок спойлера

+1
А зачем оценивать «разжатые» данные?
Это подмена понятий, ваш изначальный комментарий негодовал о:
почему, например, когда я открываю Facebook.com как неавторизованный пользователь, страница занимает 6.16 MB и браузер отправляет 65 запросов


Вам эти данные приходят в сжатом виде и весят никак не 6 с лишним мегов.
1МБ нa страничку, учитывая шрифты/иконки/картинки — это более менее.
Нa мобильной версии приходит около 300кб нa всю страницу.

Так что не сгущайте краски.
+7
Ну так «занимает» же, а не «качается». И эти мегабайты яваскрипта еще надо распарсить и выполнить.
0
Вот именно, HTML/JS/CSS еще парсится и интерпретируется. Результат займет в памяти еще больше места.

Цифра в 6 мегабайт не характеризует ничего, в отличие от сжатого размера, который реально передавался по каналу пользователю.
0
Для пользователей с широким каналом от этого ни холодно ни жарко, сжатие разве что помогает разгрузить магистральные каналы. Имеет значение именно не сжатые данные, они ведь занимают реальную память. А интернет-канал это дело вторичное, и количество трафика играет роль только при жестких ограничений на сеть — мобильные сети и т.п. таким образом сжатие играет вторичную роль, решая только одну проблему из множества.
0
> Имеет значение именно не сжатые данные, они ведь занимают реальную память.

Это нет так. Реальную память занимает *результат* исполнения кода, а не исходный текст. Короткий код может легко занять много памяти, достаточно насоздавать много объектов в цикле.
+1
Если это делает ДАЖЕ короткий код, сложно представить на что способно большое количество кода.
0
На самом деле, как ни странно, сложно. В частности в одной из программ, в которой я переделал один модуль, сложную систему объектов была заменена на заранее просчитанную таблицу. Модуль на 200K стал модулем на 1M, но зато таблица на пару мегабайт перестала строиться при запуске — что улучшило время запуска (сильно), скорость работы (заметно), и потребляемую память (вдвое). Уменьшился даже запакованный образ дистрибутива, пострадало только место на диске (но это для нас был самый некритичный параметр).
+1
> сложно представить на что способно большое количество кода

Еще как сложно! Там могут быть оптимизации, ленивые вычисления, которые сэкономят память.

Гадать о производительности кода по его размеру — такое себе занятие. Именно поэтому размер сжатого кода еще имеет какое-то значение, то разжатого – цифра ни с чем ни связанная.
+4
Вы думаете, что все пользователи получают данные в сжатом виде? Или, что сжатие даётся пользователям даром и мегабайты хлама никак не влияют на производительность?
0
Вы думаете, что все пользователи получают данные в сжатом виде?

У 99% браузеры поддерживают сжатие.

Или, что сжатие даётся пользователям даром

Да, почти даром.

мегабайты хлама никак не влияют на производительность

Вот это ужe под вопросом. Возможно, как написали выше, они грузят что-то заранее, чтобы потом нe «лагало» и нe погружало ничего.
+2
Даже если разжатие не сильно нагружает процессор (скорее всего, это так), память всё-таки критична. Например, у меня в телефоне браузер крашится, если веб-страница пытается съесть больше 12-13 мегабайт (с учётом графики, шрифтов и всего-всего). А тут в мобильной версии сколько, говорите, после разжатия будет? Уже мегабайта 2-3, а это ещё без фотографий и текстов. А когда пользователь залогинится — тогда самый трэш и начнётся. Там ещё и доп. стили и скрипты прилетят, и реклама с логикой её показа.
-2
Например, у меня в телефоне браузер крашится, если веб-страница пытается съесть больше 12-13 мегабайт

Он крашится если вкладка загружает больше 13 мегабайт? Чего? Диска или памяти?
Одни фотки сейчас весят по 2-3, если не больше. Может вам надо обновить телефон?
0
А не поздно писать обличающие статьи, если потребители уже считают происходящее нормой?..
+1
Зря вас заминусовали. Да, телефон надо обновить, вы правы. Эта модель вышла летом 2011-ого. Но парадокс в том, что вплоть до весны-лета 2013-ого года всё работало более-менее сносно (в 2012-ом так вообще летало). Вы полагаете, тогда фотки весили сильно меньше? За счёт чего?

Оффтопик
Первый сайт, на котором я испытал вылет — сайт сети кинотеатров «Формула Кино»… Оказалось, что проблема была в том, что они встроили на сайт видео трейлеров к фильмам. И они, даже не запускаясь, крашили браузер на середине загрузки страницы, если не нажать «стоп». Это было ещё году в 13-ом. Сейчас вылетает вообще на 90 процентах сайтов (исключая мобильную версию вк, форумы типа 4pda и ещё несколько хорошо оптимизированных под мобильные телефоны порталов).

Краш скорее всего был по оперативной памяти. Наверное, не на 15 мегабайтах, а на 40-50 (это вроде предел для одного приложения в Андроид 2.3), при доступных 150 мегебайтах всего на все приложения в сумме. Это число я написал по ошибке, перепутал с размером кэша после вылета.
0
FB скорее всего так делает, чтобы заранее прогрузить в кэш или даже запустить выполнение тех скриптов, которые потребуются после авторизации.

Видимо, посчитали что лучше пусть у тех, кто просто открыл и не авторизировался, делались лишние запросы, чем заставлять дополнительно ждать загрузки тех, кто таки авторизировался с этой страницы.
0
Полагаю потому что строчить блог посты и хайпиться другими способами, и решать реальные задачи это разные вещи.
+2
Я много имел дело с реалиями вебразработки, но все же пикрелейтед — это дно.

На пике первая загрузка гмейла в последней лисе.
-3
Но ведь это не вина гугла, что в Firefox не реализовали ShadowDOM v0 (точнее, пытались, но он пока страшно далёк от завершения, а пока реализовывали, сама спецификация v0 стала deprecated, так что силы брошены на ShadowDOM v1).
+12
Но ведь это не вина гугла, что в Firefox не реализовали ShadowDOM v0

Embrace, Extend, Extinguish нового поколения.
+6
Это либо вина либо менеджмента гугла в плохой поддержке браузеров с 10% рынка суммарно, либо разрабов которые пишут код на плохо полифилящихся технологиях, которые только один браузер поддерживает, либо и тех, и других.
А разгадка проста — из-за сильной интеграции с другими сервисами гугла, в первую очередь с андроидом, гмейлом пользуются все и писать они могут практически любой говнокод. Сравните даже хотя бы с яндексовой почтой.
UFO landed and left these words here
+5
Во-вторых, гугл тем самым форсирует более быструю имплементацию стандартов у всех.

Используя устаревшую версию стандарта? Согласен с первым утверждением, но второе не верно.
+4
Да не стояло там ничего на месте. Во-первых, была прекрасная и весьма шустрая Опера (2004-2008 если берём). Во-вторых, Firefox был не так уж плох (хотя и медленней, но не медленней, чем IE, а ещё намного безопаснее и функциональнее). Так что конкуренты не просто были, они развивались. И IE тоже развивался. Вспомните 5.5 в Win2k, и сравните с 7.0 и 8.0. Совсем разные вещи
UFO landed and left these words here
+2
Почему это был не его изобретатель

Изобретатель чего, AJAX?

Расскажите, это всё очень интересно. Мне тогда и в самом деле было 10-15 лет, и разработкой я тогда ещё не занимался, только читал книжки (года так с 2005-2006).

на ряду с полным месивом в поддержке существующих

Имхо, не было там особого месива. У меня до сих пор стоит учебник по JavaScript 2004 года издания на полке. Так вот, 60-70 процентов вещей, которые там описаны — кроссбраузерны на сто процентов (да-да, тот самый ES3). Остальное — в двух вариантах, для IE и для Firefox. Opera же, заняв очень мудрую позицию, часто поддерживала оба варианта (окей, не оба, почти всегда вариант IE; но начиная с момента, когда появился Хром, а в Хроме и Firefox подходы были более близки к друг другу и к стандарту — ситуация поменялась, и Opera стала делать как Chrome и Firefox, а синтаксис IE иногда поддерживался в придачу, «для совместимости» — как пример, свойство document.all, которого кроме IE нигде больше не было, а в Opera до версии 11.50 оно всё ещё работало).
+1

Месиво всё-таки было и именно благодаря ему обрели популярность Prototype, MooTools и jQuery. Они брали на себя большую часть боли по поддержке особенностей браузеров. Отдельной историей было ещё и месиво с реализациями CSS.

0
А что именно было с реализациями криво? Про CSS тех лет я почти ничего не знаю. Ну то есть знаю поведение IE7-8, немного — IE6 (тестил на нём один свой проект ради спортивного интереса). Остальное мимо меня прошло.
0
Больше всего запомнилось, что размеры блока разные браузеры по разному понимали. Современным языком говоря было разное значение box-sizing и управлять им нельзя было. А pixel perfect тогда было обычным требованием, буквально принимали вёрстку диффом скриншота и макета
UFO landed and left these words here
+2

В лидеры Хром выбился благодаря монопольному положению Гугла на рынке поиска и агрессивному маркетингу.

UFO landed and left these words here
+4
Хром на момент появления и в последствии действительно превосходил все, что было.

Не во всём и не для всех. У него как был дубовый, не настраиваемый интерфейс, так и остался.
-1
значит они вовремя поняли, что интерфейс должен быть не настраиваемым, пошли так сказать по пути Эппла
0
Просто большинству плевать, а на меньшинство плевать большинству.
0
эээ… дефолтный интерфейс должен быть удобным… а все эти " в новой версии мы вам дадим мильон новых тем" вызывают тяжелый вздох…
+6
Вопрос — а нафига он вообще нужен? Без него интерфейс просмотра писем не сделать?
0
Конечно не сделать. А SquirrelMail вообще никогда не существовало.
+12
Для того, чтобы судить о вкусе блюд, необязательно быть поваром.
И не надо про эти ваши «большие проекты». Реальность в том, что именно «большие проекты» в большинстве случаев нафиг не нужны, их лепят вместо простых сайтов с текстом и картинками потому что это «стильно, модно, молодежно», а не потому что необходимо.
+3
а не потому что необходимо.

Если бы это не было необходимым, то простые сайты с текстом и картинками выигрывали бы в конкурентной борьбе, но мы наблюдаем обратную ситуацию — выигрывают те самые "большие проекты".


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


Можете себе свой гипертекстовый фидонет замутить и там делать свои страницы с простым текстом и картинками. В вебе поезд ушел.

+5
Если бы это не было необходимым, то простые сайты с текстом и картинками выигрывали бы в конкурентной борьбе

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

Так этих сайтов нет, потому что они проиграли конкурентную борьбу.


А одной скорости для выигрыша в борьбе мало.

Ну вот видите, вы сами ответили. Производительность должна быть достаточной, прирост производительности выше чем нужно — уже не дает никакой пользы. И если клиента устраивает производительность на уровне 1% от возможной, то ПО работающее на уровне этого 1% будет иметь конкурентное преимущество над тем, что работает на уровне 90%. Потому что пользователю на эту разницу плевать, а вот затраты на разработку — возрастут.

+4
Так этих сайтов нет, потому что они проиграли конкурентную борьбу.

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

Нет, просто вы меня поняли так, как хотели понять.
Дело не в том, что если сайт грузится за 10 секунд, то это нормально и быстрее не надо. Дело в том, что между сайтом за 10 секунд с хорошим контентом и сайтом за 1 секунду с плохим любой нормальный человек выберет первое. Зато между сайтами с хорошим контентом но загрузкой в 10 и 1 секунду — второе. Это не та разница, на которую можно наплевать.
И дело, кстати, не только в загрузке, но и в последующем скроллинге и т.п.
0
Зато между сайтами с хорошим контентом но загрузкой в 10 и 1 секунду — второе.

Если бы это было так — мы бы видели в топе сайты с хорошим контентом и загрузкой в секунду. Но это не так.


а потому что современные монстры раньше были нормальными легкими и быстрыми сайтами

Но их потом взяли и специально сделали ненормальными, тяжелыми и медленными? Зачем? Заговор рептилоидов?
Я серьезно спрашиваю. Как вы объясняете этот парадокс?

0
Я бы объяснил чрезмерным переусложнением логики с одной стороны (но усложнение нужно и порой неизбежно), тем, что мониторы стали больше и графика потяжелела, плюс стало больше видеоконтента и анимаций — с другой (в этом тоже есть плюс, ибо красиво и людям нравится), и с третьей стороны — большой ленью разработчиков, которые часто вместо того, чтобы закодить что-то самостоятельно, тянут сторонний фреймворк, половина возможностей которого им вообще не понадобится (может быть понадобится в перспективе, но не сегодня и даже не завтра). А во фреймворке ещё куча своих подкомпонентов. А фреймворков на крупных сайтах часто 2-3. Плюс на больших сайтах бэкенд тоже обычно отвечает далеко не молниеносно (взять тот же Twitch). Плюс объём пересылаемых на сервер и обратно данных, который растёт как минимум линейно вместе с усложнением логики.

Избежать всего этого можно — если делать простые и не очень красивые сервисы с небольшим количеством функций. «Дёшево и сердито». Но на такое меньше спрос, людям это уже приелось, им чего-то нового хочется. А за новое порой приходится платить тормозами, увеличившимся трафиком, необходимостью обновлять браузер и даже ОС…
+1
Тем, что модно и тем, что можно (в смысле «гляди, как мы могЁм»). Туда же и регулярные редизайны.
И не надо говорить, что «компании все просчитывают перед тем как сделать». Ярчайший пример эпик фейла — Кинопоиск 2.0. Просто если изменения не такие резкие, то пользователи просто потихоньку привыкают, но это вовсе не значит, что они в восторге от всего этого.
0
Тем, что модно и тем, что можно (в смысле «гляди, как мы могЁм»). Туда же и регулярные редизайны.

Модно и можно кому? Вы же понимаете, что решение принимается не программистами? Зачем бизнес в это деньги вкладывает, если это ничего не дает?

0
Потому что бизнесу кажется (ключевой момент), что так будет лучше («патамушта какнкуренты так сделали, давай и мы сделаем»). Но «кажется» и «будет» — разные вещи.
+1
Потому что бизнесу кажется (ключевой момент), что так будет лучше («патамушта какнкуренты так сделали, давай и мы сделаем»). Но «кажется» и «будет» — разные вещи.

Почему-то успешным оказывается именно тот бизнес, которому так кажется. А которому не кажется — успешным не оказывается.
Видимо, "кажется" обоснованно, в итоге.

0
попытка ошибкой выжившего оправдать неверную логику?

При чем тут ошибка выжившего? И логика вполне верная.

0
Ну, тогда вы должны доказать непосредственную связь между кажется и успешным.
Потому что между успешным/неуспешным и кажется/не кажется могут любые пропорции быть.
Например, что большинство бизнеса, которому казалось — стало не успешным. Или что куча бизнеса, которому не казалось — стало успешным, после чего начало казаться.
А так, у вас есть условный успешный бизнес, которому сейчас что-то кажется. И он может в любой миг стать не успешным (яху, нокиа). И как они стали успешным? От того, что им казалось или нет? И сколько прочих бизнесов, которым казалось, не стали успешными
0

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

0
Еще раз — у нас, фактически, нет успешного бизнеса, которому не кажется (или есть, но это какие-то единичные и малоизвестные случаи).
Доказывайте.
Например, для начала докажите, что все те успешные бизнесы изначально были из тех, кому казалось. А не те, которым не казалось, а когда достигли успеха — стало казаться.
0
Доказывайте.

Зачем? Это очевидное для любого пользователя интернетов в 2018 наблюдение. С-но, именно это наблюдение стало причиной появления обсуждаемой статьи. И 2к комментов к ней. Вы сейчас будете придуриваться и делать вид, что всего этого нет? Ну если нет — то и обсуждать нечего, сайты быстрые, весят мало.


А не те, которым не казалось, а когда достигли успеха — стало казаться.

А какая разница, стало или было? Это совершенно несущественный фактор.

0
Почему-то успешным оказывается именно тот бизнес, которому так кажется. А которому не кажется — успешным не оказывается.
Видимо, «кажется» обоснованно, в итоге.
А какая разница, стало или было? Это совершенно несущественный фактор.

А давайте позовем дедушку КО?
Итак, если бизнес достиг не думая, сейчас сидя на достигнутом стал думать, то успех и думанье за — никак не связаны.
Более того, это совершенно не означает, что завтра эти думальщики не вылетят в трубу, а место их не займут другие. Которые тоже не думали, но достигнув вершины станут думать и… цикл замкнется.

На что я вам и указываю. Вы видите кого-то, кто сидит на вершине и СЕЙЧАС поступает так. Как это доказывает, что он именно так поступал, дабы там оказаться? Никак. Более того, вы не можете утверждать, что своим поведением сейчас он не шагает к пропасти. Потому что куча контор, которые сидели на троне многие годы, вдруг пролетали мимо поворота и вылетали. И как это зависит от думанья или нет — у вас нет фактов однозначных.
То, что на рынке любят культ карго — не секрет. Только это не означает, что его почитатели смогут полететь вверх.
-1
Итак, если бизнес достиг не думая, сейчас сидя на достигнутом стал думать, то успех и думанье за — никак не связаны.

Так никто и не говорит, что успех связан. Речь не о том.


Речь о том, что либо те, кто занимается успешным бизнесом — умные люди, и, с-но, если они считают правильным вешать на сайты свистоперделки, а Am0ralist не считает, то это потому, что они знают что-то такое, чего не знает Am0ralist.
Есть второй вариант — на самом деле отбор отрицательный, с-но условный Ларри Пейдж — тупой. Именно потому что он тупой, он и стал миллиардером (и остальные тоже). Из-за своей тупости он любит свистоперделки. А вот Am0ralist — он умный. По-этому он свистоперделки не любит, он знает, что все это просто каргокульт. И по той же причине миллионов Am0ralist не заработал — для этого надо быть тупым. Как Ларри.
Ну и третий вариант — все это просто такое большое совпадение.


Вариант по душе выбирайте уже сами.

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

Не говоря уже о том, что ваши рассуждения разбиваются о примеры Нокиа и Яху. Там тоже сидели умные люди, которые зарабатывали небось миллиарды. И которые с усмешкой посматривали на конкурентов, точно зная, что нужно потребителям.
Надеюсь пример вам будет понятен, так как общаться с людьми, которые любят переходить на подобную демагогию, когда стараются выставить собеседника идиотом сравнения умного и богатого Ларри с анонимным пользователем хабра — удовольствие ниже среднего
+1
Зачем бизнес в это деньги вкладывает, если это ничего не дает?
За 4 года Webmoney сделали редизайн, по-моему, 6 раз, или даже 7. Зачем — непонятно.
0
За 4 года Webmoney сделали редизайн, по-моему, 6 раз, или даже 7. Зачем — непонятно.
Не только Webmoney, но и много крупных банков и магазинов часто меняют дизайн. ИМХО это сильно раздражает постоянных клиентов, которые привыкли к прежнему. ИМХО многие начальники, принимающие решения, просто не знают основ психологии, а исполнителям нужно показывать свою необходимость делая ненужную работу.
0
ИМХО многие начальники, принимающие решения, просто не знают основ психологии
Они как раз либо знают, либо догадываются.

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

Я в курсе, что есть новые тренды. Но тут получается массовый «вирус» — 25-30 процентов сайтов делают редизайн (не обязательно самые крупные), они становятся «модными и современными», и остальным уже как-то неловко оставаться со старым — в частности, они боятся, что новые клиенты начнут не так охотно прибывать :)
0
Но новые появились бы и без смены дизайна, разве нет?
Статьи на Хабре и в других издания, шумиха в разных соцсетях и прочем. Ну а дальше — работает правило «не важно что о тебе говорят, лишь бы фамилию правильно называли».

Конечно тут важет факт редизайна, а не его тормоза, но… тут уж как получается…

Но тут получается массовый «вирус» — 25-30 процентов сайтов делают редизайн (не обязательно самые крупные), они становятся «модными и современными», и остальным уже как-то неловко оставаться со старым — в частности, они боятся, что новые клиенты начнут не так охотно прибывать :)
И они, к сожалению, правы. Мода тоже часто заставляет носить одежду, которая откровенно неудобно, а иногда и опасна для здоровья. Но ведь носят. Тоже самое и тут.

Но тут получается массовый «вирус» — 25-30 процентов сайтов делают редизайн (не обязательно самые крупные), они становятся «модными и современными», и остальным уже как-то неловко оставаться со старым — в частности, они боятся, что новые клиенты начнут не так охотно прибывать :)
И они, к сожалению, правы. Мода тоже часто заставляет носить одежду, которая откровенно неудобна, а иногда и опасна для здоровья. Но ведь носят. Тоже самое и тут.

Причём как раз некоторый парадокс в том, что айтишникам это очень тяжело понять, так как очень многие их них скорее готовы прослыть «немодными», тем мучиться с неудобной одеждой… но ведь людей, «следящих за модой» — куда больше.
0
Мода тоже часто заставляет носить одежду, которая откровенно неудобна, а иногда и опасна для здоровья.
ИМХО с модой сложнее см. Википедию:
Сегментами рынка модной индустрии являются категории, на которые подразделены различные марки и бренды, в зависимости от своих параметров — качества изделий, способа выпуска коллекций и ценовой политики производителя
Есть «Высокая мода», «Средний ценовой сегмент», «Массовые марки». В свою очередь в них есть под-сегменты.
0
Просто у них нет задачи понравится всем и каждому.
Не всем и каждому, а удержать постоянных клиентов. Нпр., если клиенты массово забирают вклады из банка — он может рухнуть.
И если старые пользователи ворчат, но не уходят,
Обычно уходят. В развитой экономике есть большой выбор. И внутри одной структуры часто бывает выбор. Нпр., операции по банковскому счету можно делать он-лайн, а можно в отделении. Если клиентам неудобно он-лайн, они будут использовать отделения банка загружая работников, а эффективность сайта упадет. Многие магазины торгуют не только по сети. Будет больше покупок вживую, больше заказов по телефону, а прибыль через сайт упадет.
0
Недавно АкБарс Банк замутил редизайн интернет-банка. Был довольно простой и кондовый как топор. Стал весь такой плоско-модный, с ненужными анимациями, блеклыми надписями, странными мелкими размерами шрифта (и как ни странно, чем важнее информация, тем мельче) и как следствие огромными пространствами между строками. Тихий ужас. К счастью, сделали кнопочку «Старый дизайн», но наверно скоро уберут.
+1
Потому что нет бизнеса как принимающей решения сущности, есть конкретные люди, и чем компания больше, тем больше этот разрыв.

Конкретный манагер просто хочет выслужиться и иметь красивые слова для написания в отчётах, манагер этого манагера — 50-летний чувак, которому вообще уже на всё плевать, дайте до пенсии доработать, ну и так далее.
0
В развитой экономике при достаточной конкуренции малая и средняя фирмы не выживут при плохих решениях. К сожалению, большие компании, которые почти монополисты, могут позволить себе значительные убытки от неоптимальных решений.
0
С другой стороны, компании, которые почти монополисты, могут позволить себе инвестировать в фундаментальный ресёрч. А это уже совсем не к сожалению.

И если государство не начинает бегать и спасать монополии, о которых говорите вы, то в монополизации с таковым исходом я особо ничего плохого не вижу.
0
Встречал в литературе мнения, что ОС Dr DOS была в свое время лучше, чем MS DOS, что C++ не стал бы столь популярным, если бы MS Pascal не сильно уступал турбо паскалю и VBA бы не было. IE был не лучший браузер. MacOS 7.x сильно превосходила W-95 и W-98, но тут в случившемся кризисе виновата прежде всего Apple Computer, Inc… Нпр., ценовой политикой: мышь для мака стоила целых $60US, в то время как мышь для РС только 8.
0
PS Слышал мнения, что большой успех Явы был обусловлен мощным PR, а не только достоинствами. Однако, все подобные утверждения непроверяемы: история не имеет сослагательного наклонения.
0
Попробую ответить на ваш вопрос. Причин тут несколько:
1) решение «добавить вот эту рюшечку» обычно принимается не программистом, а каким-нибудь продажником или маркетологом (по крайней мере, в случае малого и среднего бизнеса, а не контор уровня Facebook), большинство из которых — это гуманитарии из тех, что называет процессором системный блок. Соответствено, о том, что это повлияет на скорость, они просто не думают.
2) у программиста, реализующего это решение, обычно не хватает либо квалификации (просто не знает, как сделать ту же асинхронную загрузку или догадаться повесить подгрузку скрипта на подходящее событие), либо времени (когда задача ставится в духе «это надо было сделать вчера, а ты тут собираешься еще два дня с оптимизацией возиться»), либо мотивации («зачем тратить усилия и оптимизировать, если все равно никто этого не оценит толком»).
3) выросло поколение пользователей, которое толком не знает, что такое по-настоящему быстрые сайты, и сложившуюся ситуацию воспринимает как норму (поэтому и не уходит к конкурентам, даже если они есть).
4) отношение к пользователю как к слепому и умственно отсталому существу, которое неспособно самостоятельно найти кнопку «подписаться» или «задать вопрос» и его необходимо потыкать мордой в баннер на полэкрана.
5) всеобщее убеждение, что программа или сайт должны постоянно обновляться вместо «хорошо сделанное и выполняющее свои задачи ПО в обновлениях не нуждается» (кроме разве что исправления уязвимостей в безопасности, если таковые будут найдены).
0
Имхо, никто не мешает публиковать хороший контент и быстрым сайтам без рюшечек (такие есть, и это не только старенькие форумы в классическом дизайне)… Другое же дело, что таких сайтов очень мало.
0
Имхо, никто не мешает публиковать хороший контент и быстрым сайтам без рюшечек

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

А те, кто без рюшечек — должны искать посетителей иначе. Своё ядро преданных пользователей, сарафанное радио. Я вот вспоминаю, многие паблики в вк вроде «Подслушано» в начале своего пути так развивались. А вовсе не через поиск, рекламу или оплаченные посты в других сообществах.
+1
Солидные научные сайты (нпр arxiv.org ) и Википедия без рюшечек. ИМХО наука должна делать погоду в IT. К сожалению, не все берут пример с научных сайтов.
0
Согласен с вами целиком и полностью! Жаль, плюсануть кармы не хватает. Впрочем, это частный случай более глобальной проблемы «жаль, что наука и научный подход лишь в малой степени определяют жизнь людей».
+3
Выигрывали бы при прочих равных.

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

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

А как же, господи, как же я ненавижу блоги с этими модными новыми адаптивными вёрстками, которые сделаны так, что на планшете половину экрана занимает неубирающийся, нескроллящийся, неинформативный блок с контактами, разделами и мордой автора.
0
Гмейл выиграл не потому, что он свистит на компьютере пользователя.
Как раз за счёт этого. В 2004м, когда он появился большая чем почты в браузере была на обычных формах и потому работала гораздо медленнее, чем AJAX-подобный GMail…

Конечно в современных реалиях быстрого интернета и многомегабайтных страниц GMail'а разница невелика — но тогда GMail был меньше, а «обычная почта» — тормознее.
+1

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


AJAX того уровня у меня на моих машинах того времени (а тогда я был школьником, едва начавшим получать свой доход в несколько тысяч рублей месяц, и комплюктеры у меня были не очень) почему-то не тормозил. Сегодняшнее гмыло у меня тормозит на сегодняшних околотоповых машинах, при этом из каких-то нетривиальных новых фич фронтенда — instant actions (или как оно там), и всё.


И оно не свистело. Оно было удобно и по делу.

0
И оно не свистело. Оно было удобно и по делу.
Так всегда бывает. Вначале добавляются фичи, которые реально удобны (AJAX позволил резко снизить задержки), а потом, через несколько лет — получаем монстра.

Во многом и Chrome был рождён из-за того, чтобы GMail-подобные сайты можно было писать не опасаясь добавить пару строк JavaScript'а… ну а потом, как и везде — оптмизаторы V8 упёрлись в возможности железа, а астронавты продолжили решать несуществующие проблемы…
0
Так оптимизаторы упёрлись в попытках оптимизации. Вопрос, зачем было пихать столько фич и свистелок, чтобы это в итоге начало тормозить? Причём это вопрос не только к Хрому. А также к авторам всё новых и новых стандартов (которые часто сначала добавляли, потом выпиливали, потом снова добавляли спустя год уже в другой версии).

Только вспомнить, сколько всего редко используемого (и в целом опционального) было напихано: Flex, CSS Grid, WebSQL (на страницах MDN как-то осторожно пишут, что лучше этим не пользоваться, поскольку разработка стандарта была приостановлена на стадии драфта), SPDY/HTTP2, WebRTC, WebAudio с кучей фильтров, больше подходящих для работы со звуком в проф. аудиоредакторе типа Nuendo/Cubase, чем для применения на сайтах или в JS игрушках (который сначала добавили, потом убрали, потом снова добавили в сокращённом варианте, но только в Chrome, в Firefox не стали).
0
Пара из перечисленных вами вещей таки нужна. Flex позволяет наконец нормально верстать, HTTP2 ускоряет загрузку, несмотря на оверхед шифрования. CSS Grid был бы полезным, но он лишь немногим лучше Flex и с более худшей поддержкой, позднее внедрён, поэтому да, сейчас не нужен.
0
Флекс и грид для разных вещей, они отлично дополняют друг друга.
+1
Grid был бы полезным, но он лишь немногим лучше Flex и с более худшей поддержкой, позднее внедрён, поэтому да, сейчас не нужен

Грид совсем для других вещей. И он не с худшей поддержкой. Как раз грид, внедрился во все новые версии браузеров очень даже хорошо, в отличие от флексбоксов, которые внедряли долго и криво. Вообще грид и флекс — это наконец-то возможность нормально верстать сайты.
-1
HTTP2 ускоряет загрузку

Тогда почему я так мало где его вижу?

CSS Grid был бы полезным

Он не то чтобы бесполезен. Он сложен в освоении. По крайней мере для тех, кто пос старинке верстал на блоках.

Flex позволяет наконец нормально верстать

Вот здесь поподробнее, плиз. Чем до этого было не нормально?

И кстати с корректностью отображения у этой технологии всё плохо. Я молчу про Оперы на Presto, которые не умеют Flex, потому что его ещё не было, и Хромы версий до какой-то там. Но ирония в том, что даже в Firefox дизайн, сделанный на Flex-ах, безбожно корёжится аж до версии 51 включительно (она вышла, на минутку, не так уж и давно). Если кто не верит — можно открыть Twitch с помощью сервиса-эмулятора, позволяющего просматривать сайты в разных версиях браузеров под разными ОС.

Как по мне, при такой вёрстке как минимум меньше контроля над происходящим (хотя всё ещё можно корректировать огрехи расположения с помощью position: relative, но получается, что эти корректировки ещё и должны быть browser specific).
0
> По крайней мере для тех, кто пос старинке верстал на блоках.

Дожились, я думал по старинке это на таблицах…
0
Тогда почему я так мало где его вижу?

Лично я вообще не вижу, пока не открою инструменты разработчика.
Чем до этого было не нормально?

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

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

Больше его там.
0
WebRTC, например, единственная возможность получать realtime аудио с сервера сейчас, когда Flash по умолчанию выключен в браузераx. HLS даёт задержки 20-30 секунд что бывает неприемлемо.
0
Фейсбук выиграл не потому, что у него пердящая форма авторизации. Гмейл выиграл не потому, что он свистит на компьютере пользователя. Ну и так далее.

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


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

0
Примеры старого реддита, википедии, арХива, SO и прочего уже приводили. Корреляция там не очень очевидна на моей выборкей взгляд.
0

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

0
Не, для демонстрации того, о чём вы говорите, придётся продемонстрировать появившегося потенциального убийцу реддита с более лучшим дизайном.
0
Переключил GMail почту на упрощённое HTML отображение. Грузится мгновенно. В отличии от стандартного интерфейса, для которого даже прогресс-бар загрузки в виде логотипа сделали.
0
Это всегда так было. Даже в 2004м. Но раньше основной интерфейс, после загрузки, «летал». А теперь… увы…
+2
Не скажите. Тот же ВК, например, если брать клиентскую часть — практически оригинальный продукт (до редизайна точно, да и после процентов на 70-80).
+5
Веб — это информация, текст, таблицы, картинки.

Эм, нет. Веб — это добавление информации, текста, таблиц, картинок… А для этого нужен и js, и фреймворки, и на фронтенде, и на бэкенде. Предпросмотр нового коммента все-таки удобнее, чем перезагружать страницу отправкой формы и проверять как оно выглядит, не так ли?)

0
Согласитесь, глупо подтягивать всю библиотеку jQuery, чтобы добавить анимацию меню или прокрутки.
0
Аргументируйте. Если вам так нужна анимация или прокрутка, и вы не хотите реализовывать это каждый раз заново — сделайте свою библиотеку. Это будет как минимум компактнее и проще для работы лично для вас. А ещё полезно в целом как разминка для мозга :)

P.S. Никогда не люблю юзать сторонние решение, особенно если они явно избыточны.
+1
Потому что вы обрекаете пользователей на баги, которые давно починены в библиотеках.

Откройте любую статью, посвещенную опенсорсу. Как там хорошо, что много глаз код просматривают и все такое… (заметите под ковер heartbleed). А потом разверните аргументы на 180* и получите перечень проблем, которые возникают от «всего своего». Начиная от качества этого «своего» и заканчивая временем нового разработчика для понимания.

Нет ничего «крутого» в том, чтобы сделать медленну, кривую, работающую только в пачке браузеров реализацию, вместо того, чтоб взять нормальную.
-1
При чём тут вообще крутость?

Потому что вы обрекаете пользователей на баги, которые давно починены в библиотеках.

Надо просто писать без багов.

Начиная от качества этого «своего»

Зависит от того, кто и как реализует (и насколько ему интересно/приятно этим заниматься).

и заканчивая временем нового разработчика для понимания

Опять же, если код аккуратный, с комментариями (а ещё лучше, self-docemented, не нуждающийся в комментариях) — порог вхождения нового разработчика будет не очень высоким.

чтобы сделать медленную

В том-то и дело, что как правило, это будет в 2-3 раза быстрее, чем на каком-то фреймворке/движке, как минимум из-за отсутствия лишней логики.

работающую только в пачке браузеров

Так надо писать так, чтобы работало во всех, а не в пачке! Где я за «пачку» агитировал?

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

Но с другой стороны, для старых браузеров можно использовать условно подключаемые полифилы, и результат будет надёжнее и предсказуемее, так как фреймворк неизвестно насколько большой совместимостью в сторону старых версий обладает, особенно если брать динозавров вроде IE 6-8 и новые версии JQuery. Причём даже если фреймворк обладает такой совместимостью, то вот плагины к нему (на примере того же JQuery) с вероятностью 99,9% — нет, и всё равно в старом браузере сайт сломается и будет нерабочим. Кроме того, в случае 90% проектов на совсем старые браузеры вроде IE до версии 9 можно вообще забить, поставив заглушку с просьбой обновиться.

Что до компактности, то из-за неё сложность исполнения кода браузером увеличивается если не на порядок, то в разы, также растёт и количество потребляемой памяти: например, известный факт что движки обычно работают с синтетическими объектами событий (заворачивая внутрь них обычные как одно из полей), оборачивают HTML элементы в специальные объекты, возвращая результаты из функций-селекторов, и так далее).
+8
Надо просто писать без багов.

Так надо писать так, чтобы работало во всех, а не в пачке!

Как у вас всё просто. А чтобы быть здоровым и богатым, нужно зарабатывать много и не болеть?
+1
Насчёт совместимости: браузеры постоянно обновляются, языки тоже. Написав свою библиотеку один раз вы всё время должны будете её поддерживать.
+6
Иногда глупо не добавлять jQuery для подобных вещей, только потому, что jQuery порой более стабилен большинства известных браузеров.
+12
Вот из-за подобных мыслей сайты и тормозят. Опытные разработчики возьмут и просто напишут нужный transition на css и добавят will-change для фонового пререндера и выноса этой анимации в отдельный слой, чтобы не перерисоывавать всё, когда что-то будет меняться. Это всё будет работать на GPU и не тратить процессорного времени и работать будет моментально, и не будет жрать лишнего, т.к. браузер знает что будет анимироваться, а что нет.

А другой человек подумает, возьму я JQuery (который, к слову, давно уже пора закопать) и буду анимировать всё на нём. И конечно же будем вычислять каждый кадр каждого свойства каждой анимации на CPU, и каждый раз будем сбрасывать кеш всей страницы. Это ведь на порядок, как вы говорите, стабильнее. А на пользователей нам плевать.

Верно я понял вашу мысль на тему «JQuery для анимаций»?
+6
Да я до сих пор помню свой проект, где я сделал на css необольшой аккордеон (я бекенд разработчик, которого на фронт сунули, не судите строго :) ). Потратил около недели, чтобы все красиво было, принес на ревью, мне сказали «шо эта, сложный цсс, я не понимаю. Мы пишем не write-only код, а цсс который занимается вычислениями это нонсенс! (там были calc-и для заголовков элементов в аккордеоне). Жду от тебя через 2 дня все переписанным на понятный js…

Долго я там не проработал, но осадок остался…
+1
Ну css тоже надо уметь писать, иногда он действительно нечитаемым становится от избытка стилей. Для таких случаев и были придуманы препроцессоры с миксинами, функциями, инклудами и прочими штуками, сохраняющими DRY. С другой стороны может опыта у ревьювера было маловато, вот его и понесло чуть-чуть.

В любом случае визуализация должна быть на стороне css — это точно, а на JS уже бизнес-логика. Если ваш calc только для позиционирования элементов, то не вижу ничего страшного в этом, сам с недавнего времени начал активно его использовать и не понимаю теперь как жил без него.
-1
"… препроцессоры с миксинами, функциями, инклудами и прочими штуками" превращают понятный CSS в нечитаемай без дополнительных телодвижений код.
0
Ну да. Их назначение — брать код, нечитаемый даже с телодвижениями и сделать его кодом, читаемым с дополнительными телодвижениями.
+4
Не забывайте jQuery — это в первую очередь более-менее удобные селекторы, ну а во вторых, если следовать вашей логике, то сперва надо написать свою ОС, потом свой браузер, а уже потом если все таки жизни хватит, писать нормальную анимацию)
0
А что по этому поводу говорит автор в статье? Тоже предлагает ОС свою написать?

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

Конечно, есть и другие критерии. Например, дополнительные абстракции ради снижения сложности поддержки ПО. Как раз тот из вариантов, когда JQ можно использовать для селекторов. Хотя, лично я в этом вижу не слишком много смысла, благо 2018год на дворе и давно есть querySelector, но мнение имеет право на существование.
0
Я бекенд программист, по этому лично для меня, написание нативных решений js, в любом случае подразумевает дополнительные затраты по времени. Автор предлагает улучшать все, где мы имеем счастье(и/или несчастье) работать, так почему бы (следуя этой логике) не начать с главного (ос), а потом уже про jquery поговорим отдельно…
0
Тут есть такая тонкая грань, где использование JQ обосновано, а где нет. Часто пишут велосипеды, вместо того, что бы использовать готовое, часто наоборот. Решать где нужно что-то писать с нуля, а где нет — опыт и зачастую чисто субъективное.
0
Тут есть такая тонкая грань
Даже 2 грани. Можно взять готовый код, описание алгоритма и сильно переработать под свою задачу (это будет не с нуля), но иногда вставляют как есть.
0
по этому лично для меня, написание нативных решений js, в любом случае подразумевает дополнительные затраты по времени

Вы полагаете, изучить и научиться применять на практике такую большую библиотеку, как jQuery (пусть и не самую сложную из тех что есть), будет быстрее? Тут смотреть надо
+1
Автора в статье поведение OOM-киллера в линуксах удивило, так что я уже боюсь представить, что он там про ОС думает.
0
Но ведь удобные селекторы теперь есть из коробки с приходом querySelector и querySelectorAll в HTML5… Или jQuery умеет что-то ещё в этом плане?
+1
Ее обычно добавляют не для анимации, а для удобства работы с DOM. Действия с информацией предполагают работу с элементами интерфейса. Кто-то jQuery использует, кто-то Angular, совсем без js сложно обойтись.
-2
Предпросмотр нового коммента все-таки удобнее, чем перезагружать страницу отправкой формы и проверять как оно выглядит, не так ли?)

То есть в эпоху стамегабитного интернета Вам западло лишний раз "перезагрузить страницу отправкой формы"? Если уж Вам тяжело перещагружать страницу со 100500 комментариями — загрузите окно предварительного просмотра в iframe, наконец!

+1
iframe

Который по сути отдельная страница, с кучей накладных расходов на её создание и поддержку.
+1
С 10-50 соседями на каждом канале.
Или, едва добиваещемуся 5 ГГц в соседнюю комнату.
0
Я не говорил в квартире. Частный дом с участком в 6 соток позволяет вольготно использовать 2,4 ГГц.
0
В Москве и Петербурге до 139Мб/с выжимал на 4G+ с Йотой. В среднем 50-70 где-то в центре города.
0
Ну у меня 400 КБ/c. Попробовал открыть страницу с этой статьей в приватном режиме, в первый раз 16 секунд, во второй 10. В этих условиях мне удобнее предпросмотр на js.

Если на каждой странице будет по iframe со своей разметкой на каждое действие, то мне кажется ресурсов это будет занимать еще больше. Вместо 20 вкладок в памяти браузера будет 60-100. А если и нет, все равно это менее удобно, почему и стали делать на js.
0
А может не надо пихать на каждую страницу комменты и т.п.? Не?
Тот же Хабр в данном случае исключение, здесь комменты могут быть даже интереснее статей. Но в подавляющем большинстве случаев комменты прямо на странице нафиг не нужны, а вот малый вес и быстрая работа еще никому не вредили. Хотите пообсуждать — вот вам ссылка на форум. Легко и просто, но не модно, это да.
+1
А причем здесь именно комменты? Создание информации не только из комментов состоит. Валидация форм, подгрузка элементов списка по фильтру при вводе, скрытие/показ элементов по условию. А еще есть бэкенд, который все это обрабатывает. И это все надо написать и потом поддерживать.

Критикуешь — предлагай. Если это легко и просто, покажите, что сделали лично вы и сколько времени на это потратили, без js и библиотек/фреймворков. Причина идет из создания кода, а не из моды. Я этим занимаюсь, и утверждаю, что не легко и не просто.
+1
Я говорю о конкретной и при этом самой распространенной категории сайтов. Таких сайтов, которые были практически единственными на заре веба. Сайтов информационных, на которых контент генерирует только автор сайта. Где пользователь только просматривает его. Поэтому там не нужно ни форм с валидацией, ни прочего. Но где все это навешивается, потому что у 100500 других сайтов такое есть.
В конце концов есть простое и абсолютно элементарное решение — кнопка или ссылка, по которой пользователь переходит на страницу, где вы можете хоть гигабайт жабаскрипта навешать. Хочет какой-то пользователь пострадать — пусть страдает. Не надо делать тормозные страницы, только из-за того, что кто-то захочет что-то прокомментировать.
И даже на более интерактивных сайтах можно что-то такое придумать, чтобы страницы, где 99,99% пользователей только читают, не загружали весь мусор, необходимый для интерактивного взаимодействия.
0
. Где пользователь только просматривает его. Поэтому там не нужно ни форм с валидацией, ни прочего. Но где все это навешивается, потому что у 100500 других сайтов такое есть.

Такие сайты никуда не делись. Вот пожалуйста, www.kurims.kyoto-u.ac.jp/~motizuki/top-english.html
Или возьмите arxiv там все так как и было. Но фейсбук и хабр не могут быть как в 90-ых.
+1
Перестаньте уже сравнивать все подряд с фейсбуком и хабром (а также ютубом, гмейлом, твиттером и т.п.).
Сайты на которых интерактивное взаимодействие — основная, критическая часть функционала — это одно. Где совершенно необязательная — совсем другое. Но вторые почему-то маниакально изображают из себя гибрид фейсбука с твиттером.
0
Я говорю о конкретной и при этом самой распространенной категории сайтов. Сайтов информационных, на которых контент генерирует только автор сайта.

Таких сайтов сейчас практически нет. Интернет-магазины, соц-сети, веб-интерфейсы к сервисам типа почты — это самые распространенные категории, и везде есть функционал, который требует действий от пользователя. Даже на сайте газеты NY Times есть кнопки подписки, поиска, и подгрузка картинок при прокрутке. И как раз на популярных ресурсах перенос части обработки на клиент дает пользу.


по которой пользователь переходит на страницу, где вы можете хоть гигабайт жабаскрипта навешать

Ну вот это они и есть. Не хотите, не переходите) Вы предлагаете тратить в 2 раза больше денег и поддерживать 2 версии. Мало кто на это пойдет.


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

+6
Таких сайтов сейчас есть сколько угодно.
Модная подгрузка страницы при прокрутке — на самом деле одно из вреднейших извращений. Если раньше при использовании pagination я мог сразу перейти на 10-ю, 100-ю, да хоть на миллионную страницу, то теперь чтобы попасть на 100-ю мне нужно перелистать все 99 предыдущих. Мало того раньше первая и последняя страницы работали одинаково быстро, то теперь быстро (и то относительно) работает только первая, поскольку при подгрузке постепенно растет объем пожираемой памяти и тормоза.
Вы предлагаете тратить в 2 раза больше денег и поддерживать 2 версии

А зачем ее отдельно поддерживать? Если вы не будете лезть с ненужными никому кроме вас «улучшениями», то она может работать десятилетиями. В конце концов верстку вы можете иметь идентичной с интерактивной страницей.
Мне тоже не нравится тормознутость, но надо понимать, что у нее есть причины

У нее гораздо меньше рациональных причин, чем вам хочется думать.
0
Таких сайтов сейчас есть сколько угодно.

Примеры?


Модная подгрузка страницы при прокрутке

Я не писал "подгрузка страницы", я написал "подгрузка картинок". Это совсем не то, о чем вы говорите.


А зачем ее отдельно поддерживать?

У вас какое-то неправильное представление о том, как делаются веб-приложения. Если мы переименовали поле в базе данных с body на text, то и в обычном коде, и в коде "без скриптов" надо поменять условный output($news['body']) на output($news['text']). Если мы поменяли верстку шаблона интерактивной страницы для новости, то и верстку шаблона для страницы "без скриптов" надо менять, чтобы они были идентичные. Просто отключить скрипты не выйдет, вы можете в этом убедиться, отключив скрипты в браузере. Нужно предпринимать отдельные усилия, чтобы работало и так и так. Один и тот же шаблон использовать нельзя, потому что в одном шаблоне есть условная кнопка "Подписаться", а в другом нет. Либо каждый блок, требующий скриптов, оборачивать в проверку выводить или нет, и проверять, что при добавлении очередной кнопки в версии без кнопок ничего не поехало. И т.д. и т.п.


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

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

0
Примеры?

Вики. Которая как раз прекрасно работает на отображение вовсе без js, а редактируется на отдельной странице.
Просто отключить скрипты не выйдет, вы можете в этом убедиться, отключив скрипты в браузере

Это только при условии, что js служит не только для взаимодействия, но и для отрисовки. И да, вы меня тоже изначально неправильно поняли. Совсем необязательно иметь 2 визуально идентичных версии страницы, на одной из которых комментировать нельзя, а на другой можно. Есть смысл разделить функционал. Очевидно, что подавляющее большинство только читает, скажем, новости. Они получают легкую и быструю страницу без лишних скриптов с кнопкой/ссылкой «обсудить». И вот на этой странице делайте что хотите. Я не вижу смысла делать ее визуально похожей на первую страницу.
Так я причины из практики знаю. То, о чем вы говорите, требует дополнительных ресурсов при разработке.

Так это потому что вы и те, кто дает вам задание, мыслите именно в такой парадигме.
Вообще было бы гораздо проще обсуждать все на конкретных примерах.
-1
Вики.

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


Они получают легкую и быструю страницу без лишних скриптов с кнопкой/ссылкой «обсудить». Я не вижу смысла делать ее визуально похожей на первую страницу.

Ну вот у нас и появилось 2 страницы вместо одной, да еще и с разной версткой. И почему вы все время про комменты говорите? Это был пример конкретно про Хабр, на других сайтах свои применения скриптов. Та же кнопка "Подписаться". Сделают так, как вы предлагаете, а потом будут жалобы от пользователей "почему у вас кнопку Подписаться не найти, вот сайте X она рядом со статьей, нажал и все".


Так это потому что вы и те, кто дает вам задание, мыслите именно в такой парадигме.

Если на фреймворке прототип делается за час, а без него за неделю, тут не надо никаких парадигм.

+1
Я так понимаю, что для вас «распространенные сайты» — это сайты, которые вы разрабатываете.
Потому что если судить с позиции количества пользователей, то вики — это куда более «распространенный» сайт, чем все сайты, в разработке которых вы хоть как-то принимали участие за всю жизнь. Если судить с точки зрения количества самих сайтов, то как раз сайтов со статической информацией вася-пупкин.рф опять же на порядки больше ваших сайтов, в которых действительно нужны тонны скриптов.
Даже анимацию добавляют не потому что на других сайтах есть, а потому что там из-за этого новых пользователей больше.

Это как? Откуда появляются при этом новые пользователи?
Так какие есть распространенные сайты, где все это есть, но можно убрать без проблем?

Я свои примеры привел. Давайте наоборот — приведите хотя бы один пример сайта где тонны js прямо необходимы.
Та же кнопка «Подписаться». Сделают так, как вы предлагаете, а потом будут жалобы от пользователей «почему у вас кнопку Подписаться не найти, вот сайте X она рядом со статьей, нажал и все».

По-видимому вы так и не поняли. Оставьте все необходимые кнопки, только сделайте их просто ссылками на соответствующие страницы — и все! Даже не на много, а на одну страницу.
Ну вот у нас и появилось 2 страницы вместо одной, да еще и с разной версткой.

И не говорите, это просто ужас. Ведь на второй странице нужно обязательно делать какой-нибудь крутой дизайн, а это сложно, дорого и бла-бла-бла.
Правда я сделал бы там дизайн в духе ya.ru (ага!), который стоит 3 копейки и не нуждается в поддержке. Но да, это же сейчас не модно…
Если на фреймворке прототип делается за час

Дак кто ж вам запрещает делать на фреймворке прототип? Сколько угодно. Но вот в продакшн — не надо…
0
И не говорите, это просто ужас. Ведь на второй странице нужно обязательно делать какой-нибудь крутой дизайн, а это сложно, дорого и бла-бла-бла.
Правда я сделал бы там дизайн в духе ya.ru (ага!), который стоит 3 копейки и не нуждается в поддержке. Но да, это же сейчас не модно…

Пользователям тоже будете сами объяснять, какой это крутой дизайн?
+1
Ах вон оно как, т.е. это пользователи требуют от вас какого-то особого дизайна на сугубо функциональных страницах, а не вы сами хотите выпендриться с мегатоннами украшений и жабаскрипта…
Это очень странно, поскольку google.com миллиардам пользователей по-видимому вполне нравится. А там как раз дизайн вроде того, что предлагаю я.
0
Конечно пользователи. Я-то реализовываю то, что сказал продукт, а продукт анализирует как раз требования пользователей и «вон те чуваки прикрутили Х, и у них конверсия увеличилась, айда так же сделаем».
0
Я так понимаю, что для вас «распространенные сайты» — это сайты, которые вы разрабатываете.

Из чего вы сделали такой вывод? Вы говорили про "распространенные сайты, где все это навешивается". Я попросил примеры. В Википедии это навешивается? Нет. Так какое отношение она имеет к разговору?


Я бы даже сказал, она подтверждает мои слова. Там не нужны скрипты, вот и не добавляют. А где добавляют, значит там они зачем-то нужны.


как раз сайтов со статической информацией вася-пупкин.рф опять же на порядки больше ваших сайтов

А какая вам разница, что на личном статическом сайте Васи Пупкина используется JS? Там все равно ничего не тормозит, потому что функциональности мало, да и вряд ли вы столько личных сайтов посещаете.


Это как? Откуда появляются при этом новые пользователи?

Ну вот так. Нужен человеку некий функционал, есть 2 сайта с таким функционалом, на одном есть анимации, приятные глазу, на другом нет. Поэтому он зарегистрировался на первом сайте.
На втором сайте заметили, что пользователей что-то мало, а в интернете все первый сайт обсуждают, запустили рекламу с a/b тестированием, и оказалось, что если интерфейс без анимаций, то меньше пользователей регистрируется.
А третий сайт не стал проводить тестирование, а сразу добавил анимации.


Я свои примеры привел. Давайте наоборот — приведите хотя бы один пример сайта где тонны js прямо необходимы.

Нет, не привели. Только про одну Википедию написали, которая ни при чем.
И давайте без демагогий. Я не говорил, что необходимы именно тонны js, я говорил, что в целом js и всякие библиотеки/фреймворки нужны. Но вообще https://docs.google.com неплохой пример.


Оставьте все необходимые кнопки, только сделайте их просто ссылками на соответствующие страницы — и все! Даже не на много, а на одну страницу.

"Я нажимаю кнопку Подписаться, а страница просто перезагружается. С остальными кнопками то же самое. Почините немедленно!". Ну и да, одна страница все равно требует меньше ресурсов (для разработки), чем две похожие. И зачастую разница гораздо больше, чем в 2 раза.


Правда я сделал бы там дизайн в духе ya.ru (ага!), который стоит 3 копейки и не нуждается в поддержке.

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


Но вот в продакшн — не надо

Вы думаете, для продакшена математика другая и там по волшебству дополнительные недели появляются?)

0
Ну и да, одна страница все равно требует меньше ресурсов (для разработки), чем две похожие. И зачастую разница гораздо больше, чем в 2 раза.

Про сложность согласен, это важный фактор. Хотелось бы однако отметить, что есть техники, позволяющие обойтись всего одной страницей, и при этом обеспечить её полиморфное поведение. То есть она будет одинаково хорошо работать и при отключенном, и при включенном JS. Вы наверное об этом знаете. Ну да, в разработке это сложнее, и даже не в 2 раза. Зато у нас одна страница, работающая везде и у всех (даже в каких-нибудь мобильных Операх Мини), все правки централизованы в одном месте, разработчики заняты делом и получают повышенную зарплату за возросшую сложность. Классно же.
0
Классно же.
Офигенно! Для всех кроме владельца сайта который за это платит.
+1
Я бы даже сказал, она подтверждает мои слова. Там не нужны скрипты, вот и не добавляют. А где добавляют, значит там они зачем-то нужны.

Далеко не всегда. Скажем, надоедливые баннеры «добавляйтесь в друзья» или «закажите обратный звонок», закрывающие контент в самый неподходящий момент, вряд ли можно назвать нужными. Но их вешают. Про навязывание подписки на push-уведомления и вовсе молчу. Или, скажем, онлайн-чаты, которые сейчас на каждом втором магазине висят. В принципе, неплохая вещь, если их делать нормально, то есть сначала видна только кнопка «Задать вопрос» (еще для привлечения внимания по ней можно какой-нибудь блик пустить), а при щелчке по ней подгружаются необходимые скрипты и начинается чат. Но нет же, делают загрузку скриптов сразу и сразу же разворачивают окно чата.
0
Если на фреймворке прототип делается за час, а без него за неделю, тут не надо никаких парадигм.

Так речь же о том что на фреймворке у конечного пользователя тормоза начнутся.
+1
Речь была о том, что убрать фреймворки легко и просто, потому что они низачем не нужны, кроме моды. Я объяснил, что это не так. Есть выбор — уменьшить стоимость разработки (время и деньги), добавив тормозов конечному пользователю, или наоборот. Обычно выбирают первое.
0
Либо каждый блок, требующий скриптов, оборачивать в проверку выводить или нет, и проверять, что при добавлении очередной кнопки в версии без кнопок ничего не поехало. И т.д. и т.п.

.come_block {
    display:none;
}
body.has_js .come_block {
    display:block;
}
0

Ну вот этот come_block надо добавлять в каждый блок, и желательно в обертку, чтобы собственным классам не мешало. Суть же не в том, что сделать нельзя, а в том, что поддерживать надо. А еще оно все равно на клиент поедет.

0
В обёртку — это как? come_block — Это и есть собственный класс в примере выше)
0
<button class="display_inline_block come_block"></button>

Ну если вы вот так сделаете, то верстка может поехать, там же display другой задан.

0
А, не понял вас. Да, поехать теоретически может. Добавление/удаление каждой кнопки по-хорошему надо будет тестировать на обеих версиях. Я просто имел в виду, что класс самой кнопки останется без изменений, и правила для неё тоже.
+2
Мой код там только в качестве примера, притом не самого лучшего. Можно сделать наоборот
body.no_js .come_block {
    display:none;
}

И удалять класс no_js яваскриптом.
0
На сайтах может и не нужны, но сейчас веб это не только, а может и не столько сайты, сколько распределённые приложения, а браузеры — среда исполнения толстых клиентов.
+26
Но автор же предлагает не переписать абсолютно все с нуля или начинать писать не используя чужие библиотеки и фреймворки, а хотя бы не городить по верх и так уже раздутого кода еще и свою халабуду из такой же «эпоксидной смолы» и палок. А на счет расширения штата разработчиков — тут вообще не понятная ситуация, когда команды/компании набирают сначала овер дохера менеджеров, чтоб продать продукт на который код еще и писать то не начали, а потом еще и выясняется, что на разработчиков ничего уже не осталось из заложенного бюджета.
+1
Недавно как раз одна компания отчиталась о превышении некоего лимита впервые в истории.
Думаете не хватает на разработчиков?
-1
А причём тут ядро, система может быть одна, просто вместо интерпретируемых языков для прикладных приложений будут снова использовать компилируемые. И делать сайты без тонны JS и с серверным рендером тоже можно. Всего-то должна пройти мода на одностраничники.
+1
У серверного рендера есть свои недостатки на перспективу. Если проект имеет в будущем шансы на интеграцию со сторонними приложениями, нужно будет проектировать и писать API. На старте проекта можно сделать единый механизм для веб-фронтенда и приложений, а рендерить на клиенте, и таким образом не делать двойную работу.
+1
Только вот большинство сайтиков никогда ни с кем не интегриуются…
Но страдать пользователей от тормозов теоретической будущей интеграции заставляют уже сейчас.
0
Ну так совсем не обязательно реализовывать на клиентской стороне функции, не нужные браузерному приложению.
+19
Так дело же не в том, что для получения хорошего софта надо платить в сто раз больше. Надо платить, условно говоря, на 20% больше, чтобы решить 80% проблем. Этого достаточно.
Мы пользовались софтом, который работал на компьютерах в сто раз медленнее нынешних смартфонов, при этом он был значительно более функциональный, отнюдь не стоил космических денег для пользователя, а разработавшие его программисты были ничуть не менее богатыми, чем современные. Так что проблема отнюдь не в том, что для разработки более качественного ПО нужно намного больше денег.
-4
Мы пользовались софтом, который [...] был значительно более функциональный

это каким же?
+19
Да что угодно возьмите. Сравните функционал почтового клиента конца 1990-х годов и того, что в вашем телефоне. Сравните ваш просмотрщик электронных таблиц и Excel, который весил меньше, чем калькулятор у вас на телефоне.
+7
Кстати да, Слак никогда не будет уметь того, что умеет kvirc, например.

Мобильный софт — это вообще издевательство. Там количество фич только уменьшается. Старые гугл.карты (еще на Андроиде 2) умели трекать остановки транспорта. В новых появилась прекрасная фича «потряси телефон, если нашел ошибку», зато они перестали показывать таймлайн с остановками маршрутки. Хотя, вроде в этом году вернули эту фичу обратно…

Атом (который редактор) в принципе не умеет того, что умеет мой emacs.

Про новый скайп уже говорили.

Даже в новом MSPaint потеряли какую-то фичу, которой многие пользовались в оригинальном приложении. Извините, не помню деталей.

При желании, этот список можно продолжать еще долго.
+2
Сравнение с мобильными некорректно, так как у них совсем другая ниша, потому и софт такой, каков он есть.

При желании, этот список можно продолжать еще долго.

В том-то и дело, что при соответствующем желании можно вывести любой тренд, какой душе угодно.

В приведенных примерах, имхо, сравниваются не совсем аналоги. Но даже в них, скорее всего (т.к. не в курсе про Атом), можно найти обратные примеры, навроде «kvirc не умеет в звонки и скрин-шеринг». Только вы ответите «это не нужно» и будете правы. И аналогично можно найту кучу фич современного софта, о которых раньше вообще не шло и речи.
0
Так речь в том числе и о мобильных приложениях, некоторым из которых с десяток лет, но развиваются они странно с точки зрения пользователя и программиста — фичи выпиливаются, а добавляются рюшечки.
0
Вот пример одинакового: функционально Ексель97 и Ескель2016 если и отличаются, то как раз не существенно для 80% пользователей. Но скорость и качество работы… Про размер дистрибутива я вообще скромно умолчу.
0
Есть нюанс — скорость работы на современном железе как раз в 16 выше. Да, интерфейс тупит, но когда надо 100500 формул считать (а эксель это в первую очередь мегакалькулятор, а не блокнот с ячейками) — 2016 будет сильно впереди. Ситуаця ровно как с фотошопом — в операциях, важных для профессионалов, новые версии сильно быстрее. Просто не всем это нужно, и в отличие от экселя, быстрые маленькие замены для фотошопа есть.
0
Функционально он мало отличается при использовании в качестве калькулятора. А так в каждой новой версии появляется несколько полезных конкретно мне фич. Тоже автосохранение, интеграция с облаком и совместная работа появившиеся в версиях 2016+ резко повысили комфорт работы, особенно с нескольких компьютеров и более чем одним пользователем.

Скорость работы именно программы выросла — Эксель научился нормально использовать многопоточность для расчетов (сравнивал 2016 на десятке с 2013 на семерке).
Либреофис отстаёт очень сильно, и может служить нормальной заменой только для относительно простых задач.
0
Скорость работы именно программы выросла — Эксель научился нормально использовать многопоточность для расчетов (сравнивал 2016 на десятке с 2013 на семерке).
Вот это, пожалуй, первое реально полезное добавление после MS Office 2000. Хоть кто-то что-то может назвать.

совместная работа появившиеся в версиях 2016+
Тоже интересно.

Но, заметьте, обе этих вещи отсутствовали в MS Office 2000 в силу полнейшей бессмысленности в тогдашних реалиях, а не потому что разработчики не могли их реализовать… и совершенно неясно почему эти вещи нельзя было добавить сохранив быстрый и отзывчивый интерфейс…

Либреофис отстаёт очень сильно, и может служить нормальной заменой только для относительно простых задач.
Возможно. Я не нагружаю его так сильно, чтобы меня нервировало отсуствие многопоточности — а вот то, что MS Office изображает на экране «патоку» даже на 24-ядерной машинке… меня раздражает…
0
> в силу полнейшей бессмысленности в тогдашних реалиях

Ну в начале 2000-х как минимум одноранговые локальные сети были нормой, а многие даже небольшие компании и домен на в2к поднимали. И терминальные серверы тогда же или чуть позже (в в2к3) в массы пошли.
0
Ну в начале 2000-х как минимум одноранговые локальные сети были нормой
В одноранговой сети совместное редактирование документов не нужно. Если уж так хочется вот прям одновременно вдвоём редактировать — проще взять стульчик и сесть вдвоём у одного компьютера. Правда-правда, попробуйте.

А вот что нужно — так это передача документов от одного отдела другому с разными рецензиями и прочим. И это всё в MS Office 2000 (да и в MS Office 95/97) достаточно хорошо развито.
+7
В новом скайпе я физически ощущал его сопротивление моей попытке напечатать сообщение…
0
Я в этом плане грешу на интернет и распространение софта по сети. Раньше пользователь покупал физическую копию и если там обнаружиывался баг, то быстро доставить фикс было проблематично, что стимулировало больше времени тратить на тестирование, тестирование на различных архитектурах, стабилизацию и тд. Ведь бажный софт мог повлиять на репутацию компании. Это же касается игр. Сейчас, когда патч можно доставить за считанные минуты практически всем клиентам, наступила эра сырого софта (и игр в том числе). Принцип «лучшие qa — это наши пользователи» вышел на новый уровень. Репутационные проблемы решают пиарщики (вот вам фтболка и скидка на следующую версию). И вправду, зачем тратить время на глубокое тестирование и отшлифовку, если через 10 минут после релиза пользователи все сами напишут, и если, вдруг, у кого-то будут проблемы — мы сможем сразу им выкатить фикс. Это же позволяет выкатывать недоделанные фичи, доделаем следующим минорным релизом, а пока и mvp сойдет.
+1
Ведь бажный софт мог повлиять на репутацию компании. Это же касается игр.

Будто раньше в предел забагованных игор не выходило.

-1
что умеет мой emacs.

Только вы почему-то не упомянули что емакс тормозит ;)

-1
Современные смартфоны существенно мощнее суперкомпьютера НАСА конца 60-х годов. Но тогда производительности компьютеров хватало, чтобы запускать человека на луну, а сейчас только чтобы запускать птиц в свиней.
+3
вы платите оверхедом не за возможность запускать птиц, а, грубо говоря, за возможность играть в новую игру хоть каждый день, при этом устанавливая ее и удаляя старую в течение минуты, причем бесплатно (относительно)
+2
за возможность играть в новую игру хоть каждый день

А можно поподробнее, что в этом инновационного по сравнению с, к примеру, приставками из 90-х?

+4
Графен, не более. Механики мобильных игр крайне тупы. Плюс с тех пор как там продоминировал фри2плей так и вообще все маркеты сгнили.
0
идти и покупать/арендовать/менять картриджи надо было, переставлять их, фактически меняя аппаратную конфигурацию компьютера.
0
И тем не менее, это можно было желать «хоть каждый день». Картриджи арендовались за небольшую сумму и киосков с ними было… достаточно.
0
По сути каждый день происходил апгрейд аппаратной части.
+2
Возможность играть в новую игру каждый день мы получили благодаря современным средствам доставки софта от производителя до клиента, когда любой может сделать игру и продать её вам без участия издателя. Средства быстрой разработки не слишком продвинулись с того времени, когда в конце 1990-х появились независимые игровые движки. А в сфере прикладного софта и того хуже, переход приложений в веб отбросил инструменты разработки (и продуктивность программистов) лет на десять-пятнадцать назад, потеряв почти все преимущества, которые приобрели десктопные IDE.
0
А AppStore и GoogleStore это не «издательство», это «средство доставки софта, которые имею приличную долю в финальноё стоимости софта» <_<
+1
В том-то и дело, что это всего лишь удобные магазины. Они не имеют вообще никакой доли в финальной стоимости софта и не претендуют на неё. Отличия от издательств тут колоссальные.
1. Вам не нужно убеждать магазин в том, чтобы он начал распространять ваш продукт. Зарегистрировались, выложили. А дальше уже покупатель голосует рублём/долларом/юанем.
2. Магазин не имеет никаких прав на ваш продукт, ни даже эксклюзивного права на распространение. Как вам больше нравится — так и распространяйте. Издательство же вас сожрёт с потрохами.
3. Магазин у вас не требует никакой финансовой доли в бизнесе. Он продал ваш софт — он взял свою комиссию, не продал, он ничего не потребовал. Насчет того, что комиссия большая, вопрос спорный. Сколько вам не жалко отдать денег посреднику за продажу вашего товара, которой без него вообще бы не было? Особенно если учесть, что тиражирование этого товара не стоит вообще ничего.
0
Они не имеют вообще никакой доли в финальной стоимости софта и не претендуют на неё.

И они даже не берут некоторый процент с продаж?

Магазин не имеет никаких прав на ваш продукт, ни даже эксклюзивного права на распространение. Как вам больше нравится — так и распространяйте.

А зачем аппстору юридические эксклюзивные права, если 99.9% пользователей iOS не имеют других источников?
-1
И они даже не берут некоторый процент с продаж?

Ну, на ваши расходы на создание продукта это уж точно никак не влияет. Согласитесь, факт, что магазин берёт свою наценку при продаже вашего товара, абсолютно естественен и логичен.
А зачем аппстору юридические эксклюзивные права, если 99.9% пользователей iOS не имеют других источников?

Зато пользователи Андроида тоже с удовольствием поиграют в те же Растения против Зомби, что и на аппсторе. А вот издатели иногда трясут ананайкой перед студиями, дескать, «хочу, чтобы в ЛастОфАс играли только на нашей любимой плейстейшен, и нигде более».
+1
Ну, на ваши расходы на создание продукта это уж точно никак не влияет.

Я склонен считать, что при отсутствии этого процента продукты в среднем стоили бы ниже.
0
Скорее приносили бы больше прибыли. Процент не такой большой, чтобы снизив цену на него получить аналогичный процент роста продаж. Стоит сейчас приложение 0.99 или 9.99 — снижать цену на 10% смысла очень мало.
0
Так там вроде не 10% берут, а 30. И для уникальных нетривиальных приложений смысла действительно нет, а для какой-нибудь ерунды по 2.99 продавать её по 1.99 вместо этого — почему бы и нет?
0
При отсутствии этого процента разработчику надо было бы самому тратиться на дистрибьюцию игр. Поэтому вряд ли. Чудес и аттракционов невиданной щедрости не бывает. До появления маркетов игры обычно продавались непосредственно правообладателями и стоили намного дороже.
+4
Суперкомпьютер НАСА в 60-ые был именно, что только в НАСА. У обычных людей ничего такого не было и в помине. И вы бы не захотели платить ту цену за компьютеры и программы, которые были в 60-ые годы. И я почему-то уверен, что в ужасном «тяжелом» вебе сегодняшнего дня вы смотрите кино, качаете игры со стима, ориентируетесь по гуглокартам и так далее. Ну а если вам нужны супервозможности 60-ых годов, то никто от вас ничего не закрывает. Браузер Lynx, какая-нибудь Windows Xp и можно спокойно считать траетории полета на Луну
+1
Windows 98 в эпоху, когда сжатие инфы больно дорогим накладным расходом занимал 245 метров после выкидывания всяких справок. Офис 97, хм… 100 мб установщик? И по сколько там каждое приложение в отдельности занимало из всего пакета?
Давайте, расскажите мне, что какая-нибудь приблуда на телефон, типа читалки сложнее этих программ при соизмеримом размере?
Да даже программа эмуляции командной строки под винфон, которая умеет только в пару комманд — 16 мб. Эмулятор нескольких команд доса, блин, который занимал сколько килобайт на дискетке?
UFO landed and left these words here
+6
Не напомните, какой размер указателя в байтах был на windows 98, и каков он в «современных приблудах на телефоне», раз уж взялись мерить?
Припомню, да. 4 байта размер указателя в Windows 98 (сегмент 16 бит, смещение 16 бит), 4 байта сегодня (да, большинство приложения 32-битные до сих пор). И?

При этом с помощью этого браузера я могу решить в тысячи раз больше задач, чем с помощью вашего 97го офиса, 98 винды, и каждого по отдельности приложения для нее.
Замётано. Не расскажите — как именно с помощью вашего браузера создать табличку с формулами и посчитать что-нибудь в ней. Сделать каталог с книгами и найти там чего-нибудь? Ну или, на худой конец, подготовить и распечатать книжку с картинками? Это всё Офис делал в 97й версии без каких-либо дополнительных аддонов или чего-либо ещё…
UFO landed and left these words here
+3
Если это «наглая ложь», то вы, я думаю, сможете привести десяток популярных приложений без поддержки armeabi-v7a.

Я про существование таких знаю, могу даж пример привести. Целое одно приложение, вы не поверите.

Все остальные — либо ABI-agnostic (то есть там может быть любой поинтер), либо с поддержкой armeabi-v7a.

P.S. Да, я знаю, что в мире iOS всё не так — ну так это, опять-таки, чисто и исключительно хотелки чьи-то. То ли Тима Кука, то ли духа Стива Джобса, я не знаю. Никакой объективной необходимости в таком «форсированном» переходе на 64-бита нет и не было.
0
Я тут одну игру вспомнил, которая 16-20 гигабайт памяти жрёт только так. Интересно, как ей бы было с 32-битными указателями.

Хотя это десктопное всё, конечно.
0
Я такую точно знаю (из-за неё пришлось приобретать «до 64Гб» мать и обвес к ней) — это Cities Skyline
Из коробки, junior-level
image

После напильника, Skyline 'Skyline здорового человека', senior-level
image
0
Интересно, как ей бы было с 32-битными указателями.

Иногда удивляюсь, почему "compressed pointers" так мало распространены. Выравнивание по 8 байт — и можно адресовать 32ГБ, используя 32-битные указатели. Немного памяти сбережёт.

0
Потому что позволяет решить очень узкую задачу (расшилить с 4GB до 64GB) путём усложнения кода буквально на всех уровнях. В языках без указателей (Java, к примеру), этот приём используют иногда, кстати.
+1
Конкретно для винды — вполне правда, это под линукс всё собирается, как правило, под битность дистрибутива, а так 64-bit only это, в основном, новые игры.
0
Речь шла про «современные приблуды на телефоне». Процент винды на телефонах — где-то под микроскопом нужно рассматривать.
+3
Не расскажите — как именно с помощью вашего браузера создать табличку с формулами и посчитать что-нибудь в ней. Сделать каталог с книгами и найти там чего-нибудь? ...

Гуглодокс и прочие веб приложухи.

И не говорите мне что 97ой офис не тормозил нa компах того времени. Еще как тормозил. Ворд частенько падал при сохранении/загрузки нетривиальных документов, все они нe показывали контент при скролле и т.п.

Попробуйте собрать себе старый комп с 98ой виндой и поработать под ним. Очень быстро захочется обратно в «тормозное будушее»
+3
А причем здесь «гуглодокс и прочие веб приложухи»? Это совершенно отдельные вещи, живущие на далеких гугловских серверах.
А бразуер, грубо говоря, парсит и генерирует http, и может открыть некоторые файлы для чтения.
UFO landed and left these words here
+2
Полная глупость. Ну да, API много, систем много, но всё то, что умел офис старых версий, вы не просто не сделаете с той же лёгкостью, вы вообще этого не сделаете. Через веб-приложение — да, но при чём тут браузер?

Как верно заметили выше, браузер только парсит HTML, применяет CSS и исполняет скрипты; в довесок он умеет определять геопозицию юзера, показывать картинки и сохранять их на диск, проигрывать аудио и видео (уже лет 7-8 как), выводить и подсвечивать в консоли JS код, а также исполнять пользовательский код прямо там же. Но это обстоятельство не позволит вам сделать электронную таблицу, сверстать книгу или статью, или сделать слайд-шоу. Для всего этого нужно облачное приложение — браузер же может его только исполнить. Некорректно говорить, что функционал, предоставленный этим приложением, предоставлен непосредственно браузером. С таким же успехом можно сказать, что мы обязаны всему JVM или компилятору (браузер по сути такой же JIT-компилятор/интерпретатор).
0
Еще большая глупость заключается в том, что то что может быть исполнено на юзерской тачьке в 100 раз быстрее — зачем-то сваливают на сервак. Это вообще верх идиотии.
А может и в 1000-100000 раз быстрее. Смотря что…
0
Вот ни разу. Откуда вы мощность машинки пользователя знаете? Может там i7, а может целерон. Или вообще какой нибудь андроид тысяч за 7-8.
0
Через веб-приложение — да, но при чём тут браузер?

Ээ… А браузер без веба зачем нужен то вообще?
+1
Дык в этом и дело! MS Office — является весьма функциональным приложением, которым можно пользоваться самим по себе, без ничего, браузер же, по сути — «современный тонкий клиент»… и при этом мне безапелляционно заявляют, что он умеет больше чем офис…

P.S. Это если забыть про то, что начиная с MS Office 2000 в офис и «настоящий» браузер входит. Кокретно в MS Office 2000 — MS IE 5.0
UFO landed and left these words here
+2
exсel и эта табличка? ну это что-то вроде
«Зачем тебе телевизор мультки смотреть, давай я тебе картинку нарисую»
Ты попытался сымитировать эксель и считаешь что браузер из-за этого не уступает по функционалу? Надо было на бумаге все посчитать и изображение вставить.
UFO landed and left these words here
+2
Я следовал поставленному ТЗ

но ты же его провалил, ни одного пункта не реализовано, кроме простой части первого пункта, я ж говорю на листе мог бы посчитать и скинуть фото.
1)Таблицы с формулами нет, только предзаданные вычисления
2)Каталога с книгами нет
3)Книги с картинками нет.

При этом с помощью этого браузера я могу решить в тысячи раз больше задач, чем с помощью вашего 97го офиса, 98 винды, и каждого по отдельности приложения для нее.

Если под этими словами ты имел ввиду
«Я буду кодить новую таблицу под каждую задачу», то да можно в тыщу раз больше чем может эксель. Хотя очевидно у нас разные понятия под функционалом, когда 1 программа имеет функционал, а в другой необходимо руками реализовывать каждый конкретный случай, то спорно все же
При этом с помощью этого браузера я могу решить в тысячи раз больше задач, чем с помощью вашего 97го офиса


Даю новый челендж, писать программы при помощи рисунков, рисунок может в тыщу раз чем браузер и эксель. Рисунком можно при должно терпении создать и браузер и эксель и любую программу. Ну знаешь такой метод, тыкаешь определенными цветами в пиксели, сохранешь БМПшку, переименовываешь в exe, вуаля у нас программа. Все, языки программирования/компиляторы/интерпретаоры сакс, рисунком можно че угодно закодить.
UFO landed and left these words here
0
Видимо, речь шла о лёгкости реализации каждой такой задачи. Человек уверен, что в Экселе это делается проще и быстрее (наверное, и правда быстрее, но здесь многое уже индивидуально).

У меня вопрос по существу вашего примера имеется. Код простой, но у меня он, однако же, не работает. Ошибка очень забавна: "document.querySelectorAll(...).forEach is not a function". Перед этим я заменил стрелочную функцию на обычную, так как моя версия Хрома стрелочные ещё не поддерживает. Но тем не менее подсчёт итоговой суммы не работает. Я так понимаю, querySelectorAll возвращает в моей версии не массив, а NodeList или что-то вроде того, и у этой сущности отстутствуют методы массивов. То есть надо делать Array.prototype.forEach.call(...). Вопрос, почему у Вас работает без этого?

P.S. Не знал про темплейты, спасибо, теперь где-нибудь применю при случае :)
0
querySelectorAll всегда возвращает NodeList, но в новых версиях у NodeList тоже есть метод forEach
UFO landed and left these words here
0
Коллега, поверьте, вы практически носитель сакрального знания. Функции для манипулирования DOM сейчас практически забыты. А чтобы создать подобную страничку современному разработчику нужно подключить jquery, react, less, настроить сброку итд итп

ЗЫ foreach работает не везде
UFO landed and left these words here
+3

Да и программа такая для этого не нужна, открываете командную строку, и copy con чётотам, и фигачите прям в машинных кодах.

+2
И не говорите мне что 97ой офис не тормозил нa компах того времени. Еще как тормозил.

На новом компе 1997-го (а это был бы Pentum 133+ с 16 Мб памяти и выше) года он работал адекватно, не тормозил. На компе 1999-го уже бы летал. Сложно сравнивать производительность тех лет с современной, т.к. тогда за год-полтора производительность вырастала в разы, а сейчас лет за пять процентов на сорок.
0
О, ну на «новом компе 1997-го» любой дурак может…
У меня на новом компе 2018-го последний офис тожe не тормозит.
+4
У меня на новом компе 2018-го последний офис тожe не тормозит.
А вы в этом уверены? Или вам так кажется?

Поставьте себе MS Office 2000 (он на Archive.org доступен), поиграйтесь пару дней — и, внезапно, MS Office 2016 начнёт тормозить.

Мы просто забыли что бывают программы, которые не тормозят.

И я даже могу сказать когда это произошло: 1984й год, вот тот самый роликс молотком, являение GUI народу.

Потому что до этого времени всем было известно сколько времени занимает реакция компьютера на действия пользователя: 16.6ms, вот как клавишу нажали, так в следующем кадре — видим результат. Интерфейс весь под этот подгонялся: не можем перерисовать весь экран — думаем что можем за 16.6ms изменить, так и работаем.

А вот появление GUI сделало «патоку» нормальной… но это, в общем, ощущалось как нечто временное: да, оно тормозит пока, но потом машинки станут мощнее, и будет как в рекламе — красивые окошки и реакция за 16.6ms…

Однако прошло 30 с лишним лет, а «патока» — по прежнему на экране. Только разработчики игр знают, что может быть по-другому…
+1
У меня на новом компе 2018-го последний офис тожe не тормозит.

Вы знаете, я на последний офис в этом плане тоже не жалуюсь, видимо, там ещё достаточно кодовой базы с тех лет осталось. Зато у меня на новом компе 2018-го года заметно глазу подтормаживает последний вайбер и скайп, просто при наборе сообщений. Вдумайтесь, клиент чатика, который со всем шифрованием и эмодзи по функционалу представляет несопоставимые крохи в сравнении с офисом, притормаживает на восьмиядерном процессоре и NVMe диске.
0
Я как-то читал статью про разработку первых версий офиса (сейчас к сожалению не могу найти) — так там такие «ужастики», что скорее всего его переписали.
Ну и скайп никогда вроде как не был эталоном производительности и вообще хорошего софта.
0
Ну, крови Word 6 у меня в своё время попил, это факт. А вот на скайп вы зря наговариваете :) Я помню, как 15 лет назад говорил с заказчиком из США по скайпу, причем у меня интернет тогда был через диалапный модем, 49 килобит в хорошую погоду (сейчас про такие скорости никто уже и не помнит). Это было офигеть как круто.
+1
вот качество голосовой связи у Скайпа это наверное единственное что удерживает от полного отказа от него
+1
я могу решить в тысячи раз больше задач
Сами назвали цифру, сами доказывайте.
Например, вы сможете запустить компьютер и без ОС… ах да.
Ок, тогда выйти через него в интернет… Черт, я забыл.
Обратится к прибору через ком-порт… да что ж такое-то.
Вывести страничку на печать на принтер… блин, опять ОС требуется.

То есть вы надстройкой над ОС сможете сделать больше задач, чем может ОС. Ну-ну.
UFO landed and left these words here
+1
Во-первых, вы так и не доказали, что те тысячи задач, которые вы можете выполнить в браузере — больше задач, которые может сделать винда.
А я вам лишь указал, что все свои задачи браузеры выполняют исключительно через ОС, а значит по умолчанию браузер в этом — второй.

Более того, а что может сделать ваш браузер БЕЗ сайтов, ну раз вы ОС отказываете в дровах, которые без нее работать и не могут? Ну или хотя бы без интернета? Что, оказывается, что бы гуглить код и смотреть ютубчики нужны не только браузер, а наличие сайта и интернета? То есть по факту, специально для этого написанные вещи? А сам по себе он что умеет? Ах, считай — ничего.

После чего ваше высказывание про демагогию ниже — начинает играть новыми гранями. Вы б вначале думали, прежде чем в позу мушкетера вставать.
UFO landed and left these words here
+1
Т.е. Microsoft много лет занимается мошенничеством и получает миллиарды долларов за приложение, функции которого выполняет любой бесплатный браузер???
UFO landed and left these words here
0
Как минимум то, что может офис — он может и без интернета. И даже больше.
Ну давайте. Начнем. Создайте мне в голом браузере электронную таблицу с кучей формул, аналогом макросов и нормальным интерфейсом взаимодействия с пользователем. Без интернета, сайтов и расширений, ибо вы указали ос без драйверов типа ничего не может, а значит в таком сравнении браузер это все может из коробки без перечисленного. Вот прям открываешь браузер и в нем.
UFO landed and left these words here
0
«Повышение ставок», недопустимый прием в споре. Что вы там говорили про демагогию и про тысячу вещей, которые можете делать в явно пустом браузере и не смогли бы в ОС без драйверов?
UFO landed and left these words here
0
Тут нет никаких повышенных ставок.
А вы как-нибудь логику ведения споров осильте, компетентный вы наш. Может узнаете, что такое недопустимые приемы и демагогия на самом деле.
А вы крайне некомпетентны.
да здесь все не согласные с вами крайне некомпетентны. один вы, товарищ мушкетер.
+1
У нас и доказательства есть, но они секретные, мы их не покажем
0
А причем тут плата?))
Договоритесь со знакомым Васей, он вам сделает Ворд, а вы ему Эксель) Можете обсудить стоимость. Только она не важна) Вы можете сделать друг-другу куски офиса скажем за мильярд долларов. Хватит? Но взаимозачет же. Он вам. Вы ему.
Только фишка же получается не в деньгах вовсе) Ни он ни вы абсолютно ничего не сделаете.
Выводы.

Причем тут фишка еще и в том, что тут совсем деньги ни при чом. Потому что вы и так знаете, что Вася вам ничего в итоге не сделает) А значит и вы не захотите. Смысла же нет.

Если вы ваш скил обратите в экономические бумашки — эти бумашки вообще ничего не будут стоить. Потому что вы ничего не можете вовсе) Потому что есть другие, которые могут. Которые сделают круче, быстрее и дешевле, а скорее всего вообще задаром.

И да, браузер тут вообще не нужен.
0
Договоритесь со знакомым Васей, он вам сделает Ворд, а вы ему Эксель) Можете обсудить стоимость. Только она не важна) Вы можете сделать друг-другу куски офиса скажем за мильярд долларов.

Идея богатая и в некоторых кругах весьма уважаемая. У каждого фигуранта в этом случае остается компания с миллиардным оборотом.
Остается отрастить бороду, подвернуть штаны — и на ICO, а того краше — на IPO.
0
Отображать pdf

Только если стоит плагин от Adobe, либо, опять же, через JS расширение, написанное сторонним разработчиком (да, его иногда включают в поставку, но у меня даже нет уверенности, что его пишут те же люди, что сам браузер).

Предоставляет инструменты для их верстки.

Да, но это верно только для HTML, в какой-то другой формат экспорт сделать будет вряд ли возможно)

С помощью браузера и написанного на коленке скрипта, я могу p2p позвонить знакомому по webrtc, без всяких скайпов.

Окей, что-то такое анонсировали, как минимум в Mozilla. И как это сделать? Что для этого нужно знать, куда нажать и что куда ввести?

И делается это движением мизинца правой ноги.

Вы сильно утрируете. Хотя в целом такое и правда возможно, для создания веб-приложения не нужен сервер, можно работать и локально, и даже делать импорт/экспорт в файлы, и использовать прикольные штуки вроде Indexed DB, WebSQL и Local Storage.
UFO landed and left these words here
0
Любое более-мене крупное ПО состоит из компонентов написанное разными людьми. Вы снова скатываетесь в демагогию. Я пользуясь вашими аргументами расщеплю вам любую программу на составные части и скажу, что вы не можете сделать ничего с помощью этой программы, потому что компоненты написаны не разработчиками конкретного софта.
Итак, читаем вас же:
Во-вторых перечисленное вами не может сделать ни одна ОС, без наличия соответсвующих драйверов на оборудование.
Вы только что на глазах у изумленной публики расщепили программу на составные части и заявили, что она ничего не может. После чего обвиняете других в демагогии и некомпетентности?
UFO landed and left these words here
0
То, как вы стойко отстаиваете и несете чушь, каждый раз все больше повышая ставки в споре, что очень хорошо характеризует вас. Вы написали про тысячи задач, но перечислили десяток, слившись даже на попытке сделать лично рыками эксель (ибо нифига у вас и близко не получилось).
А приводить приложения, которые кто-то написал под браузер — это еще больше нести чушь, потому что задачи будет решать не браузер, а он будет прослойкой. Еще более тонкой, чем ОС.
UFO landed and left these words here
UFO landed and left these words here
0
и чем эта урезанная ОС, в которой есть только браузер отличается от концепции ос + браузер? сам браузер без ОС этого ничего не сможет
0
Надо сказать что специализированное приложение без ОС тоже ничего не сможет сделать, даже запустится.
0
Не помню у какого вендора, но уже встречал браузер без ОС, только БИОС.
0
Нет, имеется в виду обычные материнки какого-то вендора, с которыми можно серфить из биоса, без ОС на диске и вообще диска.
0
UEFI-биосы так называемые… но это враньё! Там только кажется что нет никакой ОС, а на деле начнёшь копать а там… обычный микроскопческий линукс, с полноценным(насколько это возможно) браузером. Всё это сделано на уровне абы было поэтому не оптимизировано под многоядерность, большое количество памяти и еле шевелится. И всё это работает с… диска виртуального, мини-SSD встроенный в материнку на 8...16Гб.
0
Все что было для windows mobile было гораздо функциональнее. SoftMaker Office — повторял функционал НАСТОЛЬНОЙ версии ms office на КПК. Почтовые клиенты тоже были такого уровня. Программы от Resco — тоже образцы невероятного функционала.
При этом все это очень быстро работало на мобильных процессорах того времени (200-500 МГц), 64-128 МБ памяти.
Но глючновато, винмобайл часто любил зависать наглухо.
0
Потребности людей с тех пор сильно уменьшились. Зачем на мобильном клиенте выбор кодировки письма? настройка mime-типов? способы кодирования вложений? Оно просто должно работать… причем без лишних заморочек — на мобильных девайсах возможность ввода и взаимодействия с приложением ограничена, а значит и многие функции становятся невостребованными.
Кстати, а почтовые клиенты прошлого умели передавать файлы больше 100мб? а 10Гб? Сейчас это на уровне средних потребностей.
+1
Кстати, а почтовые клиенты прошлого умели передавать файлы больше 100мб? а 10Гб? Сейчас это на уровне средних потребностей.

Ну не перегибайте, ни раньше, ни сейчас почтовые клиенты для передачи подобных файлов не используются. И проблема тут не столько в клиенте (дайте ему достаточно памяти и времени, он вполне себе сжуёт такой файл), сколько в ограничениях на размер вложений у почтовых сервисов. Что касается самой возможности обмена крупными файлами, то она не слишком-то и изменилась, единственное, сейчас у вас будет файлообменник с веб-мордой, а двадцать лет назад у вас был бы файлообменник с FTP-клиентом. И дисковая квота, конечно, с поправкой на размеры файлов тех лет :)
0
Почему же? вот совсем недавно отправлял фото для печати в онлайн-сервис, почта… 5Гб. Приложил вложение вжууух и письмо ушло. Всё абсолютно прозрачно, никаких плясок с какими-то там файлообменниками, настройками FTP-клиента и т.п. всё делается автоматически сервисом. И, кстати, надо заметить никаких оверсайзов на 140% из-за BASE-64 кодирования вложения.
Технологии вроде бы как не изменились, но пользовательский опыт — очень сильно.
Почему, кстати, досихпор не видно отдельных нативных почтовых программ способных автоматически передавать большие файлы вложений через файлообменники?
0
Почему же? вот совсем недавно отправлял фото для печати в онлайн-сервис, почта… 5Гб.

Ну а я так ни на одном из своих ящиков не смогу. И никто из тех пользователей, у кого нет специального корпоративного ящика с отсутствием лимита на вложения, так не сможет. Gmail сейчас имеет лимит на вложения 25 мегабайт. Mail.ru — 20 мегабайт. И подобные лимиты практически везде. У вас это редкое исключение, связанное с профессиональной деятельностью.
Почему, кстати, досихпор не видно отдельных нативных почтовых программ способных автоматически передавать большие файлы вложений через файлообменники?

Кстати, идея очень даже неплохая :)
0
Нет, обычный GMAIL, и даже маилрушечка так умеет. Про яндекс не знаю, но наверняка и его уже научили. Конечно, они не гоняют письма по почтовым серверам — они для этого используют промежуточное хранилище и делают это совершенно прозрачно обходя ограничения почтовых серверов. Будь там даже 1Мб ограничение.
+4
Так это делается совсем не так. Просто файл заливается на их собственный сервер, а к письму прикрепляется ссылка. Технически, будь такие компании с такими объёмами для хранения в 90-ые — это технически было бы возможно и в 90-ые. Тут нет какого-то особенного «ноу-хау» :)
0
Так ведь фишка в том что это делается прозрачно для пользователя. У — удобство.
0
Вот только прозрачность эта — мнимая. Как вам уже ненавязчиво указали.

Да, если все вокруг пользуются GMail'ом и GDisk'ом — то это работает. Но шаг вправо, шаг влево… и нет больше прозрачности…
0
вот совсем недавно тоже отправлял сканы в обыкновенную корпоративную почту (банки — не «совсем безнадежные» должны быть по используемым технологиям)…
один робот мне ответил что их предел 25Мб,
второй — что 20,
один человек — «шлите все только в pdf, картинки не открою»
и двое — «приложенные ссылки гуглдиска не открываются, шлите только вложением»
и это при том что мобильный клиент гугла умеет напрямую с интернет-диска гугла же только ссылки шарить (хорошо что наоборот еще отключить не догадались — с приложения гуглдиска можно отправить письмо с вложением)
так что «вжжух и ушло» — это несмотря на 2018 ситуация до сих пор из серии «любой каприз за ваши деньги»
+2
банки — не «совсем безнадежные» должны быть по используемым технологиям

ИБ — информационная безопасность


«шлите все только в pdf, картинки не открою»

Скорее всего регламент.


«приложенные ссылки гуглдиска не открываются, шлите только вложением»

Google Drive запрещён как файлообменник.

0
Google Drive запрещён как файлообменник.

А для чего он тогда создавался, для личного архивирования? Там вроде в пользовательском соглашении ничего нет про запрет передачи ссылок.
0

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

0
Какой смысл закрывать доступ к файлообменникам, если почта (и файлы в ней) разрешены? Странная логика. Точно так же могут что-то получить или отослать, из того что нельзя согласно правилам.

В целях безопасности у многих сотрудников там вообще интернета нет.

Чтобы не слили данные по операциям (соблюдение банковской тайны)? Разумно. Но у кого совсем нет интернета, там и почты не будет. А у кого интернет есть, те обычно к особо секретным базам и не допущены (отдел по работе с клиентами какой-нибудь).
+2
Точно так же могут что-то получить или отослать, из того что нельзя согласно правилам.

Входящие вложения всё-таки проверятся корпоративными политиками и антивирусом. А вот исходящие за пределы домена отослать тоже не все могут — на это нужно отдельное разрешение.


Но у кого совсем нет интернета, там и почты не будет.

Вот и выросло поколение… Почта с внутрикорпоративного сервера работает. Через почтовый клиент типа Outlook или Lotus.


А у кого интернет есть, те обычно к особо секретным базам и не допущены (отдел по работе с клиентами какой-нибудь).

Зачем отделу по работе с клиентами интернет?

0
Почта с внутрикорпоративного сервера работает. Через почтовый клиент типа Outlook или Lotus.

Нет, ну это для компании логично. Я имел в виду, у кого нет физически доступа в сеть. То есть значит сеть есть, но лишь локальная, нет именно интернета? Я просто уже привык, что это синонимы, сорри.

Зачем отделу по работе с клиентами интернет?

Например, чтобы работать с CRM. Хотя скорее всего, она тоже локально развёрнута, в интрасети.
А ещё чтобы уточнить детали тарифа/услуги, хотя наверное для этого у сотрудников стоит специальный справочный софт, не нужно даже корпоративный сайт открывать.
+2

Конечно обычная локальная сеть есть. В ней свои интранет-сервисы, конечно, крутятся, типа корпоративного портала, CRM, баз знаний и СЭД, но к интернету доступа у большинства не будет в принципе. Впрочем, он на самом деле сотрудникам для их обязанностей и не нужен.

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

Thunderbird умеет. Outlook тоже умеет.

0
Что-то им это не помогло, верней не стало ключевой особенностью при выборе.
0
Ключевой особенностью при выборе стало то, что в веб-почте достаточно зарегистрироваться и приступить к работе. Не надо ничего устанавливать и настраивать. Но мы-то говорим не в контексте того, что больше нужно пользователям, а в контексте того, почему старые приложения с бОльшим функционалом работали качественнее, чем современные.
0
Кстати, а почтовые клиенты прошлого умели передавать файлы больше 100мб? а 10Гб? Сейчас это на уровне средних потребностей.
Послать то они могли, только и сейчас на метрах 15-30 тебя входящий сервачок завернет очень часто. Используйте всякие сервисы для расшаривания файлов, говорят они.
0
Вот. Вы говорите именно о почтовом приложении, которое кроме POP3 и IMAP протоколов не знает ничего, но работает быстро. Собственно это ограничения не интернета а протокола и сети почтовых серверов.
0
Но если потребности людей уменьшились, то почему потребности приложений увеличились?
0
Потребности в стороннем, вспомогательном функционале. Нынешние пользователи пугаются даже слов сервер, порт и необходимость куда-то вводить эти данные в приложении вводят их в ступор. Как впрочем и большие перечни настраиваемых параметров приложения.
Вспомните, какой прорыв в голосовой связи через интернет произвёл скайп. Который не надо настраивать, не надо вручную прокидывать какие-то там порты в NAT(ещё одно страшное слово для пользователей) и куда-то вводить адрес прокси-сервера. Он просто работает. Запустил и работает. В этом плане потребности пользователей уменьшились, они хотят и получили заветную кнопку «сделать всё хорошо».
0
Как будто список настроек оправдывает рост объёма приложений на сотни мегабайт.
-1
Но разве так жить интересно? Это же деградация в чистом виде какая-то…

То есть пользователь, конечно, не обязан становиться разработчиком и даже админом. Но всё-таки… Хоть для себя-то какой-то кайф получить от того, что сделал, настроил, и оно заработало в итоге
+1
Столько много всего можно настроить, что чем меньше, тем лучше, на наш век все равно хватит.
0
Это не деградация, это специфика мобильного девайса. У него ограниченые возможности по вводу, особо не разгонишься. И ведь это прекрасно когда программа просто работает и не нуждается в низкоуровневой настройке — все варианты опробованы, найдена оптимальная конфигурация и зафиксирована.
+1
Не все от этого тащатся вообще, а некоторые раньше тащились, а теперь перестали. Я, например.
0
Хоть для себя-то какой-то кайф получить от того, что сделал, настроил, и оно заработало в итоге

Кайф можно получить один раз — когда вы решаете новую для себя задачу. Когда вы настраиваете софт на своём десятом компе, эта задача вызывает у вас уже не кайф, а раздражение и скуку.
0
Так что проблема отнюдь не в том, что для разработки более качественного ПО нужно намного больше денег.
ИМХО нужно больше времени. Раньше обновления были не очень часто, а сейчас лидеры индустрии ПО похоже считают, что чем чаще — тем лучше для их фирмы-производителя этого ПО.
-7
Не надо многотысячных КБ для разработки софта, достаточно выкинуть «свистелки и перделки» из имеющегося. Замечательный пример — современный вэб. Что нужно для сайта? Ответ прост — HTML, CSS, PHP/Python, SQL — совместимая БД. Можно еще написать на JS несколько простейших функций для подтягивания контента без перезагрузки (тех же комментов). А все остальные мегабайты «нод джс», «джкверри», другие фреймворки и прочие кучи дерьма работают лишь ради «красивеньких» анимаций и прочих перделок.
+22
А все остальные мегабайты «нод джс», «джкверри», другие фреймворки и прочие кучи дерьма работают лишь ради «красивеньких» анимаций и прочих перделок.
Но ведь это же нормально!

Люди, которые думают иначе либо не читали пресловутого секрета айберга, либо не до конца осознали его.

Прицитирую самую важную часть:
Вы знаете, что 90% айсберга находится под водой? Ну и с большинством программ то же самое – есть красивенький интерфейс, который занимает 10% работы и потом 90% программистской работы «за кулисами». И если вы примете во внимание, что около половины времени уходит на исправление ошибок, то на пользовательский интерфейс уходит только 5% работы. И если вы ограничиваете себя только визуальной частью интерфейса, картинками, которые показываются в PowerPoint, то мы говорим сейчас менее, чем об 1%.

Это не секрет. Секрет в том, что люди, которые не являются программистами, не понимают этого.
Сейчас мы наблюдаем простое и естественное следствие из этого закона: если люди озабочены только и ислючительно пискелями на экране — то только на оптимизацию этого параметна и будет обращено внимание.

И, кстати, зря он програмисстов отделил. Они точно также считают. Я это понял, когда увидел фразу Есть еще Gerrit, который там как-то с этим борется, но интерфейс из 90х убивает все желание пользоваться этим. Речь шла об управлении VCS для программных проектов. Уж гиковей задачи быть не может. И… всё равно: пиксели — важнее.

Кстати разработчики Gerrit'а отреагировали адекватно: последняя версия выкинула нафиг «устраевший» интерйес, который позволял мне с клавиатуры сделать то, что мне нужно за секунды. Теперь это «чудо природы» грузится многие секунды (иногда десятки секунд), глючит, но… зато у него теперь современный интерфейс! Победа!

Автор статьи вообще не понимает, где причина, а где следствие: машину с потребелением топлива 1000 листров на 100 киломестров — никто не купит. А сайт, который теряет данные, будет пользоваться большей популярностью, чем сайт «с интерфейсом из 90х». Вот и всё. Вот и вся «тайна».

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

Почему автор вообще к разработчикам обращается? Не в них ведь дело!
-1
Тут, батенька, вот еще какое дело. Капитализм выращивает (нытик-фильм на 3 часа!) невежд, так как фрустрированному тревожному дураку проще все это барахло и скармливать.

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

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

Т.е. требовать от большинства людей хотя бы базового понимания как это все устроено нерационально. И сопоставимо с требованием от всех понимания физиологии человека или электродинамики. Это в мире где большинство верит в ящериков и думает, что Солнце вращается вокруг плоской Земли.
+16
Во всем всегда виноват капитализм. Вот в других странах нет ничего, кроме ядерных ракет и медведей, зато у всех мозги — так мозги, кредитов нет, цацок дорогих нет, дешевых — тоже нет, ничего нет, кроме ЧСВ раздутого «зато не капитализм».
Причем тут капитализм? Просто производство хламья очень просто, дешево и удобно — думать не надо в первую очередь разработчикам и производителям.
Сейчас зачастую даже имея неограниченные деньги, некоторых нормальных вещей не купить — разве что в виде завода, и потом дрючить его до тех пор, пока руки переместятся с места ниже поясницы на свое нормальное.
0
Окей, я могу плавать в терминах или же вообще ошибаться. На мой взгляд корни у всей этой байды в том, что экономику «разгоняют» через стимуляцию спроса. А именно путем агрессивного маркетинга, инфляции и запланированного устаревания. В т.ч. софтового.

Еще вмешательством в образование, которое (мало того, что само превращается в модную услугу, впариваемую родичам через тревогу за детей) не позволяет сформировать у человека целостную картину мира. Производя «радостных олигофренов» чья уверенность следствие эффекта Даннинга-Крюгера.
+2
Не экономику разгоняют, а разгоняют цифирь показателей (рост экономики в процентах, число обновлений софта за год, количество моделей за сезон и тд). Плюс маркетинг — это такая религия, которая верит в силу самой себя. Маркетологи, а за ними программисты твердят: «Нужно больше обновлений, потому что людям нужно новое бла-бла». Только вот я с сотню людей спрашивал — все они ненавидят обновления лютой ненавистью, и зачастую не ставят их. Т.е. получается, что религиозники-маркетологи придумали миф, и подгоняют все под этот миф, а то. что реальность с ним не соотносится — тем хуже для реальности.
Ничто не мешает писать не кривой софт, и сократить число обновлений до одного в год-два вместо бешеного клепания бесконечных обнов, которые делают только хуже. И это будет даже дешевле, чем сейчас, но никто это не делает, потому что производители живут в своем вымышленном мире и пытаются следовать его законам, которые в реальном мире не работают или работают не так.
+3
Только вот я с сотню людей спрашивал — все они ненавидят обновления лютой ненавистью, и зачастую не ставят их.
Вот только выход обновлений — приводит к увеличению продаж/скачиваний/etc.

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

И тут получается парадокс: те пользователи, которые у вас уже есть — они обновления ненавидят… но они у вас уже есть, и, в среднем, никуда не деваются… а вот новых выпуск обновлений с новими фишками привлечёт с большей вероятностью, чем исправление багов.
0
Ничто не мешает писать не кривой софт, и сократить число обновлений до одного в год-два вместо бешеного клепания бесконечных обнов, которые делают только хуже.

Как минимум мешает невозможность учесть все nullday эксплоиты, повышенные затраты времени и денег на усиленное тестирование (которое опять же не гарантирует 100% отсутствие багов, а лишь увеличивает вероятность их обнаружения) и тот факт, что значительная часть софта — это не изолированная вещь в себе, а программа, общающаяся со сторонними компонентами, которые часто меняются. Вы выпустили клиент для инстаграмма, а завтра фб объявил об изменении api или вовсе закрыл доступ к нему. Вы выпустили графический редактор с поддержкой всех существующих камер, а через неделю олимпус объявил о выходе 5 новых фотоаппаратов с новым форматом рав, либо конкурент встроил функцию новую, без которой ваш продукт стал неинтересен аудитории. Вы уже отчаялись и написали простой блокнот для айфона, а тут эппл решил отказаться от поддержки 32-битных приложений в новых версиях ios.
+2
Как минимум мешает невозможность учесть все nullday эксплоиты, повышенные затраты времени и денег на усиленное тестирование
Это же противоречивое высказывание. Качественное тестирование (вместе с качественной разработкой) спасёт вас от null-day эксплойтов.
И не говорите, что это невозможно. Сколько дырок нашли в AS/400? В системах крутятся бухгалтерии космических масштабов, наверняка есть желающие их расковырять. И не расковыряли почему-то.
А разгадка проста: AS/400 делается для людей, которые умеют зарабатывать и считать большие деньги. А условный айфон — для закомплексованных потребителей, которые считают, что за новый телефон их сильнее будут уважать коллеги по опенспейсу. И новые сайты с 10-мегабайтными страницами — для них же, и будут посещать, потому что конформное поведение.
0
И не говорите, что это невозможно. Сколько дырок нашли в AS/400? В системах крутятся бухгалтерии космических масштабов, наверняка есть желающие их расковырять. И не расковыряли почему-то.


Разгадка проще — вы либо не слышали об этих nullday уязвимостях (вы слышали о stuxnet, heartbleed или meltdown до их появления? насколько публично IBM вообще объявляет о своих уязвимостях? Или они всегда пишут идеальный код?), либо система представляет собой неуловимого Джо (экономически целесообразнее ломать конкурентов, либо другие компоненты системы, особенно если атака точечная).

Ну не может единоразовое тестирование системы никак закрыть все баги и уязвимости. Не с нынешними технологиями. В таких компаниях как google, facebook, microsoft тестирование включает в себя регулярно работающую bug bounty не потому, что они наняли идиотов разработчиков. Сколько лет прошло с момента запуска интелом уязвимой архитектуры и до момента обнаружения spectre/meltdown? Тоже скажете, что в интел дураки сидят?
0
вы слышали о stuxnet, heartbleed или meltdown до их появления?
Слышал после.
А вы слышали о дырах в System i, до или после?
скажете, что в интел дураки сидят?
Интел и остальные упомянутые делают ширпотреб. Они не делают идеальных продуктов, ну так за идеальность им никто и не платит. Выгоднее приделать новые фичи, чем вылизывать старые — такая ниша.
+1
А вы слышали о дырах в System i, до или после?
А вы вообще много с System i общаетесь? Дыры там тоже есть: одна, две, три, четыре… и процессоры тамошние тоже уязвимы

Так что дыр в ваших любимых AS/400 — примерно столько же, сколько в процессорах Intel или AMD. Спасает их одно: на них кошечек из YouTube не смотрят… потому проще что-то сделать через одну из тысяч дыр в системе, через которую с System i общаются, чем взламывать собственно System i через одну дырку и нескольких десятков, что там есть…
0
Так что дыр в ваших любимых AS/400 — примерно столько же, сколько в процессорах Intel или AMD.
Ну да, что там больше нуля, что тут больше нуля. Столько же, чо.
0
Ну да, что там больше нуля, что тут больше нуля. Столько же, чо.
И там и там их [пока] накопали больше нуля, но меньше десятка. Что сравнимо (когда у вас есть одна-две уязвимости оценить дисперсию очень сложно).

А вот в «обычных» операционках — их тысячи!
0
Сколько лет прошло с момента запуска интелом уязвимой архитектуры и до момента обнаружения spectre/meltdown? Тоже скажете, что в интел дураки сидят?

Нет, чекисты :)
+1
А разгадка проста: AS/400 делается для людей, которые умеют зарабатывать и считать большие деньги.

Разгадка, как мне сдаётся, в том, что к айфонам и сайтам доступ имеют миллиарды людей, из которых десятки тысяч ищут уязвимости. А к iSeries доступ имеют десятки тысяч людей, из которых уязвимости ищут единицы. Мне довелось лет десять назад работать с iSeries, я не искал там уязвимости, но по субъективным ощущениям количество индусов, пишущих под неё софт, ничуть не меньше, чем в других сферах.
0
Сократить количество обновлений просто нельзя — банальные ошибки в софте и уязвимости будут оставаться незакрытыми годами… Посмотрите на нынешние обновления. Что-то кардинально меняется в интерфейсе? Ну, может быть… раз в год. А в остальном обновления касаются исключительно внутренней скрытой части софта, что не видно глазами но сильно влияет на его функционирование в современном мире. Перестанешь обновлять софт — через год он окажется дырявым как сито и никому не нужным т.к. конкуренты залатали дырки и распространили с очередным недельным обновлением.
+1
Так может нужно сразу выпускать РАБОТАЮЩИЕ приложения, прошедшие тестирование. А не обновлять (читайте исправлять) «внутренние».
0
Предлагаю попробовать прикинуть сколько надо ресурсов чтобы проверить простейшую программу которая складывает два 32-битных числа, а именно полный её тест. А потом приступить к надёжному тестированию более сложных программ. Без полного теста всех вариантов состояний программы и переходов между ними никакой гарантии отсутствия ошибок в программе быть не может.
А пока такие программы выходят в свет лишь в надежде что АЛУ процессора нас не подведёт, и как правило так и бывает. Но есть ньюанс…
+1
Без полного теста всех вариантов состояний программы и переходов между ними никакой гарантии отсутствия ошибок в программе быть не может.

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


Хотя...


А пока такие программы выходят в свет лишь в надежде что АЛУ процессора нас не подведёт, и как правило так и бывает.

А, так вы на каждой целевой машине тестировать будете? Ну ладно.

0
А как ещё можно доказать что программа действительно правильно складывает ЛЮБЫЕ числа? Целевые машины непричём — мы проверяем программу. Программа — черный ящик, она складывает числа. На входе два 32-битных числа, на выходе — результат. Нам надо убедится что программа работоспособна и правильно работает для любых чисел на входе. Сейчас мы просто предполагаем что такие простейшие операции не нуждаются в проверке и заранее считаем их валидными, но если такой уверенности нет? Механизм сложения, допустим, нетрадиционный и в нём проверяется множество условий. Каждая такая проверка увеличивает количество вариантов состояний которые надо проверить, и с ростом сложности программы оно растёт очень быстро. Даже для современного варианта «хелло-ворлда» количество состояний стремится к неприличной величине, и даже в такой программе может возникнуть сбой по вине операционки или скажем драйвера видеокарты.
0

Ну если у вас нетрадиционный вариант сложения, скажем, myplus, то вы берёте и пишете другую функцию, например,
myPlusEqualsPlus с типом (a, b : Int32) -> (myplus a b = a + b) (как говорит Карри-Говард, этот тип эквивалентен утверждению, что для любых a и b значение myplus a b равно значению a + b), пишете её реализацию (как говорит Карри-Говард пополам с теорией типов, реализация является доказательством соответствующего утверждения) и радуетесь жизни.


Правда, при написании доказательства от чёрноящиковости придётся доказаться.


Или не отказаться и использовать внутреннюю верификацию, тогда на внутренность myplus смотреть не нужно, но её сигнатура изменяется с myplus : (a, b : Int32) -> (c ** a + b = c). Зависимый тип-сумма, это всё.


Как, по-вашему, математики теоремы доказывают? Проверяют все возможные значения переменных?