После изменения имени страница классического сайта просто перезагрузится :)
на бэке тратятся ресурсы
Ни разу не сталкивался с тем, чтобы это становилось узким местом. Да и рисование HTML на бэкенде многими крупнейшими сайтами тоже тому пример. А вот то, что производительности браузера не хватает джаваскрипту — это постоянно, особенно на мобилках. Ну и gzip никто не отменял
Отрисовка кусмана HTML'а на клиенте — это более трудозатратный процесс
Видимо, разница в пределах погрешности, потому что видимой на глаз разницы в производительности между сайтами, активно юзающими innerHTML (PJAX/Turbolinks какие-нибудь), и сайтами на React не замечал (и на мобилках тормозят примерно одинаково).
Прикиньте, сколько в мире есть CRMок, облачных приложений
Прикиньте, сколько в мире есть сайтов-визиток, блогов, форумов, которые кроме гифок статичны чуть более чем полностью — но при этом в них в последнее время зачем-то пихают реакты и прочие ангуляры с js-бандлами в десяток-другой мегабайт :)
Для себя как бэкенд-разработчика я не увидел ответа на один очень важный вопрос: зачем это всё? Почему вдруг стало нельзя просто рисовать HTML на бэкенде и отдавать его браузеру как есть (с AJAX или без)?
(Не считая случаев, когда сайт таким образом написать в принципе невозможно и нужен интерактив на JS, но ведь такие сайты по пальцам можно пересчитать)
Вместо простого универсального less нужно держать в голове ещё один аналог less и стопицот ключиков к нему для разных ситуаций :)
(Впрочем, я и не против, но блин, я уже несколько лет работаю с systemd, а ключики journalctl наизусть до сих пор не помню)
Если система не грузится даже в консоль (или если её грузить небезопасно по каким-то причинам), а хочется почитать логи для выяснения причины, как с какого-нибудь LiveCD почитать эти бинарные логи?
Позанудствую: во FreeBSD баш пихают в /usr/local/bin/bash, поэтому такой скрипт там не запустится. Так что теперь я пишу #!/usr/bin/env bash (правда, где-то читал, что это тоже где-то может не работать, но я уже забыл где)
экстраполировать что-то одно на всю экосистему — большая ошибка, особенно для инженера.
Которую совершаете и вы тоже, упоминая WebStorm. А я вот сейчас возьму и вспомню какой-нибудь Sublime, который, даже обмазанный плагинами на не самом эффективном питоне, уделывает по производительности и экономии памяти всех остальных)
Если пользовать VCS, бэкапы вообще не особо нужны. ;)
Хранение и просмотр изменений — непосредственная задача VCS. Пытаться адаптировать под это бэкапы — костыль и жевание кактуса. Делать по новому бэкапу с чейнджлогом на каждое мелкое изменение — какая-то глупость, а для VCS (кроме SVN, я так понимаю, лол) совершенно нормальная и очень полезная практика. И для VCS никакой графики выпиливать не надо.)
примерно год. За это время накопилось 40 бэкапов
В то время как сделать 40 коммитов к гите дело нескольких дней — история получается в разы подробнее, а откатывать отдельные изменения в случае чего (да, их иногда приходится откатывать) гораздо проще.
пока код знаешь хорошо
Вы тоже из тех, кто способен помнить старые крупные проекты годами? Ох, вас уже целых двое.
Вот буквально вчерашний пример. Откопал сайт, к которому не прикасался год. Делал его я один, соответственно никакой удалённый репозиторий ради командной разработки не был нужен. Откопал, потому что заметил, что один пункт меню пропал (не слишком важный пункт, поэтому целый год никто ничего не замечал). Открываю nav.html — нету пункта. При этом я точно помню, что этот пункт раньше был. Соответственно, логично захотелось посмотреть, каким nav.html был раньше.
Что бы было, если бы были только бэкапы? Да ничего. Народ обычно удаляет старые версии бэкапов (особенно через целый год-то), вот и я бы тоже удалил всё старое и оставил бы только последний актуальный бэкап. Но предположим, все старые бэкапы есть — и как бы я в них искал, когда пропал пункт меню из nav.html? Сидеть распаковывать десятки-сотни архивов и смотреть содержимое nav.html в каждом? Данунафиг блин.
Но зато у меня есть локальный репозиторий git! Простейший git log nav.html — и вот я уже вижу все изменения этого конкретного файла. Не прошло и минуты, а я уже нашёл коммит, в котором пункт меню пропал. 4 апреля 2016, описание «Rewrite nav.html». Всё стало ясно: отрефакторил файлик, а пункт меню просто забыл добавить и не заметил. В итоге я просто скопировал пункт меню из старого nav.html в новый, не пришлось писать ни строчки нового кода. git add nav.html && git commit -m 'Restored some nav items'
Пример примитивный, но ничего не мешает случиться чему-нибудь аналогичному на более глобальных изменениях, вроде выпиливания большой фичи, которую внезапно понадобится вернуть. Бэкапы — не замена контролю версий, контроль версий — не замена бэкапам. Если вы способны помнить всё, что делали во всех своих проектах, к которых не прикасались годами — поздравляю, у вас на удивление хорошая память, такая очень мало у кого есть :) А я помнить не только не могу, но и не хочу: зачем, если помнить за меня может обладающий бесперебойной памятью git, причём не требуя удалённого репозитория?) А крутить в голове я лучше буду те проекты, которыми занимаюсь в настоящий момент, а вышеупомянутый сайт к ним не относится.
С VCS надо куда-то выгружать данные
О чём тут речь? В моём случае кроме git add и git commit я ничего не делал, а просмотреть всё могу как простым git log, так и каким-нибудь графическим gitk
Однажды юзер альт-табнется в перекрытое окно, и тут битмап сильно поможет: без него все эти тяжёлые векторы начнут перерисовываться с нуля, и первое, что увидит юзер — не вектор, а серое окно, которое будет оставаться серым, пока вектор не отрисуется — такое часто можно было наблюдать в каких-нибудь WinXP или любых иксах без композитинга. Если же битмап с готовым вектором будет, то он отобразится сразу, что сильно повышает юзерфрендли. Плюс к этому если верхнее окно двигать поверх нижнего окна, то за окном будет оставаться серый след (или в запущенных случаях след из содержимого окна), так как нижнее окно будет не успевать перерисовываться. Лично мне не жалко небольшой нагрузки на проц и память ради того, чтобы подобного не происходило.
А держать запущенное видео в фоне вообще не надо, такое окно стоит хотя бы свернуть)
Ну против API я ничего не имею
После изменения имени страница классического сайта просто перезагрузится :)
Ни разу не сталкивался с тем, чтобы это становилось узким местом. Да и рисование HTML на бэкенде многими крупнейшими сайтами тоже тому пример. А вот то, что производительности браузера не хватает джаваскрипту — это постоянно, особенно на мобилках. Ну и gzip никто не отменял
Видимо, разница в пределах погрешности, потому что видимой на глаз разницы в производительности между сайтами, активно юзающими innerHTML (PJAX/Turbolinks какие-нибудь), и сайтами на React не замечал (и на мобилках тормозят примерно одинаково).
Прикиньте, сколько в мире есть сайтов-визиток, блогов, форумов, которые кроме гифок статичны чуть более чем полностью — но при этом в них в последнее время зачем-то пихают реакты и прочие ангуляры с js-бандлами в десяток-другой мегабайт :)
Для себя как бэкенд-разработчика я не увидел ответа на один очень важный вопрос: зачем это всё? Почему вдруг стало нельзя просто рисовать HTML на бэкенде и отдавать его браузеру как есть (с AJAX или без)?
(Не считая случаев, когда сайт таким образом написать в принципе невозможно и нужен интерактив на JS, но ведь такие сайты по пальцам можно пересчитать)
А лет восемь назад у каждого был телефон с установленным Jimm, и в контакт-листе обязательно были какие-нибудь боты. Почему тогда я хайпа не наблюдал?
Вместо простого универсального less нужно держать в голове ещё один аналог less и стопицот ключиков к нему для разных ситуаций :)
(Впрочем, я и не против, но блин, я уже несколько лет работаю с systemd, а ключики journalctl наизусть до сих пор не помню)
Если система не грузится даже в консоль (или если её грузить небезопасно по каким-то причинам), а хочется почитать логи для выяснения причины, как с какого-нибудь LiveCD почитать эти бинарные логи?
Думается мне, лезть в системные файлы, которые для лазания не предназначены, не очень хорошо
Позанудствую: во FreeBSD баш пихают в
/usr/local/bin/bash, поэтому такой скрипт там не запустится. Так что теперь я пишу#!/usr/bin/env bash(правда, где-то читал, что это тоже где-то может не работать, но я уже забыл где)Я где-то читал, что он на патченом Qt5 без QML. Хотя первое время сам думал, что на Electron, уж модно нынче на нём такие вещи клепать)
Нуок, но лично я заявляю, что веб-технологии ересь, поюзав всякие Atom, Skype, Slack и десяток-другой сайтов SPA, особенно на китайских мобилках.)
Которую совершаете и вы тоже, упоминая WebStorm. А я вот сейчас возьму и вспомню какой-нибудь Sublime, который, даже обмазанный плагинами на не самом эффективном питоне, уделывает по производительности и экономии памяти всех остальных)
Когда мне опять будут мыть мозги веб-приложениями, SPA, Electron'ом и прочей ересью, буду в ответ кидать ссылку на этот пост.
Здесь был коммент про приватные ключи, однако если на самом деле «we generate a private key in your browser», то это уже интересно
HTTP-заголовок Content-Disposition позволяет переопределить имя файла, так что всё запустится ;)
Такие вещи делают не на «домашнем сервере», а в каких-нибудь амазоновских облаках за небольшую (вроде) плату. А там это займёт всего 2-3 недели)
Если пользовать VCS, бэкапы вообще не особо нужны. ;)Хранение и просмотр изменений — непосредственная задача VCS. Пытаться адаптировать под это бэкапы — костыль и жевание кактуса. Делать по новому бэкапу с чейнджлогом на каждое мелкое изменение — какая-то глупость, а для VCS (кроме SVN, я так понимаю, лол) совершенно нормальная и очень полезная практика. И для VCS никакой графики выпиливать не надо.)
В то время как сделать 40 коммитов к гите дело нескольких дней — история получается в разы подробнее, а откатывать отдельные изменения в случае чего (да, их иногда приходится откатывать) гораздо проще.
Вы тоже из тех, кто способен помнить старые крупные проекты годами? Ох, вас уже целых двое.
Что ж, поздравляю, вы уникальный :) Мне (и, думаю, многим другим) в первую очередь нужны и важны именно логи.
Даже спустя год? И храните все столь старые бэкапы? Вы всё ещё уникальный, можете гордиться этим))
Вот буквально вчерашний пример. Откопал сайт, к которому не прикасался год. Делал его я один, соответственно никакой удалённый репозиторий ради командной разработки не был нужен. Откопал, потому что заметил, что один пункт меню пропал (не слишком важный пункт, поэтому целый год никто ничего не замечал). Открываю nav.html — нету пункта. При этом я точно помню, что этот пункт раньше был. Соответственно, логично захотелось посмотреть, каким nav.html был раньше.
Что бы было, если бы были только бэкапы? Да ничего. Народ обычно удаляет старые версии бэкапов (особенно через целый год-то), вот и я бы тоже удалил всё старое и оставил бы только последний актуальный бэкап. Но предположим, все старые бэкапы есть — и как бы я в них искал, когда пропал пункт меню из nav.html? Сидеть распаковывать десятки-сотни архивов и смотреть содержимое nav.html в каждом? Данунафиг блин.
Но зато у меня есть локальный репозиторий git! Простейший
git log nav.html— и вот я уже вижу все изменения этого конкретного файла. Не прошло и минуты, а я уже нашёл коммит, в котором пункт меню пропал. 4 апреля 2016, описание «Rewrite nav.html». Всё стало ясно: отрефакторил файлик, а пункт меню просто забыл добавить и не заметил. В итоге я просто скопировал пункт меню из старого nav.html в новый, не пришлось писать ни строчки нового кода.git add nav.html && git commit -m 'Restored some nav items'Пример примитивный, но ничего не мешает случиться чему-нибудь аналогичному на более глобальных изменениях, вроде выпиливания большой фичи, которую внезапно понадобится вернуть. Бэкапы — не замена контролю версий, контроль версий — не замена бэкапам. Если вы способны помнить всё, что делали во всех своих проектах, к которых не прикасались годами — поздравляю, у вас на удивление хорошая память, такая очень мало у кого есть :) А я помнить не только не могу, но и не хочу: зачем, если помнить за меня может обладающий бесперебойной памятью git, причём не требуя удалённого репозитория?) А крутить в голове я лучше буду те проекты, которыми занимаюсь в настоящий момент, а вышеупомянутый сайт к ним не относится.
О чём тут речь? В моём случае кроме
git addиgit commitя ничего не делал, а просмотреть всё могу как простымgit log, так и каким-нибудь графическимgitkОднажды юзер альт-табнется в перекрытое окно, и тут битмап сильно поможет: без него все эти тяжёлые векторы начнут перерисовываться с нуля, и первое, что увидит юзер — не вектор, а серое окно, которое будет оставаться серым, пока вектор не отрисуется — такое часто можно было наблюдать в каких-нибудь WinXP или любых иксах без композитинга. Если же битмап с готовым вектором будет, то он отобразится сразу, что сильно повышает юзерфрендли. Плюс к этому если верхнее окно двигать поверх нижнего окна, то за окном будет оставаться серый след (или в запущенных случаях след из содержимого окна), так как нижнее окно будет не успевать перерисовываться. Лично мне не жалко небольшой нагрузки на проц и память ради того, чтобы подобного не происходило.
А держать запущенное видео в фоне вообще не надо, такое окно стоит хотя бы свернуть)
Есть опасение, что тех, кто тупо копипастит решения, всё-таки гораздо больше (правда, хз как это проверить)