Его не нужно перезапускать, фласк сам перечитает шаблон при следующем его использовании. Это можно явно включить или выключить опцией TEMPLATES_AUTO_RELOAD
Вы видимо не понимаете, что такое джит. Если без джита — то будет какой-нибудь транслятор, который странслирует условный WebAssembly-байткод в машинный код и закэширует. И так как все оптимизации проведены ещё на уровне байткода, то такой транслятор в теории был бы чудовищно прост и почти не требовал бы ресурсов, в отличие от монстра V8 с его джитом, пытающимся оптимизировать говнокод на говноязыке хоть как-нибудь. И вообще вспомните Android: там тоже от джита отказались (теперь ahead-of-time компиляция при установке приложения), а кроссплатформенность как-то никуда не делась.
Ну идите к разработчикам http и рассказывайте им о том, что они все идиоты и говнокодеры.
Так они и без меня в курсе.
И ваш UT99 так бы тормозил и жрал память при подобной модели.
Ещё раз: значит такая модель не нужна.
А c++ и qt5 позволяет разрабатывать приложения и фичи так же быстро?
Ну у телеграма с этим проблем нет почему-то. Значит, видимо, позволяет. И за пять лет нормальный клиент Slack вполне можно было сделать.
А зачем?
Чтобы завести пользователю полезную ему фичу — экономию ресурсов — и не вынуждать тратить деньги на апгрейд компа, если перед запуском слака приходится выключать все виртуалки и наоборот.
Браузер стал мультиплатформерной средой разработки приложений.
И это отвратительно. О чём я в общем-то уже не раз высказывался на хабре, да и не только я. Можно было поадекватнее платформу придумать.
Покажите мне еще хоть одну такую же, которая жрет меньше памяти.
Android? Там даже запуск приложений без установки вроде где-то завозили.
Мне, например, удобно когда я могу в gmail назначить митинг, он отобразится в соседней вкладке в календаре, а если нажать на ссылку то откроется hangouts и я увижу всех собеседников по камере (а если станет скучно, можно еще и хабр тут же полистать, или параллельно что-нибудь в консоли AWS настроить и т.п.)
Это всё может любая нормальная ОС, будь под неё соответствующие приложения.
Я не хотел бы устанавливать по 100500 приложений на свой компьютер на каждый чих или мега-монструозные пакеты приложений от гугла и т.п.
Тем не менее вы это постоянно делаете в браузере. Чем скачивание кучи мегабайт пожатых джаваскриптов с последующим их кэшированием принципиально отличается от установки? Разве что кнопочку «Установить» кликать не надо — ну так никто не запрещает сделать аналогично где-нибудь на уровне ОС или просто платформе более адекватной чем браузер, только все прицепились к браузерам и никому это не нужно теперь.
Не думаю что мир без современных браузеров был бы гарантировано лучше.
А я думаю. Всё, что сейчас происходит в браузерах, можно было сделать и альтернативными способами без браузеров, причём более адекватными.
несколько лет назад все смеялись над текстовыми редакторами на электроне
Я и сейчас смеюсь, особенно когда выходят новости про мигающий курсор, кушающий 13% процессора)
Почему оптимизации под IE-то, я пишу всё строго в соответствии с HTML5 и CSS3 и с парой полифиллов сбоку, доводящих IEшный жс до используемого мной подмножества ES5. (В полифиллах, может, и говнокод, но не пофиг ли, если они завёрнуты в <!--[if lt IE 9]>?)
Также, хочу отметить, что в файле app/init.py, в инструкции импорта, лучше вписать точку, вместо явного определения имени текущего каталога (пакета Python), это не будет вызывать взрыв мозга, что откуда берется и будет ясность.
Меня учили ровно наоборот: при точке непонятно, откуда это дело импортируется, приходится идти путь к текущему файлу смотреть, отрываясь от кода.
Также, если пакет переименуется, то ничего из этого не сломается
Меня учили ровно наоборот: при переименовании или перемещении точка может замаскировать сломавшиеся импорты, поэтому лучше прописывать всё явно, чтобы на сложных случаях вылетел ImportError, а не непонятно что, когда случайно импортировался другой подмодуль с таким же именем. (Хотя, возможно, к __init__ это не относится, но ведь явное лучше неявного же?)
Не знаю, как часто это всё встречается на практике, но такое мнение тоже есть.
TeX я здесь не вижу, кастомный шрифт я вижу всего один, и без него я спокойно обошёлся бы. Как верстающий под IE8 заявляю, что хабр прекрасно мог бы работать и под IE8, если бы разработчики не ленились обеспечить соответствующую совместимость (возможно и под IE6 тоже, но под него пилить сайты слишком уж трудно, а под IE8 нормально, проверено на себе).
У меня чистый vsc жрал полгига сразу после первого запуска без каких-либо сторонних плагинов. Мы в разных вселенных живём что ли?
Современные джиты вполне успешно оптимизируют мономорфный динамический код до практически неотличимого от статического.
Вы запутались. Джиты не нужно было бы изобретать, если бы изначально было нормальный язык, компилирующийся во что-нибудь нормальное. А теперь эти сами джиты, наверно, и отъедают те самые полгига памяти — они проделывают очень много работы ради оптимизаций, которые можно было бы не проделывать с изначально нормальным языком. А теперь куча человекочасов угроблено в попытках добиться того, чтобы говноязык не так сильно тормозил. К счастью, в последнее время народ одумался и запилил WebAssembly — я очень надеюсь, что с ним веб станет лучше и скромнее по ресурсам. Хотя и он тоже не без недостатков.
С++ не работает в браузерах.
Мы подходим к самому главному: пришло время избавиться от браузеров! Ещё немного, и получится Telegram!))
Поверьте, в исходниках slack нету ничего про пиксели, rgb и 8бит на канал.
Уверен, хотя бы несколько PNG-картинок найдутся. Да и в CSS что-нибудь подобное обязательно упоминается. Но всё равно это не причина тормозить и жрать память.
Если бы UT99 манипулировал тем же, чем slack (dom), то он и тормозил бы соответствующим образом.
Отсюда напрашивается вывод: dom нахрен не нужен! Slack написан на технологиях, идеально подходящих для того, чтобы тормозить без уважительных причин. Напоминаю ещё раз про С++ и Qt5 :)
в 99% случаев иметь приложение, которое работает с удовлетворительной производительностью сегодня, лучше, чем то, которое работает ну пипец как быстро, но завтра
Slack появился почти пять лет назад. Ладно, пусть прототип был фигак-фигак и в продакшен, но за пять лет-то самое быстрорастущее бизнес-приложение в истории (где-то выше в комментах такое утверждали) мог бы переписаться на что-нибудь более приличное и стать ещё более быстрорастущим, уделав любые телеграмы.
а во втором — не имеете.
Ну, телеграм, который на C++ и Qt5, у меня есть и вполне меня устраивает) Других пользователей и самих разработчиков, думаю, тоже. (Паранойя вроде закрытого сервера или обязательности мобильника это отдельная история, ресурсов не касающаяся.)
Хм, я всегда думал, что они раздельны. Но ладно, даже если так, общее потребление памяти в компе при запуске пустого хрома у меня подскакивает с 5.20 гб до 5.45 гб — мне всё ещё непонятно, почему бы пустому браузеру не вписываться в сотню мегабайт.
Ладно, пусть минус 142 мегабайта на говнокод флэша. А остальные 326 мегабайт зачем? Что мешает вписаться хотя бы в сотню мегабайт, учитывая, что открыта всего одна вкладка, и та полупустая?
А вы можете рассказать, куда он, как и хром, девает полгига оперативки сразу же после запуска? Как это объясняется, кроме как говнокодом? Только повторно гнать пургу про свистоперделки не надо, пожалуйста, я не поведусь.
Каким образом факт динамической типизации сам по себе делает код — говнокодом?
Ладно, это моё субъективное мнение. Я ненавижу динамически типизированные и интерпретируемые ЯП. Потому что можно и нужно делать статически типизированные и компилируемые хотя бы в байткод (хорошо что хоть WebAssembly появился). Это опять же даст плюс к производительности.
Ну и плюсы, если уж на то пошло — слаботипизированный язык.
Но при этом статически типизированный. Это огромный плюс к производительности.
Я думал, что цель — разработать приложение, в соответствии с требованиями. Разве нет?
Вы на протяжении всей этой ветки так и не рассказали, почему «требованиям» нужно так много ресурсов. Не увиливайте от вопроса. При этом, когда я говорю про говнокод, вы почему-то с этим не соглашаетесь. Если не из-за говнокода — так почему же?
Да ладно, с++ семантически проще, чем js.
Ну вот и прекрасно! Давайте писать всё хотя бы на C++? Нахрена существует js?
Какие пиксели-то?
RGB, по 8 бит на канал. Откройте свой Slack, нажмите PrintScreen, вставьте картинку из буфера обмена в какой-нибудь графический редактор и поиграйтесь с масштабом и пипеткой — вы увидите, что Slack отрисован очень даже пикселями.
Никто такого низкоуровневого апи не использует.
А при чём тут низкоуровневые апи? UT99 тоже манипулирует вполне себе полигонами и текстурами, а не пикселями, но при этом не тормозит. И текста там тоже хватает. Мессенджеру тоже ничего не мешает рисовать так же, только не 300 кадров в секунду, а пореже. Каковы же принципиальные отличия UT99 от мессенджера, которые вынужнают последнего кушать кучу ресурсов, вы так и не рассказали. (Спойлер: это отличие — говнокод и лень разработчиков. Какого-то другого правдоподобного варианта я от вас так и не услышал.)
Sublime Text 3 работает ещё быстрее, запускается ещё быстрее, памяти жрёт ещё меньше, функциональность при этом вроде как схожая при наличии соответствующих плагинов. VS Code — прожорливая тормознутость, всё познаётся в сравнении :)
Electron сам по себе говнокод, js сам по себе неоптимизированное говно с динамической типизацией. А современная мода на функциональное программирование всё усугубляет, потому что на интерпретируемых ЯП работает очень плохо. Неужели надо упоминать такие очевидности?)))
Чем он нормальный
Да хотя бы тем, что на C++, который компилируется в машинный код и в сравнении с тем же js кушает минимум ресурсов. Но нет же, C++ для современных веб-макак слишком сложный, сидят говнокодят на электронном js, и в результате мы получаем какой-нибудь Slack.
Очевидно, никакие мессенджеры пикселями не рисуют.
Эм, они в принципе не могут рисовать не пикселями, у меня все имеющиеся мониторы вполне себе пиксельные вообще-то. Векторные мониторы ещё в прошлом веке вымерли. Кроме того, я не знаю никакой современной видеоподсистемы, конечным результатом работы которой были бы не пиксели.
А с чего вы взяли что тормоза в slack и skype из-за говнокода?
С того, что Electron. Потому что нужно брать нормальный Qt5, слава телеграму.
Потому что мессенджер рисует сильно не так, как UT99. Неужели надо упоминать такие очевидности?
Да, надо. Что именно там не так? 24-битные RGB-пиксели вроде бы одинаковые и там, и тут. OpenGL вроде бы одинаковый и там, и тут — при этом UT99 на OpenGL у меня выдаёт все 300 кадров в секунду и оперативки опять же не кушает (если перерисовывать кадр реже чем 300 раз в секунду, то и процессор не будет кушать). Такими темпами создание мессенджера на игровом движке окажется хорошей идеей :\
Тормоза-то не из-за говнокода (в 99% процентов случаев).
В том-то и проблема, что из-за говнокода — см. Slack и Skype. Именно из-за говнокода я и ною тут в комментах. Если бы ресурсы действительно потреблялись на что-то дельное, я бы помалкивал.
А мессенджеру надо рисовать свистоперделки.
UT99 даже в программной отрисовке выдаёт не меньше 120 кадров в секунду. Даже под вайном в линуксе. Думаю, не надо пояснять, что по меркам 2018 года он ресурсов не кушает вообще? Почему вдруг примитивный мессенджер должен тормозить и жрать ресурсы сильнее весьма сложных компьютерных игр? Графика в UT99 по современным меркам не очень, но всё же технически она сложнее чем в любом мессенджере.
Да, над UT99 работала куча талантливых разработчиков, сделавших прекраснейший программный рендеринг, но блин, неужели современные разработчики настолько деградировали, что даже три с половиной несчастных свистоперделки в мессенджере подлатать не в состоянии? Это при том, что, в отличие от времён создания UT99, им доступен OpenGL [ES], прекрасно работающий на любой кофеварке. Илон, забери меня на Марс, я не хочу жить на одной планете с такими людьми.
Да хотя бы графическая подсистема.
Пример с UT99 выше.
Ну у меня слак занимает те же 200мб и 0% загрузки процессора. Что вы с ним делаете, что там гигабайты?
Даладна, неужели с помента последнего его использования мной его подлатали? Он у меня жрал полгига сразу же после запуска.
Telegram, к слову, прямо сейчас у меня кушает всего 100 мегабайт оперативки и 0% процессора, хотя я его активно пользую. (Были слухи о 50 мегабайтах на винде, но лично не проверял.)
логичнее потратить оставшиеся 6гб на всякого рода кеширование.
Логичнее, поэтому любая современная ОС этим занимается автоматически, со стороны разработчиков приложений никаких дополнительных действий обычно не требуется :) (Исключения вроде mysql это исключения.)
Его не нужно перезапускать, фласк сам перечитает шаблон при следующем его использовании. Это можно явно включить или выключить опцией
TEMPLATES_AUTO_RELOADВы видимо не понимаете, что такое джит. Если без джита — то будет какой-нибудь транслятор, который странслирует условный WebAssembly-байткод в машинный код и закэширует. И так как все оптимизации проведены ещё на уровне байткода, то такой транслятор в теории был бы чудовищно прост и почти не требовал бы ресурсов, в отличие от монстра V8 с его джитом, пытающимся оптимизировать говнокод на говноязыке хоть как-нибудь. И вообще вспомните Android: там тоже от джита отказались (теперь ahead-of-time компиляция при установке приложения), а кроссплатформенность как-то никуда не делась.
Так они и без меня в курсе.
Ещё раз: значит такая модель не нужна.
Ну у телеграма с этим проблем нет почему-то. Значит, видимо, позволяет. И за пять лет нормальный клиент Slack вполне можно было сделать.
Чтобы завести пользователю полезную ему фичу — экономию ресурсов — и не вынуждать тратить деньги на апгрейд компа, если перед запуском слака приходится выключать все виртуалки и наоборот.
И это отвратительно. О чём я в общем-то уже не раз высказывался на хабре, да и не только я. Можно было поадекватнее платформу придумать.
Android? Там даже запуск приложений без установки вроде где-то завозили.
Это всё может любая нормальная ОС, будь под неё соответствующие приложения.
Тем не менее вы это постоянно делаете в браузере. Чем скачивание кучи мегабайт пожатых джаваскриптов с последующим их кэшированием принципиально отличается от установки? Разве что кнопочку «Установить» кликать не надо — ну так никто не запрещает сделать аналогично где-нибудь на уровне ОС или просто платформе более адекватной чем браузер, только все прицепились к браузерам и никому это не нужно теперь.
А я думаю. Всё, что сейчас происходит в браузерах, можно было сделать и альтернативными способами без браузеров, причём более адекватными.
Я и сейчас смеюсь, особенно когда выходят новости про мигающий курсор, кушающий 13% процессора)
Почему оптимизации под IE-то, я пишу всё строго в соответствии с HTML5 и CSS3 и с парой полифиллов сбоку, доводящих IEшный жс до используемого мной подмножества ES5. (В полифиллах, может, и говнокод, но не пофиг ли, если они завёрнуты в
<!--[if lt IE 9]>?)И что? Можно запихать стопицот разных ссылок на самые разные скрипты — а вот прямо на этой странице где хотя бы одно реальное использование TeX?
А лучше б не был :)
То есть мы возвращаемся к упоминавшимся ниже говнокоду и лени программистов.
Меня учили ровно наоборот: при точке непонятно, откуда это дело импортируется, приходится идти путь к текущему файлу смотреть, отрываясь от кода.
Меня учили ровно наоборот: при переименовании или перемещении точка может замаскировать сломавшиеся импорты, поэтому лучше прописывать всё явно, чтобы на сложных случаях вылетел ImportError, а не непонятно что, когда случайно импортировался другой подмодуль с таким же именем. (Хотя, возможно, к
__init__это не относится, но ведь явное лучше неявного же?)Не знаю, как часто это всё встречается на практике, но такое мнение тоже есть.
Открыл хабр в чистом хроме — тот отожрал ещё две сотни мегабайт. Куда? Зачем? Почему? Что такого на главной хабра занимает две сотни мегабайт?
У меня чистый vsc жрал полгига сразу после первого запуска без каких-либо сторонних плагинов. Мы в разных вселенных живём что ли?
Вы запутались. Джиты не нужно было бы изобретать, если бы изначально было нормальный язык, компилирующийся во что-нибудь нормальное. А теперь эти сами джиты, наверно, и отъедают те самые полгига памяти — они проделывают очень много работы ради оптимизаций, которые можно было бы не проделывать с изначально нормальным языком. А теперь куча человекочасов угроблено в попытках добиться того, чтобы говноязык не так сильно тормозил. К счастью, в последнее время народ одумался и запилил WebAssembly — я очень надеюсь, что с ним веб станет лучше и скромнее по ресурсам. Хотя и он тоже не без недостатков.
Мы подходим к самому главному: пришло время избавиться от браузеров! Ещё немного, и получится Telegram!))
Уверен, хотя бы несколько PNG-картинок найдутся. Да и в CSS что-нибудь подобное обязательно упоминается. Но всё равно это не причина тормозить и жрать память.
Отсюда напрашивается вывод: dom нахрен не нужен! Slack написан на технологиях, идеально подходящих для того, чтобы тормозить без уважительных причин. Напоминаю ещё раз про С++ и Qt5 :)
Slack появился почти пять лет назад. Ладно, пусть прототип был фигак-фигак и в продакшен, но за пять лет-то самое быстрорастущее бизнес-приложение в истории (где-то выше в комментах такое утверждали) мог бы переписаться на что-нибудь более приличное и стать ещё более быстрорастущим, уделав любые телеграмы.
Ну, телеграм, который на C++ и Qt5, у меня есть и вполне меня устраивает) Других пользователей и самих разработчиков, думаю, тоже. (Паранойя вроде закрытого сервера или обязательности мобильника это отдельная история, ресурсов не касающаяся.)
Хм, я всегда думал, что они раздельны. Но ладно, даже если так, общее потребление памяти в компе при запуске пустого хрома у меня подскакивает с 5.20 гб до 5.45 гб — мне всё ещё непонятно, почему бы пустому браузеру не вписываться в сотню мегабайт.
Ладно, пусть минус 142 мегабайта на говнокод флэша. А остальные 326 мегабайт зачем? Что мешает вписаться хотя бы в сотню мегабайт, учитывая, что открыта всего одна вкладка, и та полупустая?
Пока вы отвечали, я ради чистоты эксперимента перезапустил с пустым профилем, полагая, что в расширениях может быть говнокод —
Для Electron-приложений ситуация аналогичная: каждое из них кушает не меньше чем полгига.
Но вопрос остаётся: нахрена ему столько?
Ничего я не путаю.
(фаерфокса это тоже касается, но он хотя бы больше суток с кучей вкладок висит открытый)
А вы можете рассказать, куда он, как и хром, девает полгига оперативки сразу же после запуска? Как это объясняется, кроме как говнокодом? Только повторно гнать пургу про свистоперделки не надо, пожалуйста, я не поведусь.
Ладно, это моё субъективное мнение. Я ненавижу динамически типизированные и интерпретируемые ЯП. Потому что можно и нужно делать статически типизированные и компилируемые хотя бы в байткод (хорошо что хоть WebAssembly появился). Это опять же даст плюс к производительности.
Но при этом статически типизированный. Это огромный плюс к производительности.
Вы на протяжении всей этой ветки так и не рассказали, почему «требованиям» нужно так много ресурсов. Не увиливайте от вопроса. При этом, когда я говорю про говнокод, вы почему-то с этим не соглашаетесь. Если не из-за говнокода — так почему же?
Ну вот и прекрасно! Давайте писать всё хотя бы на C++? Нахрена существует js?
RGB, по 8 бит на канал. Откройте свой Slack, нажмите PrintScreen, вставьте картинку из буфера обмена в какой-нибудь графический редактор и поиграйтесь с масштабом и пипеткой — вы увидите, что Slack отрисован очень даже пикселями.
А при чём тут низкоуровневые апи? UT99 тоже манипулирует вполне себе полигонами и текстурами, а не пикселями, но при этом не тормозит. И текста там тоже хватает. Мессенджеру тоже ничего не мешает рисовать так же, только не 300 кадров в секунду, а пореже. Каковы же принципиальные отличия UT99 от мессенджера, которые вынужнают последнего кушать кучу ресурсов, вы так и не рассказали. (Спойлер: это отличие — говнокод и лень разработчиков. Какого-то другого правдоподобного варианта я от вас так и не услышал.)
Electron сам по себе говнокод, js сам по себе неоптимизированное говно с динамической типизацией. А современная мода на функциональное программирование всё усугубляет, потому что на интерпретируемых ЯП работает очень плохо. Неужели надо упоминать такие очевидности?)))
Да хотя бы тем, что на C++, который компилируется в машинный код и в сравнении с тем же js кушает минимум ресурсов. Но нет же, C++ для современных веб-макак слишком сложный, сидят говнокодят на электронном js, и в результате мы получаем какой-нибудь Slack.
Эм, они в принципе не могут рисовать не пикселями, у меня все имеющиеся мониторы вполне себе пиксельные вообще-то. Векторные мониторы ещё в прошлом веке вымерли. Кроме того, я не знаю никакой современной видеоподсистемы, конечным результатом работы которой были бы не пиксели.
С того, что Electron. Потому что нужно брать нормальный Qt5, слава телеграму.
Да, надо. Что именно там не так? 24-битные RGB-пиксели вроде бы одинаковые и там, и тут. OpenGL вроде бы одинаковый и там, и тут — при этом UT99 на OpenGL у меня выдаёт все 300 кадров в секунду и оперативки опять же не кушает (если перерисовывать кадр реже чем 300 раз в секунду, то и процессор не будет кушать). Такими темпами создание мессенджера на игровом движке окажется хорошей идеей :\
В том-то и проблема, что из-за говнокода — см. Slack и Skype. Именно из-за говнокода я и ною тут в комментах. Если бы ресурсы действительно потреблялись на что-то дельное, я бы помалкивал.
UT99 даже в программной отрисовке выдаёт не меньше 120 кадров в секунду. Даже под вайном в линуксе. Думаю, не надо пояснять, что по меркам 2018 года он ресурсов не кушает вообще? Почему вдруг примитивный мессенджер должен тормозить и жрать ресурсы сильнее весьма сложных компьютерных игр? Графика в UT99 по современным меркам не очень, но всё же технически она сложнее чем в любом мессенджере.
Да, над UT99 работала куча талантливых разработчиков, сделавших прекраснейший программный рендеринг, но блин, неужели современные разработчики настолько деградировали, что даже три с половиной несчастных свистоперделки в мессенджере подлатать не в состоянии? Это при том, что, в отличие от времён создания UT99, им доступен OpenGL [ES], прекрасно работающий на любой кофеварке. Илон, забери меня на Марс, я не хочу жить на одной планете с такими людьми.
Пример с UT99 выше.
Даладна, неужели с помента последнего его использования мной его подлатали? Он у меня жрал полгига сразу же после запуска.
Telegram, к слову, прямо сейчас у меня кушает всего 100 мегабайт оперативки и 0% процессора, хотя я его активно пользую. (Были слухи о 50 мегабайтах на винде, но лично не проверял.)
Логичнее, поэтому любая современная ОС этим занимается автоматически, со стороны разработчиков приложений никаких дополнительных действий обычно не требуется :) (Исключения вроде mysql это исключения.)