Comments 7
Немного напомнило, как в свое время майкрософт сделала директх, чтобы обходным путем решить проблему быстрого вывода данных на экран. при этом беос могла все это сделать без лишних хаков с оверлеями и чисто софтверно. то есть проблема была в архитектуре.
Как насчёт учёта времени и стоимости разработки? Ассемблер будет быстро компилироваться, но писать его без ошибок долго и дорого.
А также, например, скорости и стоимости деплоя/развёртывания. Нативное приложение может быть быстрее — но заставить его поставить и обновалять сложно.
Почемуто их в статье не посчитали.
Если серьезно, вот вам непопулярная точка зрения: скорость в большинстве программных проектов не ставится в приоритет не только потому что
- Нет острого ощущения ее нехватки,
но (и это основная причина) потому что
- Если взяться за низкоуровневые/нативные инструменты, то большинство приложений будет слишком легко сделать достаточно быстрыми (достаточно — значит дальнейшее ускорение незаметно для пользователя)
fillpackart верно указал, куда ведет "неправильный" путь. Возможно, желания делать "правильно" нет потому что это неперспективно с точки зрения новых задач. И привычней оставаться в тени.
Т.е. вот летает у тебя какое-нибудь несложное приложение, мессенджер например, и что дальше? Делать проекты сложнее? Ну так их и так не совсем "неправильно" делают, скорее "на грани".
Короче говоря, люди сами создают себе трудности, усложняют задачи. А то вдруг закончатся
Если мы примем это как метафору разработки программного обеспечения, вы удивитесь, что программисты с радостью выбирают поезд. Они даже до хрипоты спорят, что есть неопровержимые причины для выбора поезда. Нет, они не возражают, чтобы компилятор не торопился «поработать». Хотя существуют более быстрые способы добраться до того же пункта назначения.Так прикол-то в том, что они этот поезд выбирают не для себя любимых, а для пользователя. Это не они будут трястись неделю в душном прокуренном плацкарте, а бедолага пользователь. А программисты наоборот довольны и радостны: поезд — это охрененно круто и совместимо. Высочайшая пропускная способность (аэропорт и близко не даст такого), возможность перевозить сотни тонн грузов, возможность остановиться буквально в любой точке маршрута, чтобы взять ещё людей (или их высадить) и ещё пять томов других преимуществ.
И вот когда над программистом не стоит злого-презлого менеджера с большой дубиной, который говорит ему: «ты у меня будешь делать так, как надо пользователю, а не тебе!» то на пользователя попросту забьют в пользу более комфортной разработки.
Кто ж спорит, что на Electron'е кодить не в пример приятнее и быстрее, чем на голом C++ в связке с каким-нибудь FLTK.
Пока подобные размышления никак не привязаны к стоимости разработки — название статьи можно без проблем заменить на "либо у вас этого нет, либо есть неоптимально". Мир софта немножечко шире библиотеки Datascript.
Не считать стоимость разработки можно только в мире розовых поней, где софт появляется сам собой, да еще и сразу в опенсорсе.
Либо быстро, либо неправильно