Это все нужно начинать с целей: зачем это вообще кому-то нужно (не html, а выписка как таковая). Я вижу цели (но могу в них глубоко заблуждаться):
Очевидная: передать клиенту реквизиты и сумму, которую он должен заплатить. Для этого можно вообще не заморачиваться, а это крупным шрифтом и напечатать.
Прозаичная: подтверждение клиенту что вы будуте ему оказывать эти конкретно услуги, за которые он платит (я понимаю, что есть договор для этого, но см. пункты дальше).
Юридическое оправдание со стороны клиента чтобы он показал "мы оплатили вот эти услуги, бла бла бла" (клиент мог показать в суде что было оплачено)
Чтобы вы могли в суде показать что конкретно оплачено
Чтобы клиент мог показать бумажку по бухгалтерии за что они заплатили при проверке. К слову, платить тоже бухгалтерия будет.
Пункты 2 и 4 в данном случае означают, что этот документ может быть рано или поздно отправлен на печать. Скорее всего рано и потом будет сложен в стопку расходов.
Пункт один требует наличие детализированной таблицы, с помощью которой отдел разработки или кто там будет отображать бухгалтерии за что они конкретно они там будут платить и бухгалтерия 99% развернет их, если не будет расшифровки. Еще может использоваться бухгалтерией для решения в будущем подъема / срезания капитала отдела. Ну и так далее. Это я к тому, что вряд ли получится выкинуть и бумажный вариант, и таблицу. Более того, стремление к какой-то непонятной внутренней красоте с убиранием полезной и удобной информации как по мне просто показатель непонимания как это будет использоваться. Попросту говоря, это приводит к усложнению работы бухгалтерии на стороне клиента. А с учетом того, что кроме этой, собственно, бухгалтерии и аудиторам, которые в эту бухгалтерию ходят, эта вещь вообще мало кому уперлась, это просто некрасиво.
Да, я могу заблуждаться и может оказаться что таблица действительно с расшифровкой никому не нужна. Но что-то мне подсказывает, что если вы её уберете, она перестанет казаться никому не нужной.
Так задумано. Именно, чтобы можно было автоматически парсить пользовательские назначения платежа с ошибками
Это обязательно породит кучу путаницы вокруг "что из этого день, а что месяц". Пишите в timestamp, чего уж мелочиться :)
Есть принятые стандарты (типографии, в данном случае), и если есть техническая возможность следовать им, почему нет? Именно такие мелочи делают ощущение несерьезности к подходу. Пока по верстке, разным форматам, кавычкам, отступам, вертикальному гриду и прочему складывается ощущение что это делал джун разработчик и дизайнера никто даже проверить не просил. И, тем более, никто не носил это в свою же бухгалтерию, послушать что они скажут.
Шаг ли это вреперд по сравнению со стандартными формами? Мне кажется, что нет, и что это огромный прыжок назад: все привыкли к стандартным формам, и пусть они некрасивые, они делалить теми и для тех, кто их будет читать и кто привык к ним, и изменять это в сторону красивого очень супер сложно. Это как если бы человек без навыков программирования пришел рисовать мне как должна выглядеть IDE.
Вот пример: где я живу, тут всегда одинаковые счета-фактуры. Я всегда знаю что в нижнем правом углу есть банкгиро код, слева от него ОКР номер, сумма под табличкой справа. Если кто присылает в другом формате — ставит меня в тупик. Даже если это будет супер красиво, мне нужно будет искать глазами где что и как и будет бесить, пусть листок будет самым красивым в мире с позолотой.
P.S. Только что подумал, что довольно вероятным использованием является подшивание в папку и пролистывание разных фактур для быстрого поиска по счету оплаты с целью "за что мы заплатили 100500 рублей". Теперь попробуйте распечатать свою форму, сшить её как принято в России (за левый корешок, там еще, к слову, в вашем логотипе дырку сделают хах), и быстро найти счет?
P.P.S. Хорошо, похоже кавычки победили, на елочки все забили.
Показывать счет в html довольно удобная вещь, обладает своими преимуществами. Однако в вашем примере "красивым" назвать это сложно.
Так не понятно, но есть ощущение что цена выравнена по левой стороне. Это достаточно грубая ошибка: цены всегда выравниваются по правой границе, причем ровно по точке, так гораздо проще сравнивать.
Итого должно быть в той же колонке, а не где получится, потому что сразу видно и легко подсчитать. Сейчас его откровенно нужно искать глазами
Что будет если одна услуга будет заказана дважды? А если какая-то услуга будет скидкой? Как-то откровенно не хватает столбцов.
Отсутствие отступов и бесполезная зебра в таблице, все это только усложняет чтение. В общем, есть же правила формирования красивых и читаемых таблиц.
Теперь немного не про таблицу.
Я буду вам очень благодарен за пустую трату чернил на ваш огромный плотный логотип, да. Еще и в цвете. Можно и по-скромнее быть.
Слева пустота, а сама таблица пытается влезть в очень узкое место. Я бы поместил данные в шапку, а таблицу бы растянул на всю ширину. И это примерно как люди ожидают увидеть страницу. Заодно уберет проблемы с несколькими страницами: на дополнительных страницах будет только полезная таблица, а не бесполезная пустота.
На странице три даты и все в разном формате.
Как будет выглядеть заказчик "НИИ им. Орджаникидзке двух Орденов Ленина и Ордена Красной звезды университет Московский Авиационный Институт".
Всем плевать, но в России официально кавычки это "« »".
Ну и просто визуально несбалансированно, одна часть страницы очень тяжелая, сомнительное выравнивание в левой части, в общем, есть куда развивать.
Наблюдал как люди носят маски. Женщина стянула маску, чехнула в руку (в маске же не удобно чихать), почесала нос, надела обратно. И вообще гигиена ношения масок, зачастую по много часов, а то и дней, только увеличивает шанс заразиться. А так да, в лаборатории все хорошо и красиво, свежая чистая маска, все аккуратно носят и не снимают чтобы чхнуть.
Скажите это по крайней мере 1% населения с аллергией на пенициллин (Источник). Меня из-за него два раза откачивали в детстве (кто-то не учится на своих ошибках, ага, постсоветская медицина?). Может уже и прошло, но антибиотики - последнее на что я рискну.
Ну можно сделать сильно проще используя CloneNode. Только не уверен что вызванный этим пересчёт лейаута не приведёт к большему падению производительности. Я бы в идеале хотел бы использовать тот факт, что контент дивчика и так уже отправлен на видеокарту как текстурка, и достаточно просто не трогать контент, а анимировать средствами видеокарты (translate свойства), было бы практически бесплатно
Это, конечно же, правда, но большинство библиотек, предоставляющих подобный функционал (как правило, модалки с анимашкой), делают проверку внутри и не монтируют ничего пока модалка не отображена, и отмантируют обратно после анимашки, так что накладные расходы не такие уж и большие (если подходить аккуратно).
хм, было бы здорово если бы в браузере была какая-то апишка типа «сделать скриншот дивчика и показывать его пока идёт анимашка», но вот нет.
Некорректный пример (как написали выше). Самый крутой способ это когда можно вынести функцию из компонента, но доступен далеко не всегда. Дальше начинается вопрос с useCallback и тут очень все непросто, покуда сам useCallbakc не бесплатен и вопрос что дешевле: перерисовать компонент или прибегнуть к хукам совсем не прост.
Спасибо, капитан, мы учтём что нудно каждый раз думать обновление каких данных должно приводить к перерисовки. Впрочем, это отличный способ заняться преждевременной оптимизацией: при изменении бизнес требований часто нужны другие части для обновления. А Json stringify это победа. Гораздо лучше заранее правильно проектировать данные, все эти deep compare абсолютно всегда стрельба себе в ногу без исключений.
Прощайте анимашки, хех. Это я к тому что обычно библиотеки требуют такой апи (привет antd) не просто так, в противном случае это копитанство.
великолепный перевод, в котором полностью потерян смысл. На первый взгляд появляется ощущение что async await накладывает дополнительные расходы (что оно делает, но это экономия на спичках. Да даже не спичках, а что еще дешевле?), но по тексту просто рекомендация грузить данные параллельно. Это, кончено, хорошо, но не всегда просто или вообще возможно, а ещё очередное капитанство и вообще не имеет отношения к реакту, а скорее про js или вообще про программирование как таковое.
Но знаете что? Я плюсану статью, может это вынудит других разработчиков смотреть другие пути оптимизации приложений и прекратит скатывание веба в тот ад, в котором он оказался? Хотелось бы верить.
Однако адгезивный материал способный на такое был бы крайне полезен во многих отраслях
Наудивление сложно найти какие-то пруфы, но вот Один пример, согласно которому даже такая крошечная площадь контакта держит от 50Н даже для обычного момента, т.е. для удержания человека за обувь понадобится всего в 20 раз большая площадь контакта, что сильно меньше площади подошвы.
Это я к тому, что реклама слегка врет по скорости схватывания, но приклеить ботинок к потолку чтобы он выдержал массу человека не такая уж и проблема. Подошва раньше оторвётся
Да, каких я идей только не слышал: сверхзвуковые самолеты, сверхбольшие самолеты, сверхмаленькие самолеты, самолеты, которые могут садиться на дороги общего пользования и становиться машинами, самолеты которые могут садиться на крышу, самолеты которые летают в космосе, самолеты, которые летят в двух метрах над водой, и экономят кучу топлива, круглые аэропорты, аэропорты на высоте 10 км (здравая идея с здоровенными проблемами), отстегивающийся фюзеляж, да даже ядерные самолеты, которым вообще не нужна дозаправка. Только что-то за последние 50 лет из инноваций только то, что теперь расписание полета на айпадике смотрят, а не печатают на бумаге.
Конечно многие идеи очень интересные и было бы здорово увидеть возвращение сверхзвуковых самолетов, но в реальности больше верится в то что райнэир скорее найдет как вместить в самолет еще больше людей, чем что нас ждет возвращение Конкорда. Ну и с учетом что даже от легенды 747 отказались, самой прибыльной и работающей моделью ялвяются среднемагистральные а320 и модель лоукостера, спроса на ультразвук должно быть рекордно мало.
P.S. Некоторые идеи крутые, но, как показало время и экономика, быть крутой — недостаточно.
P.P.S Я слегка утрирую про инновации, но, в основном, они всё же касаются безопасности и добавлению автоматизации, концептуально изменений нет.
А сколько свопа съедено на 4гб? Понятное дело что система резервирует память если она есть, но это напрямую влияет на общее ощущение производительности, например, если не будет хватать памяти держать в ней последние используемые файлы, сиамка будет вынуждена постоянно из писать и считывать с диска, что неблагоприятно скажется на производительности (я предполагаю что с ультрабуке с 4гб вряд ли супер быстрый ssd).
Чуть ли не 10 лет назад разрабатывал примитивный автопилот для автомобиля. Ну он должен был ездить по определенной площадке с хорошо известными препятствиями. Всё бы ничего, но на самом въезде в площадку был бетонный блок, который системой зрения не распознался… Никто не пострадал, кроме самой платы, которую пришибло отлетевшим аккумулятором (никого не было в машине по понятным причинам, а кнопки аварийной остановки развались при нажатии, это было фиаско).
Да, только нужно будет обзавестись привычкой говорить всем кому вы шлете письма «проверьте папку «спам»», а то современные почтовые сервисы ой как не доверяют всему что не является Гуглом Майкрософтом и ещё парой крупных поставщиков
Ну он не выглядит в два раза выше чем шире, так что думаю что в википедии более правильная информация. Цена, скорее всего, в статье проектная, в википедии итоговая, но не уверен.
Неа. Были базовые настройки, но последнее время проекты достаточно большие, пришлось предать нативный вим и перебраться в vs code с vim режимом. Вот думаю попробовать omnivim2, но не уверен в судьбе проекта
Я поколечен вимом и у меня хоум роу для правой руки на единицу смещён. И вообще мозг выработал удобную методику пользования горячими клавишами и мне достаточно удобно. Не думаю что какие-то переучивания приведут к повышению продуктивности.
Главный недостаток что пользоваться любым редактором без vim режима теперь физически больно.
Вообще нужно заметить, что это справедливо только если сравнивать с innerHTML. Если ручками делать через ссылку на конкретный элемент и Создавать через document.createElement(), то virtual Dom обречён быть медленнее (потому что он это и делает внутри). И если обновить только один элемент в массиве через конкретный элемент - только он и пересчитанная (не считая пересчета layout, но виртуальное дерево тут тоже не помощник, если чей-то размер поменялся, браузер вынужден пересчитать остальные).
И, справедливости ради, шаблонизатор с грамотным биндингом (который будет изменять значения только когда они меняются, причём не через innerHTML, а element.setAttribute к примеру), будет заведомо быстрее виртуального дома.
Ну и виртуальный дом начинает значительно тупить при большом количестве узлов (10 000+), нужно ещё и виртуальный рендеринг прикручивать.
Огромное и, возможно, главное преимущество виртуального дома - это удобство и возможность делать всякие willUnmount.
PS ещё пропущен concurrent mode, который не увеличивает скорость отрисовки, но повышает отзывчивость, и тут виртуальный дом превосходен.
Потому что это прям совсем не так. Почему-то достаточно сложно найти точные цифры, но интернет говорит что согласно US National Transportation Safety Boardвыживаемость при авиаварии составляет 95%, да и вообще самолету нужно прям совсем во что-то врезаться или разобраться в полёте для совсем плачевных ситуации. Ну т.е. аналогия с автобусом будет если по автобусу стрельнет танк или автобус врежется в стену на полном ходу.
Да, что-то я пропустил что в мембрану сложнее встроить диоды перед каждой кнопкой. Но проблема по-прежнему общая и тут скорее вопрос целесообразности, проблема решаемая и там и там.
Не уверен про «ножницы», но Тут есть пару примеров. В целом не вижу никаких технических ограничений, разве что нерационально переусложнять конструкцию. Ну и ещё я бы добавил что обычно механические клавиатуры значительно более дорогие, и начинают добавлять всякие антигостинг.
Спасибо! Продолжу свою мысль:
Это все нужно начинать с целей: зачем это вообще кому-то нужно (не html, а выписка как таковая). Я вижу цели (но могу в них глубоко заблуждаться):
Пункты 2 и 4 в данном случае означают, что этот документ может быть рано или поздно отправлен на печать. Скорее всего рано и потом будет сложен в стопку расходов.
Пункт один требует наличие детализированной таблицы, с помощью которой отдел разработки или кто там будет отображать бухгалтерии за что они конкретно они там будут платить и бухгалтерия 99% развернет их, если не будет расшифровки. Еще может использоваться бухгалтерией для решения в будущем подъема / срезания капитала отдела. Ну и так далее. Это я к тому, что вряд ли получится выкинуть и бумажный вариант, и таблицу. Более того, стремление к какой-то непонятной внутренней красоте с убиранием полезной и удобной информации как по мне просто показатель непонимания как это будет использоваться. Попросту говоря, это приводит к усложнению работы бухгалтерии на стороне клиента. А с учетом того, что кроме этой, собственно, бухгалтерии и аудиторам, которые в эту бухгалтерию ходят, эта вещь вообще мало кому уперлась, это просто некрасиво.
Да, я могу заблуждаться и может оказаться что таблица действительно с расшифровкой никому не нужна. Но что-то мне подсказывает, что если вы её уберете, она перестанет казаться никому не нужной.
Это обязательно породит кучу путаницы вокруг "что из этого день, а что месяц". Пишите в timestamp, чего уж мелочиться :)
Есть принятые стандарты (типографии, в данном случае), и если есть техническая возможность следовать им, почему нет? Именно такие мелочи делают ощущение несерьезности к подходу. Пока по верстке, разным форматам, кавычкам, отступам, вертикальному гриду и прочему складывается ощущение что это делал джун разработчик и дизайнера никто даже проверить не просил. И, тем более, никто не носил это в свою же бухгалтерию, послушать что они скажут.
Шаг ли это вреперд по сравнению со стандартными формами? Мне кажется, что нет, и что это огромный прыжок назад: все привыкли к стандартным формам, и пусть они некрасивые, они делалить теми и для тех, кто их будет читать и кто привык к ним, и изменять это в сторону красивого очень супер сложно. Это как если бы человек без навыков программирования пришел рисовать мне как должна выглядеть IDE.
Вот пример: где я живу, тут всегда одинаковые счета-фактуры. Я всегда знаю что в нижнем правом углу есть банкгиро код, слева от него ОКР номер, сумма под табличкой справа. Если кто присылает в другом формате — ставит меня в тупик. Даже если это будет супер красиво, мне нужно будет искать глазами где что и как и будет бесить, пусть листок будет самым красивым в мире с позолотой.
P.S. Только что подумал, что довольно вероятным использованием является подшивание в папку и пролистывание разных фактур для быстрого поиска по счету оплаты с целью "за что мы заплатили 100500 рублей". Теперь попробуйте распечатать свою форму, сшить её как принято в России (за левый корешок, там еще, к слову, в вашем логотипе дырку сделают хах), и быстро найти счет?
P.P.S. Хорошо, похоже кавычки победили, на елочки все забили.
Показывать счет в html довольно удобная вещь, обладает своими преимуществами. Однако в вашем примере "красивым" назвать это сложно.
Теперь немного не про таблицу.
Наблюдал как люди носят маски. Женщина стянула маску, чехнула в руку (в маске же не удобно чихать), почесала нос, надела обратно. И вообще гигиена ношения масок, зачастую по много часов, а то и дней, только увеличивает шанс заразиться. А так да, в лаборатории все хорошо и красиво, свежая чистая маска, все аккуратно носят и не снимают чтобы чхнуть.
Скажите это по крайней мере 1% населения с аллергией на пенициллин (Источник). Меня из-за него два раза откачивали в детстве (кто-то не учится на своих ошибках, ага, постсоветская медицина?). Может уже и прошло, но антибиотики - последнее на что я рискну.
Ну можно сделать сильно проще используя CloneNode. Только не уверен что вызванный этим пересчёт лейаута не приведёт к большему падению производительности. Я бы в идеале хотел бы использовать тот факт, что контент дивчика и так уже отправлен на видеокарту как текстурка, и достаточно просто не трогать контент, а анимировать средствами видеокарты (translate свойства), было бы практически бесплатно
Это, конечно же, правда, но большинство библиотек, предоставляющих подобный функционал (как правило, модалки с анимашкой), делают проверку внутри и не монтируют ничего пока модалка не отображена, и отмантируют обратно после анимашки, так что накладные расходы не такие уж и большие (если подходить аккуратно).
хм, было бы здорово если бы в браузере была какая-то апишка типа «сделать скриншот дивчика и показывать его пока идёт анимашка», но вот нет.
Некорректный пример (как написали выше). Самый крутой способ это когда можно вынести функцию из компонента, но доступен далеко не всегда. Дальше начинается вопрос с useCallback и тут очень все непросто, покуда сам useCallbakc не бесплатен и вопрос что дешевле: перерисовать компонент или прибегнуть к хукам совсем не прост.
Спасибо, капитан, мы учтём что нудно каждый раз думать обновление каких данных должно приводить к перерисовки. Впрочем, это отличный способ заняться преждевременной оптимизацией: при изменении бизнес требований часто нужны другие части для обновления. А Json stringify это победа. Гораздо лучше заранее правильно проектировать данные, все эти deep compare абсолютно всегда стрельба себе в ногу без исключений.
Прощайте анимашки, хех. Это я к тому что обычно библиотеки требуют такой апи (привет antd) не просто так, в противном случае это копитанство.
великолепный перевод, в котором полностью потерян смысл. На первый взгляд появляется ощущение что async await накладывает дополнительные расходы (что оно делает, но это экономия на спичках. Да даже не спичках, а что еще дешевле?), но по тексту просто рекомендация грузить данные параллельно. Это, кончено, хорошо, но не всегда просто или вообще возможно, а ещё очередное капитанство и вообще не имеет отношения к реакту, а скорее про js или вообще про программирование как таковое.
Но знаете что? Я плюсану статью, может это вынудит других разработчиков смотреть другие пути оптимизации приложений и прекратит скатывание веба в тот ад, в котором он оказался? Хотелось бы верить.
Наудивление сложно найти какие-то пруфы, но вот Один пример, согласно которому даже такая крошечная площадь контакта держит от 50Н даже для обычного момента, т.е. для удержания человека за обувь понадобится всего в 20 раз большая площадь контакта, что сильно меньше площади подошвы.
Это я к тому, что реклама слегка врет по скорости схватывания, но приклеить ботинок к потолку чтобы он выдержал массу человека не такая уж и проблема. Подошва раньше оторвётся
Гиперлуп на суше запустить лет 15 не могут, посмотрю как его будут строить через Атлантику
Да, каких я идей только не слышал: сверхзвуковые самолеты, сверхбольшие самолеты, сверхмаленькие самолеты, самолеты, которые могут садиться на дороги общего пользования и становиться машинами, самолеты которые могут садиться на крышу, самолеты которые летают в космосе, самолеты, которые летят в двух метрах над водой, и экономят кучу топлива, круглые аэропорты, аэропорты на высоте 10 км (здравая идея с здоровенными проблемами), отстегивающийся фюзеляж, да даже ядерные самолеты, которым вообще не нужна дозаправка. Только что-то за последние 50 лет из инноваций только то, что теперь расписание полета на айпадике смотрят, а не печатают на бумаге.
Конечно многие идеи очень интересные и было бы здорово увидеть возвращение сверхзвуковых самолетов, но в реальности больше верится в то что райнэир скорее найдет как вместить в самолет еще больше людей, чем что нас ждет возвращение Конкорда. Ну и с учетом что даже от легенды 747 отказались, самой прибыльной и работающей моделью ялвяются среднемагистральные а320 и модель лоукостера, спроса на ультразвук должно быть рекордно мало.
P.S. Некоторые идеи крутые, но, как показало время и экономика, быть крутой — недостаточно.
P.P.S Я слегка утрирую про инновации, но, в основном, они всё же касаются безопасности и добавлению автоматизации, концептуально изменений нет.
А сколько свопа съедено на 4гб? Понятное дело что система резервирует память если она есть, но это напрямую влияет на общее ощущение производительности, например, если не будет хватать памяти держать в ней последние используемые файлы, сиамка будет вынуждена постоянно из писать и считывать с диска, что неблагоприятно скажется на производительности (я предполагаю что с ультрабуке с 4гб вряд ли супер быстрый ssd).
Чуть ли не 10 лет назад разрабатывал примитивный автопилот для автомобиля. Ну он должен был ездить по определенной площадке с хорошо известными препятствиями. Всё бы ничего, но на самом въезде в площадку был бетонный блок, который системой зрения не распознался… Никто не пострадал, кроме самой платы, которую пришибло отлетевшим аккумулятором (никого не было в машине по понятным причинам, а кнопки аварийной остановки развались при нажатии, это было фиаско).
Да, только нужно будет обзавестись привычкой говорить всем кому вы шлете письма «проверьте папку «спам»», а то современные почтовые сервисы ой как не доверяют всему что не является Гуглом Майкрософтом и ещё парой крупных поставщиков
Ну он не выглядит в два раза выше чем шире, так что думаю что в википедии более правильная информация. Цена, скорее всего, в статье проектная, в википедии итоговая, но не уверен.
Неа. Были базовые настройки, но последнее время проекты достаточно большие, пришлось предать нативный вим и перебраться в vs code с vim режимом. Вот думаю попробовать omnivim2, но не уверен в судьбе проекта
Я поколечен вимом и у меня хоум роу для правой руки на единицу смещён. И вообще мозг выработал удобную методику пользования горячими клавишами и мне достаточно удобно. Не думаю что какие-то переучивания приведут к повышению продуктивности.
Главный недостаток что пользоваться любым редактором без vim режима теперь физически больно.
Вообще нужно заметить, что это справедливо только если сравнивать с innerHTML. Если ручками делать через ссылку на конкретный элемент и Создавать через document.createElement(), то virtual Dom обречён быть медленнее (потому что он это и делает внутри). И если обновить только один элемент в массиве через конкретный элемент - только он и пересчитанная (не считая пересчета layout, но виртуальное дерево тут тоже не помощник, если чей-то размер поменялся, браузер вынужден пересчитать остальные).
И, справедливости ради, шаблонизатор с грамотным биндингом (который будет изменять значения только когда они меняются, причём не через innerHTML, а element.setAttribute к примеру), будет заведомо быстрее виртуального дома.
Ну и виртуальный дом начинает значительно тупить при большом количестве узлов (10 000+), нужно ещё и виртуальный рендеринг прикручивать.
Огромное и, возможно, главное преимущество виртуального дома - это удобство и возможность делать всякие willUnmount.
PS ещё пропущен concurrent mode, который не увеличивает скорость отрисовки, но повышает отзывчивость, и тут виртуальный дом превосходен.
Потому что это прям совсем не так. Почему-то достаточно сложно найти точные цифры, но интернет говорит что согласно US National Transportation Safety Board выживаемость при авиаварии составляет 95%, да и вообще самолету нужно прям совсем во что-то врезаться или разобраться в полёте для совсем плачевных ситуации. Ну т.е. аналогия с автобусом будет если по автобусу стрельнет танк или автобус врежется в стену на полном ходу.
Хотя это контринтуитивно, конечно.
Да, что-то я пропустил что в мембрану сложнее встроить диоды перед каждой кнопкой. Но проблема по-прежнему общая и тут скорее вопрос целесообразности, проблема решаемая и там и там.
Не уверен про «ножницы», но Тут есть пару примеров. В целом не вижу никаких технических ограничений, разве что нерационально переусложнять конструкцию. Ну и ещё я бы добавил что обычно механические клавиатуры значительно более дорогие, и начинают добавлять всякие антигостинг.