JS вместо HTML

[веломан]

короче почитал я тут одного умного человека и открыл он мне интересную мысль, но пока сомнения есть, что гугл уже к этому готов

Для чего это все можно еще применять. Например для создания крайне легких и быстрых сайтов через связку:
client-side (JS/AJAX) -> JSON запрос -> маппинг JSON запроса на хранимку или запрос в базе -> база (sql или pl/pgsql) -> JSON ответ от базы -> client-side (JSON/AJAX)-> отображение.
В таком варианте программирование как таковое присутствует только на клиенте и минимально в базе.

При этом уходит фактически все server-side программирование (php/perl/java/etc).
При желании http json<->postgresql общение можно сделать через простой модуль в nginx (libpq поддерживает асинхронный неблокирующий режим работы с базой).
Производительность таких решений легко может на порядок превышать производительность классического веб сайта (при одинаковом железе).

Чем сейчас занимается код веб-сайта 90% времени:
1)генерацией запросов в базу (ORM)
2)превращением ответов базы в объекты (опять ORM)
3)преобразованием объектов в HTML
Вопрос: зачем городить такие сложности если можно получить от базы готовый JSON и отдать его клиенту как есть для отрисовки?

в общем смысл в том, чтобы всю работу (вместо ПХП) делала БД, при этом отдавала сразу JSON, который идёт прямиком в JS.
конечно во всякие CRM/ERP вообще без вопросов заедет, но в остальном, что скажет угл?

[Hector]

веломан, да какая разница если яваскрипт движок все отрендерит.

[веломан]

ну разница очевидно есть, раз яндекс нормально это сделать не может до сих пор

[Hector]

веломан, потому что нет у него столько ресурсов. Сам попробуй сколько времени и процессорного в том числе займет обойти например phantom js лям страниц. Это не сравнить с обычным get request. Часто сайты что сделаны по твоему принципу сами рендерят html и кормят ботам.

[Lord_Alfred]

Давно уж такой подход используется, вы че.
Один только react.js сейчас как ценится у фронтендщиков.
А по поводу запросов в базу - так там всё идет через API, а не прямыми запросами в СУБД, никто так не делает.

PS: гугл нормально такое сожрет и отрендерит.

[Reach]

нормально сожрет только то где нет аякса

[somtam]

Вместо тысячи слов:



для гугла в JS фронт-энд фрэймворках есть как правило Server-Side Rendering это когда на клиенте нет JS он рендерит страницу на сервере (nodejs)

Выше смотрю кто-то упомянул ReactJS

[eXeCUT]

Если думать дальше, чисто теоретически можно вообще без веб-сервера обойтись, ведь SQL - это тоже язык программирования и на нём можно написать что душе угодно. Вариант такой:
Клиент -> сервер БД на 80-ом порту парсит запрос -> ответ в виде html\json -> клиент

Давно встречал реализацию CMS на чистом SQL, но сейчас не могу найти.

Самый лёгкий вариант для минимизации назгрузки на сервак что мне представляется возможным - это использовать сервер как распределительный прокси между клиентами, а клиенты - это отдельные браузерные приложения на JS, которые синхронизируются между собой и раздают свои копии другим клиентам. peer-to-peer сайт получается=)

А вообще я не встречал такого ajax-сайта при условии отсутствия на нём не ajax-версии, чтобы гугл его нормально индексировал. Он индексирует только то, что выдаёт веб-сервер. А то, что касается попытки рендеринга самим гуглом - это другая история. Подозреваю что гугл это делает, чтобы прочекать сайт на вшивость, эквивалентность того, что отдаёт сервер и отображает браузер.

[Ronald]

Сообщение от eXeCUT

Если думать дальше, чисто теоретически можно вообще без веб-сервера обойтись, ведь SQL - это тоже язык программирования

Нет, sql - это язык запросов, а не язык программирования. Абсолютно разные вещи, что душе угодно написать не получится, потому как большие и тяжелые запросы - очень медленные и неповоротливые. Любой софт висящий на 80 порту - это уже веб-сервер принимающий и обрабатывающий http реквесты, да и сама идея обойтись без веб-сервера - это как отпилить себе ногу и пытаться примотать к культе веточку скотчем, если не хуже.

[unicorn]

Сообщение от веломан

в общем смысл в том, чтобы всю работу (вместо ПХП) делала БД

Во-первых, при большой нагрузке БД успешно ляжет. Бекенд (пусть будет php) сможет организовать кеширование на любом уровне под различную нагрузку. Во-вторых, по мимо банального CRUDа, даже мелкому бложику нужна серверная логика: авторизация, генерирование сайт мапов и rss-лент и т.д. В-третьих, по большому счету разницы нет. Чтобы написать API для json и клиент для его рендеринга, нужно кода не меньше чем для обычных контроллеров, которые отдают готовый html. Не стоит также забывать что готовая и сжатая страница грузится на порядок быстрее за счет меньшего кол-ва запросов к серверу.

[Ronald]

Сообщение от unicorn

Во-первых, при большой нагрузке БД успешно ляжет.

Ну в теории можно заюзать nosql, mongo или elastic у них вроде как есть api, отдают json и умеют слушать 80 порт. Только зачем столько геморроя, ни гибкости, ни кеширования нормального, ни анализа запросов, хотя, для каких-то супер тривиальных целей, аля саггесты в форму юзеру отдавать - сойдет.