LINUX.ORG.RU

Разработка Web-интерфейса с пользователем.

 ,


1

4

Уважаемые коллеги!

Сегодня существует великое множество различных т.н. «веб-фреймворков» для создания различных интерактивных сайтов. (Кстати, почему и зачем так много, что любой обыватель может легко потеряться в таком изобилии, лол?) Однако, практика показывает, что многие из этих модных-модных достижений силы современной программистской мысли преподносят не самые приятные сюрпризы уже после того, как разработчик их использующий, окунётся с головой в разработку своего очередного творения мирового масштаба, рассчитанного на сверхнагрузки (aka HighLoad в мечтах и фантазиях).

Поэтому резонно возникает вопрос: какой технологией для создания качественных (простых и надёжных) web-интерфейсов, которая вас не подводила, пользуетесь вы, уважаемые коллеги, профессиональные web-разработчики? :-)

Ответ на: комментарий от deep-purple

Любителям этого, на твои доводы плевать.

Ну так зачем обобщать на все веб-приложения? Твой подход с «только натив» хорошо для веб-приложений масштаба шаред хостинга или совсем уж монстров вроде вышеупомянутых социальных сетей. А среднего и крупного мастаба проект отказом от распространенных фреймворков ты просто погубишь так как оно будет или неподдерживаемое/неразвиваемое нечто, завязанное на одного разраба или не окупит затраты на разработку/опоздает с выходом на рынок.

anonymous ()
Ответ на: комментарий от anonymous

зачем обобщать на все веб-приложения

Обычно «васе» надо чтобы поставил и сразу работает. Иначе, что это за популярный универсальный фреймворк общественного назначения?

среднего и крупного мастаба проект отказом от распространенных фреймворков ты просто погубишь

Так изначально я о чем? Именно о том что все фреймворки рождены или спермотоксикозниками, или внутри галер, но, там то они сами его себе написали, под себя. Дык, остальные тупо фанаты, слетаются на всякое говно и орут что это круто. Кому-то, может, и правда подойдет, но это ж редкость.

deep-purple ★★★★★ ()
Ответ на: комментарий от InterVi

появление/исчезновение

Какой ужас! Тоггл элемента делается в пару строк.

ездило/растворялось/улетало/etc

А конкретнее что ездило и куда улетало? Возможно, обойдемся стилями.

Плавная анимация скроллинга

Два десятка строк с requestAnimationFrame — еще и для других перделок тут же сгодится.

«магнитился» к нужным секциям

Нам уже пригодился предыдущий код.

ивенты

https://stackoverflow.com/questions/2490825/how-to-trigger-event-in-javascript

не ломалось при изменении размера окна браузера

Вешаемся на ресайз окна, смотрим значение скролла, докручиваем куда надо. Ну, строк 5-10, да?

какой-нибудь параллакс

А парралакс, так и быть, возьмем плагином. Но только параллакс. Я бы его еще и раздербанил — там много полезного готового про скролл, положение, ивенты...

Зато знаешь как лендос летать будет? То-то.

deep-purple ★★★★★ ()
Ответ на: комментарий от azelipupenko

Не важно, через HTTP, через открытый WS-канал,

Важно. Есть фундаментальное отличие - во втором всегда есть состояние, а в первом нет. Как максимум какие-то убогие кастыли, но они не являются полноценным состоянием.

LjubaSherif ()
Ответ на: комментарий от azelipupenko

а его двунаправленность позволяет уведомлять об изменениях БД (модель) интерфейс (вид) (привет, классический MVC).

Нотификация лишь малая часть, а двунаправленность позволять строить master<->master архитектуру.

LjubaSherif ()
Ответ на: комментарий от LjubaSherif

Важно. Есть фундаментальное отличие - во втором всегда есть состояние, а в первом нет. Как максимум какие-то убогие кастыли, но они не являются полноценным состоянием.

Спасибо, я в курсе про фундаментальное отличие. Я ведь говорю в контексте темы «обращаться ли при каждом запросе в БД или нет» это фундаментальное отличие абсолютно не имеет значения.

azelipupenko ()
Ответ на: комментарий от LjubaSherif

Нотификация лишь малая часть, а двунаправленность позволять строить master<->master архитектуру.

А что имеется в виду под «master<->master архитектурой» web-приложения?

azelipupenko ()
Ответ на: комментарий от menangen

https://ru.vuejs.org

Смотрю на Vue.js и возникают вот какие мысли. Рассмотрим пример с официального сайта:

<div id="app-3">
  <span v-if="seen">Сейчас меня видно</span>
</div>

Ну и JavaScript для работы с ним:

var app3 = new Vue({
  el: '#app-3',
  data: {
    seen: true
  }
})

Получается, что с jQuery можно достигнуть того же эффекта даже короче, причём использовав обычный CSS. Меня смущает, что к HTML, CSS, JavaScript тут надо ещё и знать все директивы Vue.js. Не слишком ли много?

azelipupenko ()
Ответ на: комментарий от Int0l

действительно если на jquery хелловорд короче, то зачем что-то другое?

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

azelipupenko ()
Ответ на: комментарий от azelipupenko

на кого, в таком случае, останется пенять, кроме как на себя

лучше пенять на кого-то? - отличный выбор! и еще про галеры не забываем ...

anonymous ()
Ответ на: комментарий от anonymous

лучше пенять на кого-то? - отличный выбор! и еще про галеры не забываем ...

Нет, конечно. Лучше не пенять, а наслаждаться жизнью. Поэтому не хочется попасть в ситуацию, где придётся пенять.

azelipupenko ()

Код писать только ручками. Серверная часть - на С или С++. И все будет хорошо.

anonymous ()
Ответ на: комментарий от anonymous

Код писать только ручками.

разумно - этоподходит даже в том случае, когда код написаный ручками генерит код автоматом ...

anonymous ()
Ответ на: комментарий от InterVi

Не те же самые, а те, которые нужны, только нужные!!! Мы (мир) уже кстати доехали до песца что на СО спрашивают как сложить два числа с помощью жквери. А что ради пары пуков на страничку грузят десяток либ — это уже вообще я давно смотрю норма.

deep-purple ★★★★★ ()
Ответ на: комментарий от InterVi

Готовое чаще не подходит. Чистить готовое от лишнего — тоже время. Было дело, я колупался дня два чтобы колорбокс подогнать к хотелкам. В итоге снёс его к херам и за несколько часов сделал микро-плагинчик для жквери, фоновая подгрузка, текст под картинкой, ресайз окна. И я потратил меньше времени чем курил какое-то говно.

Так эта ваша «выгода по времени» уже выливается в новости типа «даладна — отрубили лишнее говно и сайт стал летать». Не, ты знаешь, я ж тоже не без греха и даже делал такие лютые костыли типа $('selector').click().click(); и подрубал целые либы просто потому что мне лень. Но это всё в прошлом. И ты и все другие потом так же осознаете всё это.

deep-purple ★★★★★ ()
Ответ на: комментарий от azelipupenko

упёрся в какое-то неразрешимое противоречие

Тотальная некомпетентность и синдром утенка - безусловно неразрешимое противоречие.

anonymous ()
Ответ на: комментарий от azelipupenko

Для проектов больше, чем hello world, очевидно. Очевидно настолько же, насколько очевидно, что сравнивать фреймворк с ванилой на примере hello world'a это верх идиотизма.

Покажи хоть один пример, где бы использование фреймворка в hello world'е выигрывало бы у ванильной реализации, в любом языке, в любой платформе.

Еще полезно тебе будет вообще изучить вопрос, зачем люди пилят эти самые фреймворки.

anonymous ()
Ответ на: комментарий от anonymous

Для проектов больше, чем hello world, очевидно. Очевидно настолько же, насколько очевидно, что сравнивать фреймворк с ванилой на примере hello world'a это верх идиотизма.

Не очевидно. Это всё бла-бла.

Покажи хоть один пример, где бы использование фреймворка в hello world'е выигрывало бы у ванильной реализации, в любом языке, в любой платформе.

Если фреймворк проигрывает даже на ЗдравствуйтеМир, то что говорить про ЗдравствуйтеРеальныйМир приложения?

Еще полезно тебе будет вообще изучить вопрос, зачем люди пилят эти самые фреймворки.

Зачем мне изучать этот вопрос? Люди занимаются много чем бесполезным. Мне это тоже изучать надо? Лол.

azelipupenko ()
Ответ на: комментарий от anonymous

Все с тобой понятно.

Лол. Ну вот один коллега выше дал хотя бы ссылки на сравнение ЗдравствуйтеМир приложений на разных фреймворках и на ванильном JS. А что посоветовал ты? Изучать вопрос зачем создаются фрэймворки? Зачем не эта бла-бла-философия? Правильно, она мне незачем.

azelipupenko ()
Ответ на: комментарий от azelipupenko

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

LjubaSherif ()
Ответ на: комментарий от azelipupenko

Зачем не эта бла-бла-философия? Правильно, она мне незачем.

Ровно как мне незачем тебе что-либо советовать и объяснять.

anonymous ()
Ответ на: комментарий от azelipupenko

Смотрю на Vue.js

Не смотри на эту парашу. Там уже ламерки целиком и полностью обделались со своими мусорными шаблонами и через пару лет все хомячки орать не «шаблоны наше всё», а jsx-наше всё.

JavaScript

И эта параша целиком и полностью не юзабельная. Бери отрыжку мелкософта.

jQuery

Сравнивать это мусорное убожество и какие-то более-менее вменяемые подходы? Слишком слабо.

Меня смущает, что к HTML, CSS, JavaScript тут надо ещё и знать все директивы Vue.js.

Правильно, а отгадай почему? Потому что ламерки не осилили интегрировать своё дерьмо в язык, а язык в дерьмо. Именно поэтому родилась эта json-отрыжка, чтобы ламерки могли ваять конфиги. Особенно меня веселят эти строки. Как только видишь строки - знай - ты видишь дерьмо.

LjubaSherif ()
Ответ на: комментарий от azelipupenko

Не очевидно. Это всё бла-бла.

Это очевидно. В твоей жкуери-параше состояние находится в не в коде, а мусорной хтмл-отрыжке, т.е. неведомо где. Структура хтмл-отрыжки так же находится неведомо где. А структуры у твоего жскуери-лапши вообще нет.

В ситуации, когда ты пишешь код нормально - у тебя всё существует в рамках кода. Структура описывается кодом, состояние описывается кодом, изменяются базовые примитивы языка, а не неведомая магия.

Если фреймворк проигрывает даже на ЗдравствуйтеМир, то что говорить про ЗдравствуйтеРеальныйМир приложения?

Это потуги уровня «зачем нужна типизация?», «она даже на хелворде не работает» - нет, она работает. И ответ тут тот же самые. Она позволяет описывать архитектуру в рамки неких ограничений обусловленных этой самой архитектурой.

Зачем мне изучать этот вопрос? Люди занимаются много чем бесполезным. Мне это тоже изучать надо? Лол.

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

LjubaSherif ()
Ответ на: комментарий от LjubaSherif

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

Это понятно. Но что если у меня контент-ориентированный сайт, данные которого целиков лежат в БД? Мне походы в БД нужны именно за данными, которые представляются на сайте. (Оставим пока кэш в покое, я не хочу сейчас думать о любого рода оптимизациях.) Теперь, если взять тот же Postges, то его архитектура предполагает отдельный процесс на каждое соединение. Рабочим максимумом, насколько я знаю, является 400-500 одновременных сессий PostgreSQL. Т.е. к серверу WebSockets можно открыть хоть 100500 персистентных соединений (сохраняя состояния и все дела, круто, да), но вот если бы можно было открыть 100500 соединений к СУБД, то было бы идеально. Но так сделать нельзя, увы. Поэтому, конечно, постоянные соединения с состояниями - это очень круто, но походы в БД для контент-ориентированных сайтов тут приходится организовывать через пул соединений (или открывать новое соединение на каждый запрос данных из БД). И при таком подходе, уже не имеет значения, используется ли WebSockets или HTTP. Я вот что имею в виду.

azelipupenko ()
Ответ на: комментарий от deep-purple

Что наводит на мысл, что это один тролль с разными учетками, типа:

- ко, ко, ко, всё г, JavaScript параша, татата!
- ППКС
- да, и я тоже!
- блин, а где пруфы?
- какие пруфы, ты че, макака? Ко-ко-ко!

Детсад

menangen ★★★★★ ()
Ответ на: комментарий от LjubaSherif

Это очевидно. В твоей жкуери-параше состояние находится в не в коде, а мусорной хтмл-отрыжке, т.е. неведомо где. Структура хтмл-отрыжки так же находится неведомо где. А структуры у твоего жскуери-лапши вообще нет.

Что-то я не понял. Ты сейчас признал очевидность полезности Vue? Вроде бы ты раньше заявлял, что это «параша». Лол.

Это потуги уровня «зачем нужна типизация?», «она даже на хелворде не работает» - нет, она работает. И ответ тут тот же самые. Она позволяет описывать архитектуру в рамки неких ограничений обусловленных этой самой архитектурой.

Нет, не так. ЗдравствуйМиры призваны показывать минимальные рабочие примеры, которые вызовут интерес. Когда я вижу ЗдравствуйМир, который можно записать на том же языке, но короче, я уже не принимаю аргументы типа «ну вот на большом проекте либа/фреймворк себя проявит, а ЗдравсвтуйМир не для него». Лол. Зачем тогда вообще демонстрировать ЗдравствуйМир?

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

Какой тебе пример привести? Как поменять стиль span-а с помощью visibility? Ты серьёзно? Лол.

azelipupenko ()
Ответ на: комментарий от menangen

ко, ко, ко, всё г, JavaScript параша

Видишь только то, на что подгорает.

это один тролль

Навело на мысль — уточняй у мочераторов про ойпишники.

deep-purple ★★★★★ ()
Ответ на: комментарий от azelipupenko

Это понятно. Но что если у меня контент-ориентированный сайт, данные которого целиков лежат в БД?

Это детский садик, который вообще не рассматривается( по крайней мере у меня). Я говорю о чём-то общем, либо хотя-бы о чём-то более-менее сложном. Если тебе нужно отдавать текст/картиночки, то тут ничего не нужно.

Т.е. к серверу WebSockets можно открыть хоть 100500 персистентных соединений (сохраняя состояния и все дела, круто, да), но вот если бы можно было открыть 100500 соединений к СУБД, то было бы идеально. Но так сделать нельзя, увы.

Ничего не понимаю, каким образом ты связал свой коннекшен к базе и вебсокет? Зачем и почему тебе нужно открывать коннекшен к базе на коннекшен вебсокета? У тебя пхп головного мозга?

И при таком подходе, уже не имеет значения, используется ли WebSockets или HTTP. Я вот что имею в виду.

В таком подходе - это каком? Скорее всего, как я уже говорил ранее - у тебя пхп-проблемы.

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

Опиши подробней архитектуру, о которой ты говоришь. Мне она не очевидна.

LjubaSherif ()
Ответ на: комментарий от azelipupenko

Что-то я не понял. Ты сейчас признал очевидность полезности Vue? Вроде бы ты раньше заявлял, что это «параша». Лол.

Зачем ты пытаешься ловить меня? Это гиблое дело. Но давая я тебе помогу, вместо того, чтобы агриться на базворды - ты мог бы попытаться осилить и понять то, что тебе говорили. В частности - vue как имплементация и vue как подход( на самом деле о vue тебе вообще никто ничего не говорили) - это две разные вещи. Тебе говорят о подходе, который никаким образом к vue отношения не имеет, он лишь имплементирует в себе какие-то части этого подхода.

Нет, не так. ЗдравствуйМиры призваны показывать минимальные рабочие примеры, которые вызовут интерес.

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

Понимающий видит разницу, видит то, что даёт один подход и второй. А ты видишь лишь портянку, которая делает какой-то примитивное действие. Хотя эта портянка не про действие, а про демонстрацию подхода.

Какой тебе пример привести? Как поменять стиль span-а с помощью visibility? Ты серьёзно? Лол.

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

LjubaSherif ()

На мой взгляд Svelte обладает интересным соотношением характеристик, я делаю на него ставку.

ddidwyll ★★★ ()
Ответ на: комментарий от LjubaSherif

Это детский садик, который вообще не рассматривается( по крайней мере у меня).

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

Я говорю о чём-то общем, либо хотя-бы о чём-то более-менее сложном. Если тебе нужно отдавать текст/картиночки, то тут ничего не нужно.

Да вообще, web не нужен, чего уж там мелочиться.

Ничего не понимаю, каким образом ты связал свой коннекшен к базе и вебсокет?

Я не связываю вебсокет с БД. Я не понимаю, откуда ты это взял?

Зачем и почему тебе нужно открывать коннекшен к базе на коннекшен вебсокета?

Мне не нужно открывать соединение к БД на соединение с WebSocket-сервером. Мне нужно отвечать на запросы данных от клиента, которые необходимо получать из БД. (Они там в структурированном виде лежат.)

У тебя пхп головного мозга?

Нет.

В таком подходе - это каком? Скорее всего, как я уже говорил ранее - у тебя пхп-проблемы.

В подходе, когда данные хранятся в БД, а извлекаются по запросу от клиента. У меня нет пхп-проблем. Как они у меня могут быть, если я не пишу на пхп? Лол.

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

Совершенно верно, это и предполагается.

Опиши подробней архитектуру, о которой ты говоришь. Мне она не очевидна.

Очень просто. Открываешь соединение с WebSocket-сервером, руки пожали друг другу, все дела. Потом говоришь такой: ей, сервер, дай мне вот те данные по вот таким вот критериям. И тут вот как раз сервер WebSocket такой берёт и осуществляет поход в БД, потом данные отдаёт клиенту - на, мол, бери, они твои.

Всё тоже самое можно сделать и с обычным Ajax-запросом.

azelipupenko ()
Ответ на: комментарий от azelipupenko

Ты решил играть со мною в игры, пытаясь юлить и отказываясь от своих слов? Хорошо, будем играть по другому.

Т.е. к серверу WebSockets можно открыть хоть 100500 персистентных соединений (сохраняя состояния и все дела, круто, да), но вот если бы можно было открыть 100500 соединений к СУБД, то было бы идеально. Но так сделать нельзя, увы.

Теперь рассказывай, если 100500 соединений вебсокета никак не связаны с соединениями к бд, то зачем ты рассуждал о том, что на 100500 нужно 100500? Какие основания у тебя были для этого?

LjubaSherif ()
Ответ на: комментарий от LjubaSherif

Зачем ты пытаешься ловить меня?

Не пытаюсь, зачем мне это?

Это гиблое дело.

:-)

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

Но я то спросил конкретно о Vue. Раз мне ответили, значит речь о Vue :-)

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

Может быть у них шизофрения, раз они видят то, чего не видно?

Понимающий видит разницу, видит то, что даёт один подход и второй. А ты видишь лишь портянку, которая делает какой-то примитивное действие. Хотя эта портянка не про действие, а про демонстрацию подхода.

Подход продемонстрирован. Он более громоздок, чем подход jQuery.

Вот видишь, ты уже сел в лужу, пытаясь натягивать свои мусорные представления на реальность.

Не вижу.

С чего ты взял, что там твои ламерские стили?

С чего ты взял, что там что-то другое?

azelipupenko ()
Ответ на: комментарий от LjubaSherif

Ты решил играть со мною в игры, пытаясь юлить и отказываясь от своих слов? Хорошо, будем играть по другому.

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

Теперь рассказывай, если 100500 соединений вебсокета никак не связаны с соединениями к бд, то зачем ты рассуждал о том, что на 100500 нужно 100500?

Потому что есть 100500 клиентов, которым нужные данные, которые в БД.

Какие основания у тебя были для этого?

Обеспечить пользователей данными.

azelipupenko ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.