Философия о будущем веба

Ну да, нужно ставить Линейку и миркоГ

То есть пердолиться, а там аппарат просто работает 7 лет.

Если бы ты видел что там в кишках этого монстра от яндекса… они такого франкенштейна собрали с телеметрией, что он и на 8-ом айфоне не особо то и шустр, там просто ад в 600 слоёв из либ, и куча разных команд собирает это по 14 минут на своих nvme ssd маках про, можешь представить что там внутри живёт

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

Читаю на форуме:

можешь представить что там внутри живёт

Рядом кто-то: смотрит «Годзиллу 2».

Видимо, вот так и выглядит))

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

Прикол в том, что на ассемблере приходится писать как раз жоэсерам. Вместо декларативного описания у них дебри лапшекода. И уже поверх этой лапши переизобретается декларативное представление. То есть там уже 10 слоёв абстракций, чтобы выплюнуть немножко текста и обработать события от трёх кнопок.

Мне иногда кажется, что его пишут какие-то вояки, которым слово оптимизация только на плакатах грозит

Видел бы ты, как разрабатываются ячейки КТПУ для газпромовских вышек…

Ну, надо же как-то зарплату в 200 штук обосновать

Расскажи, очень интересно. Это типа будок навроде тех, что возле мачт опсосов? Тоже попилы или старые пердуны с засаленными руками командуют студентами?

Нет, это грядки высоковольтных ячеек наподобие вот этих. Да так же, как ты и описал. «Сроки сжаты, надо хреначить» во все поля, специалисты уровня «Ы А ЧО ЭТО?», собирают криворукие ребята, не умеющие в чертежи.

Это без гаппсов

С ними, только pico.

Насколько старых?

Примерно год твоего айфона +/-

там уже 10 слоёв абстракций

весь остальной текст я проигнорирую как просто твои фантазии не относящиеся к реальности, но вот про какое-то количество слоёв абстракции, у меня вопрос - ну и чё в этом такого? ну N-слоёв и чё?

Я про оффициальные.

Не слушай никого.

Отдавай для своей сложной админки статическую HTML/CSS морду, а загрузку данных в её поля и действия с ними напиши на plain JS если нужно и только там где действительно нужно. Серваку надо будет отдавать либо статику, либо JSON с данными в качестве ответов на XHR так что нагрузка на сервак будет минимизирована. И в браузере не будет крутиться 100500 мегабайт фреймворка, так что и на браузер нагрузки не будет.

Фреймворки приходят и уходят, завтра вообще сдохнет jQuery какой и всё. А plain JS/HTML/CSS никуда не денутся. И всегда найдётся кто-то кто в этом разберётся, в отличии от фреймворка который был когда-то модным, а теперь стал говном мамонта и спецов по нему вообще нет.

Особенно если тебе надо морду написать, чтобы было просто и работало, а не «использовать фреймворк»

То есть…. ОН. ГЕНЕРИТ. ХТМЛ. ИЗ. СКРИПТА.

А почему собственно и нет? Сейчас появилась куча возможностей, можно делать как удобно

• Можно как деды CGI писать.
• Можно написать серверное приложение и отдавать из него HTML’ки из шаблонов как отцы.
  • Можно скомпилить шаблоны в код. Обычно так и делают, это тупо быстрее и меньше ресурсов ест чем каждый раз разбирать шаблон.
  • Можно собирать HTML’ки сразу в коде. Это удобнее когда шаблонного кода у тебя больше чем собственно HTML. Или там для генерации svg.
• Можно из приложения отдавать статическую станичку и js который сам всё отрисует на клиенте.
  • Всё то же самое, но шаблоны у нас на клиенте. Они тоже разные, может быть классический {% for link in links %}<a href="{{ link }}'>, может быть а-ля vue <a v-for="link in links">, может быть на чистом js for (link in links) { $('<a>') }, можно чистый js скомпилить из шаблонов.
• То же самое, но сразу и на клиенте и сервере

Разные подходы удобнее в разных случаях, у всех свои трефдоффы. Я сторонник server-side, но удобство клиентских фреймворков прекрасно понимаю. Меня от их использования сдерживает главным образом конченая ублюдская экосистема npm и необходимость усложнения для поддержки поисковиков.

Вангую, что все это весит в разы больше голого хтмла и жрет дофига ресурсов.

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

но зачем это все для простейших действий?

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

Лучше взять айфон про макс за 130к

я брал за 120, подорожали чтоли?

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

1. Systems approach
2. Cynefin framework
3. VPEC-T

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

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

Фреймворки приходят и уходят, завтра вообще сдохнет jQuery какой и всё.

• jQuery не фреймворк.
• jQuery тащил совместимость с кучей кривых браузеров еще до того, как некоторые из местных посетителей научились ходить. И не сдох.
• Фиг ли он сдохнет, из браузеров никто совместимость со старыми версиями JS не выкидывает и API не ломает.

В общем, стыдно должно быть с такими аргументами и незнанием матчасти.

jQuery не фреймворк.

Да неужели. И чем же он не фреймворк? Чего в нём нету такого, что есть в других «фреймворках»?

Фиг ли он сдохнет, из браузеров никто совместимость со старыми версиями JS не выкидывает и API не ломает.

А при чём тут это? Вот завтра решит гугель что jQuery deprecated и всё. А большинство его использующих тащат jquery.js именно с гугля, как обезьяны.

Так что сдохнуть оно может вообще в любую секунду.

В общем, стыдно должно быть с такими аргументами и незнанием матчасти.

Это да. Стыдитесь.

И чем же он не фреймворк?

Тем, что он библиотека.

Вот завтра решит гугель что jQuery deprecated и всё. А большинство его использующих тащат jquery.js именно с гугля, как обезьяны.

Гугл у нас теперь отвечает за доставку jquery.js. Какая божественная аналитика про большинство сайтов! Чо-т ржу в голосину.

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

Почитай про отличия моделей MVVM и MVC. Они могут разными умными словами называться, но эти точно найдешь. Суть в том, что модели данных для бизнес-логики и презентации - разные (ну кроме совсем вырожденных случаев).

в 10 полезных минутах он… Генерит обычный хтмл из скрипта. То есть…. ОН. ГЕНЕРИТ. ХТМЛ. ИЗ. СКРИПТА.

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

Первый ARM процессор появился в 1985 году и яббл к этому никакого отношения не имеет

Тем, что он библиотека.

Да неужели. А библиотека не может быть одновременно и фреймворком? Это вас так в вебошлёпном ПТУ учат?

Гугл у нас теперь отвечает за доставку jquery.js.

Вообще-то да. Редкий павиан догадается раздавать jquery.js со своего сервака.

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

Именно. Святой вуй, блогочестивый ангуляр и прочие причисленные к сонму фреймворков. Не использовать всё это тормозное и тупорылое говнище - аццкий грех. Прям секта какая-то.

Первый раз прогружается вся хреномундия

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

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

С нагрузкой сервера не связано. Имеет смысл если у тебя интерактив.

Если юзер просто пришел, загрузил единственную страницу и ушел - смысла нет.

Грузи сначала html с css, потом скрипты. Делать через жопу никто ведь не заставляет.

а больше пушка похожа на водяной пистолет

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

я уже на опеннете побугуртил по этому поводу:

на кой чёрт мне сип и webrtc в браузере?
на кой чёрт я должен страдать из-за ретардов, которые не могут в установку отдельного мультимедийного ПО?
причем страдать не по каким то там идейным показателям жора озу/цпу, а по вполне реальным тестам безопасности.
почему браузеры равняются на дебилов?

https://www.opennet.ru/opennews/art.shtml?num=54480

https://ru.wikipedia.org/wiki/%D0%A4%D1%80%D0%B5%D0%B9%D0%BC%D0%B2%D0%BE%D1%80%D0%BA

нужно принудительно перезагружать страницу ожидая по минуте когда весь шлак прогрузится заново

Ну ты кэш-то в браузере включи, не искушай судьбину.

Тут как раз наоборот зачастую кэш и есть источник проблемы. Только Ctrl+F5, только хардкор.

завтра вообще сдохнет jQuery

Конкретно на это я бы не рассчитывал :D

Могу привести пример – сайт-читалка электронных книг.

Весь сайт в собранном виде это два файла – index.html и sw.js на 25кб gzip суммарно (preact+purecss+мой говнокод, скорее всего станет чуть тяжелее – не весь функционал запилен).

Лежать может это фигня где угодно, оно статичное.

Для работоспособности этой штуки достаточно чтоб юзер зашёл на сайт один раз.

Дальше эта фигня работает как PWA, способна работать без интернета благодаря ServiceWorker. Локальные копии и автообновление по списку имеющихся адресов в наличии, в комплекте с обходом блокировок.

Планируемый сервер-сайд – рой копеечных говноВПС, в том числе находящихся за NAT’ом лишь бы хоть один порт был открыт. Серверную часть лабаю на гулаге, там пилить дольше.

В теории такая фигня не будет бояться ничего кроме полного вырубания внешнего инета, и то – я начинаю посматривать в сторону webrtc и p2p связи.

Имеющийся в данный момент функционал легко можно сделать сервер-сайд, но… зачем?

Веб уже не для чтения текста, веб – платформа для приложений. Я ждю когда вместо всей этой фигни с разметкой, стилями и скриптами будут загружать васм-бинарник и давать ему доступ к набору api для взаимодействия с устройством и пользователем чтоб тот уже сам рисовал себе какой хочет интерфейс.

Грузи сначала html с css, потом скрипты. Делать через жопу никто ведь не заставляет.

Так оно и делается в стандартном серверном варианте. Вот только зачем ещё грузить лишние скрипты для генерации страниц в браузере? Сам html-код – мелочь по сравнению с контентом. А контент так или иначе придётся тянуть с сервера. В чём профит?

Сам html-код – мелочь по сравнению с контентом. А контент так или иначе придётся тянуть с сервера. В чём профит?

Так интерактив же. Не всем нравится, когда поставленный лайк приводит к полной перезагрузке страницы со всем гоконтентом. И не всем нравится этот интерактив (которого неизбежно будет становиться все больше, все шире и все развесистее) запиливать и поддерживать в режиме мясорубки.

А чем твоя поделка отличается от обычной читалки разпостраняемой через репы дистрибутива? Вместо условной убунты у тебя браузер, вместо штатного ПМ у тебя свой велосипед, вместо репы у тебя снова свой велосипед. В вебе одни веломастера.

Да, да. Щас бы римлянам рассуждать об перспективах ренессанса (с)

Профит во ВТОРОМ шаге (и последующих). Это называется интерактивность. Я выше про это уже написал, и про MVVM.

Если тебе интерактивность особо не нужна - можно и не заморачиваться.

Так интерактив же. Не всем нравится, когда поставленный лайк приводит к полной перезагрузке страницы со всем гоконтентом

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

С этим могу согласиться. Хотя ведь интерактивность интерактивности – рознь. По сути всё это нужно в случае частых малых изменений в больших объёмах данных.

на странице с бесконечной прокруткой

Нах-нах

Тем, что это читалка и одновременно онлайн-библиотека?

По сути всё это нужно в случае частых малых изменений в больших объёмах данных.

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

И модели данных у рисовалок совершенно не такие как у бизнес-логики сервера.

Короче, суть именно в продвинутой интерактивности. Когда надо делать хитровымудренные интерфейсы.

Мимо. Большинство читалок поддерживают стандартный формат онлайн библиотек.

В админке буквально несколько кнопочек

Wrong way

В конфиге буквально несколько строчек

Unix way

Да уже давно всё движется к сиськам-писькам и порно-траффику через сети Илона Маска 🤣

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

Короче, суть именно в продвинутой интерактивности

Да чего распинаться, понятно что тут мало кто делал

сложные админки

иначе этих вопросов бы не было.