есть мнение, что все в этой жизни циклично.
когда-то была десктопная разработка
потом началась веб-разработка и все перешло на сервера (ВФ для СФ)
сейчас, как известно эпоха front-end single page application, целью внедрения которой было ускорение работы приложений (что далеко не всегда получается на самом деле), а также была благородная идея ухода от разнообранных серверных языков, на более единообразную JS-based разработку, но и здесь прокол - размножившиеся фронтэнд фреймворки по сути являются мета-языками и только добавили еще больше разнообразия и путаницы в разработку. И при всем при этом, front-end разработка имеет значительные недостатки, как браузеро-зависимость, необходимость выгрузки всего кода на клиента, значительно меньшая безопасность и прочее.
так вот, интернет (в т.ч. и мобильный) становится все быстрее и быстрее, клиентская аппаратная часть становится все быстрее и быстрее, и когда-то когда скорость связи и работы браузера станут такими быстрыми, что серверное веб-приложение будет работать молниеносно. И вот тогда снова все вернется на старый, добрый, безопасный сервер, и все эти передряги с front-end разработкой люди будут вспоминать как давний и плохой сон...
В смысле закончится? Она толком то и не началась еще) большинство сайтов это серверрендеры, а в америке так еще и серверверрендеры со стремным дизайном
Я приспешник серверной разработки. Всё на сервере, вся бизнес логика и так далее. Front-end только для вывода информации, выданной сервером. Никакой логики. Минимум логики. Максимум, что может быть - какая-то валидация... Или подсчет суммы - стоимость часа умножить на количество часов, на JavaScript. Это максимум, чтоб пользователь изменяя значения стоимости мог подогнать под "правильное" суммарное значение (на которое договорились с клиентом, например).
Пока есть возможность, по-максимуму стараюсь всё делать в арех-контроллерах.
Я как раз наоборот - адепт SPA. Считаю что нынешние JS фреймворки это просто дар богов! А современные web приложения имхо должны состоять из двух равносильно сложных частей:
- рендеринг UI + бизнес логика на фронте
- REST API на бэкенде.
- Взаимодействие исключительном мелкими порциями информации.
Правильно ты Den говоришь что циклично, просто ты не тот цикл заметил. Надо было заметить что раньше (до эпохи интернета) были Операционные системы с программами. Программы грузились и общались с системой посредством вызова системных программ. Никто не перезагружал все приложение (тот жу Word) после нажатия на кнопку. Сегодня web становится эдакой большой распределенной системой где фронтенд это программы, а бэкенд это системные методы. Программа загружается, инициализирует свое состояние и дальше реагирует на действия пользователя - сама что-то внутри считает или дергает системные методы если надо обратиться за данными извне.
То что вы описываете как рендерить на бэкенде и отдавать статическую страницу пользователю это уже нафталин времен начала интернета (времен статических html страниц). Уже давно признано что протокол http это прошлое, которое тормозит развитие интернета.
А и мой ответ на вопрос "Когда закончится эпоха front-end single page application?"
Никогда, потому что она еще только в зачаточном состоянии.
Да, Дима, это всё хорошо, когда у тебя i7 и 16ГБ. А есть люди, у которых процы по-проще и памяти по-меньше. А есть ещё мобильные устройства. Туда desktop-приложение уже сложно засунуть. А вот открыть сайт в браузере, а не устанавливают спец приложения - это самый удобный способ. И Visualforce с его контроллером на стороне СФ, а не в JS, очень хорошо себя показывает. По крайней мере, на много лучше, чем Lightning.
Конечно, можно всем выдать самые новые телефоны/планшеты за килобаксы. Но бизнес, обычно, считает деньги. И намного дешевле написать страничку на Visualforce и выдать мобильник за $100, чем пилить на Lightning и выдавать каждому мобильник уже за $500.
Это всё хорошо, но "ООП ради ОПП" бизнесу не подходит. Это вот свой продукт можно пилить на новых технологиях ради новой технологии (изучения).
Не знаю про какой ты бизнес пишешь, который не может позволить себе современное железо. Понимаю еще мы работали бы с 1с и ты писал про молочную ферму где-то на окраине цивилизации. Сейчас у каждого второго телефон мощнее моего ноута. И это у нас, а что говорить про развитые страны. Это всего лишь оправдание лени переходить на новые технологии. Сейчас современные фреймворки настолько оптимизированы огромной армией разработчиков что говорить про какие-то тормоза просто стыдно (я говорю про нормальные фреймворки а не про Lightning 
). Я уже не раз говорил что все тормоза из-за неправильной архитектуры SPA (у нас же выгрузить на фронтед 10к записей чтобы построить один select для фильтра это просто must have). И даже если где-то что-то подлагивает, то это происходит намного быстрее (для пользователя) чем дождаться загрузки целой страницы с кучей JS после нажатия кнопки Save.
Ладно с Salesforce и бизнесом конкретно можно обрисовать требования по железу и исходя из этого принимать решение о необходимости использования упрощенного рендеринга для поддержки 486 или PentiumI компов. Но не стоит голословно заявлять что весь бизнес покрыт нафталином.
Если абстрагироваться от Salesfоrce и предстваить реальный сервис/сайт с кучей пользователей. И представить что за рендеринг отвечает только сервер. 100к пользователей работают в одном время. Это одному серверу кроме бизнес логики надо его построить html чтобы отдать его. За это будет платить кто? Вы со своего кармана. Ситуация когда есть SPA и работа общение через JSON. Рендеринг UI уже ложится на устройство пользователя, а ваши сервера разгружаются. И с сервисом уже могут одновременно работать не 100к а лям пользователей.
И еще такая просьба - посмотрите вокруг. Столько из ваших сайтов/сервисов которые вы используете каждый день работает без клиентского рендеринга UI? Bitbucket? Jira? Соцсети?
Я не призываю бросить все и переходить на JS SPA :). Понятно что для простых страничек он избыточен. Но я призываю всех понять что надо принимать и следовать современным тенденциям, а не пытаться отказываться от них придумывая разные отмазки, типа бизнес консервативен. Старый бизнес да, новый нет!
Я пойму если использование VF будет просто аргументировано быстротой выполнения задачи (сделал, бабки получил и забыл) и армией вчерашних школьников, которые смогут эту страницу поддерживать!
У меня клиенты - приличные компании, которые ворочают приличным объемом $. Но они не раскидываются этим $ на топовые железяки. Никогда не видел, чтоб кто-то в бизнесе так раскидывался $. Разве что продажники. Им нужен последний мак, ифон и ипад - им же продавать надо "успешность". Всем остальным надо $ зарабатывать.
Про серверную нагрузку в контексте СФ как раз сам и СФ и думает. Именно по-этому я не парюсь на счет СФ серверов. А вот за нагрузку на UI никто, кроме меня отвечать не будет. И нагружать его кучей JS я не хочу. Мне достаточно тормознутого Lightning (ладно, может он становится быстрей, я каждые пол года не замеряю его скорость :-) ).
Все эти Жыры и Фэйсбуки тоже тормознутое овноподелие. Jira тормозит. Открывает таски еще медленней, чем в СФ записи. У меня нервов не хватает. Тоже Trello бесплатное работает в разы быстрей.
Visualforce - это не отмазка, а более дешевый способ решения задач. Тратить больше $ только потому, что это новое бизнесу нет смысла.
Понятное дело, что если покупается автомобиль, то покупается новый, т.к. он более экономичен, чем тот, который был произведен 10 лет назад (хотя тоже есть область для споров. По крайней мере, первый год нового авто точно дешевле, чем полностью откапиталенный старый авто).
Но с VF всё по-другому. Что Visualforce, что Lightning в итоге выдают HTML+JS+CSS. Visualforce выдаёт меньше всего этого. Если надо сделать вшух-вшух, то да, Lightning или на VF налепить фреймворков...
У меня, в основном задачи, которым не нужен SPA. Та же Service Console - хороший пример SPA, в котором пользователь работает безвылазно. Но переходить на разные странички и там каждый раз грузить своё SPA - мне кажется это перебор.
Что-то мне кажется что у твоих клиентов требования это максимум вывести форму тремя инпутами 
Понятное дело что для такого заводить ангуляровский/лайтнинговский солюшен не имеет смысла(хотя это и делается в 3 минуты, ровно столько по времени как и на VF)
Но к примеру у нас есть страничка, которая тупо будет валиться по всяческим лимитам, потому что она ультра сложная.
Плюс наши клиенты не любят отправлять кучу данных на апекс чтобы свалидировать изменения в одном инпуте. Им нужно все и сразу на месте, чтобы понимать что 80% того что они наменяли будет правильно работать/хранить правильные значения.
На VF страницу тоже можно сделать, она даже была раньше, когда требовалось отобразить всего 10 записей. Но запросы у клиентов растут и VF просто тупо не вывозит.
Ну и кстати про то что для всего этого нужно топовое железо - оно нужно только если у вас работают криворукие индусы(jira тому пример, у них даже топовое железо не вывезет тормознутось UI - потому что он тормозит не из за железа). Тот же VK построен по принципу SPA и все грузит и рендерит очень очень быстро для хермильена пользователей.
Плюс ко всему - нужно всегда быть готовым к тому что VF уйдет в небытие.
И кстати Дима правильно сказал - не надо переходить на SPA и никто не призывает вас это делать. Нужно понимать где и как его применить.
Только вот как минимум попробовать новшества, которые сФ поставляет для разработчика из коробки, стоит!
Я скажу так. Я видел много разработчиков которые попробовали кодить SPA (даже для небольших страниц) и испытали огромный восторг. И теперь имея под рукой заготовку (VF страницы контейнер + Apex контроллер с RemoteAction хендлером) стартуют и ведут разработку страницы любой сложности в считанные минуты. И ни одного не видел кто бы сказал - да ну его нафиг, пойду я назад на VF (может мне так везет)
И я уже знаю не одну компанию которая дает тестовое задание для SF на базе Ангуляра а не на базе VF, потому что они отказались от VF под чистую.
Почему не на базе lightning? Или они Angular разработчиков ищут? :)
Потому что ВСЕ (что VF, что не VF разрабы) солидарны что Lightning говно.
Просто использовать VF не вариант. Остается очень крутой, быстрый и правильный способ.
Ангуляр + SLDS. Выглядит точно так же как Lightning, но работает так же быстро как VF.
И разработка в разы быстрее с учетом наличия уже куче готовых решений (компонентов) под Ангуляр.
Я делал и на ангулар и на лайтнинг. Ангулар был актуален, когда ещё лайтнинг был в бета версии и глючил по любому вопросу, выстреливая своими aura exceptions. Сейчас меня всё устраивает. Постоянно появляются новые компоненты, старые фиксятся, решение нативное и собралось много готовых решений.
Поэтому я считаю уже это просто делом вкуса.
Тем более, что порог вхождения в lightning ниже с его классическим JS, а не как на последнем ангулар. Только первый ангулар мог сравнится с простотой лайтнинга.
п.с. да и лэйбл Deprecated для VF это лишь вопрос времени.
Вот тут соглашусь с тобой. Я начинал ангулярить под SF когда еще про Lightning и не упоминали. Попытки перейти были, но это было в то время когда Ligthning был неюзабельным. Сейчас все поменялось однозначно. Но мне не довелось еще попробовать Lightning серьезно. (Да и от SF немного отошел). Так что слышал что Lightning начинает принимать человеческое лице и программистов в нем прибывает. Еще годик, максимум 2 и классический VF просто закроют и сделают доп опцией для старых клиентов.
Не будет такого, по крайней мере в ближайшие лет 10, энтерпрайз жеж.
НАДО ЭТО ПОМЕТИТЬ ДЛЯ ИСТОРИИ И ВЕРНУТЬСЯ К ЭТОМУ ДИАЛОГУ ЧЕРЕЗ ГОД И ДВА
Согласен :)
Переход на что-то новое - это всегда боль для существующего бизнеса. Новому бизнесу проще сразу засесть на новое.
Так в том и дело, бизнес то новый появляется, а его подсаживают на старую иглу.
Глупцы!
Лучше уже сразу подсесть, чтоб когда допилят, ты уже на этом сидел.
А то я вот смотрю на Лайтнинг, плююсь, но понимаю, что им надо заниматься. А так не хочется...
Ну кстати нет, все товарищи, которые недавно подсели на СФ - все на Лайтнинге. Плюются, но сидят. Знают про Классик, завидуют, но сидят на Лайтнинге.
ну вот собственно и первые действенные признаки конца эпохи приложений, выполняющихся на клиенте:
экспресс-приложения раняться на сервере, клиент на экране видит "трансляцию" UI
Это не касается Frontend SPA!
Это про desktop системные приложения.
Эра Web SPA никогда не закончится. А смысл в том, что сейчас выгоднее переносить сложную логику рендерингу UI на сторону пользователя банально потому что это ресурсы. Вот сам ответь на вопрос. Ты сделал какой-то мегасервис с мегакрутым UI, о пусть даже с VR. Ты готов поднимать супер дорогие сервера за свои деньги чтобы рендерить VR за свой счет для каждого пользователя а ему отправлять только картинку? Или тебе будет проще отослать ему какую нибудь метадату с координатами размером в 100кб а пользователь пусть уже тратится на дорогие видеокарты и прочее железо чтобы все это дело отобразить.
Тоже и с Web - раньше html рендерился на стороне сервера и ждал ресурсы. А сейчас сервер отвечает только за то чтобы достать данные из базы и серелизовать JSON. Наоборот будущее за распределенными системами. И если смотреть далеко в будущее, то скорее мы увидим что твой персональный комп будет использоваться для рендеринга UI для твоего соседа, а его для рендеринга твоего. Но никакой владелец web сервиса не будет просто так брать на себя лишние расходы.
вот еще интересный пример приложений для мобильных платформ:
и в последнем абзаце снова говорится, что проще все это ранить на твоем славном сервере, чем на кто-знает-что-там клиентской стороне
я потихоньку изучаю современную JS разработку на примере MERN стека,
все очень интересно и впечатляет,
и натолкнулся на информацию, что SPA фактически не индексируются поисковиками, то есть никакого смысла делать на них сайты нет вообще. И для решения этого есть дополнительные либы, которые имплементируют старый добрый Server Side Rendering (SSR) подход. Back to SSR так сказать
Смысл работы поисковиков очень простой - они тупо запрашивают контент по определенному адресу (полученному из ссылок на том же ресурсу или на другом). Тоже самое что мы делаем в браузере. Открыл урл - сервер тебе вернул html. Браузеры потом начинают этот html парсить и тут происходит вся магия в виде натягивания css, запуска js, отрисовки страницы. Поисковики этого не делают - они тупо разбирают контент из самого html (конечно это в упрощенной форме). JS они не запускают, никаких дополнительных запросов к API они не эмулируют. Так что SPA тут не при чем. Если ты на сервере в свой html не вставил текст, а делаешь это потом с помощью того же JQuery на onload, то поисковик тоже ничего не проиндексирует.
SPA и простые контентные сайты под SEO это разные понятия. Надо изначально определяться для кого ты пишешь сайт - для людей или для поисковиков.
Так что в очередной раз - никуда SPA не денется. Это просто другое
Если ты про Mongo, Express, Angular, Node то не трать время. С этим стеком все плохо (кроме Ангуляр ). Это только поиграться. Для реальных проектов такому архитектору который выберет этот стек для реального проекта надо кое что отрезать.
Mongo -> Postgres (там есть JSONB если тебе так нравится NoSQL)
Node -> .Net/Java/Python
Express -> ASP.NET/Spring/Django
Я перепробовал все и остановился сейчас на .Net и с уверенностью скажу что это сейчас поезд который набирает ход. Лучше запрыгивай в него, пока он не уехал
Это я имею в виду не старый бородатый .Net под винду, а .Net Core который опять же перестал быть Core, а стал мультиплатформенным .Net 5.0 (чудеса наименования)
И стек .Net 5.0 + Angular (TypeScript) сейчас самые быстроразвивающиеся технологии.
это интересно, но я сделал заход в эту тему с Хероку Function-as-Service темы, где пока что можно использовать только JS функции, поэтому уходить с изучения JS-ного бэк-энда мне нет смысла
А, с этой точки зрения твои усилия оправданы.
Но если задумаешься запилить полноценный НЕ-SF проект, то вспомни мой совет
это интересно, но я сделал заход в эту тему с Хероку Function-as-Service темы, где пока что можно использовать только JS функции, поэтому уходить с изучения JS-ного бэк-энда мне нет смысла
я конечно понимаю что несколько крутых контор используют node.js для своих бекендов - но js должен быть только на UI, имхо
Node.js имеет смысл брать для каких не особо важных микросервисов, серьезное чтото на нем я бы пилить точно не стал, несмотря на то что "ГУГАЛ/ЯХУ/ПЕЙПАЛ его использует"(в каких то мелочах, может быть и используют)
Проблема NodeJS в том что это изначально не серверная технология. Популярность он свою заслужил исключительно из-за хайпа. Кроме того что Javascript является динамически дипизированным языков, вся его архитектура насквозь пропитана асинхронностью. Когда делаешь какой-нибудь hello world проект все выглядит потрясающе, но только начинаешь пилить что-то свое тут и случается "мохнатый зверек". Что-то отдебажить просто нереально, отловить ошибку в асинхроне нереально, 90% ошибок валятся в рантайме из-за неправильного приведения типов. NPM это вообще помойка где качество либ ниже плинтуса. NodeJS это мир зеленых джунов и небольшего количества гиков, которые знают до винтиков как работает Chrome's V8 JavaScript engine изнутри. У нас в компании есть один проект на NodeJS (и то только потому что нужен был JSForce (до меня еще делали)). Это звиздец. Он уже работает много лет только по принципу "работает, не трогай". Если случается какие-то ошибки то на них просто закрывают глаза, потому что отдебажить и понять что в какой-то либе отвалилось крайне сложно. Конечно в NodeJS сильно помогает TypeScript. Но мало кто его умеет правильно использовать в проектах, потому что это уже выходит за рамки hello world проектов.
Опять же возвращаясь к Хероку Function-as-Service. Javascript для них оправдан, потому что эти самые Function 100% будут состоять из одной функции и включать в себя не более пары сотен строк. Тут особенно и не запутаешься.
