Изоморфные веб-приложения готовы?

Хоть бы вас всех такой понос пробрал, чтоб вы с толчка неделю не вставали.

Думаешь, все умеют в английский? Перевод на БХ.

Думаешь, все умеют в английский?

кому надо умеют, остальные кущяют хлеб бородинский и водку-мандарины

the bulk of the code runs in the browser in order to support a more modern, interactive experience

дальше не читал. за эти поползновения нужно просто убиват.

от количества пафоса в этом сообщении у меня солонка стала по «смирно» и пропела гимн США

прочитал по-диагонали

идею писать fallback интерфейс на PHP на случай, если отвалится или не заведется интерфейс на JS активно продвигали почти сразу после того, как умерли динозавры

в чем разница «изоморфных» от обычных с fallback на Web 1.0 ?

если разницы нет, то, с моей точки обзора, нет, идея не взлетела, таких сайтов надо еще поискать

Все программисты — да.

прочитал по-диагонали

That's your problem. Идея в том, что серверный fallback на Node.js, и код для fallback и клиентского JS-интерфейсу тот же самый, только в некоторых местах надо ставить что-то в духе if (isClient) { . . . }.

Давно Web-development стал иметь отношение к программистам?

Со времён perl+cgi, наверное. Это достаточно давно?

Fail by design.

Пащиму, насяльника?

А можно просто использовать рельсы не писать «аппы» на 1 страницу.

Давно Web-development стал иметь отношение к программистам

погромист в треде, все в дебагер

продолжайте наблюдения

Хоть бы вас всех такой понос пробрал, чтоб вы с толчка неделю не вставали.

Пусть просто сдохнут.

Узнаю ЛОР. Уже начали друг друга виртуально кормить говном, а ответа на исходный вопрос и близко нет.

А какой ответ ты ждёшь? Тут как бы считается, что все эти ваши хунгуляры сами по себе не нужны, а ты про костыль для них спрашиваешь.

Тут Дартвейдер полраздела исписал за хунгуляры.

неустаю приводить пример фейспука или твитера

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

а у тебя предлагают сделать на джаваскрипте чтото сложнее хеловорда с изменением цвета рамочки?

ну удачных терабайт и терагерц(ибо тормоза и потребление с каждым лоадом или циклом растут в геометрической прогрессии)

Это агент тёмной стороны, не верь ему.

React, все работает. Сервер сайд - 93 строки.

Мне не нравится, когда на JS начинают переделывать браузер: подгружать страницы, управлять историей, кнопками вперёд-назад, делать свои табы. Некоторые даже делают свой браузер с контролами внутри страницы. Этот функционал уступает браузерному, просто потому, что браузер писали умные люди, а на сайте этот функционал прикрутили по-быстрому.

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

Ну вот например http://dev.nodeca.com/

Первый раз страница грузится с сервера, а дальше все на клиенте рендерится. Всяких упоротых «if (client)» нигде нет.

прочитал по-диагонали

That's your problem. Идея в том, что серверный fallback на Node.js, и код для fallback и клиентского JS-интерфейсу тот же самый, только в некоторых местах надо ставить что-то в духе if (isClient) { . . . }.

идея понятно, но нет подробностей, например о:

что делать с безопасностью?

все имеют исходник (обфускацию и упаковку разными closure compiler я не хотел бы делать на JS. Closure compiler НЕ делает код быстрее. Часто - наоборот. Он делает код меньше, чтобы сэкономить на трафике. Не самое узкое место, если ты не гугл. Зато отладка превращается в жесть)

валидации для безопасности на JS - это отличный способ сделать продукт медленным,

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

и второй вопрос: как нагуглить 100 миллионов топиков о практическом применении? nodejs fallback и вариации node js render dom дают 3.5 унылых топика от 2011 года

есть ли где-нибудь миллионы успешных инсталляций?

Это ж каким надо быть ишаком, чтобы на серваке жабкоскрипт использовать? Это ж ващеее...

Да не, замысел-то хорош. Только для начала браузеры нужно по-человечески делать, чтобы не текли. А то вот так промотаешь во фконтактиге ленту, бац — OOM-киллер пришиб браузер, потому как тот слишком разжирел и отожрал всю оперативу...

Не знаю, почему, но сборщик мусора не отрабатывает даже если ты явно напишешь delete() для объекта!

И из-за этого приходится городить бредятину! Я до сих пор не могу придумать способ передачи потокового видео без необходимости перезагрузки iframe, в котором это видео отображается (раньше делал mjpeg'ами, понятно, что как накопится тысяча-другая кадров, браузер начинает сильно тупить из-за жировых отложений).

У тебя 2гб оперативки?

Дома 2, на работе и ноуте 4.

все имеют исходник

Так же, как и в случае обычных single page application. Никто, вроде, от этого не умер.

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

Это, как я понимаю, должно выноситься не в fallback, а в API.

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

все имеют исходник

Так же, как и в случае обычных single page application. Никто, вроде, от этого не умер.

исходник серверного кода или его часть? от этого умирают...

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

Это, как я понимаю, должно выноситься не в fallback, а в API.

вот. пропущенная подробность. клиентский код уже нельзя просто так взять и отрендерить на сервере

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

это - очень здорово, но это - по-прежнему сильно сложнее, чем дропнуть совместимость с браузерами без JS, нет?

исходник серверного кода или его часть? от этого умирают...

Что там такого критического будет? Явки-пароли-токены, что ли? И там, скорее, наоборот, клиентский код (минус рюшечки) идёт на сервер.

клиентский код уже нельзя просто так взять и отрендерить на сервере

HTML отрендерится теми же шаблонами, больше ничего и не надо.

Они изобрели PJAX?

Abstraction, Abstraction, Abstraction

УБИВАТЬ, УБИВАТЬ, УБИВАТЬ