на самом деле это значит что вы не стоите 80. по крайней мере для них и на конкретную вакансию. у них — жесткое разделение на роли, и на каждую вакансию нужен специалист в конкертной области + тематике, т.е. если ты выше среднего и по фронтенду и по бэкенду, их будет волновать только одна из областей (при формировании зарплаты, а не принятия решения по офферу). у меня достаточно много знакомых работает\работало в яндексе, и часть из них приходили туда сразу на предложение выше рынка, потому что того стоили, именно в конкретной предметной области.
они не берут overskilled людей, они это прекрасно понимают, на самом деле, у гугла такая проблема есть, да, но вроде как решается потихоньку (вот планку понизили, говорят)
в одном проекте модули которые по неймспесам разбиты и идут components/component от basedir, по expose загружаю модули из node_modules И bower_components (debowerify не всегда нормально отрабатывает, поправить его не успел еще) и прочих вендорных скриптов.
в другом джаваскрипт и цссы вообще собираются в зависимости по html шаблонам, и подгружаются и инициализируются автоматически, в этом случае происходит полный ремапинг — но он автоматический, не вручную прописываю конечно же.
в первом случае browserify именно как сборщик по зависимостям работает, во втором — как удобный манипулятор js для того что бы например исключить одинаковые вещи которые есть в основном js из js для конкретной страницы \ асинхронного загруженного компонента (например и там и там прописана зависимость от hogan.js — автоматом исключаю общее (на самом деле там несколько хитрее, и в большинстве случаев грузится только то что реально есть (может находится) на странице.
browserify.
require('someModule/maybe/mappedToFS', {expose: 'shortNameOfModuleAndItCanBeDoneInBuildFile'}), там где надо
там где надо указываете basedir и все, он будет рутом и можно будет писать/по/неймспейсам при этом это будет проще дебажить потому что понятно что где лежит сразу, и в принципе раскладывание по неймспейсам по папкам это общепринятая практика в разных языках.
можно указать entry point (и даже не один) у которого указать basedir и он будет автоматом на все распространен. в общем никаких проблем не вижу и не понимаю, в моем случае у меня есть бандлы, все приложение рисуется на сервере И на клиенте, бандлы собираются автоматически синхронные и асинхронные версии, все просто до безумия и я не вижу никаких проблем вызванных браузерифаем у себя.
../… вот такие пути нельзя использовать, это да, безумие. нет, я имею в виду вообще, такие пути вообще нельзя использовать нигде, особенно в браузере, но вообще — в любом коде. это всегда приводит к проблемам. разве что можно ./ для указания принадлежности к текущему неймспейсу.
сам себя не похвалишь никто не похвалит. статья большая, но странная. вы браузерифай готовить просто не умеете, он с его гибкими трасформациями позволяет делать очень классные вещи. а во вторых ну зачем изобретать еще один формат, и уж простите определять зависимости по конфигу? ну что за прошлый век.
глупо бессмысленно тратить ресурсы. а организовывать трансялцию всех событий в реал тайме — безумно дорого, а не в реалтайме это несколько теряет смысл и так никто не делает.
зачем на список твитов биндинги данных? они фактически не изменяются, и более эффективно не делать так, потому что это просто бессмысленно. да и вообще это очень часто не нужно, зря везде все так делать начали, зря зря зря.
я согалсен про компоненты, в своем текущем проекте я возвел это в абсолют и получил очень много профита. но вы мне расскажите как рендерить приложение на ангуляр на сервере без запуска phantom.js? :)
людей (меня например) смущает в гибридном жс, то, что ни капли не сложнее приготовить тоже самое без запуска виртуального браузера на сервере. мне нравится использовать node.js, но я не вижу никакой проблемы отрендерить то что мне нужно на сервере написав бэкенд на любом языке, для которого есть реализация использумого шаблонизатора.
читал, и она не много о другом, по моему.
кстати «уи слой» используют яндекс (бем тулзы на node.js) и mail.ru (в почте по крайней мере).
для яндекса — это хороший способ отделить фронтенд разработчиков от бекенда.
для мэил.ру — ускоронение рендеринга (поищите, на хабре статья была).
и да отделить слой рендеринга в отдельный «сервис» внутри приложения — это часто хорошо, точнее даже так, делить на отдельные «сервисы» всегда лучше чем огромный монолитный каркас.
с другой стороны зайдите.
помните, то что backbone очень минималистичный, из коробки доступно почти ничего?
так вот, твиттер флайт — еще более минималистичный, по объему кода еще меньше. у него нету привязки к какому либо шаблонизатору — и не обязательно вовсе. например на одном проекте с ним рендеринг ВСЕГО происходит на сервере, даже того что подгружается асинхронно. Сделано это из соображений простоты (ну и на самом деле так много кто работает, например basecamp, github (вроде частично) и вконтакте (в большинстве мест)). На других — разные шаблонизаторы, в основном handlebars. которые имеют реализацию под многие языки, и рендерить можно на чем угодно. вообще я давно собираюсь написать пару статей по флайту, но никак времени не найду, но уже успел некоторое число людей на него перевести :)
в другом джаваскрипт и цссы вообще собираются в зависимости по html шаблонам, и подгружаются и инициализируются автоматически, в этом случае происходит полный ремапинг — но он автоматический, не вручную прописываю конечно же.
в первом случае browserify именно как сборщик по зависимостям работает, во втором — как удобный манипулятор js для того что бы например исключить одинаковые вещи которые есть в основном js из js для конкретной страницы \ асинхронного загруженного компонента (например и там и там прописана зависимость от hogan.js — автоматом исключаю общее (на самом деле там несколько хитрее, и в большинстве случаев грузится только то что реально есть (может находится) на странице.
require('someModule/maybe/mappedToFS', {expose: 'shortNameOfModuleAndItCanBeDoneInBuildFile'}), там где надо
там где надо указываете basedir и все, он будет рутом и можно будет писать/по/неймспейсам при этом это будет проще дебажить потому что понятно что где лежит сразу, и в принципе раскладывание по неймспейсам по папкам это общепринятая практика в разных языках.
можно указать entry point (и даже не один) у которого указать basedir и он будет автоматом на все распространен. в общем никаких проблем не вижу и не понимаю, в моем случае у меня есть бандлы, все приложение рисуется на сервере И на клиенте, бандлы собираются автоматически синхронные и асинхронные версии, все просто до безумия и я не вижу никаких проблем вызванных браузерифаем у себя.
../… вот такие пути нельзя использовать, это да, безумие. нет, я имею в виду вообще, такие пути вообще нельзя использовать нигде, особенно в браузере, но вообще — в любом коде. это всегда приводит к проблемам. разве что можно ./ для указания принадлежности к текущему неймспейсу.
кстати «уи слой» используют яндекс (бем тулзы на node.js) и mail.ru (в почте по крайней мере).
для яндекса — это хороший способ отделить фронтенд разработчиков от бекенда.
для мэил.ру — ускоронение рендеринга (поищите, на хабре статья была).
и да отделить слой рендеринга в отдельный «сервис» внутри приложения — это часто хорошо, точнее даже так, делить на отдельные «сервисы» всегда лучше чем огромный монолитный каркас.
помните, то что backbone очень минималистичный, из коробки доступно почти ничего?
так вот, твиттер флайт — еще более минималистичный, по объему кода еще меньше. у него нету привязки к какому либо шаблонизатору — и не обязательно вовсе. например на одном проекте с ним рендеринг ВСЕГО происходит на сервере, даже того что подгружается асинхронно. Сделано это из соображений простоты (ну и на самом деле так много кто работает, например basecamp, github (вроде частично) и вконтакте (в большинстве мест)). На других — разные шаблонизаторы, в основном handlebars. которые имеют реализацию под многие языки, и рендерить можно на чем угодно. вообще я давно собираюсь написать пару статей по флайту, но никак времени не найду, но уже успел некоторое число людей на него перевести :)