Comments 117
Это человеческое эго умирает потихоньку (контроль над чем-то) вот и появляются такие статьи, попытка вернуть "былое". Свойственное "старикам". То есть умирание Эго неизбежно, мудрые мира сего об этом знают, и 2017 лет назад дал наставление — "не ищи земных сокровищь, где моль и ржа все съедает, а ищи сокровищь на небесах" — не дословная цитата, которая говорит, что всё чтобы не изучил человек — потеряет, в том числе и свои заслуги 15 летней давности превратятся в труху. Всегда придут молодые, амбициозные которым описанные сложности в статье не кажутся таковыми, но их сиенит другое поколение и так в бесконечном цикле, старшее поколение будет жаловаться на молодое, дескать "а вот у нас такого небыло". ))) вообщем, потерять и не угнаться за знанием и опытом — это условия жизни и их не изменить.
Статья точно отражает моё отношение к современным подходам к разработке веб-сайтов. Для меня идеалом того, как нужно начинать проект, всегда остаётся ASP.Net MVC 5 в Visual Studio. Т.е. ты запускаешь VS, нажимаешь «Create Project», выбираешь тип проекта, нажимаешь кнопку «Run» и оно работает… Не нужно устанавливать Node.js чтобы на ней запустить трансляторы, сборщики и прочий мусор. Это мусор, потому что не приносит в проект значительной пользы… Всё то, что вы делаете с этими инструментами можно отлично сделать на чистом JS+CSS3+HTML5. Да, пропадёт синтаксический сахар последних версий JS, не будет типов из TS, чуть сложнее работать с CSS без SCSS и иже с ними… Но сколько усилий тратится для разворачивания рабочей среды! Сколько усилий тратится на отладку после всех этих преобразований! Мне кажется что сейчас искуственно повышают порог входа в программирование, чтобы сохранить образ профессии для избранных. От того и все эти консольные инструменты и зоопарк необходимых утилит.
А потом вас просят поправить строчку в CSS и переделпоить ваш милый монолит. И вот уже идет 15 минута в VSTS, который сначало мило скачал весь ваш проект из source control, потом восстановил все ваши Nuget пакеты (а cache у вас не заработал), после чего сделать билд вашего солюшена (все проекты, конечно, но вы поставили флаг
/maxcpucount:3 для ускорения), запустил все тесты (dotnet, если что)).А вам нужно было только строчку в CSS обновить :)
Нужно понимать о каких масштабах идет речь: в каких-то случаях такой подход оправдан. В большинстве — нет.
Плюс если проект хоть раз уже был собран — то его исходники уже есть, все nuget-пакеты тоже лежат на месте. Да и проекты вообще собирать не нужно — бинарники же свежие.
Использование ASP.Net MVC не предполагает монолитной архитектуры. Можно даже микросервисы с помощью WebAPI реализовать. И пересборка не нужна, т.к. не было изменений в .Net файлах.
Не то что-бы я был с вами несогласен, но сменить строчку в цсс может занять дни пока решение пройдет через всех заинтересованых лиц. Не считаю что время на деплой это сколько нибудь важная деталь. Главное что-бы одной кнопкой сделать можно было.
Не надо обновлять фреймворки из-за найденных дыр
Как будто если написать свой велосипед вместо фреймворка, то дыр в нем не будет...
Будут, но:
- свой велосипед пишется не супер-универсальным, а с конкретным функционалом. Это уже уменьшает число возможных дыр. Не поддерживает форма эмодзи — и не надо, зато нет дыр, связанных с эмодзи.
- закрытый код ломать сложно, если разработчик не совсем идиот.
- ломать один сайт вручную намного менее интересно, чем сломать общий движок для миллиона сайтов. Поэтому срабатывает принцип "неуловимого Джо".
Поэтому сайт на своем примитивном движке может прожить 10 лет без обновлений, а к Joomla и Drupal каким-нибудь лучше ставить обновления сразу же. И после этого смотреть, не сломали ли эти обновления что-нибудь. Не забыв взять денег с клиента за поддержку сайта в течение тех же 10 лет, и забыв прописать штрафы, на случай если движок таки взломают.
Я не против утилит вроде Node, Gulp и прочего, я за то, чтобы они были интегрированы в удобную среду разработки и чтобы для программиста это было не головной болью, а также просто, как нажать кнопку «Run»
Вы сами себе противоречите.
Нет, не противоречу.
Если Gulp, Node и т.д. являются частью удобного ПО для разработке, которое можно поставить из коробки и не париться с конфигурированием, то от этих инструментов есть толк.
Но я против них как отдельных утилит, из-за которых разворачивание рабочего окружения превращается в боль. При том, что и без них можно создавать неплохие продукты, а многие из ставят не осознавая назначение и практически не используюя преимуществ, которые они дают.
Вообще было бы классно увидеть, к примеру, «NodeIDE», при установке которой ставится весь зоопарк и, к примеру, создание и первый запуск Angular5 проекта правратилось бы в New Project => Angular5 => поставить галочки рядом с TypeScript, Gulp => Прописать путь к Git => Run => Приложение запущено и работает
По поводу новых фич в C# — они не усложняют, а упрощают разработку и к тому же никто не заставляет их использовать…
Так Webstorm, например, подходит под ваше определение NodeIDE. И проект на Angular там можно создать, почти не покидая GUI.
Но это уже дополнительные обертки. Всю работу в любом случае выполняют программы в коммандной строке.
именно потому что у нас есть отдельные утилиты все так хорошо развивается
а не монструозный msbuild который только с ГУИ можно сконфигурировать
монструозный msbuild который только с ГУИ можно сконфигурировать
Это что, юмор такой?
По монструозности. Сейчас весь бойлерплейт в виде настроек под две конфигурации (release/debug) вынесли в sdk, а студию научили не сходить с ума от <Compile Include="**/*.cs"/>. В итоге дефолтный файл проекта ужался до меньше чем до десятка строк.
Если интереесно, то я, что называется, на пальцах, объяснял, как оно работает.
Конечно, лень. Хотел бы учить консоль — учил бы консоль, а не Photoshop/Illustrator/InDesign/Premiere/Dreamweaver/Flash.
Это другая сторона, другой подход к созданию сайтов — со стороны дизайна, а не программирования.
Вопрос лишь в том, насколько вам всё это необходимо для разработки. У меня в браузере стоит инструмент разработчика для Angular, который светит сайты с Ангулар и он в последнее время срабатывает даже на лендинг страницы. То есть, какой-то извращенец сделал лендинг страницу на Ангулар, и скорее всего лишь для установки формы отправки сообщений или что-то вроде того.
Тут суть в чём. Мелкомягкие сделали мощную и расширяемую систему сборки (msbuild) которой 95% C# разработчиков пользуются вообще не подозревая о её существовании. Для них смена настроек или добавление этапа сборки выглядит как "поставил галочку в студии" или "установил нугет-пакет ткнув мышкой в студии". Авторы расширений сборки в виде нугет-пакетов обычно поставляют расширение к самой студии для редактирования настроек. Не нужно иметь никаких знаний о том, как всё внутри работает, ибо работает оно из коробки.
В случае с нодой и gulp/bower всё в точности наоборот. Отсюда некоторая фрустрация при их использовании.
трансляторы, сборщики и прочий мусор. Это мусор, потому что не приносит в проект значительной пользы…
Сложно сказать, это троллинг такой или заявление всерьёз
npm install
npm build
npm run
Вам бы кнопочки тыкать :)
Ну это обычная "боль" старичков. Если признаться честно самому себе, то мы (люди) не хотим терять того, что достигли, а когда теряем — вот тут и начинается нытьё )) а теряют все и это будет всегда, таково условие жизни. Человек описал свою боль, что 15 лет назад он был "на коне", а щас у руин своих знаний и опыта )) это неизбежно для каждого из нас. Для молодых, амбициозных людей, уверен, описанные сложности вовсе так не кажутся. С вашим комментарием согласен.
Понятно, что плюсов появления того же вью очень много. Но проблема не во вью с реактами а в том, что это все развивается безконтрольно и совершенно враздрай. Чем хорош бакенд? тем что все развивается согласно каким-то логичным и понятным принципам. В фронтенде все далеко не так очевидно… И это, на данный момент, печально.
Кроме того — как он делает ошибку «старичка» — вы делаете такую же ошибку молодости, которая верит, что она всемогуща, времени много вагонов и уж вы-то огого… Не поверите как быстро бегут года. И если мне в 46 интересно ковыряться с новыми фишками фронтенда как хобби, то многие ли готовы участвовать в (на данный момент) совершенно безумной гонке?
Миру фронтенда необходим какой-то центр. Который будет если не ограничивать, то хотябы направлять чтобы все шли в что-то стройное. Вот неплохой пример в сторону — .net core — развивается, выглядит как сказка, писать приятно и т.п. Там тоже есть свои тонкости с обновлениями, но с каждой версией все становится стройнее и приятнее… (имхо)
Понял так, как Вы сформулировали — "Он о том, что в мире фронтенда опыт больше ничего не значит".
Ну я не верю в молодость, я чуть младше Вас и наблюдаю за собой, что не угнаться за молодежью и нельзя остаться на том же уровне, чем занимался n лет назад. Это не только касается ИТ, возьмите тех же актеров, как они умирают невостребованными.
Если положить руку на сердце, то фронтэндом тут только не ограничишься. Какова значимость опыта в Delphi, Visual Basic, windows XP, что там еще было? Да поглядите на архитектуру ЦПУ, ядра ОС (linux), библиотеки и тд. Опыт 10 летней давности сегодня превратился в тыкву. Всегда надо бежать "на острие атаки", а это в 40 нереально в силу объективности, силы к нам не приходят, но явно уходят.
А как можно "центровать" фронтенд? Это же не один язык, но и разметки, фрэймворки, движки всякие. Как эти сущности можно слить в одну экосистему типа Net core (я только догадываюсь, что это)? Это изобрести принципиально новый вэб?
Чем хорош бакенд? тем что все развивается согласно каким-то логичным и понятным принципам.
Не всегда это конечно верно. "Тучи" пайтон библиотек, например, в асинхронщине для веба уже говорят об сложности контролирования процессов. Один из последних докладов moscowPython по asyncio об этом говорит, что стало много всего, что страшно всё это эксплуатировать в продакшене, нереально понимать, что происходит на самом деле.
И вот там, в бекенде, — конкуренция экосистем, каждая из которых рождает какие-то решения, неудачные хоронят, удачные перенимаются. При этом есть такие, которые растут по воле одного «визионера», есть катящиеся по воле сообщества. Но, самое главное — там есть выбор.
На фронте же вы прибиты в html-css-js. Их можно ругать, а можно любить. Но даже самый ярый фанат при наличии сколько-нибудь критического мышления назовет пару-тройку явных неприятных недостатков этих технологий. На бэке, если недостатки для вас критичны, вы просто выбираете другой стек, где недостатки менее критичны. На фронте вам остается только смириться. У вас, фактически, нет другого стека.
Вы можете говорить про angular, react и прочее и прочее, но все они, в конечном итоге, транслируются на выходе ровно в то, что умеет браузер. Они не решают эти проблемы, трансляцией невозможно решить концептуальную проблему того, во что вы транслируете. Получается, что все эти платформы — это «workaround» над проблемой. Способ обойти. При этом — автоматизированный способ обхода… А мы все знаем, что именно такая неявная автоматизация может достаточно больно бить по лбу.
Если в вашем тексте заменить "бэкенд" на "фронтенд" и vice versa, то смысл вообще нисколько не поменяется:
Мне кажется, как бы ни парадоксально это звучало, преимущество «фронтенд»-технологических стеков именно в их разнообразии. Не подходит Angular? Можно React использовать. Проблемы с Vue? Есть Ember. И вот там, во фронтенде, — конкуренция экосистем…
На беке же вы прибиты к JSON, HTTP, SQL. Их можно ругать, а можно любить. Но даже самый ярый фанат при наличии сколько-нибудь критического мышления назовет пару-тройку явных неприятных недостатков этих технологий. [...] У вас, фактически, нет другого стека. Вы можете говорить про JSON и HTTP и прочее и прочее, но все они, в конечном итоге, транслируются на выходе ровно в то, что умеет веб-сервер. Получается, что все эти платформы — это «workaround» над проблемой.
>> На беке же вы прибиты к JSON, HTTP, SQL.
Вы же фронтендер, да? Вы вот реально уверены, что на бэке без SQL никуда? Вы реально считаете, что HTTP — это ограничение именно бэка? Что оно не со стороны фронта ограничение? Вы реально считаете, что форматов обмена, кроме JSON, нету? И вы твердо уверены, что текстовый обмен — это ограничение именно бэка?
>> в конечном итоге, транслируются на выходе ровно в то, что умеет веб-сервер.
Ну, т.е. во что угодно, что в принципе может исполнить компьютер? Вы же понимаете, что тут «умелок» несколько больше?
Вот, ИМХО, где-то на этом месте и произошла небольшая локальная катастрофа. «Становится понятно, что веб-платформа обладает довольно мощным потенциалом для реализации сложных интерфейсов. » При этом сама платформа остается связкой «языка разметки гипертекста», «каскадных таблиц стилей» и прикрученных сильно сбоку скриптов, чтобы все это выглядело как «реализация сложных интерфейсов».
Т.е. интерфейсы стали лепить на том, что предназначено для гипертекста. Смогли? Да. Гениально? Да. Удачно получилось? Спорно.
В проектировании интерфейсов, как ни странно, отлично «заходит» ООП-подход. Вся вот эта «инкапсуляция», «полиморфизмы эти ваши» и т.д. Реально просто хорошо все это ложится «в логику». А в существующей реализации инкапсуляция невозможна, попытки родить абстракции «текут», любая связность — эмуляция, полиморфизм реализуется кодогенерацией…
Мне вот реально кажется, что текущий подход к проектированию веб-интерфейсов, мягко говоря, неидеален. Можно было на отметке «стало понятно» чуть-чуть притормозить, обдумать хорошо и сделать «правильно».
Но, момент упущен…
Для «инкапсуляции представления» мы создаем параллельный DOM. Оно же так работает? Т.е. для того, чтобы оно было как-то «инкапсулировано», мы делаем копию содержимого элемента в стороне и как-то связываем это с происходящим на странице. А дальше мы берем какой-нибудь узел, пишем ему в контент «А», а в shadowDOM — «Б». Вуаля, у нас html-исходник показывает «А», а на странице мы видим «Б». И для того, чтобы понять, почему и что происходит, вам нужно знать, как все это устроено. Мне кажется, абстракция слегка «подтекает».
«Типобезопасность», всяческие TypeScript и т.д. — на выходе транслируются в js, который про всю эту кухню, мягко выражаясь, не в курсе. Т.е. локально на вашей машине с контролируемыми вами же входными данными — все ок, и TS реально полезен. При этом в реальности эта вещь теряет половину своих умелок на этапе трансляции. Мне вот лично не нравится, что часть семантики моего кода где-то по пути к исполнению «выпадает».
Внутри веб-стека достаточно много странностей, это, надеюсь, вы отрицать не будете? Не поймите меня превратно, я не осуждаю людей, которые все это изобрели, они делают реально крутые вещи. Просто местами создается ощущение, что эти самые вещи им приходится лепить из г-на и палок. И многие вещи в вебе, которые мне трудно принять, просто не имеют другого решения в текущих реалиях. А реалии таковы, что на связке из языка-для-разметки-гипертекста + каскадных-таблиц-стилей + не самого удачного скриптового языка усиленно рождается система построения интерфейсов. «Рынок» хочет «уже сейчас», и поэтому вся эта система обрастает все новыми и новыми решениями, причем каждое рождается вне всякой связи с параллельными, а «абстракции текут»…
На выходе мы имеем по 4-10 решений на каждый случай жизни, и при этом каждое «не без недостатка». Может, все же был смысл на определенном этапе, когда веб-интерфейсы стали реально востребованными, попробовать не надстраивать все это над разметкой гипертекста и инструментом для стилизации оного же, а спроектировать язык построения интерфейсов?
То что при трансляции «выпадают» особенности языка — это тоже нормально. Знаете ли — при компиляции С++ в машинный код точно так же пропадают модификаторы доступа, но это почему-то ничего не расстраивает.
Нет, подтекающая абстракция — это когда что-то работает не так как утверждалось.
Давайте не будем подменять устоявшуюся терминологию своими субъективными представлениями.
«leaky abstraction» — термин, популяризованный Джоелом Спольски. Традиционно переводится как «протекающая» или «дырявая» абстракция.
Вот здесь, например, можно ознакомиться с формулировкой понятия и историей возникновения термина.
Фактически — это абстракция, не абстрагирующая деталей реализации, которые призвана абстрагировать.
А ваше «когда что-то работает не так как утверждалось» — это таки баг, косяк реализации и много еще чего, но точно не она.
Например, сообщение теряется в канале с гарантированной доставкой потому что канала больше нет.
Прямо мимо, этот случай к протекающей абстракции не имеет отношения от слова «никак».
А когда «вам нужно знать, как все это устроено» — это просто любопытство.
Разница в мотивации. Узнать детали реализации, потому что интересно — это любопытство. Узнать детали реализации, потому что без них не работает — дырявая абстракция. «Почувствуйте разницу».
при компиляции С++ в машинный код точно так же пропадают модификаторы доступа
Вы же понимаете, что компиляция С++ в машинный код, который исполняется «как есть» уже на целевой платформе — вещь несколько более предсказуемая, чем «машинный перевод» одного языка в другой, за которым следует трансляция в следующий язык по цепочке. Попробуйте в гуглотранслейте перевести пару предложений с русского на церковнославянский, оттуда на староанглийский, а затем снова на русский, и посмотрите на результат. Я знаю, что набор лексем в языках программирования несколько победнее, да и правила попримитивнее, но ассоциация, в целом, верная.
Давайте не будем подменять устоявшуюся терминологию своими субъективными представлениями… Фактически — это абстракция, не абстрагирующая деталей реализации, которые призвана абстрагировать.
Давайте! Так вот: абстракция ShadowDOM работает. При помощи ShadowDOM мы заменили отображение тэга, теперь он показывает "B" независимо от своего содержимого. Не вижу никакого противоречия. И не вижу зачем тут нужно обязательно знать детали реализации.
Вы же понимаете, что компиляция С++ в машинный код, который исполняется «как есть» уже на целевой платформе — вещь несколько более предсказуемая, чем «машинный перевод» одного языка в другой, за которым следует трансляция в следующий язык по цепочке.
Нет, не понимаю. В отличии от машинного перевода между естественными языками, трансляция программ — процесс точный, и от количества слоев поведение программы не зависит.
теперь он показывает «B» независимо от своего содержимого.
Т.е. вместо того, чтобы абстрагироваться от реализации, мы абстрагировались от содержимого, и у нас все «Ок»?
не вижу зачем тут нужно обязательно знать детали реализации.
Ну т.е. я захожу на страницу, вижу надпись «Василий». Смотрю в html страницы, вижу там «Павел». Еще раз смотрю на саму страницу… И действительно, зачем мне детали?
Не вижу никакого противоречия.
Давайте попробуем увидеть.
У нас есть семантическая верстка (классика html + css, контент отдельно, представление отдельно, и все это поверх общего дерева объектов). На этом уровне абстракции мы не можем инкапсулировать в одном объекте и данные, и их представление.
Появляется надобность инкапсуляции данных+представления на уровне отдельного объекта. И мы пилим сущность сбоку, которая фактически тупо перекрывает селекторы первой на процессе рендеринга.
На выходе мы имеем два интерфейса работы с семантикой документа и его отображением, при этом теряем возможность «в лоб» отследить связность данные-представление, т.к. у нас появился перекрывающий слой (заметьте, не абстрагирующий, а перекрывающий). При этом на уровне ShadowDOM один хрен сохраняется наследование стилей из первой иерархии. Т.е. «классический» DOM косвенно влияет на представление ShadowDOM, а shadow частично перекрывает селекторы классического.
Осталось понять, нет ли смысла, случаем, проанализировать ситуацию, и отказаться от одной из иерархий, или, например, полностью абстрагировать одну из них другой…
от количества слоев поведение программы не зависит.
Вот это, простите, в идеальном мире происходит. Не в нашем.
Если взглянуть на тот же C++, поведение программы может зависеть не только от количества слоев, но и от вполне себе реальной аппаратной платформы, на которой программа исполняется. Для абстракции от, хотя бы, аппаратной реализации, например, целый LLVM пилят.
трансляция программ — процесс точный
«Точность» трансляции (причем относительная или приемлемая), может быть достигнута только на комбинации определенных языковых подмножеств. Прежде чем так безапелляционно утверждать про «точность», для начала представьте трансляцию по цепочке, допустим, C++ => Java => C. Попробуйте оттранслировать и сравнить набор инструкций на выходе.
И не говорите, что в связке веб-языков эта проблема неактуальна. Иначе для чего, по аналогии с LLVM, нынче WebAssembly пилят?
Я в ситуации с ShadowDOM вижу только одну проблему — вы зачем-то полезли смотреть HTML-разметку страницы.
Если взглянуть на тот же C++, поведение программы может зависеть не только от количества слоев, но и от вполне себе реальной аппаратной платформы, на которой программа исполняется.
Поведение корректной программы — нет, зависеть не может.
Иначе для чего, по аналогии с LLVM, нынче WebAssembly пилят?
Для скорости же.
вы зачем-то полезли смотреть HTML-разметку страницы.
На самом деле, мотивация может быть разная, от «посмотреть, что там на самом деле получается» и «разобраться, почему мне макет рас****ло на 4 экрана», до «распарсить новостные статьи с N сайтов и отобразить в красивом единообразном аггрегаторе». Меня вот удивляет то, что вы не видите причин полезть смотреть разметку страницы.
Поведение корректной программы — нет, зависеть не может.
Категорично, задорно, по юношески, не верно.
Во-вторых, лично я уже много лет не смотрю в HTML-разметку: она стала бесполезна с широким распространением AJAX. Вместо этого я смотрю в дерево DOM при помощи инструментов разработчика Chrome. Там, кстати, ShadowDOM как раз показывается.
Во-первых, абстракция — это не про удобство отладки или парсинга, а про проектирование программы./blockquote>
Точно, и изоляция — это не про сокрытие данных от «вероятного противника», а про сокрытие деталей реализации нижележащего слоя абстракции.
Да, абстракции, обычно, образовывают «слои», т.е. есть «нижний» слой, и «верхний», как правило, над ним, не сбоку. А изоляция — это инструмент, и метрика, если хотите, абстракции. Если сквозь «верхний» слой видно, что лежит «внизу», абстракция «течет», если сверху самого низа не видно — абстракция хорошая.
Ваши примеры того как у вас не получается достать из разметки то, что реально показывается пользователю («B»), как раз и демонстрируют отсутствие протечек в абстракции: процесс отображения надежно заабстрагирован и не виден снаружи.
Ага, со стороны оно выглядит, как модель-представление. На поверку — модель-модель. Скопировать кусок данных — одно из самых хреновых решений. Вопрос представления, как правило, сильно проще вопроса двусторонней синхронизации…
В общем, один вопрос:
Есть DOM, есть Shadow DOM, две абстракции. Какой из этих слоев сверху?
И разработчикам компиляторов иногда приходится это «протечки» патчить.
Вот тут и разница в разработчиках. Одни чинят и патчат, другие говорят «мне норм».
Разработчики фреймворков знают о «протечках» в браузерах. И тоже патчат.
Я, собственно, товарищу mayorovp просто говорю, что «абстракция течёт». Причем проблема ее, в первую очередь, растет из того, что сама она построена поверх другой не самой удачной абстракции. Ну и до кучи, я говорю, что на определенном этапе (например, на этапе перехода от гипертекста к интерфейсам) стоило/стоит подумать о том, что иерархию абстракций, возможно, можно сделать лучше, переработать, причем начиная с уровня «пониже». Вероятно, это могло бы пойти всем на пользу.
Не?
А закусился я на «нормальная абстракция», «мне норм», «ты просто не понимаешь, абстракция норм». Зря, наверное.
Я думаю, что сайты, о которых говорит автор, должны будут наконец сдохнуть, а он — остаться без работы. То что не смог сделать FrontPage, сделают Wix и Shopify. В этом отношении, кстати, прогресс идёт крайне медленно, разработка конструкторов под типовые задачи до сих пор не развернулась на полную.
Вот дизайнер без привязки к технологии вряд ли вымрет, чувство прекрасного и графики генератором не генерируется. Но пытаться создавать сайты под ключ, по старинке, и зарабатывать только этим уже КМК маловероятно.
Чем отличается функционал сайта? Можете конкретно написать? Я не подкалываю, я честно не вижу никаких отличий в задачах сайта в 2000м и в 2018м. Расскажете?
Как минимум сейчас ему нужно уметь адаптироваться под 100500 различных экранов с разными dpi, физическими размерами и способами взаимодействия.
Та же «готовая телеметрия от Google» требует не всегда тривиальной настройки. Адаптивный дизайн довольно часто не просто «две резиновые верстки» (и не две, а три: десктоп с мышкой, планшет под пальцы, телефон), а повторное использование модели данных -> тоже фреймворк, тоже требующий навыков.
Метрика в том функционале, который существует в Google чрезмерно раздута лишним, бесполезным функционалом. Да и в Яндексе много чего ненужного. На самом деле большинство данных неточные и даже искажённые (проверял).
Речь о библиотеках и фреймворках шла в контексте основного функционала сайта, а не метрики. Элементарные счётчики можно самим написать. Яндексом пользуемся только для благосклонного отношения со стороны этой поисковой системы, на функционал сайта он ни как не влияет.
Адаптивный дизайн… ну вот делаем фиксированный дизайн с размерами до 1 пикселя, а современные планшеты и смартфоны сами его подгоняют под экран пользователя. То есть разработчики браузеров избавили нас от необходимости адаптивного дизайна. Остаётся только две версии: десктопная (1000px ширина сайта) и мобильная (процентные размеры). Еще версия стилей для печати. Всё.
Не надо усложнять простые вещи. Для того, чтобы перевезти десяток кирпичей достаточно тележки. Не надо для этого мастерить карьерный самосвал.
Нет никакой разницы, показываешь ты котиков через HTML3.2 или через нынешний… HTML5+ с shadow DOM и тыщей скриптов для аналитики.
И для этого вовсе не нужны всё новые и новые библиотеки и фреймворки. Необходимо только знать html, php, js на базовом уровне, чего (к сожалению) нет у нарождающегося поколения веб-мастеров (дизайнеров, верстальщиков, программистов и т.д.). Вместо того, чтобы зафиксировать объект css свойством position человек пишет более 2000 сторок кода на ява скрипте! Обычная страничка с текстом содержит свыше 20 контейнеров и у каждому присвоен свой собственный класс! Это реальные примеры.
Это не эволюция, а деградация. Когда вымрут первые разработчики фреймворков, большинство новомодных проектов перестанет существовать, потому что не останется специалистов разбирающихся в первоначальном коде.
Меня не удивляет количество комментариев, которые говорят больше о комплексах авторов, чем о тексте. Я видел много раз, как под тяжестью собственной популярности погибают профессиональные онлайн сообщества.
Меня не удивляет отсутствие мнения тех, кто понимает, но молчит. Дело не только в карме, просто не колышет уже давно. В детстве мы называли это "олимпийским спокойствием".
Давайте я попробую объяснить — автор статьи (не перевода) говорит не о жестокости прогресса. Он сетует (не должен был бы, но его право) на то, что прогресс размывает ценность тех качеств, на которых он же сам и базируется. Это нормально, на самом деле и неизбежно.
Я понимаю, отчего это тяжело. Первые сайты я делал 22 или 23 года назад (не помню точно). Тогда же и чуть раньше мы разбирались в том, как работают процессоры, сети, дизайн, менеджмент. Тогда же воевали в первых для нас онлайн сообществах (usenet и FIDO, ага).
Проходил все эти круги во всех этих областях несколько раз. Несколько раз видел, как то, что я сделал и всех напугало становится трендом через пятилетку. Много раз видел, как в "простоте" терялся изначальный смысл. В любой области — я до сих пор могу, иногда, поправить современного "тренера", потому что он запомнил механически и физически не может заметить своей ошибки, то, что для него аббревиатура — для меня память победы, понимания.
Так вот тем, кто обзывает автора — он прошел круги 5 раз. Пройдет и в шестой. Эффективнее и быстрее многих вас, будьте уверены. Я это знаю.
Постоянно воспитывая новые команды (люблю это дело и буду продолжать), глядя на то, как тяжело новичкам (девушке, которая всего год в теме) добиться настоящих результатов, подсказывая им, как близко они, на самом деле, ходят — я все время понимаю, как повезло нам (не ровесникам — 99% из них вылетели уже на первом витке). Насколько сложнее стать профессионалом сейчас. Сколько бессмысленного приходится запоминать (да, иногда злит, но привыкаешь), как тяжело это будет забыть и запомнить новое в третий, например, раз.
Большинство не узнает. Большинство вылетит как раз на третьем витке. (((
Так вот тем, кто обзывает автора — он прошел круги 5 раз. Пройдет и в шестой. Эффективнее и быстрее многих вас, будьте уверены. Я это знаю.
Если бы он действительно смог, то у нас была бы статья вроде "Объясняем современный Javascript динозавру". Полезные советы от того кто "смог и сможет еще".
Большинство не узнает. Большинство вылетит как раз на третьем витке.
Но судя по тексту статьи, вылетает как раз автор. Никакой полезной информации, одно нытьё и отсутствие актуальных знаний матчасти.
Из перевода, как раз, не очень понятно, что девушка подошла не просто так, а после его лекции. Поэтому, если он себя и ставит на одну ступень — то это, конечно, немного позерство. Ну, а не чувствовать себя профессионалом и всезнающим — хороший признак профессионализма, в любом случае.
Вообще, мой комментарий был об опасности и ненужности строить свое мироощущение на оценках другого человека (я не плох, пока есть хуже меня). Тем более, что бессмысленно судить о человеке, не имея шанса узнать его лично, а лишь по статьям в интернете.
Поясню — для меня, например, заметный мотив данной статьи — "видимость" автора, PR. Но значимый вывод, подтверждаемый собственным опытом (а это главный фокусировщик внимания), который я лично делаю — запрос снова растет, скоро должен произойти новый "соскок" технологии вверх. Создание вебстраниц должно полностью вернуться к дизайнерам (не только графическим, но, в первую очередь, информационным).
Отчасти это уже произошло — в последние 5 лет я с облегчением посылаю подавляющее большинство обращающихся в сторону конструкторов сайтов. Я не нужен, это отлично! И тенденция будет продолжаться. Но для этого технология должна упроститься (очиститься), как это происходит всегда. Вот мой вывод — дизайнер хочет правильных и чистых инструментов, значит будут. Тем более, что как и он — я уже много лет вижу куда оно может и развивается.
Я не стал отвечать на предыдущий комментарий от justboris, кстати, чтобы не дискутировать и не задавать глупых вопросов, почему кто-то нам что-то должен. Это и есть пример той оценки, о которой говорил. Если сама статья не интересна, то, как любил повторять мой знакомый: "проходя мимо… проходите мимо".
Но вот в комментариях к замечательному переводу статьи, который он публиковал (такая деятельность — отличный повод уважать человека и его усилия), есть та же мысль. Для общего прогресса важно не только то, как быстро или глубоко лично Вы овладеваете максимальным количеством навыков (не успеете), важно не то, какая технология самая религиозно верная (отвечая другому комментарию от zvulon — нет, VueJS тут ненадолго) — в развитии любой системы с интерфейсом к человеку важны не только ее "фичи", но и простота.
Просто потому, что главный контроллер и потребитель, человек, существенно ограничен в развитии своего уровня восприятия сложности. По сравнению с технологиями — мы стоим на месте. Потому технологии и эволюционируют в кошочек, начинаясь как очень быстрые (фиг догонишь) и борзые (фиг удержишь) проекты.
Да, кстати, а факт того, что у новичка такие же шансы вскочить на поезд, как и у старожила — это то, что я всегда привожу как самый положительный мотив остаться в нашей области всем начинающим — пока еще можно вскочить быстро, замечательно!
Замечательный комментарий, но… почему "пока еще можно"? Это утверждение относительно мира или все же конкретной личности существующей во времени? Разве знания приходят от людей? Если не от них, то как они могут знать (пока еще можно), что задумал Всевышний?
Нет-нет, это абсолютно практическое замечание, ключевые слова "быстро вскочить".
Снова приведу личный пример — мой отец был ученым физиком, мать хирург, брат летчик. Ни в одном из этих случаев вас не подпустят к настоящему "телу" без долгой подготовки и испытаний. Пока наша область во многом любительская, пусть даже местами такая же сложная, как ранние полеты энтузиастов, пока она не зарегулирована (несмотря на все более возрастающее влияние на ежедневную жизнь огромного числа людей) и не устоялась — тут рады каждому здравомыслящему и заинтересованному лбу.
Вы отлично описали то, о чём не пишут в комментариях, обычно. Не переживайте, рейтинг статьи говорит о том, что людей с олимпийским спокойствием пока достаточно много.
Вобщем-то это не ново. Давайте посмотрим кто еще может жаловаться в такой же манере
— Разработчики схем: раньше все было большое и можно было понять что на схеме, теперь микросхемы закрыты и понять что внутри нельзя
— Таксисты: раньше знания города ценились, теперь есть навигаторы. (да и вообще скоро роботы водить будут)
— Системные администраторы: раньше все было просто, теперь докеры виртуалки и infrastructure as a code.
По существу:
— то что раньше весь код сайта был понятен из браузера просто недоработка раннего веба,
точно также как скачивая jpeg вы не получаете оригинальный pdf со слоями вас же устраивает.
— что код скомпилированой программы невозможно посмотреть (без определенных телодвижений) вас не беспокоит?
Этот путь прошли процессоры ( REAL mode, Protected Mode)
Операционные системы
Языки программирования
Теперь веб.
Но посмотрите linux устоялся более менее
язык C живее всех живых
HTML почти такой какой был
Автору посоветую vue.js надеюсь он станет долгим стандартом.
На мой взгляд динамикой веба надо либо наслаждаться,
либо уходить туда где устоялось
мне тоже сложно с этими дикими изменениями (даже не за 20 а за 4 года)
вернулся в бекенд, там спокойнее.
А дизайн он же в фотошопе делается — может ему туда?
тк в скором будущем сайты резать из макетов будут роботы.
К моему личному счастью. )
Я освоил Си сто лет назад… и остановился перед С++. Попытка чтения Страуструпа и все эти cin, cout, конструкторы, деструкторы вызывали вопрос — а зачем это всё нужно? Можно же по рабоче-крестьянски — на чистом С. Впрочем научному сотруднику (т.е. мне) приходится писать программы только вида загрузить из файла, считать по формулам, выгрузить в файл. Т.е. плюшки плюс-плюса для меня избыточны. Возможно. А может и нет.
Если мне нужна программа с интерфейсом — есть BC++ 2002 года. ))) Можно из компонентов всё сложить и туда же сунуть чисто сишный код. Иногда делается интересно — чего ж такого в нынешних языках программирования. Читаю, но увы — у меня нет задач где я бы мог их эффективно применить, и поэтому мне трудно понять их плюсы-минусы.
Динозавр смахивает скупую динозаврью слезу.
Про таксистов вы очень хороший пример привели!
Как раз вчера меня такой "новый таксист" Uber, оснащённый навигатором, повез на улицу с нужным названием, но не в Москве, а в Алтайском крае. Время в пути 2 дня его не смутило.
А хороший таксист, знающий город, везёт быстрее предсказания навигатора и объезжает подборки теми путями, который навигатор и не предлагает. Жаль, таких мало осталось.
Ошибку с Алтайском краем адекватный человек может совершить только раз в жизни, а вот блуждать без навигатора можно каждый день.
Как всё-таки приятно прочитать хороший перевод. Спасибо.
Я думаю, что у многих людей, кто в программировании длительное время, значимое по отношению к прожитой жизни, эта статья вызвала отклик. Я помню, как программируя под z80, я упивался тем, что вот он мой маленький мирок, изученный почти полностью и я тут могу все. Сейчас же знаний столько, что их не объять ни измерить толком и эту данность необходимо принять. Все знать невозможно — раньше говорили начитанные люди, а сейчас это можно сделать слоганом на главной странице GitHub. )
Автор не учёл несколько факторов:
- Благодаря сложности и скорости изменений он продаёт свои лендинги по цене в пять раз большей, чем должен бы. И все берут. Веб-программисты получают больше чем инженеры-механики, при этом времени на их подготовку уходит в три-четыре раза меньше.
- вместе со сложностью появляются новые требования. Не было у него 15 лет назад требования отзывчивого дизайна, например.
все нововведения сначала игнорят это всё ведь интернет уже у всех хороший да и компы быстрые, а в следующей версии или с новой тулзой пытаются решить эту проблему и так по кругу, и самое плохое что первые попытки делать по новому всегда говно, а если начать изучать когда уже получился отличный инструмент то их уже может быть несколько похожих
P.S. Если только это не дедлайн;)
Большинство новых технологий просто не нужны дизайнеру.
Они появились-то только потому, что создание сайта из процесса "дизайн-верстка" превратилось в процесс "разработки". И сайты теперь делать не веб-дизайнеры, а разработчики, которые по процессу мышления намного ближе к программистам.
Дизайнеры же за это время мутировали в нечто элитное, не всегда понимающее, что такое "размер файла", например.
То есть если каждый разработчики 2000х был сплавом технологий, посередине между "гуманитарным" дизайном и "инженерным"программированием, то сейчас это всё разделено между разными людьми с более узкими специализациями.
Отсюда и непонимание, почему мы не хотим все эти "npm run" и не закатываем восторженно глаза "ооо, Фigma!!"
К сожалению, эти люди не понимают важной вещи — узкая специализация это зачастую очень плохо:
у узких специалистов нет видения проекта целиком, сейчас для этого опять же отдельные специализации
количество инструментов и технологий сильно раздувается, большинство из них избыточны для обычного сайта.
технологии становятся модой, используются "сырыми", зато новыми, меняются.
узкие специалисты не могут разрабатывать новые инструменты и развиваться вертикально
- узкая специализация имеет свойство вырождаться, становиться все более узкой
На самом деле, с 2000 года в вебе не появилось никаких новых задач с точки зрения дизайна. Только снежинки теперь надо уметь заверстать в спрайты и svg, отрендерить через canvas, и адаптировать всю эту дрянь к зоопарку экранов. Потому что мода такая.
Ничего, ещё несколько лет — и мы получим сначала GUI для всего, чему нужна сейчас командная строка, умрет необходимость настраивать инструменты перед использованием. Потом увидим интеграцию отдельных утилит в Macromedia Dreamweaver 2030.
И снова все встанет на свои места, когда сайт может нормально сделать один человек, а не программер, верстальщик, администратор, разработчик бэкенда, дизайнер интерфейса, дизайнер анимации, графический дизайнер и три менеджера.
Вот все эти новые фичи ведь не отменяют старые, я так понимаю, что груз обратной совместимости так и продолжает расти. А это значит, что и браузерные движки становятся все сложнее и сложнее. При этом все это стоит на фундаменте, который вообще не был предназначен для того, чем веб сейчас является.
Итого я думаю, что где-то впереди маячит комбинаторный взрыв и серьезный пересмотр всей архитектуры веба.
Да что такого нового появилось?
Новостные сайты — те же
Банковским — ничего нового не надо
Сайт автодилера — тоже ничего нового
Интернет-магазин — ничего нового
Появились соцсети, у них свои задачи и проблемы, и весь новый стек на самом деле заточен под них. А остальным все это и не надо.
Героически решаем проблемы, созданные собой же.
Пальцы можно шире расставлять.
Это не потому, что они на гребне прогресса или технически крутые.
Это потому, что они не могут сделать просто.
Но разве это не должно быть стимулом узнавать что-то новое и делать что-то лучше/качественнее?
Если авторов и их клиентов всё устраивает, то по факту качество работ устраивает стороны. Они находятся на одном уровне развития. То есть, лучшее качество или максимальное развитие уже между их отношениями существует прямо здесь и сейчас до тех пор, пока кто-то из сторон не сделает иной вывод, что мы "на дне". Но если не сделать такой вывод, то стимул к росту не появляется, и он не нужен, так как — итак всё хорошо. )))
Нет такого понимания, во всяком случае у меня, что такое истинное делать что-то лучше/качественнее. Это переменная величина, которая меняется относительно наблюдателя, так как через время задаются новые требования, новые планки между участниками процессов, будь это в спорте или науке. Причем это происходит как на низшем уровне развития, так и на высшем, где ставятся мировые рекорды.
Качество — это только личный уровень развития. Кто-то вообще не понимает эти ваши интернеты, айфоны всякие. Искренне не понимают и не могут их оценить. То есть, ваше недоумение, о том, что это не дотягивает до каких-то высот их вообще не это волнует.
Также, это справедливо относительно личностного роста, заботе о здоровье, других сфер бытия. Тут нет планки — вот оно счастье, вот она та самая высота! Нету её. Планка меняется. Достигнув порога развития наступает разочарование которое способствует дальнейшему шагу по лестнице выше. Сегодня это качество, завтра это уже не устраивает кого-то. И не все могут подтянуться на одну какую-то планку качества. Это невозможно, чтобы первоклассник сразу познал азы линейной алгебры )) На мой взгляд существует множество планок качества одновременно в пространстве, поэтому когда нибудь, те ребята из приведенной ссылки выше осознают и подтянутся выше, но принудительно за уши вытащить всех на некий уровень на мой взгляд не получится )) Будет много крови ))
С вебдева я начал 20 лет назад, к нему внезапно вернулся и сейчас. За эти годы периодически тоже доводилось сталкиваться, так что рука на пульсе держалась. И я категорически не согласен с автором статьи — сейчас всё на порядок легче. Интернет забит под завязку готовыми темплетами, сниппетами, примерами, так что по сути вебдев превратился в детский конструктор. И даже заказчики изменились к лучшему (да-да).
В начале нулевых конечно время было золотым, заказчики спокойно платили по $1K за десятистраничные статичные сайты без всяких там корзин, скриптов интеграции оплаты и CMS, а потом ещё и платили за каждое обновление. Но при этом были настолько далеки от интернета, что переубедить в неправоте их требований было просто невозможно. Так что если заказчик хотел получить пылающую огнём золотую кнопку и мерцающий заголовок, то он его получал.
Сегодня ситуация изменилась. Конечно всё ещё встречаются индивиды из ролика про красные линии, но в целом работать с заказчиками стало легче — требования в основном звучат к техническим решениям, а не к эстетическим. И то уже можно спокойно убедить заказчика в том, что ему больше не надо поддерживать сайт для браузеров каменного века, как это было в переломные годы «войны стандартов» начала середины 10-ых. Можно вполне спокойно объяснить человеку, что пользователь с деревянными счётами на древнем компьютере вряд ли его потенциальный заказчик, так что пусть себе гуляет по просторам и не жрёт попусту трафик.
Хотя может я просто немного лукавлю, может просто мне в какой-то степени больше везёт с тем, что ко мне не обращаются такие деревянные заказчики.
После минимизации и компиляции в смысл могу лишь сказать: да, ребята. Что-то мы не молодеем.
P.S. 15 лет в webдеве уже оказывается.
P.P.S. Ужас то какой
<frameset>Ну и пока человек пишет по делу — все ок, а как только начинает размышлять — начинается поток сознания, который читать сложно.
Сейчас одна технология, потом появляется вторая, — вбухивается куча денег в её раскрутку. Она становится модной. Хотя, по сути, может просто являться разновидностью уже существующих. И не обязательно будет лучше.
Потом снова появляется что-то «новое» которое вытесняет «старое». И так до бесконечности.
Реальных прорывов в web-разработке давно нет, — есть бесконечная череда смены фремворков и технологий которые являют собой смену шила на мыло
Программа сборщик ставится один раз и тихо собирает до переустановки ОС.
Тоже самое и некоторыми прочими штуками типа pug
А вот «контейнерное» производство да, тяжело :) Чтобы проект развернуть нужно убить кучу времени, а потом это на сайт выгрузить проблема
А самое интересное, что средний уровень компьютерной грамотности пользователей упал по сравнению с тем, что было 15-20 лет назад. Тогда использовать ПК могли избранные. А сейчас он у каждой обезьяны. Новые студии разработки, дополнительные уровни абстракции призваны понизить порог вхождения, но на деле приводят к спагетти-коду потому, что системных знаний у молодых специалистов нет («зачем это учить? Оно не актуально!»). Вот и приходим к тому, что бОльшей вычислительной мощностью мы компенсируем неоптимально написанный софт. Более широкими каналами и многоуровневым кэшированием + CDN мы компенсируем раздутые сайты которые без всего этого обычному пользователю просто недоступны. Лично я (считайте садистом — дело ваше) разработчиков дрючу до тех пор, пока их проект не откроется у меня на мобиле с принудительным ограничением полосы до уровня EDGE за приемлемое время. Нет? Считаешь, что сейчас 21 век и у всех в кармане смарт с 4G и можно ничего не оптимизировать? Значит хреновый ты программист. Иди книжки читать. Желательно древние и не актуальные.
Всё простое опять стало сложным