Всё печально только на первый взгляд, фронтенд сильно вырос за последние несколько лет. Но единого подхода тут нет и не планируется в обозримом будущем: подход задаётся фреймворком. То что круто в Angular будет отстоем в React и т.д. Другое дело что есть общий подход к product-коду (конкатенация, минификация, cdn, etc.)
Ну и конечно не стоит забывать специфику фронтенда. Если на беке ты соблюдаешь баланс между качеством и скоростью, то на фронте надо соблюдать баланс между качеством-скоростью-размером-кросбраузерностью, что порождает порой интересные мысли в подходах.
Если вы глубокий бекендер, обратите внимание на изоморфные фреймворки вроде Meteor и Derby, мне кажется вам понравится
Я предлагаю: использовать директивы вместо ngInclude. Всё. Точка. Больше ничего не предлагаю.
Если у вас меню на каждой странице инклудится, а такое бывает, то да — используйте директиву.
Ели вам достаточно держать меню, футер и т.п вне странице, в шаблоне верхнего уровня — значит у вас нет проблемы с вложенными инклудами.
Выглядит неплохо, но это как раз из серии «написать своё».
Не хочу обидеть вас, называя это велосипедом — решение имеет право на жизнь, но об этом я как раз и говорил: зачем изобретать, если есть стандартный функционал директив.
А что вас так пугает в этом совете? Оборачивать меню, которое на каждой странице одно и то же, что в этом страшного? Мне кажется вполне уместно. Футер — по сути тоже самое меню. Отделить логику многократно используемых элементов от контента, разве это не хорошо?
Гейб не покинет Valve просто потому что сам valve изменился — steam, оси, операционки, контроллеры… Конечно они пилят игры, но контора сильно изменилась
Я не сравнивал jQyery и Angular. Первый — библиотека, второй — фреймворк, т.е. разные вещи. Это просто была маленькая реклама Angular. Сложно удержаться, когда что то так нравится, каюсь.
Если вы посмотрите мой комментарий выше, то я говорю:
Написать самому — это всегда похвально.
И это не сарказм. Плюсов масса — начиная с «пока пишу сам научусь», заканчивая тем что у тебя практически 100% контроля над кодом. Но многое упирается в то, что код должен быть хорошим, его надо поддерживать, рефакторить и т.п. Из успешных примеров фреймворки потом и получаются, мне кажется.
Вообще везде где можно не брать фреймворк, лучше — не брать. Но писать самому всё не получится — всегда не хватает либо знаний, либо времени, либо желания.
Да, я тоже хотел сказать — это из серии «сразу делай хорошо».
Я с вами в одном точно согласен — mvc и mvvm не так уж сложно реализуется, заводить только для этого фреймворк, возможно и правда перебор.
Вы знаете, я вот стал использовать Angular. По двум причинам (кроме модульности из коробки) — манипуляции с dom намного элегантнее реализуются, чем с jQuery, и, та-дам, его пилит гугл, т.е. у меня хоть какая то гарантия что через месяц его не забросят.
Написать самому — это всегда похвально. Писать где можно на чистом js, вместо jQuey — жму вам руку.
Но у этого подхода есть один недостаток — в свою архитектуру нового программиста интегрировать — целое дело.
(на самом деле недостатка два, но о втором — качество кода — ни слова: я в вас верю ;) )
Нет правда, я наблюдал ситуации, когда увольняется главный разраб, а через неделю сносят самописный чудо-фреймворк и ставят что то с гитхаба. Вдруг оказалось что никто не хочет в нём ковырятся.
Да и банально, при смене работы, например, гораздо лучше сказать что ты знаешь бекбон, чем фреймворк имени программиста Иванова.
Как то использовал Zepto вместо jQuery из тех же соображений — маленький размер, выкинута поддержка старого IE.
Но там по ходу вяснялись некоторые не очень приятные вещи — в jquery какой то метод есть, а в зепте только планируется.
Но это просто к слову, если у вас просто форк без зависимостей, думаю таких проблем не будет )
Как то раз мне внезапно захотелось, что бы сайт после загрузки появлялся плавно (с использованием css transition). С использованием ng-cloak этого не получилось, поэтому сделал вот так:
Что получилось? ng-class начинает работать только после того как Angular полностью загрузился, контент появляется плавно и довольно симпатично, все довольны. За это решение спасибо StackOverFlow.
… после выкупа я должен был создать условный «Хабрафонд», в который топ-менеджеры Mail.Ru Group планировали занести личные деньги и инвестировать в стартапы, не раскрывая себя. Я должен был быть ширмой, скрывать происхождение средств и окучивать стартаперов, которых очень много на Хабре, как ты знаешь...
И тут следом эта новость ) Хотелось бы услышать комментарии по этому поводу, желательно в духе «Да, мы не являемся ширмой ни для каких топ-менеджеров, мы это мы», ну или как то так.
Вот понимаете, проблема то в том, что если решение выглядит логичным, далеко не факт что оно работает. Я думаю библиотеку разрабатывают не совсем хипстеры и со своей задачей она справляется, но к ней есть ряд вопросов, которые при желании можно свести к двум: «А надо ли?» и «А оно точно работает?».
Если бы только можно было сравнить как-то пользу от библиотеки, до того как начнёшь внедрять её в проект.
Вы знаете, мне ещё интересен такой момент — когда мне считать свой сайт аяксовым? Т.е. требующим дополнительных манипуляций, как в статье. Если у меня js'ный фронтенд с rest'ом, то всё понятно, сайт аяксовый.
А если у меня php+jquery, где два с половиной аяксовых запроса?
Ну и конечно не стоит забывать специфику фронтенда. Если на беке ты соблюдаешь баланс между качеством и скоростью, то на фронте надо соблюдать баланс между качеством-скоростью-размером-кросбраузерностью, что порождает порой интересные мысли в подходах.
Если вы глубокий бекендер, обратите внимание на изоморфные фреймворки вроде Meteor и Derby, мне кажется вам понравится
github.com/shikolay/Front-end-Developer-Interview-Answers
Если у вас меню на каждой странице инклудится, а такое бывает, то да — используйте директиву.
Ели вам достаточно держать меню, футер и т.п вне странице, в шаблоне верхнего уровня — значит у вас нет проблемы с вложенными инклудами.
Вот главный шаблон, index.html:
Теперь я хочу что бы на публичных страницах у меня была одно меню, на приватных другое.
В шаблоне страницы делаем:
На другой страницу вместо <top-menu> будет, например, <top-public-menu>
Что сложного? Что плохого? Где аргументы? Как вы предлагаете это решить?
Не хочу обидеть вас, называя это велосипедом — решение имеет право на жизнь, но об этом я как раз и говорил: зачем изобретать, если есть стандартный функционал директив.
docs.angularjs.org/guide/migration
Можно даже из пользователей небольшой пантеон набросать =)
Если вы посмотрите мой комментарий выше, то я говорю:
И это не сарказм. Плюсов масса — начиная с «пока пишу сам научусь», заканчивая тем что у тебя практически 100% контроля над кодом. Но многое упирается в то, что код должен быть хорошим, его надо поддерживать, рефакторить и т.п. Из успешных примеров фреймворки потом и получаются, мне кажется.
Вообще везде где можно не брать фреймворк, лучше — не брать. Но писать самому всё не получится — всегда не хватает либо знаний, либо времени, либо желания.
(результаты моих экспериментов совсем не так красивы)
Я с вами в одном точно согласен — mvc и mvvm не так уж сложно реализуется, заводить только для этого фреймворк, возможно и правда перебор.
Вы знаете, я вот стал использовать Angular. По двум причинам (кроме модульности из коробки) — манипуляции с dom намного элегантнее реализуются, чем с jQuery, и, та-дам, его пилит гугл, т.е. у меня хоть какая то гарантия что через месяц его не забросят.
Но у этого подхода есть один недостаток — в свою архитектуру нового программиста интегрировать — целое дело.
(на самом деле недостатка два, но о втором — качество кода — ни слова: я в вас верю ;) )
Нет правда, я наблюдал ситуации, когда увольняется главный разраб, а через неделю сносят самописный чудо-фреймворк и ставят что то с гитхаба. Вдруг оказалось что никто не хочет в нём ковырятся.
Да и банально, при смене работы, например, гораздо лучше сказать что ты знаешь бекбон, чем фреймворк имени программиста Иванова.
Но там по ходу вяснялись некоторые не очень приятные вещи — в jquery какой то метод есть, а в зепте только планируется.
Но это просто к слову, если у вас просто форк без зависимостей, думаю таких проблем не будет )
И прописал стили:
Что получилось? ng-class начинает работать только после того как Angular полностью загрузился, контент появляется плавно и довольно симпатично, все довольны. За это решение спасибо StackOverFlow.
И тут следом эта новость ) Хотелось бы услышать комментарии по этому поводу, желательно в духе «Да, мы не являемся ширмой ни для каких топ-менеджеров, мы это мы», ну или как то так.
Если бы только можно было сравнить как-то пользу от библиотеки, до того как начнёшь внедрять её в проект.
А если у меня php+jquery, где два с половиной аяксовых запроса?