И там и там суть реализации одинакова.

имеется ввиду что пользователь может взаимодействовать с HTML'кой которой ему сервер нарисовал так-же как и с приложением. Или вообще с человеком из тех-поддержки по телефону - тоже "фронтенд"

имеется ввиду что пользователь может взаимодействовать с HTML'кой которой ему сервер нарисовал так-же как и с приложением. Или вообще с человеком из тех-поддержки по телефону - тоже "фронтенд"

Ну он вроде в контексте веб приложений говорил. Так и там и там суть одинаковая - шаблон + данные = DOM, все.

Ну он вроде в контексте веб приложений говорил. Так и там и там суть одинаковая - шаблон + данные = DOM, все.

ну да, ток рендер в браузере

ну да, ток рендер в браузере

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

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

ну не, не "абсотлюно такие-же". Да, похожие моменты есть но... virtual DOM это тебе не просто шаблонизатор, это почти целый движок. Vue, React, Angular... это всё virtual DOM

ну не, не "абсотлюно такие-же". Да, похожие моменты есть но... virtual DOM это тебе не просто шаблонизатор, это почти целый движок. Vue, React, Angular... это всё virtual DOM

И у них, внезапно есть шаблоны, за исключением react - это вообще полный п-ц, венец наркоманской мысли

ну не, не "абсотлюно такие-же". Да, похожие моменты есть но... virtual DOM это тебе не просто шаблонизатор, это почти целый движок. Vue, React, Angular... это всё virtual DOM

ангуляр не vdom

И у них, внезапно есть шаблоны, за исключением react - это вообще полный п-ц, венец наркоманской мысли

JSX да, это ужас, одна из причин почему мы выбрали Vue вместо React, но.. шаблоны там лишь описывают компоненты, а сам по себе vdom намного сложнее обычного серверного шаблонизатора аля "взять - вставить - нарисовать"

ангуляр не vdom

hmm, I see

JSX да, это ужас, одна из причин почему мы выбрали Vue вместо React, но.. шаблоны там лишь описывают компоненты, а сам по себе vdom намного сложнее обычного серверного шаблонизатора аля "взять - вставить - нарисовать"

Это реализация у него сложная, но все сводится к вставить/убрать/нарисовать/заменить.

Это реализация у него сложная, но все сводится к вставить/убрать/нарисовать/заменить.

ну .. "да"

Можно и в го создать древовидную структуру неких элементов с интерфейсом render, но... фрагментация памяти будет - мама не горюй, на клиенте такое прощается, на сервере нет. Хотя... на клиенте это тоже п-ц последнее время (сугубо ИМХО), браузеры, на относительно простых страницах, по создаваемой нагрузке уже давно переплюнули жабо-приложения

Можно и в го создать древовидную структуру неких элементов с интерфейсом render, но... фрагментация памяти будет - мама не горюй, на клиенте такое прощается, на сервере нет. Хотя... на клиенте это тоже п-ц последнее время (сугубо ИМХО), браузеры, на относительно простых страницах, по создаваемой нагрузке уже давно переплюнули жабо-приложения

что ты имеешь ввиду под франгментацией памяти?

"фрагментация памяти (в системах динамического распределения памяти) — Наличие в ОЗУ большого числа коротких несмежных блоков, не позволяющее удовлетворить запрос на выделение блока большего размера."

короче говоря - рендерьте на клиенте, не рисуйте на сервере, на сервере - данные, всё) максимум что сервер имеет право рендерить это JSON да и UX это значительно повысит, взаимодействие с UI плавнее

короче говоря - рендерьте на клиенте, не рисуйте на сервере, на сервере - данные, всё) максимум что сервер имеет право рендерить это JSON да и UX это значительно повысит, взаимодействие с UI плавнее

Ок, на этом и порешим, а то в оффтоп полезли

Ок, на этом и порешим, а то в оффтоп полезли

??

шаблонизаторы - это зло, гошный в т.ч. Здоровые люди пишут server side frontend на DSL, транслируемый в html. В Го этого нет. Но тут надо понимать, что всё что касается фронтенда в Го отвратительно, потому что вендор не заинтересован писать фронт на Го, а энтузиасты ничего кроме колхоза традиционно предложить не могут

Вы по-юношески категоричны. НЕ ВСЕ шаблонизаторы - зло. Фронтенд на DSL - тот еще костыль, призванный уменьшить количество боли от html + css + js, не более того. Все, что касается фронтенда, отвратительно не только в Го. И оно отвратительно безотносительно вендора. А сама идея писать фронт на Го... Кхм, какие там "ключевые плюшки" в Го? Строгая статическая типизация, многопоточность "искаропки" (все вот эти горутины, каналы и прочее), грамотная стандартная библиотека. Что из этого нужно на фронте? Вот ничего из этого на фронте не нужно, и не надо мучить бабушку с идеей писать гошный фронт.

ну не, не "абсотлюно такие-же". Да, похожие моменты есть но... virtual DOM это тебе не просто шаблонизатор, это почти целый движок. Vue, React, Angular... это всё virtual DOM

ага, "почти целый движок... шаблонизации")))

И у них, внезапно есть шаблоны, за исключением react - это вообще полный п-ц, венец наркоманской мысли

ну, как бэ, "реактивный подход" не они придумали, и, собственно, нормальный подход. Единственный косяк в том, что в браузере эта самая "реактивность" под капотом генерит шаблоны... вот тут да, попахивает наркоманией. Но "се ля ви"

JSX да, это ужас, одна из причин почему мы выбрали Vue вместо React, но.. шаблоны там лишь описывают компоненты, а сам по себе vdom намного сложнее обычного серверного шаблонизатора аля "взять - вставить - нарисовать"

честно говоря то, что один шаблонизатор сложнее другого, не делает его "не-шаблонизатором"

Вы по-юношески категоричны. НЕ ВСЕ шаблонизаторы - зло. Фронтенд на DSL - тот еще костыль, призванный уменьшить количество боли от html + css + js, не более того. Все, что касается фронтенда, отвратительно не только в Го. И оно отвратительно безотносительно вендора. А сама идея писать фронт на Го... Кхм, какие там "ключевые плюшки" в Го? Строгая статическая типизация, многопоточность "искаропки" (все вот эти горутины, каналы и прочее), грамотная стандартная библиотека. Что из этого нужно на фронте? Вот ничего из этого на фронте не нужно, и не надо мучить бабушку с идеей писать гошный фронт.

> Строгая статическая типизация Нету этого у го, а на фронте это нужно.

Про явную и статическую верю - нужно. Строгая то зачем?

Про явную и статическую верю - нужно. Строгая то зачем?

Что-бы в большом приложении можно было не терять контроль за тем, что происходит.

зачем на фронте вот это: var a1 int64 = 10 var a2 int32 = 20 a3 := a1 + a2 //ошибка конпеляции

зачем на фронте вот это: var a1 int64 = 10 var a2 int32 = 20 a3 := a1 + a2 //ошибка конпеляции

А зачем это вообще?))

А зачем это вообще?))

собственно, вам лучше знать. Вы же заявляете, что строгая типизация на фронте нужна.

собственно, вам лучше знать. Вы же заявляете, что строгая типизация на фронте нужна.

Строгая типизация избавляет от целого класса ошибок, поэтому собственно она и нужна.

Что-бы в большом приложении можно было не терять контроль за тем, что происходит.

вот вам моя откровенная имха на тему того, "что нужно на фронте": 1. Отказаться от html + css + js (на этом пункте оно становится просто влажной фантазией, дальше можно не читать) 2. Родить вменяемую абстракцию данные -> представление/разметка -> стилизация/оформление 3. То, что придет на замену html, должно включать в себя исключительно набор базовых примитивов. Дальше - строить поверх этого, а не сбоку.

Строгая типизация избавляет от целого класса ошибок, поэтому собственно она и нужна.

На фронте? Критичные ошибки с переполнением по разрядности? Реально?

вот вам моя откровенная имха на тему того, "что нужно на фронте": 1. Отказаться от html + css + js (на этом пункте оно становится просто влажной фантазией, дальше можно не читать) 2. Родить вменяемую абстракцию данные -> представление/разметка -> стилизация/оформление 3. То, что придет на замену html, должно включать в себя исключительно набор базовых примитивов. Дальше - строить поверх этого, а не сбоку.

мобильные аппликухи

Честно говоря, для фронта из всех интов выбираешь тот, который "побольше", и, не заморачиваясь, используешь только его

мобильные аппликухи

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

вот вам моя откровенная имха на тему того, "что нужно на фронте": 1. Отказаться от html + css + js (на этом пункте оно становится просто влажной фантазией, дальше можно не читать) 2. Родить вменяемую абстракцию данные -> представление/разметка -> стилизация/оформление 3. То, что придет на замену html, должно включать в себя исключительно набор базовых примитивов. Дальше - строить поверх этого, а не сбоку.

> Родить вменяемую абстракцию данные -> представление/разметка -> стилизация/оформление Вменяемая абстракция это как? Сейчас вроде самые вменяемые абстракции для построения гуёв как раз во фронтенде водятся.

Вон гугл даже запилили свой реакт для мобилок на дарте

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

у вас проблемы с html, я понял

> Родить вменяемую абстракцию данные -> представление/разметка -> стилизация/оформление Вменяемая абстракция это как? Сейчас вроде самые вменяемые абстракции для построения гуёв как раз во фронтенде водятся.

вменяемая абстракция - это инкапсуляция во все поля, а не попытка размазать то же самое "представление" по 3 слабо взаимосвязанным платформам.

Вон гугл даже запилили свой реакт для мобилок на дарте

а еще гугл запилил flutter, причем он мне нравится сильно больше

у вас проблемы с html, я понял

проблемы с html - у всех)

лично у меня их нет

а еще гугл запилил flutter, причем он мне нравится сильно больше

Так я о нём же

вменяемая абстракция - это инкапсуляция во все поля, а не попытка размазать то же самое "представление" по 3 слабо взаимосвязанным платформам.

Ну и при чём тут абстракции и кроссплатформенность?

Так я о нём же

хотя дарт конечно полное дерьмо

> 2k18 > ключевое слово new всем как раз не хватало ещё одной жабы

Так я о нём же

а, я думал, вы про react-native. И вот flutter, конечно, использует "реактивный" подход, но не имеет под собой ни html, ни css, ни прочей ереси, не нужной в интерфейсах приложений

а, я думал, вы про react-native. И вот flutter, конечно, использует "реактивный" подход, но не имеет под собой ни html, ни css, ни прочей ереси, не нужной в интерфейсах приложений

Но JSX это не шаблон и не HTML

Ну и при чём тут абстракции и кроссплатформенность?

а откуда вы кроссплатформенность вдруг взяли. Для веб-фронта, допустим, платформа одна - браузер. Никакой кроссплатформенности там не подразумевалось

Но JSX это не шаблон и не HTML

jsx на выходе один хрен генерит html

вот, собственно, дайте flutter-в-браузере, и для веб-приложений будет норм

jsx на выходе один хрен генерит html

Нет. Генерирует он HTML только если это SSR сервер

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

оно начинает строить virtualDOM - так?

оно начинает строить virtualDOM - так?

Ну так DOM - не html

Вы по-юношески категоричны. НЕ ВСЕ шаблонизаторы - зло. Фронтенд на DSL - тот еще костыль, призванный уменьшить количество боли от html + css + js, не более того. Все, что касается фронтенда, отвратительно не только в Го. И оно отвратительно безотносительно вендора. А сама идея писать фронт на Го... Кхм, какие там "ключевые плюшки" в Го? Строгая статическая типизация, многопоточность "искаропки" (все вот эти горутины, каналы и прочее), грамотная стандартная библиотека. Что из этого нужно на фронте? Вот ничего из этого на фронте не нужно, и не надо мучить бабушку с идеей писать гошный фронт.

== Кхм, какие там "ключевые плюшки" в Го? Строгая статическая типизация, для фронта нужен фреймворк, а его в го нету. А как к ЯП к Го претензий нет, но кому сейчас нужен ЛЮБОЙ ЯП сам по себе? вот вам пример Го-шного фронтенд фреймворка от энтузиаста https://github.com/icza/gowut который замахнулся на GWT - колхоз вот ещё парочка, замахнулись на реакт - https://github.com/gopherjs/vecty https://github.com/myitcv/react тоже колхоз

а в DOM оно что пишет?

== Кхм, какие там "ключевые плюшки" в Го? Строгая статическая типизация, для фронта нужен фреймворк, а его в го нету. А как к ЯП к Го претензий нет, но кому сейчас нужен ЛЮБОЙ ЯП сам по себе? вот вам пример Го-шного фронтенд фреймворка от энтузиаста https://github.com/icza/gowut который замахнулся на GWT - колхоз вот ещё парочка, замахнулись на реакт - https://github.com/gopherjs/vecty https://github.com/myitcv/react тоже колхоз

да НЕ НУЖЕН на фронте Го-фреймворк

вот даже реально, если смотреть в сторону webassembly - нафига именно Го?

== Кхм, какие там "ключевые плюшки" в Го? Строгая статическая типизация, для фронта нужен фреймворк, а его в го нету. А как к ЯП к Го претензий нет, но кому сейчас нужен ЛЮБОЙ ЯП сам по себе? вот вам пример Го-шного фронтенд фреймворка от энтузиаста https://github.com/icza/gowut который замахнулся на GWT - колхоз вот ещё парочка, замахнулись на реакт - https://github.com/gopherjs/vecty https://github.com/myitcv/react тоже колхоз

Писать гуй на Го - не более чем анекдот. Язык чуть менее чем полностью непригоден для этого.

да НЕ НУЖЕН на фронте Го-фреймворк

отучаемся говорить за весь интернет. Не нужен он только тому, от кого зависит его появление - гугелю

честно говоря, последнее, что на Го стоит делать, это писать любой вид гуя

Писать гуй на Го - не более чем анекдот. Язык чуть менее чем полностью непригоден для этого.

язабан

не, вру, не последнее. Есть еще системы управления ракетами, системы жизнеобеспечения и т.д. и т.п. А вот перед ними - сразу ГУЙ)

а в DOM оно что пишет?

не HTML (в большинстве случаев)

язабан

за правду банить????

не HTML (в большинстве случаев)

но в некоторых таки html?)

ERROR: S client not available

но в некоторых таки html?)

Да. При старте приложения наверняка загоняет разметку через свойство innerHTML, ибо так быстрее.

Александр, вы же согласны со мной, что идея писать интерфейсы приложений на html + css + js - это так себе затея. Вот красиво сверстать текст, статейку, и вся вот эта "семантическая разметка" - отлично в html+css ложится.

и задумывалось оно именно для того

честно говоря, последнее, что на Го стоит делать, это писать любой вид гуя

Обоснуйте ваши громкие слова. Шаблонизаторы html - это тоже вид гуя.

Обоснуйте ваши громкие слова. Шаблонизаторы html - это тоже вид гуя.

обосновываю: чистый html - так себе средство для создания гуя.

показать статью с картинками и красивой разметкой - верю, html + css + шаблонизатор - отдавай результат

обосновываю: чистый html - так себе средство для создания гуя.

это херовое обоснование. оно логически не стыкуется. писать фронтенд != чистый html

а "шаблонизатор html" - вообще не средство для создания гуя. Это инструмент для отдачи этого гуя клиенту.

а "шаблонизатор html" - вообще не средство для создания гуя. Это инструмент для отдачи этого гуя клиенту.

шта?!

Обоснуйте ваши громкие слова. Шаблонизаторы html - это тоже вид гуя.

Ну во первых нужна нормальная асинхронность, а не горутины. Ещё нужен нормальный параметрический полиморфизм.

гуй - это html + css + обвеска из js-со-товарищи

и в этом случае ваш гуй нифейхуа не на го написан

он вполне себе на html+css+js vs "на реакте" vs "на чем там еще модно сейчас писать"

а гошный шаблонизатор может максимум этот гуй в браузер клиенту отдать

и ему, в этот момент, срать вообще, на чем этот гуй написан. Он го не касается, го его просто отдает "как есть"

и в этом случае ваш гуй нифейхуа не на го написан

сэнькю кэп. Но это не обоснование - это констатация факта

Александр, вы же согласны со мной, что идея писать интерфейсы приложений на html + css + js - это так себе затея. Вот красиво сверстать текст, статейку, и вся вот эта "семантическая разметка" - отлично в html+css ложится.

JSX можно сказать, что просто способ описать дерево компонентов, он не обязательно должен потом превращаться в HTML.

Ну во первых нужна нормальная асинхронность, а не горутины. Ещё нужен нормальный параметрический полиморфизм.

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

сэнькю кэп. Но это не обоснование - это констатация факта

как вы себе представляете реализацию гуя на го? Го с его многопоточностью в браузере НИНУЖЕН

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

с асинхронным - прям реально большие проблемы

как вы себе представляете реализацию гуя на го? Го с его многопоточностью в браузере НИНУЖЕН

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

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

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

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

как вы себе представляете многопоточность в контексте страницы браузера, ограниченной ОДНИМ системным thread'ом?

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

Чтобы рисовать гуй многопоточность и правда не нужна.

вы, случаем, многопоточность с асинхронностью не путаете?

Чтобы рисовать гуй многопоточность и правда не нужна.

согласен. Асинхронность нужна)

согласен. Асинхронность нужна)

всё так

если гую потребовалась многопоточность - это какой-то неправильный гуй)))

вероятно, архитектурные проблемы какие-то. Типа "а давайте вот эти матрицы данных запросим из базы и перемножим между собой прямо в колбэке вооот этой кнопки")))

если гую потребовалась многопоточность - это какой-то неправильный гуй)))

Бизнес логике может понадобится, но именно View многопоточность нафиг не сдалась.

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