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 вообще без вопросов заедет, но в остальном, что скажет угл?

[веломан]

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

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

там речь про это:

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

[eXeCUT]

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

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

Это и то и другое. Вот википедия:
SQL (ˈɛsˈkjuˈɛl; англ. structured query language — «язык структурированных запросов») — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей системой управления базами данных.

То, что он не предназначен для таких вещей как нормальный язык программирования это понятно. Писать на нём программы убыточно и будут делать только из безвыходности или извращенцы=) Но в нём есть всё для этого - процедуры, циклы, условия и прочее. В PostgreSQL даже баш-скрипты можно писать и исполнять, к unix-соккетам подключаться, ввод-вывод в файлы и прочее. Можно написать любую программу, короче. Хоть интерпретатор SQL

[xUnicornx]

Как говорил мой тезка unicorn - логику с помощью скл ты не добавишь, а вот положить БД при большом количестве юзеров - запросто. Все равно нужно какая-то логика для редактирования хтмл выдаваемой страницы, через мускл клиенты делать это не удобно.
В этой ситуации проще всего сделать статические страницы html и их уже дергать с помощью аджакса. Тогда БД исключаеться из схемы и все работает просто и надежно.
Но, имхо, это возврат назад в каменный век. Хотя.. Для каждой цели свой инструмент

[веломан]

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

В этой ситуации проще всего сделать статические страницы html и их уже дергать с помощью аджакса. Тогда БД исключаеться из схемы и все работает просто и надежно.

[malishka]

В этой ситуации проще всего сделать статические страницы html и их уже дергать с помощью аджакса. Тогда БД исключаеться из схемы и все работает просто и надежно.

Вроде это уже придумали, кеш называется?

[xUnicornx]

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

какйо вопрос - такой и ответ.

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

Вроде это уже придумали, кеш называется?

Кеш - это немного другое ) Но ответ сути не меняет - от серверной части программинга никуда не деться. А то что описал ТС - больное воображение автора книги

[xUnicornx]

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

А то что описал ТС - больное воображение автора книги

в общем лол, не доконца понял схему которую рисует автор книги) еще один вариант реализации приложения

[AlexBO]

ТС, технология правильная, одностраничный интерфейс с запросами голых данных от сервера и компоновкой клиентом существует и используется лет 15 как минимум (мои попытки в частности этим сроком датируются).

Но, как и раньше, вы не учитываете скорость распространения железа. Рендер и компоновка на стороне клиента как раньше сильно зависел от железа клиента, так и сейчас зависит. Если у вас более-менее серьезный ПК, то это не значит что даже у 10% ваших посетителей будет что-то похожее.

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

Это как с канвасом в html5 было на старте, технология вроде супер, всё гуд вроде бы, и даже одна конторка создала супер уникум сайт на канвасах в виде игры, где реальный человек (видео качество изображения) бежал по сайтам и реагировал на ваши нажатия клавиш, взаимодействовал с элементами сайта.

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

Всему свое время. Да, когда большая часть ПК-шек обновится до приемлемого уровня, данная технология станет основной, но пока - это потеря посетителей и ухудшение ПФ на своих сайтах - гарантированно.

[веломан]

хм, чё прям так сложно сгенерить HTML JS-ом ?
там же нету циклов и прочего, чисто вывести DOM

[malishka]

лет 15 как минимум (мои попытки в частности этим сроком датируются).

Ого, интересно. Т.е вы использовали ajax уже в 2003ем? Если так, то это был мегапрорыв на то время.
Я помню, первый раз увидел ajax элемент, где-то в 2005-2006 году на nnm.ru. Когда кусок странцы сам по себе обновился - это была фантастика. Тогда правилом было вопрос-ответ-вопрос-ответ, страницами целиком, и в этом правиле не было исключений. По кр, мере для обычного юзера. В лабораториях Microsoft эксперименты с Аякс начались еще во времена IE 5.5 (вроде первый браузер который может аякс), кажется, но это все не для массовой публики, и мы узнали об этом лишь потом.