knitevision1: то есть как, вы конечно же должны по завершению проекта делать какую-то ретроспективу на будущее - что пошло не так, что можно было бы сделать лучше и т.д. Анализ решения нужно делать и это правильно. Но просто так "улучшать" уже полностью готовое решение тоже не хорошо, только если вы точно знаете что текущая реализация будет мешать в будущем. Хотя лучше уж тогда просто сделать себе пометку и при оценке нового функционала закладывать время на рефакторинг.
Хотя еще зависит от того что вы пишите. Если это ваш личный продукт - вам решать как поступать. А если это старый добрый аутсорс то лучше минимизировать риски регрессий и не трогать рабочий код без объективной необходимости. Если у вас на каждый релиз будет что-то ломаться заказчик будет грустным и в один прекрасный момент перестанет вам платить и уйдет от вас к кому другому.
knitevision1: ну не совсем. Рефакторинг без причины признак дурачины. А если проект завершен на 95% то смысла тратить время и ловить регрессии не особо есть.
Если проект состоит из нескольких итераций, то просто закладывается время на рефакторинг перед каждой из них. Но и в процессе разработки минимально менять код тоже нужно.
Тут самое страшное это регрессии. Без покрытия кода тестами при каждом релизе придется прогонять фул тест вручную и на это будет уходить масса времени.
Anderseno: я к тому что вы можете просто обходить дерево и вместо генерации diff просто устанавливать значения атрибутов те что нужно/были, а лишние атрибуты дропать... ну и элементы. У вас скажем есть правило что inline-стилей не должно быть - значит у каждого элемента рекурсивно убираем оный. МОжет быть правило что текст должен быть прямо в li и никаких оберток в спаны и т.д. - без проблем, если доходим то элемента li то меняем его содержимое на текст. Ну вы поняли.
Anderseno: DOM это дерево. Обходите рекурсивно и ищите различия. Если меняются только атрибуты - то все проще. Если могут ноды добавляться - то чуть сложнее.
Вообще если бы вы расписали зачем вам нужен этот самый массив - было бы проще.
iNikNik: большую часть проблем невилирует сам ангуляр так как у него есть ленивая инициализация. Но это не сильно надежно. У меня у самого такой же подход (gulp-inject просто фигачит все файлы в index.html в head в нужном порядке (по зависимостям) и периодически возникают проблемы всеравно изза configure и т.д.).
iNikNik: нет, не по этому. .run ничего не запускает, вызывая этот метод вы говорите ангуляру "запусти ка вот это дело когда ты уже пройдешь фазу конфигурации и перейдешь непосредственно к запуску...
KOPC1886: да сколько ж повторять, либо загружайте все в head либо используйте какой-нибудь менеджер модулей.
KOPC1886: у вас проблемы с порядком загрузки файлов. Так как вы подключаете все внутри body скрипты загружаются вместе, без блокировок. Это как бы и хорошо но ваше приложение загружается явно быстрее и выполняется первым.
Если вы про HipHop который транслятор PHP в C то фэйсбук от него отказались в пользу HHVM, который JIT-компилируемый как и JS. То есть с оптимизациями кода в рантайме и все такое. А еще есть phpng (будущий PHP7) в котором так же перелапатили все что связано с управлением памятью и получили нефиговый такой прирост производительности.
А что node.js? Javascript быстрый, но это все тот же event-loop однопоточный что и в браузере. Весь JS код выполняется в одном потоке, то есть если у вас где-то внезапно появится циклик на пару секунд весь сервер замрет на эти самые пару секунд. Да конечно nginx + проксирование на несколько инстансов спасут но все же... А асинхронное I/O есть и у PHP (ReactPHP + ilbev + mysqli имеет возможность асинхронно запросы выполнять). Вот только заботиться о SAPI и о управлении процессами-воркерами уже не на вашей ответственности.
node.js идеален для простеньких сайтиков и демонов. Для чего-то сложного его можно использовать только если ничего больше не знаешь.
Что до БЭМ и препроцессоров - я бы вообще не рекомендовал нынче отказываться от последних.