Это далеко не всегда так.
Отдать страничку с данными и правда не сильно сложно, гораздо сложнее отдать часть приложения с данными. Потому что вдруг выясняется, что у фронтенда есть:
внутреннее состояние (любимый цвет кнопок, текст не до конца набранного комментария, настройки какого-нибудь фильтра и еще уйма интересных штук, которые разумеется более чем реализуемы в парадигме "отдать страничку, а при переходе по ссылке отдать следующую страничку", но по какой-то причине очень часто приводят к "я тут накидал на jquery, пожалуйста не трогай это никогда")
архитектура. Потому что на чистом HTML, CSS и JS можно реализовать всё что угодно, но на Angular (фанатам фейсбука читать как "React") оно почему-то выходит более поддерживаемым и работоспособным.
как ни странно, команда, которая обычно этим самым фронтендом занимаются фуллтайм, и обычно, при SPA подходе decoupling (как это по-русски правильно?) получается значительно выше.
Но ведь на текущем витке фронтендовых технологий SPA и правда удобнее и проще делать. Каноничный клиент-сервер кажется проще ровно до тех пор, пока внезапно не оказывается, что фильтры в интернет-магазине должны работать без перезагрузки страницы, справа внизу должен быть уютный чятик, а блок сравнения товаров желательно сделать так, чтобы он тоже не требовал перезагрузки страницы.
Современный веб уже очень сильно не про "отдать отрендеренную сервером страничку".
Разработка на Scala как она есть. Вообще нам в половину сервисов надо передавать неявно контекст, а в половину не надо. Поэтому мы не будем использовать implicit (прим. пер. — неявно) и дефолтный аргумент для него, а запилим свой микрофреймворк на 5kloc на шаблонах и с макросами, подвязанный через недокументированное api sbt и без документации, но зато с веб-интерфейсом на локалхосте, и вот оно :)
Компилируется это на этапе сборки проекта перед публикацией. Т.е. в браузере работает уже "скомпилированная" версия. Не совсем скрипты, совсем не PHP.
Ну, в общем идея такая, что с языком (JS) все более-менее в порядке. Дело в том, что HTML и CSS слишком низкоуровневы для Rich Internet Applications. Поэтому логичным образом появились более высокоуровневые абстракции, который приближают решение проблемы к оперированию над объектами предметной области. В случае с React и Vue отдельно стоит упомянуть Virtual Dom и те проблемы, которые он решает (и создает, ага): https://habrahabr.ru/post/256965/
Отдалённо, связь такая же как и между языком ассемблера и си. На первом можно реализовать абсолютно всё, но долго и дорого.
300 000 страниц в сутки это 3.5 запроса в секунду.
Парни, вам есть еще куда расти во-первых, а во-вторых положите уже всё в память, она по-прежнему быстрее любого SSD
Это да. Вопрос в том, когда бы оно было разработано, во сколько бы обошлась разработка нинзя-отрядом матёрых С++ разработчиков это всё. Для не самой концептуально сложной Джавы хорошие программисты стоят не дешево, а уж для плюсов… я даже не знаю, есть ли такие люди среди нас.
Ну и еще большой вопрос, насколько оно быстрее бы вышло грамотно настроенного netty. Смущают разве что паузы GC.
Есть у меня подозрение, что highload это в первую очередь не про производительность одного единственного веб-сервера, а про масштабирование всей системы в первую очередь.
Стойте-стойте. А как же качество продукта? Или у вас производительность программиста исчисляется не в числе решенный задач, а в строках кода, которые он написал?
Задача программиста не писать код, а решать поставленные задачи с помощью написания кода. Как программист должен узнать, что задача решена и решена корректно, если у него нет инструмента проверки валидности логики?
Код, который запускается это далеко не тот же самый код, который работает корректно. Даже если вы пишете на Haskell и Scala.
Код в первую очередь должен быть понятным на уровне предметной области. А преждевременная оптимизация — зло. Будь то функции по 100+ строк или вынос каждого оператора в отдельную функцию.
Код в первую очередь должен быть читабелен человеком.
Еще с момента анонса беспроводных наушников от Apple мучает вопрос — современный Bluetooth 4.x принципиально может передать звук без потерь?
Вроде бы не может, и потому использует разные кодеки вроде aptX, которые пережимают декодированный на хосте аудиопоток. В результате получаем двойное кодирование с потерями.
Так ведь?
Вопрос. Если все worker-ы симметричные, то не проще было ли писать приложение без cluster (особенно учитывая что усложнять пример не хотелось), а запускаться потом через PM2? Там и gracefull reload, и cluster, и auto restart, и даже логи в реальном времени.
И таки для request request-promise, которые для тестирования кода, лучше таки --save-dev использовать.
Если рассматривать сферический DOM в вакууме, то да, React == Shadow DOM + DOM, а потому медленнее.
Но на самом деле речь ведь о скорости и сложности, с которой DOM переводится из состояния A в состояние B.
Да, эффективное использование DOM всегда быстрее, но сложность в таком случае может расти очень быстро, если речь идёт о чем-то более сложном, чем обновление properties на узлах. И тут внезапно может оказаться, что толковый подход это уже половина реактовского dom reconciliation, только глючная и никем не тестированная.
Например, знаменитое 0.1 + 0.2 не равняется 0.3 в связи с тем, что в JavaScript нет встроенного десятичного типа.
Может, я чего-то не понимаю в знаменитостях, но еще на первом курсе любого технического вуза рассказывали как сравнивать типы с плавающей точкой?
Loopback
Могу поделится своим негативным опытом. Дело было год назад. Речь о REST API сервере.
Штука в целом прикольная — ты такой накидал конфигурацию, а оно такой быстренько поехало. Ну почти.
Только хвалёный ORM не может делать джойны в БД. Ну и эпизодически выплывали интересные артефакты, связанные с тем, что местному ORM-у, ну скажем так, есть еще куда расти.
Справедливости ради, архитектурно там предусмотрены дырки, куда можно засунуть правильную реализацию джойнов и всего этого database-related добра с учетом специфики конкретной базы, но на тот момент готовых компонент для этого не нашлось.
Ну и в ряде мест оно необъяснимо тормозило. В документации об этом разумеется не писали, но дебаг приводил опять же в ORM.
В результате переписали за месяц на Express + Mongoose. Стало лучше, быстрее, и главное проще и более предсказуемо.
Я вот либо что-то упустил в самых основах, либо это нечто совсем недавно появилось. Но хм… это не создает новой области видимости. Если не сложно, можно ссылку на пример? Вот gist с прямым примером: https://gist.github.com/wertlex/b97115e0f2fe0bc023297f6b2db8edd5
Насчёт 7. switch в javascript зло конечно дикое, но из него можно изобразить что-то вроде паттерн матчинга для бедных. Для очень бедных.
switch(true) {
case type === "click" && something.isDefined() === true:
return "It was click";
case type === "mouseenter" && somethingElse.isDefined() === true:
return "It was mouseenter";
default:
return console.warn(`No case for event type "${type}"`);
На мой взгляд даже в таком виде это сильно симпатичнее цепочки if-else-if. Но дно достигается, конечно, в момент объявления переменной в любом case. Никакие let и const не спасают — scope у всех один.
Часть 0. Изучить Haskell, чтобы понимать функциональную магию Shapeless, Scalaz, Iteratee итд.
Это далеко не всегда так.
Отдать страничку с данными и правда не сильно сложно, гораздо сложнее отдать часть приложения с данными. Потому что вдруг выясняется, что у фронтенда есть:
Но ведь на текущем витке фронтендовых технологий SPA и правда удобнее и проще делать. Каноничный клиент-сервер кажется проще ровно до тех пор, пока внезапно не оказывается, что фильтры в интернет-магазине должны работать без перезагрузки страницы, справа внизу должен быть уютный чятик, а блок сравнения товаров желательно сделать так, чтобы он тоже не требовал перезагрузки страницы.
Современный веб уже очень сильно не про "отдать отрендеренную сервером страничку".
Разработка на Scala как она есть. Вообще нам в половину сервисов надо передавать неявно контекст, а в половину не надо. Поэтому мы не будем использовать implicit (прим. пер. — неявно) и дефолтный аргумент для него, а запилим свой микрофреймворк на 5kloc на шаблонах и с макросами, подвязанный через недокументированное api sbt и без документации, но зато с веб-интерфейсом на локалхосте, и вот оно :)
Это я пропустил, или автор в самом деле сравнивает перфоманс:
Автор немного лукавит)
Тут дело скорее не в самих монадах, а в do-notation.
Компилируется это на этапе сборки проекта перед публикацией. Т.е. в браузере работает уже "скомпилированная" версия. Не совсем скрипты, совсем не PHP.
Ну, в общем идея такая, что с языком (JS) все более-менее в порядке. Дело в том, что HTML и CSS слишком низкоуровневы для Rich Internet Applications. Поэтому логичным образом появились более высокоуровневые абстракции, который приближают решение проблемы к оперированию над объектами предметной области. В случае с React и Vue отдельно стоит упомянуть Virtual Dom и те проблемы, которые он решает (и создает, ага): https://habrahabr.ru/post/256965/
Отдалённо, связь такая же как и между языком ассемблера и си. На первом можно реализовать абсолютно всё, но долго и дорого.
Вполне пристойно обстоят, есть некоторые нюансы, но можно и без server-side рендеринга обойтись: http://andrewhfarmer.com/react-seo/
300 000 страниц в сутки это 3.5 запроса в секунду.
Парни, вам есть еще куда расти во-первых, а во-вторых положите уже всё в память, она по-прежнему быстрее любого SSD
Это да. Вопрос в том, когда бы оно было разработано, во сколько бы обошлась разработка нинзя-отрядом матёрых С++ разработчиков это всё. Для не самой концептуально сложной Джавы хорошие программисты стоят не дешево, а уж для плюсов… я даже не знаю, есть ли такие люди среди нас.
Ну и еще большой вопрос, насколько оно быстрее бы вышло грамотно настроенного netty. Смущают разве что паузы GC.
Есть у меня подозрение, что highload это в первую очередь не про производительность одного единственного веб-сервера, а про масштабирование всей системы в первую очередь.
Стойте-стойте. А как же качество продукта? Или у вас производительность программиста исчисляется не в числе решенный задач, а в строках кода, которые он написал?
Задача программиста не писать код, а решать поставленные задачи с помощью написания кода. Как программист должен узнать, что задача решена и решена корректно, если у него нет инструмента проверки валидности логики?
Код, который запускается это далеко не тот же самый код, который работает корректно. Даже если вы пишете на Haskell и Scala.
Код в первую очередь должен быть понятным на уровне предметной области. А преждевременная оптимизация — зло. Будь то функции по 100+ строк или вынос каждого оператора в отдельную функцию.
Код в первую очередь должен быть читабелен человеком.
Вроде бы не может, и потому использует разные кодеки вроде aptX, которые пережимают декодированный на хосте аудиопоток. В результате получаем двойное кодирование с потерями.
Так ведь?
Вопрос. Если все worker-ы симметричные, то не проще было ли писать приложение без cluster (особенно учитывая что усложнять пример не хотелось), а запускаться потом через PM2? Там и gracefull reload, и cluster, и auto restart, и даже логи в реальном времени.
И таки для
request request-promise, которые для тестирования кода, лучше таки--save-devиспользовать.Если рассматривать сферический DOM в вакууме, то да, React == Shadow DOM + DOM, а потому медленнее.
Но на самом деле речь ведь о скорости и сложности, с которой DOM переводится из состояния A в состояние B.
Да, эффективное использование DOM всегда быстрее, но сложность в таком случае может расти очень быстро, если речь идёт о чем-то более сложном, чем обновление properties на узлах. И тут внезапно может оказаться, что толковый подход это уже половина реактовского dom reconciliation, только глючная и никем не тестированная.
Может, я чего-то не понимаю в знаменитостях, но еще на первом курсе любого технического вуза рассказывали как сравнивать типы с плавающей точкой?
Могу поделится своим негативным опытом. Дело было год назад. Речь о REST API сервере.
Штука в целом прикольная — ты такой накидал конфигурацию, а оно такой быстренько поехало. Ну почти.
Только хвалёный ORM не может делать джойны в БД. Ну и эпизодически выплывали интересные артефакты, связанные с тем, что местному ORM-у, ну скажем так, есть еще куда расти.
Справедливости ради, архитектурно там предусмотрены дырки, куда можно засунуть правильную реализацию джойнов и всего этого database-related добра с учетом специфики конкретной базы, но на тот момент готовых компонент для этого не нашлось.
Ну и в ряде мест оно необъяснимо тормозило. В документации об этом разумеется не писали, но дебаг приводил опять же в ORM.
В результате переписали за месяц на Express + Mongoose. Стало лучше, быстрее, и главное проще и более предсказуемо.
Я вот либо что-то упустил в самых основах, либо это нечто совсем недавно появилось. Но хм… это не создает новой области видимости. Если не сложно, можно ссылку на пример? Вот gist с прямым примером: https://gist.github.com/wertlex/b97115e0f2fe0bc023297f6b2db8edd5
В целом — да, но в принципе такой штуки можно и достичь простой оберткой function -> react class. Но за ссылку спасибо.
Насчёт 7.
switchв javascript зло конечно дикое, но из него можно изобразить что-то вроде паттерн матчинга для бедных. Для очень бедных.На мой взгляд даже в таком виде это сильно симпатичнее цепочки
if-else-if. Но дно достигается, конечно, в момент объявления переменной в любомcase. Никакиеletиconstне спасают — scope у всех один.