Что-то в этом вебе слишком много всего

Но является фактором. Если бы дело было не в ЯП, я бы и по сей день мог хорошо сидеть на Дельфи + MS SQL. Но это не выйдет.

Раз уж я завёл эту тему... смотрю скринкат по react на learn.javascript.ru

Вижу странное.

Виртуальный дом - это жирный и дорогой слой абстракции. Он превращается не в html, а в конструкторы, написанные на JS. Из опыта мне кажется это трудным для отладки и неэффективным. Наверняка такие конструкторы работают медленнее, чем рендер статического html. Если html можно прочитать глазами И смотреть в инспекторе, то DOM, порождённый из виртуального можно смотреть только в инспекторе, т.е. минус один инструмент.

Далее. Сначала поднимаем на знамя идею «компонент ничего не знает о своём окружении», и эта идея перестаёт работать уже на примере аккордеона. Тогда выносим состояние в родителя (нарушение идеи модульности) и прокладываем провода между родителем и ребёнком (усиление связанности или связности, как её там зовут).

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

Как вообще надо было бы сделать аккордеон? Я бы отделил два понятия: виджет (который будем рисовать) и аккордеон (куда виджет будет помещаться). Понятие видимый/невидимый должно полностью находиться внутри виджета. Даже если он не может включить свою видимость, он должен знать о том, когда его видимость меняется. У него должны быть методы «показать», «скрыть», события «меня хотят скрыть», «меня скрыли», «меня хотят показать», «меня показали» и «видим ли я?», которые не нужно переписывать, если я захотел поместить его в аккордеон. Виджет должен уметь выразить своё неудовольствие при попытке его скрыть или показать (допустим, там может быть заполненная форма, ожидающая отправки на сервер, которую нельзя просто так запихнуть в карман - нужно заставить юзера или её отправить, или явно выразить свой пофигизм на эту тему). Во всяком случае, так было в Дельфи, который мне только что рекомендовали закопать, так в tk (для окон) и что-то вроде того было даже в клиппере ЕМНИП. Собственно, мне даже не вполне ясно, почему я в XXI веке должен заниматься проектированием и рукописной реализацией понятия видимости, да ещё и иметь с этим трудности. В чём тогда состоит смысл этого фреймворка, какую помощь он мне оказывает?

И собственно аккордеон, который принимает виджеты, имеющие вот этот набор методов, и их включает в себя.

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

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

Допустим, я придираюсь. Но мне что-то кажется, что это не я придираюсь, а что этот react дурацкий :( И вот пока в сумме получается: сам JS - дурацкий. bootstarp дурацкий (bootstrap 3 не может отрисовать меню на 4-летнем браузере Opera Mini; да, это 0.01%, но ведь всего в старых браузерах в России работает 20% пользователей). Может, просто не нужны эти выпадающие меню, раз 20% браузеров могут поиметь с ними проблемы?

express дурацкий (нельзя применить шаблонизатор для генерации статического файла без костылей).

И вот теперь и с react что-то не так красиво, как должно быть для «фреймворка N1».

Что тогда не дурацкое?

Я не понял, может, это со мной что-то не так? Слишком много хочу? Но ведь XXI век вроде, очевидные вещи должны быть сделаны уже. А все эти веб-фреймворки новые и начинались с нуля, это не С++ какой-нибудь, где груз совместимости. Что мешало сделать нормально?

Или я просто не догнал что-то? Или не умею программировать?

Проблема в том, что ты думаешь перед тем как что-то сделать. А JS-макаки не думают, потому что «Ололо! Давай фигачить, чо тут думать.» Поэтому весь веб с этим его JS — говнище с кучей костылей.

Нет. Анон не прав.
Проблема в том, что ты начал изучать веб с изучения фреймворков, а не нативных технологий. Ты не пытаешься понять и изучить прямо работу с DOM\BOM\, их концепции и принципы работы. От того тебе все непонятно и ты все понимаешь неверно.

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

Именно поэтому ты, например, считаешь реакт - фреймворком, в то время как это просто библиотека для повышения абстракций. Сделанная для тех, кто не может эффективно работать с DOMом напрямую (и это не в плохом контексте, с ним правда сложно работать напрямую эффективно, нужно иметь богатый опыт).

Задача с выпадающим списком реализующаяся абсолютно во всех браузерах, ты воспринмимаешь какой-то сложной, потому что ты не пишешь на CSS, а пишешь сразу на абстракциях. Ограничиваешь себя ими, и не понимаешь как они вообще работают.

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

Веб - это целая платформа. И проста она лишь в глазах тех, кто под нее не пишет. Ровно по тем же причинам она многим кажется нелогична или нессуразна.

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

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

// Мопед не мой.

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

фрилансером—вебмастером

Нет никаких «вебмастеров», это звание себе придумали школьники, которые научились ставить WP и плагины к нему. Такой себе сферический в вакууме «компьютерщик», только в вебе.

Ограничиваешь себя ими, и не понимаешь как они вообще работают.

Я думал, это нормально - ехать на автомобиле и не знать, как устроен руль. Достаточно знать, что поворачиваешь руль вправо - и машина поворачивает вправо. Видимо, этот автомобиль так не едет :(

Задача с выпадающим списком реализующаяся абсолютно во всех браузерах

Думаю, не во всех, например, как насчёт Lynx?

потому что ты не пишешь на CSS, а пишешь сразу на абстракциях

Мне «продавали» бутстрап, как абстракцию, облегчающую боль адаптивного дизайна и позволяющую приступить собственно к созданию сайта быстрее. Т.е. мне было сказано: возьми бутстрап и сделай меню за 5 минут. Я в это поверил, сделал, но оно не работает в 4-летней Opera Mini. Теперь открывается правда жизни: сделать адаптивное выпадающее меню за 5 минут нельзя, оказывается, нужно долго для этого учиться. Поскольку я в свежем браузере видел кривое выпадающее меню, в т.ч. на сайтах веб студий, я начинаю думать, что это крайне сложная задача, доступная только истинно крутым профессионалам.

Ты разрываешь моё сердце (и не ты первый :( ) Вот прям хочется матом ругаться уже.

Понял, спасибо!

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

В общем, дело твое.
Рано или поздно ты либо сам поймешь, что идешь по не той дорожке. Либо просто выдохнешься и обстоятельства зажмут. Удачи.

Либо подходить ко всему обстоятельно и кардинально.

Обстоятельно - это понятно. А вот что есть «кардинально»?

Идеальный стак копротехнологий.

Нет никаких «вебмастеров», это звание себе придумали школьники

Я в курсе, но Денис судя по его сообщению метит именно туда.

Виртуальный дом - это жирный и дорогой слой абстракции. Он превращается не в html, а в конструкторы, написанные на JS. Из опыта мне кажется это трудным для ...

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

изменение чего-либо в «виртуальном» дом намного дешевле, поскольу это всего лишь изменения в яваскрипте.

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

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

отрасль бодается за нативную реализацию этой концепци в браузерах, но пока не дободали.

Ну и ещё одна фигня. Иммутабельность. Когда они хотят пересортировать список постов в блоге, дело кончается тем, что они для этого копируют массив. Да, я понимаю, иммутабельность - это действительно классная концепция. А теперь представим себе чат, где 100500 сообщений и добавляется ещё одно.

неее, это ж далеко не всегда полное копирование. там правит бал
https://en.wikipedia.org/wiki/Persistent_data_structure. а народ сетует что нет нативной браузерной реализации и таскает за собой immutable.js

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

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

на иммутебельности и подходах мира функционального программирования строятся все эти концепции управленя сложным состоянием, и отображением этого состояния в DOM.

адаптвную вёрстку и кроссбраузерность лучше оставить на совести верстальщиков. пусть они воюют за перфект-пиксель

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

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

Автомобили сейчас строят на платформах. Платформа - это некая параметрическая (или даже непараметрическая) модель с блоками и пределами конфигурации. К ней прилепляют кузов, опции и дальше уже дело маркетологов. Так что я правильно подхожу к строительству автомобилей. Другой вопрос, есть ли качественные платформы. Я думаю, что есть, ведь не одни только хипсторы должны быть в мире. Вопрос - как их найти? Похоже, что популярность - это не критерий.

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

Слушай, ну все видели этот ваш пейсбук, ну сколько можно трындеть то про быстрее. Как видишь угребищное тормознутое нагромождение свистопердящих «компонентов» вместо сайта, сразу ясно - это передовые быдлокодеры внедрили реакт.

Ну, вам виднее же, конечно.

Это я тут веб пишу уже 20 лет. Чего уж мне знать.
Ох, сколько было вас таких.

Тут не пёрфект-пиксель, а тупо меню разворачивается и не сворачивается. Или выпадающая часть выпадает совсем (за пределы экрана, к примеру). Ты клонишь к тому, что в нынешнем мире один человек не может сделать качественный сайт от начала и до конца?

на иммутебельности и подходах мира функционального программирования строятся все эти концепции управленя сложным состоянием, и отображением этого состояния в DOM.

Ммм. А можно мне какие-нибудь другие концепции?

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

Т.е. желание собирать из крупных _работающих_ кусков одинаковое в любой отрасли. Другое дело, если куски на поверку не работают, тогда это и есть слово hipe, от которого хипстер.

Если ты считаешь, что мне нужно забить на реакты и бутстрапы и учить голый js, html, css, то я к этому прислушаюсь со всем вниманием. И кстати, я реакт назвал фреймворком не потому, что я его таковым считаю, а просто потому, что названий слишком много и они все в голове не помещаются.

спасибо за immutable.js, но я, написал нечто подобное на хеш-таблицах, ни на секунду не поверю, что оно прямо такое быстрое и экономное до памяти.

Если ты считаешь, что мне нужно забить на реакты и учить голый js, html, css

Голый JS, HTML и CSS учить, конечно, надо. Не столько ради того, чтобы их использовать, сколько ради того, чтобы понимать, что во что транслирются все крутые фреймворки - примерно так, как для написания нативных программ полезно быть знакомым с «переносимым ассемблером» Си.

ну как, DOM это ж состояние, которое браузер непосредственно рендерит.

Зачем нужно делать свой синтаксис для этого DOM? Например, есть какой-нибудь innerHtml. Мне не нравится то, что react плюётся конструкторами, которые не декларативны, при том, что декларативное описание в виде innerHtml в принципе существует.

Голый JS, HTML и CSS учить, конечно, надо

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

И допустим, я выучил. Мне не нравятся эти фреймворки. Я понял, что популярные != хорошие. А есть ли хорошие фреймворки в природе, вот в чём вопрос?

Хз. Ничего не могу сказать. Как-то больше по JS, хотя и не нравится тоже.

http://vanilla-js.com/

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

И я не говорю о том, что изучать надо со столь низлежащих абстракций как принципы работы микропроцессоров например (хотя полезно). И даже не о преставлении о том, как работают веб-платформы на уровне хранения данных в памяти, jit компиляций\оптимизаций и вот это всего (хотя это еще более полезнее). Нет. Я говорю начать с того необходимого минимума, который касается конкретно окружения, в котором ты собираешься что-то строить. Но, конечно, это все надо если ты хочешь применять инструменты по назначению. И не удивляться чему-либо - потому что на самом деле в каждом из них есть логика и от каждого есть польза, а любое непонимание вытекает именно что от непонимания того, откуда зачем и почему эти инструменты вообще появились.

Учиться html и css - это сравни изучению правописания. Ты можешь декларативно описывать UI хоть на чем. Суть в том, что ты в конечном счете работаешь с конкретными объектными моделями DOM и CSSOM. И моделями построенными поверх них, например, vdom в том же реакте\вью\етк. Чтобы понять, зачем нужен тот же реакт, например, (и нужен ли он, и в каких случаях он действительно нужен, а в каких это будет из пушки по воробьям) следует сначала изучить то, поверх чего он работает. А ведь есть еще нативные концепции веб-компонентов и shadow dom, которые весьма отличаются подходом к разработке, хоть и призваны решать те же вещи.

Прежде чем пытаться с наскоку в двусторонний дата-биндинг, следует изучить работу BOM на примитивном уровне. Событийную его модель. Его нативные объекты. Нативные на том уровне, которые он предоставляет в качестве API. На том уровне, на каком эти кучи API стандартизованы.

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

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

посмотрите на marionettejs. обычный такой себе классический mvc фреймфорк без экзотики. такая себе надстройка над backbone, который надстройка над jQuery.

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

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

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

Суть в том, что ты в конечном счете работаешь с конкретными объектными моделями DOM и CSSOM. И моделями построенными поверх них, например, vdom в том же реакте\вью\етк. Чтобы понять, зачем нужен тот же реакт, например, (и нужен ли он, и в каких случаях он действительно нужен, а в каких это будет из пушки по воробьям) следует сначала изучить то, поверх чего он работает.

Услышал тебя. Буду изучать.

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

Я просто смотрел скринкаст по react, потому что react востребован на рынке труда :)

Зачем нужно делать свой синтаксис для этого DOM?

У DOM вообще нет синтаксиса. Это объектная модель. Живая, объектная модель, в памяти. С объектами, методами, классами, вот этим всем. HTML это лишь один из способ ее сериализации.

Зачем нужно делать свой синтаксис для этого DOM?

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

Например, есть какой-нибудь innerHtml. Мне не нравится то, что react плюётся конструкторами, которые не декларативны, при том, что декларативное описание в виде innerHtml в принципе существует.

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

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

React это даже не фреймворк. Это всего-лишь библиотека.
Чтобы он стал хоть отчасти похожим на фреймворк, к нему надо прикрепить еще несколько компонентнов.

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

Я просто смотрел скринкаст по react, потому что react востребован на рынке труда :)

Сегодня да. Вчера не был. Послезавтра все поменяется. (И вообще уровень популярности чего-либо весьма сомнителен и булшитен - где именно-то , на каком рынке, и куда вы дели тонны легаси в этом своем рынке).

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

Мне не нравится то, что react плюётся конструкторами, которые не декларативны, при том, что декларативное описание в виде innerHtml в принципе существует.

Может тебе нужен просто шаблонизатор на клиенте. Handlebars емнип не сильно жирный, попробуй. А логику пиши сам на ванильном JS, ты же не безрукий инвалид. Мало что ли API в браузерах? Как по мне так слишком даже много. Зачем еще какие-то мутные прокладки?

marionettejs

Не соглашусь, что рынок шире. В России 2 вакансии по данным rabota.yandex.ru, против более чем 100 по react.

HTML это лишь один из способ ее сериализации.

Применимый по умолчанию и случайно являющийся форматом для html по умолчанию. Что делает его заметно более удобным, чем альтернативы, при прочих равных.

значит окончательно отходит классика )

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

Ага, и наверняка считается, что дебаг в норме не нужен. Но мне будет трудно поверить, что это так :)

на каком рынке, и куда вы дели тонны легаси в этом своем рынке

rabota.yandex.ru - правда, он глючит, цифры по разным запросам не сходятся. Обещали починить.

Если ты хочешь строить сразу из кирпичиков, не вдаваясь в сути.

Я хочу: начать зарабатывать быстро. Чтобы через время мои знания не обезценились. Со временем хочу зарабатывать много. Из кирпичиков, из блоков или из навоза с соломой - вопрос второстепенный.

Почему здесь ангуляр и реакт стоят рядом? Причём, блин, уровень удовлетворённости реактом высок, а ангуляром - не очень.

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

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

CustomElements. В HTML сегодня теги вида <this-is-my-supe-button> и <my-super-widget> вполне валидны. Что ты хочешь изучать в HTML в 2018 году, когда его задача лишь описать DOM модель, а не как было 15 лет назад, когда от того, как правильно и валидно будет написан html зависело на 99% верное отображение и поведение. Сегодня отображение и поведение уже не на плечах браузера, а на плечах программистов. На стандартных встроенных вижетах ты никуда не уедешь. Даже уже стандартные инпуты зачастую не используют, а делают поля ввода из обычных элементов. Иногда вовсе отрисовывают их на канвасе (если говорить например о текстовых процессорах, или редакторах).

Спасибо!

Это прикол, чувак. Но в каждой шутке как говорится.

Я понял, что это. Там бенчмарки однако есть.

Ну и к слову, как по мне, программисту с большим опытом, особенно опытом работы в системах с живыми объектами, где repl-driven-development - изучать веб должно быть проще простого. А все эти концепции объектных моделей на уровне азов вполне понимаются очень быстро, а дальше только их вариации - со справочником всегда под рукой никаких проблем быть не должно. Ну, а уж понять примитивнейший эвент-луп и ассинхронщину, если ты писал ГУЙ то вовсе должно быть проще простого.

Многим сложнее для людей которые приходят из статических языков, из языков с парадигмами структурного программирования. Из языков где первоочередное это IDE и компилятор бьющий по рукам.

Я не делю программистов\ людей на правильных и неправильных. И языков не делю. И сам пишу помимо веба на сишечке, go и иногда на java. Просто веб люблю больше всего. За его динамичность и за то, что он живой. Сильно жалею, что когда было можно, веб-девелопмент не пошел по пути smalltalk-систем. Потому как считаю, то его разработка должна быть именно в такой парадигме. А концепция файлов, модулей, компиляции, и вот этого всего - лишь вносит путаницу - многие пытаются подходы привычных им сфер перекладывать сюда, а здесь все иначе.

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

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