LINUX.ORG.RU

JS фреймворк для фронтэнда с минимальным погружением

 , ,


3

5

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

Из поверхностного обзора веяний моды в этой области я узнал, что то, что я ищу, описывается термином single page application. В идеале, фреймворк должен взять на себя и визуальную составляющую, но если что, CSS я напишу сам.

Хочется сказать фреймворку: «Положи на DOM 4 кнопки, 2 списка, затем еще 3 кнопки. И пусть оно выглядит не совсем отвратительно.» Для каждого из элементов DOM прописать простенькую логику и повесить на события: сходи на сервер с таким запросом, из ответа возьми данные и замени контент там-то. Часть данных о состоянии для каждого элемента желательно хранить за пределами DOM, они нужны не пользователю, а чтобы составить правильное обращение к бэкэнду. Желательно иметь заготовки для чисто клиентских операций: сортировать список, фильтровать список и т.п.

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

Обзор хелловорлдов для фреймворков из списка «Топ 10 баззвордов чтобы зашибать деньги на фрилансе» показал, что кашу они там заварили знатную, и вот это коричневое в ней - вряд ли шоколад. Поэтому прошу совета, с каким из фреймворков приятнее иметь дело для краткого и довольно дилетантского знакомства?

★★★
Ответ на: комментарий от byko3y
for (let fruit of fruits) {
  select.options.add(new Option(fruit.Description, fruit.id))
}
tz4678 ★★
()
Ответ на: комментарий от byko3y

Array.from() знаю и использую, но хочется более чистого, нативного решения. Первым двум вариантам нужна транспиляция.

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

Пока херачу полифилы и не парюсь:

NodeList.prototype.map = function (callback, thisArg) {                                      
  return Array.from(this).map(callback, thisArg)                                             
}
ksa242
()
Ответ на: комментарий от ksa242

Array.from() знаю и использую, но хочется более чистого, нативного решения. Первым двум вариантам нужна транспиляция

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

Более того, нельзя делать varname.forEach() на varname неизвестного типа, потому что она может оказаться не массивом и код завалится. Ты можешь найти в разных библиотеках безопасное итерирование по массиву в виде:

Array.prototype.forEach.call(varname, ...)

Оно же работает для NodeList.

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

Так а в чем проблема-то?

Так я и говорил, что не проблема, а «хотелка». Я понимаю, почему так было сделано. Зря, наверное, ответил, только масла подлил своей идиосинкразией…

ksa242
()
Последнее исправление: ksa242 (всего исправлений: 1)
Ответ на: комментарий от ksa242

Так я и говорил, что не проблема, а «хотелка»

Так твоя хотелка ВЫПОЛНЕНА. Но тебе нужно, чтобы сегодня она была выполнена вчера.

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

Первым двум вариантам нужна транспиляция.

Не нужна. Это нативный синтаксис. если ты пишешь под браузеры, которые не поддерживают нативный ES, тебе в ЛЮБОМ СЛУЧАЕ нужна будет транслитерация. Если ты под ВСЕ браузеры пишешь на es3-es5, ты теряешь в перфомансе на новых браузерах, городя костыли, для того, что уже есть нативно в движках.

Правильно - это писать es6+ код, и грузить его в script type=Module, а для старых браузеров отдельно оттранслированный код грузить в script nomodule. Также, как утебя нативное есть отдельные x86, x 64 и arm бинарники, а ты не тянешь бинарники всех архитектуру на каждую платформу.

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

Подожди. Мы всё ещё про DOM API говорим? Я массивы из AJAX-запросов перебираю через forEach, map, filter, и мне, упоротому, хочется так же результат Element.querySelectorAll перебирать, чтобы был единый подход. Element.querySelectorAll всегда возвращает NodeList (это к вопросу об undefined.forEach), и у него таки есть forEach, но нету map и filter. Вот и вся суть мелочной личной придирки.

ksa242
()
Последнее исправление: ksa242 (всего исправлений: 2)
Ответ на: комментарий от anonymous

Ну да, надо помнить, что с массивом arr.map(), а с NodeList – [...nodes].map() или Array.from(nodes).map(). Чисто визуально раздражает и тратит капелюшку мыслетоплива.

ksa242
()
Последнее исправление: ksa242 (всего исправлений: 1)
Ответ на: комментарий от byko3y

Ну, знаешь, и некоторые русские считают россию хорошей страной. За отчизну, за государя! Таких только пожалеть остается. Кушайте, мусье, кушайте.

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

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

Ты несешь какую-то дичь. DOM - это не жс, это отдельно взятое API? которое поддерживается во МНОГИХ языках программирования, у него есть отдельно взятый интерфейс. Интерфейс NodeList по спецификаии DOM не реализует методы, которые ты хочешь. JS тут не при чем. Иначе бы эти методы должны были быть реализованы и в питоне, и в го, и в плюсах, и вси, и вообще везде, где есть DOM API.

Ты, твою мать, понимаешь что такое API?

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

Ну да, надо помнить, что с массивом arr.map(), а с NodeList – […nodes].map() или Array.from(nodes).map(). Чисто визуально раздражает и тратит капелюшку мыслетоплива.

Ах, какая жалость, что в CS больше, чем одна структура данных! Уверен, что выбрал ту профессию?

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

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

function selectAll(selector, ctx = document) {
    return [...ctx.querySelectorAll(selector)]
}

Пользуйся!

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

Не нервничай, я давно понял, что меня одного смущает, что в DOM API в одной части *List есть forEach, в другой – нет, хотя length и item есть во всех; что есть forEach, но нет map/filter/reduce; что в одном *List есть методы delete и has, а в другом – remove и contains.

ksa242
()
Последнее исправление: ksa242 (всего исправлений: 1)
Ответ на: комментарий от ksa242

Ты путаешь интерфейсы. NodeList и Array - это мало того, что разные интерфейсы, так еще и разные API. Один это хост-объект окружения, другое - встроенный в язык (стандартная библиотека). У тебя проблемы с пониманием базы, как устроено программирование в целом. Ты просто не представляешь какую околесицу ты из-за этого несешь.

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

какая жалость, что в CS больше, чем одна структура данных!

Довольно неудобно, что функции для работы с последовательностями не работают с некоторыми последовательностями, не так ли?

P.S. JS на лоре окончательно обезумел, хоть отключай.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от anonymous

NodeList и Array - это мало того, что разные интерфейсы, так еще и разные API

Да, и причем херовые.

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

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

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

Это не функции, а методы. Если ты будешь вызывать метод, как функцию, работать они будут одинаково с любой последовательностью, ламер.

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

Это не функции, а методы

Не обезьяна, а макака. Понемаю.

Если ты будешь вызывать метод, как функцию

Коньяк тоже можно клизмой заливать. Но надо ли?

Хотя, в принципе, для себя можно написать обертки для превращения map, reduce и filter обратно в нормальные функции, да. И теоретически должно работать на любых объектах, у которых есть length и доступ по индексу (a[]).

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 4)
Ответ на: комментарий от anonymous

А фронт делается на html/css + jQuery + ajax вызовы. Можно еще пару библиотек взять для таблиц с их сортировками и фильтрами.

И все. Что еще надо? Какие нафик фреймворки? o_O

Ну ты, друг, очевидно никогда не писал фронтенд, который чуть сложнее простой формочки. Попробуй и такие глупые вопросы пропадут.

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

Ну ты, друг, очевидно никогда не писал фронтенд, который чуть сложнее простой формочки. Попробуй и такие глупые вопросы пропадут

Даже достаточно сложный фронт можно накидать на минимуме JS и фреймах. Другое дело, что есть вещи, которые строятся только на интенсивном использовании JS в масштабах всей страницы, например, параллельная работа с неким содержимым в отдельной панельке и на главной странице — это основной критерий для выбора React/etc. Но, как я уже писал выше, далеко не всем людям такое нужно. Если у тебя есть очень ограниченная область с динамикой, например, какой-то отдельный график или тем более таблица, то это критерий того, что JS тебе нужен, но ровно в этом графике/табличке.

Я вот пишу суровую динамику, где, например, есть отдельная панелька настроек, но реальность такова, что пользовать в итоге никогда не видит одновременно настроек и основного содержимого сайта, потому динамическая реализация настроек здесь излишня. Самая мерзотное же свойсто SPA заключается в том, что если пользователь внезапно окажется не домозяйкой и откроет две вкладки, то всё замечательное взаимодействие окошечек и панелечек рассыпется, причем, эта рассинхронизация может продолжать существовать весьма долго. По этой причине разрабы SPA-фреймворков так активно двигаются в сторону SSR, но писать SSR внезапно оказывается сложновато, а еще было бы неплохо синхронизировать между вкладками клиентский кэш через localStorage — и внезапно оказывается, что делать грамотный SSR на React/Vue/Svelte/Frameworkname ни разу не просто и не быстро, и не ясно еще, что было бы проще: ванильный JS или вот это.

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

И теоретически должно работать на любых объектах, у которых есть length и доступ по индексу (a[]).

это называется array-like object в стандарте.

Array.prototype.* работают на таких объектах по стандарту, не надо ничего писать.

[].map.call(document.querySelectorAll(selector)).forEach()

Довольно неудобно, что функции для работы с последовательностями не работают с некоторыми последовательностями, не так ли?

а вот последовательности это iterables, для них нет к сожалению альтернатив кроме Array.from.

drsm ★★
()
Последнее исправление: drsm (всего исправлений: 1)

Хочется сказать фреймворку: «Положи на DOM 4 кнопки, 2 списка, затем еще 3 кнопки. И пусть оно выглядит не совсем отвратительно.»

В 2021 году это можно сделать двумя путями.

  1. взять jquery и twitter bootstrap. сделаешь сам за неделю.

  2. взять три фреймворка, два сборщика, три прекомпайлера, двести библиотек подключить, нанять front-end программиста и через два месяца оно заработает.

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

1. взять jquery и twitter bootstrap. сделаешь сам за неделю

Полтреда уже обсуждаем, что jQuery в этом списке лишний.

взять три фреймворка, два сборщика, три прекомпайлера, двести библиотек подключить, нанять front-end программиста и через два месяца оно заработает

По факту я уже примерно через две недели мог выдать что-то работающее, будучи не знаком с фреймворком и современным JS+CSS. Правда, показывать это мне бы сейчас было стыдно.

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

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

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

По факту я уже примерно через две недели мог выдать что-то работающее, будучи не знаком с фреймворком и современным JS+CSS. Правда, показывать это мне бы сейчас было стыдно.

А ты можешь за 2 недели въехать в то что написал другой незнакомый человек за 2 недели? Я не могу, особенно если человек с небольшим опытом или такой гений что я его абстракции не пойму.

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

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

Aber ★★★★★
()
Последнее исправление: Aber (всего исправлений: 1)
Ответ на: комментарий от Alve

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

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

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

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

Как правило, при работе с чужим кодом я ограничиваю свою область интересов, не пытаясь читать всё подряд, а читать только интересующие меня и логически связанные части. Далее уже скорость разбора различается от того, насколько эти логически связанные части разбросаны по коду.

Это как большой SQL, написать проще чем понять то что уже было написано, проблема только в том что чтоб написать новый надо понять что делал старый

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

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

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

byko3y ★★★★
()
Последнее исправление: byko3y (всего исправлений: 1)
Ответ на: комментарий от byko3y

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

С лиспом к счастью не сталкивался. Теоретически могу столкнуться с clojure, но пока не случалось.

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

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

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

Это смотря какой DSL. Если он небольшой, логичный и документированный, код на нем читать может быть легче, чем на исходном языке.

Собственно, имена написанных тобой функций/методов в твоей программе так или иначе в совокупности образуют своего рода DSL, лисп или не лисп.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)

Vue + vue router + vuex. В общем, Vue. Просто, быстро, куча плагинов, гайдов и вопросов на стаке. И ts поддерживает.

Тему не читал, потому что на рынке в основном большая тройка, а по запросу подходит только Vue или React, по поводу последнего есть подробное сравнение на сайте vue. С другими фреймворками больше рисков упереться в потолок возможностей, не найти нужное решение, столкнуться с плохой поддержкой, ну и так далее.

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

именно выучить

Что именно ты имеешь в виду? Просто регулярно тут (и не только тут) слышу то же высказывание, только вместо java подставляется любой другой язык.

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

с тем же jquery можно клепать сайты, не зная языка как такового, лишь имея смутные представления о событийной модели и работе с dom. так же неосиляторы, которым лень учить язык в разное время придумывали суррогаты: coffeescript (любители ruby), typescript (c#), dart. тот же babel всего лишь ретранслятор последнего стандарта на более рание версии с использованием полифилов. поэтому его использование я считаю кошерным. новомодные фреймворки типа vue, react дают альтернативный способ работы с dom, что ни есть хорошо, ведь появится очередное поколение дебилов, не умеющих в dom, но плюсы, например, двусторонее связывание модели и представления делает использование подобных фреймворков рациональным

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

А JAVA тут при чём?

Кстати, что касается typescript не сказал бы, что его придумали для тех, кто не осилил JS. Просто в JS, прямо скажем, такая себе типизация, поэтому использование TS после JS - это просто глоток свежего воздуха.

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

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

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

а понял. я выше ответил человеку, который яву рекламировал. мне не нравится в ней многословность, конечно, она лучше чем кресты… отчасти, но не так идеальна как питон

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

У меня почему ничего не тормозит?

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

Нормальные инструменты должны позволять сделать «небольшую прожку» за два часа. Так не бывает в нормальных инструментах. Во всяких WPF, JavaFX, Swing, WinForms, VB6 - может быть и бывает. А в нормальных - нет.

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

Нормальные инструменты должны позволять сделать «небольшую прожку» за два часа.

Так не бывает в нормальных инструментах. Во всяких WPF, JavaFX, Swing, WinForms, VB6 - может быть и бывает. А в нормальных - нет.

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

ведь появится очередное поколение дебилов, не умеющих в dom

s/появится/появилось/

Примерно как поколение кодеров на Node.js, которое не умеет писать под браузер.

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

Нет двухстороннего-то. Есть одностороннее, модель->вид. Алгоритм реакции на события DOM ты пишешь ручками, изменяешь при этом модель, и потом по накатанной модель->вид. Особенно в React эта проблема обстоит тяжело, потому что тяжело прокинуть нужные состояния так, чтобы они и в представления нужные транслировались, и были доступны на изменение обработчикам из разных мест.

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