Начинаю разбираться с этими вашими вебами

Ну да, анон, ты просто гений.

у районной библиотеки некого миллионника сайт сделан именно так

Ты хотел сказать, что это что-то доказывает? Что?

А как правильнее?

Намекну, чтобы не закидали помидорами. Вы много сайтов знаете на perl и C++? Что сложнее - сверстать или сделать оптимизированный движок? А что важнее в сайтах - чтобы его посещали или создать?

Спорить и ругаться резко передумал. Просто так удивился, что написал первый коммент.

Вы много сайтов знаете на perl и C++?

У меня нельзя такие вещи спрашивать, я только $сабж. Давай, выкладывай. Прошу окружающих спрятать помидорки и послушать товарища.

А что важнее в сайтах - чтобы его посещали или создать?

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

Да всё быстро закончится, почти не больно.

Товарищ изучит по советам какой-нибудь не популярный js-фреймворк. Потом изучит cgi с perl'овкой. А потом внезапно (!) выяснится, что работодатели хотят Bitrix и Drupal с jQuery, а вовсе не кривые самописки на perl'е. Это при том, что знать один из этих монстров «на отлично» в разы сложнее, кмк, чем знать PHP. А при попытке доработать за кем-то какой-то скрипт на jQuery придется неделю не спать, чтобы разобраться нормально.

Или вообще ужасное: тут почти все говорят, суть, только про верстку, забывая, что самая сложная сложность разработать не тормозящий распределенный на несколько серверов сервер-сайд. А верстка - так, проходной мимолетный этап, который делается в 50 раз быстрее, чем сервер сайд.

Я вообще придерживаюсь мнения, что программист может отлично знать только какую-то одну область. Если пытаться на годном уровне осилить 10 js-фреймворков, 4 языка, годных для веба, 5 CMS и т.п., то ничего хорошего не выйдет.

«Регулярный сайтостроитель» таки сейчас и есть тренд. 95% всех сайтов - делаются быстро, на популярных технологиях. Это не значит, что за это мало платят.

тренд. 95% всех сайтов - делаются быстро, на популярных технологиях. Это не значит, что за это мало платят.

:)

Ваш смайл выглядит так, как будто вы что-то знаете, но не говорите. :)

Работодатели хотят рабочие проекты, а если ты про тех «работодателей», которые тупо перепродают мой труд, ловко подмазывая клиента баззвордами — с такими я дел не имею, своя голова имеется.

может отлично знать только какую-то одну область

Прямой путь к работать на дядю за вкусную, но еду. Мое личное мнение, без обид.

Товарищ изучит по советам какой-нибудь не популярный js-фреймворк. Потом изучит cgi с perl'овкой. А потом внезапно (!) выяснится, что работодатели хотят Bitrix и Drupal с jQuery, а вовсе не кривые самописки на perl'е.

Ты остал от жизни. Нынче в моде one page applications, которые состоят из сервера (c/perl/python/ruby/etc) и клиента (js). И игрушки онлайновские все делаются на этом принципе. Просто писать сайтики на php уже не модно, т.к. достаточно много индусов-кодеров, которые сбацают такое за неделю и за копейки. И какой контент будет на этом сайте? Ну, хорошо если это новостной сайт. Хорошо если это сайт компании. Но есть и другая сфера с приходом андроида и ios - веб-приложения, с функционалом как у нативных. И, конечно, ты отчасти прав, но ведь каждому свое.

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

Кто говорит? Я говорил выбирать си/си++ для серверной части :) А клиентская часть пишется на js/flash. По-моему, ты невнимательно читал посты.

Ты остал от жизни. Нынче в моде one page applications, которые состоят из сервера (c/perl/python/ruby/etc) и клиента (js).

Внезапно, «сайтики на php» тоже состоят из сервера и клиента. :)

Я говорил выбирать си/си++ для серверной части :) А клиентская часть пишется на js/flash.

Если вы мне объясните, каким таким образом вы обойдете HTML как конечный результат генерации веб-страницы (а никакой не js), я вам памятник поставлю (метафорический).

Внезапно, «сайтики на php» тоже состоят из сервера и клиента. :)

Я с этим не спорю. Только логика у вас будет в html-генерации, а не собственно в том, что нужно сделать. И какие модели вы не будете использовать, MVC и прочие абстракции при таком подходе у вас всегда будет только законченная версия продукта - html код. Ниже я поясню в чем разница.

Если вы мне объясните, каким таким образом вы обойдете HTML как конечный результат генерации веб-страницы (а никакой не js), я вам памятник поставлю (метафорический).

А не надо мне ничего, спасибо. Объясню нынешнее и многими проверенное решение как можно делать приложения для всех типов устройств:

• Серверная часть. Ключевой момент выбор API: json, json-rpc, rest.
  
• Клиент, готовый работать с этим API: js, qt, perl, c, c++, c#, вобщем какой язык не возьми, все они смогут общаться по этому апи.

Основная тенденция в том, что эту модель начали переносить даже в systemd. И в ближайшие полгода появятся готовые инструменты для работы с этим. Даже на локалхосте данная архитектура себя оправдывает, хотя и не без потерь производительности (они несущественны). Red Hat, если смотреть за их софтом по настройке того же iptables (в rhel и gui'шка своя, в федорке 19 некий firewalld), активно впиливает и продвигает данные методики. Т.к. это дает огромный скачек в развитие приложений: сервер пишется один раз и можно написать 100500 клиентов под все виды платформ от вебовской, до межсерверной (демон-демон). А поскольку текущий JS сильно завязан на html-коде, то поверх этого простого API вешается HTTP. Отвязаться от HTTP очень легко, точно также как и привязать его (по крайне мере в перле). Конечно для максимум перформанс тут подойдет решение типа CORBA, но увы, веб его никак не собирается поддерживать.

Ок. Я унизительно предположу, что почти 8 лет сайто-строительства я провел зря. Можете дать ссылку на мануал/пример реализации вашего последнего абзаца? Возможно, я последние пару лет столько пахал, что ничего вокруг не видел, а-ля «продается и отлично».

Единственное, что я не понял - это никак не отменяет реалии сегодняшних дней. Миллионы сайтов на CMS, все студии разрабатывают на этих CMS и так далее. Либо я слишком тупо (недавно проснулся), чтобы понять то, что вы написали. Либо мы говорим суть об одном, просто разными словами.

голые перл

Порнография в квадрате!

Можете дать ссылку на мануал/пример реализации вашего последнего абзаца?

Всю концепцию я описал выше. Вообще никаких мануалов никто не писал, ну кроме разве диссертации 2000 года по предложению использовать REST повсеместно. В вики точно есть ссылка на нее. Там изложена концпеция и техническая реализация.

Миллионы сайтов на CMS, все студии разрабатывают на этих CMS и так далее.

Еще раз поясню. Классические веб-сайты, те о которых вы говорите никуда не делись. Но появился новый класс конечных приложений именно для веба. Если ты взглянешь на мой pastebin (никакой рекламы, сделан чисто для себя), то на первый взгляд покажется, что это легко делается на php. Да, так и есть. Разница в том, что я могу спокойно написать нативной приложение под андройд под него не трогая веб-часть вообще, а также отказаться от лишней нагрузки на CPU для парсинга HTTP. Также могу дать прямой API под любым другим протоколом, с минимум усилий, чего нельзя добится просто написав тоже самое на php под апачем/nginx'ом. Тем не менее данный пример это случай когда невидно никакой разницы между тем или иным подходом. Как ты понял разница ощущается именно тогда, когда кроме выдачи динамичного html ничего не требуется. Вся классика отлично будет работать еще долгое время, потому что писать сервер под выдачу html-кода вообще нет смысла. Библиотека libxml, которая чаще всего используется для этих целей крайне прожорливое «существо» и даже нет смысла переходить на новую методику ради своей новой CMS. Но и что не менее важно это то, что клиентские js-движки все еще недостаточно шустры для генерации больших страниц. Проще, быстрее, приятней когда браузер получает статику и сразу рисует все, минуя лишние ajax запросы и изменения/построения DOM.

Лично ЯННП.

Кажется начинаю допирать. Хочешь сказать, что index.html это не более, чем способ загрузить клиентскую чатсь на клиент. То есть она могла там оказаться и другим путем, и также прекрасно работать в серверной частью путем «на гет-пост, дай жсон», причем вовсе не обязательно при этом быть браузером, чтобы т.о. работать с сервер-сайдом. Так?

Проще сказать на примерах. Есть новостной сайт, куча текста (с форматированием, отсутпами, стилями) + картинки. Вариант с выдачей всего этого добра из отдельного сервера через json не имеет практической пользы и выгоды.

Есть сайт, который предлагает интерфейс к записи формул, типа MATLAB и только. Можно написать на php в виде отдачи статики + немного ajax'а, а можно написать сервер с api + HTTP, тогда клиент может быть хоть на вебе + все тот же ajax, либо нативно для ios/android/desktop минуя запросы по HTTP на порт 80/443, а прямо подключаясь к серверу на порт 12345 и используя REST/JSON/CORBA.

Так?

Так. Один сервер, один API, видов реализации клиента - масса.

Проще, быстрее, приятней когда браузер получает статику и сразу рисует все, минуя лишние ajax запросы и изменения/построения DOM.

Для этого надо в браузерах реализовать кроме обновления еще процедуру слияния страниц, чтобы новые данные от сервера ложились в старые места без мерцания страницы и главное — без потери js-контекста и таких мелочей как фокус и позиции прокруток.

прямо подключаясь к серверу на порт 12345

Так это старый добрый клиент-сервер... В чем крутизна инновации-то?

используя REST/JSON/CORBA

В том, что протокол фиксирован? И какой это протокол тоже непонятно — если не хттп, то велосипед или GIOP какой-нибудь? Мне всегда казалось, что хттп тем и крут, что можно по-цгишному отдать не хтмл, а какие-то любые мутные данные, и прилепить к ним статус, mime и прочие заголовки, чтобы клиент понимал что собственно получает и получает ли вообще.

Есть новостной сайт

С другой стороны, текст вполне структурирован — дата, автор, заголовок, текст, две картинки, срач комментов. Можно написать приложение под айфон, чтобы читать в полу-оффлайне с нормальными шрифтами. Даже ютуб приложение написал.

Я к чему, может MVC-фреймворки и CMS как раз об этом?

В чем крутизна инновации-то?

Ни в чем. Я же сказал, что это давно отработанная методика. Просто в вебе ее стали использовать относительно недавно. А сейчас методика уходит в массы. Многим лень изучать obj.-c, java ради портирования проги с десктопного веба на телефон, а кушать хочется. Раскрутится webgl, тогда и нативные игры (проги кстати тоже) начнут уходить на второй план.

В том, что протокол фиксирован?

Да. Я просто развил мысль дальше, хотя выделять отдельный сокет/протокол необязательно. Все можно делать и через HTTP.

Мне всегда казалось, что хттп тем и крут, что можно по-цгишному отдать не хтмл, а какие-то любые мутные данные, и прилепить к ним статус, mime и прочие заголовки, чтобы клиент понимал что собственно получает и получает ли вообще.

HTTP несет лишнюю нагрузку. Но это мое ИМХО. Я просто до того как занялся подобными веб-приложениями много написал сервер-клиентских приложений с использованием только json. Поэтому мне проще запихнуть данные json, а в случае с бинарными данными пускать их вообще отдельно. Т.к. сериализация/десериализация тоже кушает проц.

Я к чему, может MVC-фреймворки и CMS как раз об этом?

Ты уже ответил на этот вопрос.

Вот всегда так, как ни вылезешь из криокамеры, всегда все хреново. Обратно что-ли залезть...

Видимо я этим и запутал, раз начал говорить про другие протоколы и сокеты. Сервер по идее должен иметь только один интерфейс/API, например, json + http. Все клиенты тогда тоже имеют единый интерфейс, но разные реализации: js, obj.-c, c#, java и т.д. Вот это и есть классическая модель сервер-клиент.

Обратно что-ли залезть...

Тебя никто не заставляет писать в таком стиле. Пиши как нравится/получается. А можно писать и дальше нативный код, он всегда будет ценится и всегда будут задачи только под такой путь.

Несет, но есть же lighttpd и всякие другие обрезанные сервера, в которых из CRUD только R остался, да и тот умеет только да/нет и висеть на 80 порту. А любая уважающая себя платформа умеет new HttpRequest(url, callback), что существенно удешевляет входной билет в клиент-сервер, имхо. К тому же я сильно сомневаюсь, что за проксями дешевых провайдеров и 3G-шлюзов всегда можно достучаться до 12345 удаленной машины.

Да, мне тоже уже кажется json/примитивный-http это идеальный вариант для любого вида стейтлесс-клиент-сервера.

https://ru.wikipedia.org/wiki/Model-View-Controller
http://www.tinymvc.com/

А что такое веб сокеты вообще? Можешь коротко объяснить?

http://ru.wikipedia.org/wiki/WebSocket#.D0.9E.D1.82.D0.BA.D1.80.D1.8B.D1.82.D...

Сервер не закрывает соединение, обычная tcp сессия поверх хттп заголовков.

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

// Старпёрское ворчание

До сих пор не могу понять зачем люди говорят «хид» на head.