CMS на Javascript

    Для затравки — громкое заявление: эта статья способна оставить без работы тех backend-разработчиков, которые еще не познали дао Javascript. Если вы подумали о Node.js, то напрасно. Ни строчки серверного кода. Мы поговорим о CMS, которая работает в любом современном браузере.


    Возможно, вы уже сталкивались с генераторами статических сайтов на Ruby или Python. Это удобнее и бюджетнее, чем держать сервер с прожорливым Wordpress для сайта, на котором раз в месяц публикуется новость или прайс-лист.

    Впрочем, окружение с Руби и кучкой дополнительных пакетов для Джекила — это удел гиков. Сгенерировать сайт из пары десятков страниц можно и в мобильном браузере. Даже Opera Mini способна собрать строку html-кода и отправить ее на сервер AJAX-запросом. Это на любом телефоне с Java ME. Вот валяется у вас такой мобильник без дела, а на нем можно сайты генерировать.

    Внимательный читатель уже возмутился от упоминания какого-то «сервера» в предыдущем абзаце. Все верно, я обещал, что CMS будет работать только в браузере. Чтобы наше JS-приложение могло сохранить сгенерированный сайт, нужен какой-то минимальный backend. В эпоху облачного хранения данных этот выбор очень прост: Amazon S3 или любой провайдер OpenStack Swift. Обе платформы предоставляют REST API и возможность превратить любой контейнер/bucket с файлами в веб-сайт со своим доменом. Надежный такой хостинг, плюс всем можно управлять через AJAX вместо (S)FTP. Слава CORS!

    Окей, с серверной частью разобрались. На что способна CMS, которая работает только в браузере?
    1. Быстрая генерация html по шаблону. Шаблонизаторов, как всегда, куча. Поддержка web workers последним поколением браузеров позволяет генерировать действительно большие сайты в фоне.
    2. Естественно, визуальное редактирование в WYSIWYG-редакторе и правка исходников с подсветкой кода — Ace или CodeMirror.
    3. Загрузка файлов и редактирование изображений с помощью canvas или любых облачных сервисов.
    4. Версионность и любые мета-данные для документов. Хранилище S3/Swift и localStorage в браузере дают гарантию, что наш ценный контент никуда не потеряется.
    5. Все, что угодно. Многообразие облачных сервисов с HTTP API (например, для отправки и получения email) и более сумасшедшие вещи вселяют энтузиазм относительно будущего таких JS-приложений.


    Конечно, самое вкусное здесь — цена за хостинг статичного сайта. У российских облачных провайдеров 100Мб файлов и 3Гб трафика стоят меньше 3 (трех!) рублей в месяц. При этом не нужно жертвовать удобством традиционных CMS и тратиться на простаивающие ресурсы сервера. Ведь у нас его вообще нет.

    Если затронутая тема вызовет интерес, то в следующей статье расскажу о моей реализации такой системы управления сайтом. Всем чаю!
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 54

      +28
      А сразу рассказать не судьба?
        –23
        Минусы => интереса нет.
          +41
          Минусы — это отсутствие полезного контента в статье. Плюс ставить не за что.
        –2
        Уже придумал несколько интересных применений такой системе в рамках своих задач.
        А оптимизированы ли получающиеся страницы под поисковые системы? Метатэги, ключи и прочая магия…
          0
          Скорее всего, нет. Поисковики же, вроде, не выполняют JS.
            –7
            Вот поэтому вас и минусуют. Вы же не разбираетесь в теме :). Во-первых – выполняют, если он синхронный. Во-вторых – есть разные способы их этому все-таки научить. А еще вы, помоему, не знаете о такой штуке как Backend as a Service.

            Короче, идея здравая, но:

            1. Она на поверхности. Любой нормальный MVC-фреймворк позволит такое сделать без особых проблем.
            2. Вы не похожи на человека, который сможет сделать в этой области адекватное решение.
              0
              Я не автор темы.
              За BaaS не знал, загуглил.
              2. Как вы это узнали?
                –10
                Если вы не автор темы, то никак. Я просто сложил то, что написано в статье и ваш комментарий. Вместе это создает КРАЙНЕ стойкое впечатление решателя теоремы Ферма без понимания азов математики.
                  +1
                  А насчёт выполнения поисковиками JS я и правда не знал и рассуждал так потому, что мой сайт (с как-раз таки асинхронным AJAX-запросом) был не совсем правильно проиндексирован. Спасибо, теперь знаю, что они всё-таки запускают скрипты.
                    +1
                    Недавно даже запустили SaaS-сервис, который позволяет индексировать такие сайты. А я пару лет назад сделал это: github.com/inossidabile/hashbang. Но это убивает в щи ранжирование. Так что индексируют поисковики такой контент или нет в настоящее время вопрос философский. Зависит от того, что мы хотим индексировать.
                    +12
                    Зря вы так наехали на левого человека. Хоть бы извинились, что ли.
                0
                Google очень даже выполняет, и достаточно давно
                +2
                Описанная CMS генерирует статические страницы. Поисковая оптимизация, использование JS — все зависит от вас.
                +3
                  +1
                  Несмотря на название, это не CMS. Там нет инструментов управления содержанием.
                +4
                CMS подразумевает множество информации, которая не видна каждому посетителю, например админку, права доступа.
                Такие вещи обязательно должен контроллировать бэкэнд, на фронтенде в браузере эти данные держать небезопасно, так как у любого есть к ним доступ.
                  –8
                  Если на управляющий скрипт нет прямой ссылки где-либо и его нельзя подобрать простым перебором в духе /admin/index.html, то никто к ним и не доберется. Естественно, это в случае если админ не пользуется Яндекс.браузером или браузером с яндекс/мейл панелью. Эти сволочи всё проиндексируют. И выложат ссылку в открытый доступ. :)
                    +2
                    думается мне, что надеяться на «авось никто не найдёт» как минимум не благоразумно
                      –2
                      Отлично, давайте допустим что есть сайт с подобной CMS по адресу example.com, путь к управляющему файлу сгенерирован рандомно и название файла состоит из 20..240 абсолютно случайных символов. Вопрос: как вы найдете этот файл?
                      Добавлю, что имя файла, состоящее из 140 (например) букв латинского алфавита и цифр имеет оччень немаленькое количество вариантов.
                        0
                        всё зависит от ценности ресурса. одностраничный сайт Васи Пупкина никому не нужен, зато, например, сайт вроде хабра — был бы уже давным давно взломан.
                          0
                          Хорошо, я уточню. Имя файла состоит из 200 букв латинского алфавита и цифр. Длинна числа, содержащего количество вариантов — 0.1821797716e+312, т.е. число длинной 312 символов. При переборе со скоростью, допустим, миллион запросов в секунду, количество лет, необходимых для полного перебора, составит примерно 3.4e+295 ( 36**200/1_000_000_000/60/24/365/5 ), конечно это в случае если найдется хостер, способный выдержать перебор с такой скоростью. В конце я ещё поделил на 5 из расчета что нужная комбинация будет примерно в первых 20% перепробованных вариантов.

                          Вы всё ещё уверены что перебором вы найдете админку?..
                            0
                            и всё у Вас вроде бы должно быть хорошо… пока однажды где-нибудь не засветится url…
                            А также не забывайте о возможности взлома ftp и т.д. А также взлома соседнего аккаунта хостера и через какую-либо уязвимость посмотреть Ваш url, ведь для осуществления данного взлома даже не надо изменять никаких файлов, не надо смотреть бд — что значительно упрощает несанкционированный доступ.
                              0
                              Всё проще: кафе, WiFi, сниффер.

                              И ещё проще: хистори браузера.

                              Или вы предполагаете, что этой CMS будут пользоваться исключительно спецы по компьютерной безопастности? :)
                            +1
                            Если вы куда-то заходили браузером, скорее всего, Гугл уже знает адрес.
                              +1
                              а также если сразу и админки куда-то заходили браузером, то этот сайт уже знает url, а значит что адрес скомпрометирован, и сайт может быть потенциально взломан в это же мгновение.
                          0
                          В статье же говорим о полностью построенном на JS сайте, это означает что у него единая точка входа и весь код в браузере, со всеми возможными путями и роутингами. Какие такие пути к админке?
                            0
                            Тут только вопрос, где контроль доступа осуществляется
                        • UFO just landed and posted this here
                            0
                            в такой ситуации связка логин/пароль всё-таки будет использоваться, а также использование кросс-доменный ajax — само по себе не является фактором, повышающим безопасность, а скорее даже наоборот, т.к. ограничить по-дефолту фильтрацию по ip не представляется возможным, ввиду отсутствия у многих пользователей «белого» ip.
                              +1
                              Авторизация и общение с хранилищем идет по https. Это общепринятая практика.
                              Даже в случае дефейса, восстановление из бэкапа элементарно, т.к. это статический сайт.
                                0
                                Даже в случае дефейса, восстановление из бэкапа элементарно

                                Всегда считал, что создавать сайты нужно таким образом, чтобы тот самый «случай дефейса» не произошёл.
                                  0
                                  Чью систему авторизации проще обойти — OpenStack Keystone или вашу самописную на похапэ?
                                    0
                                    погуглите на тему уязвимостей OpenStack Keystone
                                    соответственно самописная авторизация используется на меньших количествах сервисов, соответственно меньше желающих её сломать, но логично предположить, что выбор методов авторизации прямо зависит от задач и бюджета. Так кассу в маленьком ларьке не будет охранять взвод охраны, тогда как в в крупном банке такие меры предосторожности удивления совсем не вызывают.
                              • UFO just landed and posted this here
                            0
                            Вспомнил TiddlyWiki, ухмыльнулся.
                              0
                              Кстати, да. Нужно только дописать сохранение в облако.
                              +7
                              Для затравки — громкое заявление: эта статья способна оставить без работы тех backend-разработчиков, которые еще не познали дао Javascript.
                              эммм… А где, собственно, статья?
                                +3
                                Был у меня знакомый который писал магазин на css, может вас познакомить? :)
                                  –2
                                    0
                                    Ссылку не дадите?
                                      0
                                      Ссылку на что?
                                      Как вы себе представляете полностью инет магазин на чистом css? :) Это ж было из серии: «вау! с помощью css можно менять стиль элемента под мышкой, а напишука я инет магазин на чистом css»
                                        0
                                        > Ссылку на что?
                                        На магазин вашего знакомого, или статью о том, как он его делал.
                                          0
                                          Потому и спрашиваю, что не представляю.
                                      0
                                      Являясь начинающим веб-разработчиком, так же интересуюсь js (вижу в нем огромный потенциал), такая новость не может не понравится, такая низкая стоимость хостинга, просто радует, что возможно «жаба» душить не будет, платить за хостинг более 100 руб/мес, при том, что проекты мои нуждаются в доработке, а поделиться ссылочкой с друзьями, или продемонстрировать сайт (не нося его на флешке постоянно) к примеру заказчику, хочется. :)
                                      Считаю, что новичкам, таким как я, будет тоже в радость такая новость. Так как 3 руб\мес, это копейки. :) А похвастаться так же хочется.
                                        +2
                                        если нужны только клиентские штуки и только что бы показать друзьям, то проще всего заюзать pages.github.com/, и это будет стоить вам 0 руб/месяц
                                          0
                                          Благодарю Вас, обязательно затестирую. :)
                                            +2
                                            Или «захостить» на jsfiddle :)
                                          +2
                                          Вы будете писать об этой CMS или нет?
                                            0
                                            Конечно.
                                          • UFO just landed and posted this here
                                              +1
                                              Автор давай пиши! Все хотят.
                                                0
                                                Теоретически, можно. Но тут несколько важных моментов. Если заказчик имеет столь скромные средства, что не может оплатить хостинг — что собственно получит с такого заказчика разработчик? Далее — захотел заказчик банальную форму заказа или что-то другое, более специфическое, что из готового кода не взять. Да, можно опять-же исхитриться и написать все на клиентском JS. Но эта задача будет в разы сложнее, чем на привычном стеке технологий. А так как заказчик не может оплатить нормальный хостинг, адекватную сумму за эту задачу мы не получим. Даже если заказчик к этому моменту уже разжился средствами, все-равно объем работы на расширение функционала будет гораздо больше. Да и имея приличный опыт использования и расширения такой системы разработчик скорее переквалифицируется в обычного front-end разработчика, где зарплаты намного выше а проблем намного меньше.

                                                image

                                                Хотя, есть обратная сторона. Из такого проекта может вырасти что-нибудь интересное, применимое на практике, но очень далекое от изначальной цели, ну и опыт бесценный никуда не денется. Если у Вас получится и вы напишете про эту статью, будет интересно почитать. Только чтобы не оказаться в минусе, постарайтесь обойтись без громких заявлений. Такой проект, описанный изначально как jsut for fun будет воспринят намного позитивнее.
                                                  +1
                                                  Вы старую парадигму веб-разработки описали: «нужно оплатить хостинг», «форма заказа» должна иметь бэкенд на этом оплаченном сервере и т.д. Если мыслить категориями облачных сервисов, SaaS и PaaS, то все встает на свои места. Если клиенту выгоднее ценообразование облака, то он найдет того разработчика, который владеет этими технологиями.
                                                  Только чтобы не оказаться в минусе, постарайтесь обойтись без громких заявлений.

                                                  Троллинг ригидности мышления — неблагодарное занятие, но это должен кто-то делать. В конце концов минусы на хабре — это не костер инквизиции.

                                                Only users with full accounts can post comments. Log in, please.