На первый взгляд CMS весьма достойная, особенно учитывая что вы писали ее в одиночку. Этот же факт сильно останавливает от ее использования, ведь в какой-то момент у вас могут смениться приоритеты. Вы думали над способами монетизации проекта? Например, по моим ощущением функционально ваша CMS ничем особо не уступает американскому ExpressionEngine от EllisLab, которая кстати написана на предке Коханы CodeIgniter'е. Так вот у них есть бесплатная версия и платная за $300 лецензия. В рашке за эти деньги вероятно удушатся, но если вам удасться вывести свои разработку на глобальный уровень, но можно вполне себе зарабатывать.
Грустно все это...((( Надеюсь вы ребята не прогадали, но даже если нет, то вряд ли это повысит удобство для публики. Итак в последнее время не часто вас посещаю, а уж 2 ресурса юзать точно не буду.
На Хабре конечно не мало педантов типа «этой статье не место здесь..» и все такое, но все же именно разнообразие тематик и форматов статей делало Хабр чуть более интересным, чем он уже когда-либо станет с концепцией «только профильное IT». Жаль.
Довольно странно, ведь все крупные соц.сети имеют ТВ клиенты, Badoo всегда казалась мне достаточно крупной. Хотя раз не планируется, значит наверное есть причина…
Да, это базовый pjax сайт. Такие мы делали еще в далеком 2008, как только ajax стал хоть немного варимым. И это прям скажем не интересно, ибо настоящее SPA намного сложнее с точки зрения клиента и намного проще с точки зрения сервера и того как он работает с разнообразными видами клиентов (веб, мобилки, тв итп). Можно сказать что от сервера останутся только «веб-сервисы» в вашей терминологии. Кстати, а ТВ клиенты у вас есть, для Smart TV всяких?
Если честно, заголовок статьи желтоват. Ведь по сути это не проблема REST или чего угодно, просто одни разработчики не внимательно вникают в стандарты, а другие смотрят на «старших» товарищей и делают «как у них». Если по существу вопроса, то да, 404 должна возвращаться только при отсутствии ресурса, более того, если мы запрашиваем коллекцию в которой нет элементов, то даже в этом случае это 200ОК и пустой список, а вовсе не 404. Все правильно автор написал о том, что должен был быть 405 и список разрешенных методов, более того «разрешенность» может быть основана как на правах доступа (например, не админ не может удалить коллекцию), так и на просто нереализованности конкретного метода для ресурса. Более того, для каждого ресурса гоже также реализовать метод OPTIONS, чтобы клиент мог заранее узнать о своих возможностях приминительно к конкретному ресурсу. В итоге, могу сказать, что концепция REST'а прекрасна, но хороших реализаций мало, а идеально правильных просто нет. Всем кому интересна тема советую статьи и презы ребят из apigee.
Просто хочу уточнить, у вас именно SPA или все же Pjax app? Просто если полноценный SPA, тогда причем тут генерация blitz-шаблонов да и вообще понятие «страница»?
В сфере венчурных инвестиций инвесторов интересует возврат в сотни и даже тысячи раз превышающий инвестиции. Где-то слышал цифру $100М годового оборота к пятому году. Типа нижняя планка. На практике же мало кто ее преодалевает. Именно поэтому и говорят, мол малый процент успешных стартапов, хотя на самом деле как посмотреть на критерий успешности.
Да, именно Single Page Application, конечно) Обычно еще используется один из MV* фреймверков (BackboneJS, AngularJS etc). Так вот чем толще становится такой клиент, тем больше возникает желание использовать WebComponent'ы. Лично я буду юзать Polymer в следующем своем проекте. Ну и конечно история веб компонентов это история создания переиспользуемых компонент для разных проектов.
Ну так вы изучите сперва вопрос, прежде чем комментарии писать.))) Считаю что статьи на Хабре это как сигналы к действию. Они позволяют поспевать за технологиями, хотя бы относительно. Например эта статья не содержит информации более полезной, чем просто сообщить о существовании подобных стандартов, далее каждый сообразно своей любознательности может раскопать нужную информацию. Кстати на хабре про компоненты были очень даже неплохие стати уже.
Не использую edge-технологии в вебе, не могли бы вы пояснить бонусы от инкапсуляции стилей и скриптов в мелкие элементы? Пока не сталкивался со случаем, когда это действительно требовалось.
Хочу уточнить, вы когда-нибудь разрабатывали толстые javascript клиенты, типа SPA?
Сравнивать Web components, iframe и ajax вместе просто не этично, ведь и функционально и по смыслу они совершенно разные. Ajax — просто асинхронные запросы из браузера (причем преимущественно к своему же домену, отсюда и Cross-domain policy, хоть от нее и начинают отходить), iframe — дает возможность помещать полностью независимые документы как часть родительского(в первую очередь внешние к данному ресурсу, отсюда и слабости в возможностях взаимодействия с ним, согласитесь postMessage не слишком удобен), а Web components — это просто песня!))))
Но раз уж сравнение произошло, то попробую описать разницу.
1) Если мы говорим об ajax-запросе, который получает кусок html разметки для вставки в DOM текущего документа, то особенности этого очевидны. Этот кусок разметки не имеет ни малейшей инкапсуляции и является просто новой частью документа. Все новые стили и скрипты воздействуют на него, а его собственные стили и скрипты — на весь документ.
2) iframe — это супер инкапсуляция, а точнее вообще отдельный документ, со своим DOM, скриптами, стилями вообще всем. Но и грузите вы туда всегда лишнего, например базовые стили вашего дизайна. Управлять этой штукой также не очень то удобно, да и представить себе страницу полностью состоящую из iframe'ов можно только в далеких 90-х — начала 2000. Сейчас вряд ли.
3) web component — функционально это смесь первых двух подходов, т.е. с одной стороны компонент инкапсулирует в себя стили, скрипты и разметку, с другой стороны является полноценной частью текущего документа, т.е. встроена в текущий DOM, но имеет свой собственный ShadowDOM (примеры audio и video теги html5).
Очень странно вы рассуждаете)) Вы видемо действительно не понимаете суть Веб компонентов, потому как для меня ваши доводы сравнимы с: «Мы итак неплохо забиваем гвозди камнем! Зачем нам еще молоток придумали?»))))
А если серьезно, то говорить об импорте отдельно от самих Веб компонентов только людей путать.
Обрамление скриптов позабааило))) А так, ну да одна из реализаций области видимости с помощью самовызывающейся функции, только вопрос зачем вы переопределили window как document, а document как jQuery? Либо вы не понимаете что написали, либо я не понимаю зачем вам это.
Странно вы рассуждаете, учитывая что само понятие инвестирования гараздо шире венчурного о котором вы неявно упомянули. Более того венчурное инвестирование в стартапы это очень малый процент от общего объема внешнего инвестирования, которое так или иначе привлекается бизнесом. Как правильно было замечено автором, обычно инвестируют в уже прибыльные и стабильные компании для ускорения их роста и/или выхода на другие рынки.
На Хабре конечно не мало педантов типа «этой статье не место здесь..» и все такое, но все же именно разнообразие тематик и форматов статей делало Хабр чуть более интересным, чем он уже когда-либо станет с концепцией «только профильное IT». Жаль.
Хочу уточнить, вы когда-нибудь разрабатывали толстые javascript клиенты, типа SPA?
Сравнивать Web components, iframe и ajax вместе просто не этично, ведь и функционально и по смыслу они совершенно разные. Ajax — просто асинхронные запросы из браузера (причем преимущественно к своему же домену, отсюда и Cross-domain policy, хоть от нее и начинают отходить), iframe — дает возможность помещать полностью независимые документы как часть родительского(в первую очередь внешние к данному ресурсу, отсюда и слабости в возможностях взаимодействия с ним, согласитесь postMessage не слишком удобен), а Web components — это просто песня!))))
Но раз уж сравнение произошло, то попробую описать разницу.
1) Если мы говорим об ajax-запросе, который получает кусок html разметки для вставки в DOM текущего документа, то особенности этого очевидны. Этот кусок разметки не имеет ни малейшей инкапсуляции и является просто новой частью документа. Все новые стили и скрипты воздействуют на него, а его собственные стили и скрипты — на весь документ.
2) iframe — это супер инкапсуляция, а точнее вообще отдельный документ, со своим DOM, скриптами, стилями вообще всем. Но и грузите вы туда всегда лишнего, например базовые стили вашего дизайна. Управлять этой штукой также не очень то удобно, да и представить себе страницу полностью состоящую из iframe'ов можно только в далеких 90-х — начала 2000. Сейчас вряд ли.
3) web component — функционально это смесь первых двух подходов, т.е. с одной стороны компонент инкапсулирует в себя стили, скрипты и разметку, с другой стороны является полноценной частью текущего документа, т.е. встроена в текущий DOM, но имеет свой собственный ShadowDOM (примеры audio и video теги html5).
Надеюсь понятно объяснил))))
А если серьезно, то говорить об импорте отдельно от самих Веб компонентов только людей путать.